[Rdo-list] [OFI] ER diagram
by Petr Chalupa
Hi,
I wanted to understand the current model better so I've generated ER
diagram from Scott's PR https://github.com/theforeman/staypuft/pull/12.
see http://projects.theforeman.org/projects/ofi/wiki/DB_Model
How to: add `gem 'rails-erd'` and execute `rake erd
only='Staypuft::Deployment,Staypuft::DeploymentHostgroup,Staypuft::HostgroupRole,Staypuft::Layout,Staypuft::LayoutRole,Staypuft::Role,Staypuft::RoleClass,Staypuft::RoleService,Staypuft::Service,Staypuft::ServiceClass,Hostgroup,Puppetclass'
attributes='foreign_keys,content' orientation=vertical filetype=dot`
then `dot -Tsvg erd.dot > erd.svg`
Petr
11 years, 1 month
[Rdo-list] Weekly IRC RDO community meeting 2014-03-11
by Rich Bowen
Thanks to everyone who participated in the IRC meeting this morning. A reminder: we do this every Tuesday morning at 9am Eastern US time.
Minutes: http://meetbot.fedoraproject.org/rdo/2014-03-11/rdo.2014-03-11-13.02.html
Minutes (text): http://meetbot.fedoraproject.org/rdo/2014-03-11/rdo.2014-03-11-13.02.txt
Log: http://meetbot.fedoraproject.org/rdo/2014-03-11/rdo.2014-03-11-13.02.log....
=====================
#rdo: RDO weekly sync
=====================
Meeting started by mburned at 13:02:07 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/rdo/2014-03-11/rdo.2014-03-11-13.02.log....
.
Meeting summary
---------------
* LINK: https://etherpad.openstack.org/p/rdo_community_manager_sync
(rbowen, 13:02:24)
* Test Day (rbowen, 13:03:17)
* Test day stuff in the Fedora Test Day app for easier test reporting
(rbowen, 13:04:32)
* LINK:
http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=16
(rbowen, 13:04:34)
* metadata can be edited there too (rbowen, 13:04:43)
* LINK: https://fedoraproject.org/wiki/Test_Day:2014-03-19_RDOMetadata
(rbowen, 13:04:52)
* test day scheduled for March 10-20 (mburned, 13:09:42)
* rbowen has added a lot of test cases to the test day app (mburned,
13:10:40)
* some cleanup still needed (consistent naming, consistent order for
different OSes, etc) (mburned, 13:11:01)
* some need some additional content (mburned, 13:11:08)
* some packages for milestone 3 exist already for rawhide/f21
(mburned, 13:11:54)
* EPEL-7 is WIP (mburned, 13:12:26)
* AGREED: we should concentrate on epel7/epel6/f20 in that order
(fedora rawhide not a priority at this time) (mburned, 13:16:43)
* ACTION: mburns to produce icehouse livecds as soon as packages are
ready (mburned, 13:18:35)
* ACTION: rbowen to send reminders of the test day (mburned,
13:19:10)
* Hangout (mburned, 13:21:00)
* next hangout set for March 27 (mburned, 13:21:13)
* topic is Marconi, host is flaper87 (mburned, 13:21:29)
* LINK: https://plus.google.com/events/ckjhm8rggnqvrnspftna845kubk
(rbowen, 13:21:49)
* April Newsletter (rbowen, 13:23:22)
* LINK: https://etherpad.openstack.org/p/rdo_apr_2014_newsletter
(mburned, 13:23:34)
* Looking for topics if there's anything you want to say in that.
(rbowen, 13:23:34)
* Engineer interviews (mburned, 13:24:35)
* interview with ohadlevy should be posted later today (mburned,
13:24:50)
* other interviews in the works (mburned, 13:25:05)
* if interested, please contact rbowen (mburned, 13:25:17)
* Upcoming Events (rbowen, 13:26:11)
* April: RH Summit -- booth (mburned, 13:26:24)
* mburns will be in attendance (mburned, 13:26:35)
* multiple demos lined up (mburned, 13:26:51)
* OpenStack summit in May (mburned, 13:27:44)
* RDO will have a booth (mburned, 13:28:02)
* rbowen is a track chair for "Getting Started" (mburned, 13:28:14)
* will likely reuse some of the same demos from RH Summit at Openstack
Summit (mburned, 13:28:46)
* LinuxCon Japan also in May (mburned, 13:29:13)
* RDO will have a booth/table (mburned, 13:29:20)
* rbowen and red_trela will be in attendance at the booth (mburned,
13:29:47)
* a CentOS dojo will likely also happen and LinuxCon Japan (mburned,
13:30:39)
* Bug triage (mburned, 13:31:35)
* 16 open bugs as of a few hours ago (mburned, 13:32:29)
* 3 are security related, being handled by security experts (mburned,
13:34:26)
* other bugs going through normal triage (mburned, 13:35:59)
* Forum (mburned, 13:36:13)
* 38 open questions (mburned, 13:37:13)
* lot of work done last week answering and closing abandoned questions
(mburned, 13:37:50)
* closed about 20 last week (mburned, 13:37:59)
* approx 20 more opened during that time (mburned, 13:38:09)
* need some better stat tracking (mburned, 13:38:18)
* rbowen to investigate what else we can track (mburned, 13:39:53)
* other topics (mburned, 13:39:58)
Meeting ended at 13:40:31 UTC.
Action Items
------------
* mburns to produce icehouse livecds as soon as packages are ready
* rbowen to send reminders of the test day
Action Items, by person
-----------------------
* rbowen
* rbowen to send reminders of the test day
* **UNASSIGNED**
* mburns to produce icehouse livecds as soon as packages are ready
People Present (lines said)
---------------------------
* mburned (67)
* rbowen (56)
* kashyap (29)
* zodbot (6)
* red_trela (4)
* morazi (3)
* flaper87 (2)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Rich Bowen - rbowen(a)redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/
11 years, 1 month
[Rdo-list] About multi node deployment set up.
by BYEONG-GI KIM
Hi.
I'm getting started learning OpenStack, and decided to install it by
following multi node deployment.
I'm considering connecting the OpenStack with OpenFlow Controller, but I
was barely able to find related information for it.
Actually, I could not find any doccumentation or guide of Packstack
installation for multi node set up. Could anybody recommend me some
references for the installation?
Thanks in advance.
Best regards
Byeong-Gi Kim
11 years, 1 month
[Rdo-list] [OFI] data model reusing Foreman's AR models
by Petr Chalupa
Hi guys,
After yesterdays IRC talk we (Marek and Petr) started to look at OFI
models design. Unfortunately I haven't received any email with link to
that so we jumped in quite late. Anyway we've tried to decode as much
information as possible about staypuft model from etherpad [1]. Here's
ER diagram we were able to construct from those information.
<see model A>
Our main concern is that we are recreating models that are already
present in Foreman. We understand Astapor issue that it was very hard
for user understand all Foreman specifics so now we try to do it
Openstack way and use Foreman as provisioning and configuration backend.
However we still think that we should built on top of existing and
tested models and just create a new easy to use and intuitive UI.
inecas: +1 on reusing the Foreman model: the foreman model seems to have
most of the things to support what is required, building something
custom means:
* duplication of what is already there
* writing throw-away code, that nobody except the OFI itself will
use: the power of Foreman is in the community: building it on the
Foreman model (and enhancing it when needed) means the same work will be
used outside of OFI with all the benefits that come with it
I would like to avoid doing that, especially when it doesn't seem that
much work to use the existing model
So what we propose is following DB schema:
<see model B>
Each deployment is contained under an Organization for separation. Which
also means that same Foreman instance could be normally used when user
leaves the wizard.
Left side is ER model right side is representing relationships between
Hostgroups instances. The one called 'Deploy' is lets say an common
parent Hostgroup for all other hostgroups in the deployment. 'Deploy'
allows sharing of configuration to the other hostgroups. Other
hostgroups are representing Roles (like controller, compute, etc.)
Basically we'd map:
OpenStackDeployment -> Organization
OpenStackLayout -> organization's parameter
OpenStackRole -> Hostgroup (*)
OpenStackService -> N/A (at least for April)
OpenStackSeviceParam -> LookupKey (aka Smart Variable)
OpenStackDeployService -> N/A
OpenStackDeployServiceParam -> LookupKey (aka Smart Variable Value)
OpenStackDeployRole -> assignment of Host to Hostgroup (*)
At the moment, the only thing that's missing is that Foreman 1.4.1 does
not allow us to set one hostgroup to be used in two parent hostgroups
(one service in two roles). This is going to change in 1.5 when
ConfigRoles will be merged. We suppose to use quickstack modules for
April version so we still have just puppet classes on role level (not on
service level) and therefore we won't allow user to customize services
in roles. Since we need this post April we can stick with current
Foreman model. Later we could either back-port ConfigRoles or base on
newer Foreman.
Benefits we see by reusing foreman models
+ we save work on need to model everything again
+ we save work on writing logic that will copy all (Deploy)Service/Role
(Deploy)ServiceParameters values to Hostgroup/LookupKey/LookupValue
+ ability to turn off the wizard plugin (something like removing the
training wheels) and keeping the Foreman instance still usable
Cons
- people may spend some time to better understand existing Foreman code
inecas: that should be under Pros, and by people I don't mean the actual
users of OFI, but its developers
Potential concerns we understood from yesterday
1. too foreman specific
2. need of doing some business logic before Deploy is triggered
3. writing some easy UI around existing models is bigger pain that
creating new objects from scratch
4. to able to delay host provisioning until whole deployment is configured
Our answers to those
1. this is just about building new UI that we'll need anyway and
re-labeling (we already have Smart Variable which in fact is LookupKey
model), we could use STI or composition to modify Foreman objects
behavior if they are too restricting
2. It's easy to extend Dynflow process with a plugin injecting any
additional steps into the deployment process.
3. if this really becomes a problem we could always wrap existing models
by some other classes
4. If the hosts are kept in unmanaged state nothing gets applied to
them. Until orchestration takes over and switches them to managed state.
Are we sure that we need to allow user to prepare changes to an
existing-deployment-configuration and then apply them all at the same
time in April? I think we can postpone this for later and keep Foreman's
behavior for now that changes made to a hostgroup are immediately applied.
[1]: http://etherpad.corp.redhat.com/staypuft-model-design-notes
Looking forward to your feedback Petr and Marek.
11 years, 1 month
Re: [Rdo-list] [OFI] data model reusing Foreman's AR models
by Marek Hulan
Hello Scott,
we appreciate reviewing our design and your feedback. I'm sending answers below in text.
>> Anyway, here are the concerns -- let me know what you think:
> Replying to my own message with some quick ideas on how we would might
> them:
>>
>> 1) I'm not seeing any distinction between default objs (i.e.
>> OpenStackRole) and
>> per-deployment values (OpenStackDeployRole) -- we'd need to solve this
>> before allowing multiple deployments. In my model the initial set
>> of default
>> roles and values
> Create a "Default Deployment Organization" in seeds.rb and "default"
> HostGroups for each role.
> When creating an actual deployment, copy these over.
Yes we are thinking the same. Having template hostgroups and clone them to create an actual deplyment of OpenStack.
>> 2) What are the consequences of no services in April? This also means
>> we will have no per-service params, so there are UI implications
>> (i.e. instead of breaking down params by service in each role, we
>> have one list of per-role settings)
> no answer here, as it's a requirements question, not an impl one.
Out thinking is to add only what is realy needed for April. Roles <-> Services relation is given by Astapor modules so we figured we do not need model for them yet. Parameters can be organized by a Ruby hash using metaprograming no need fo actual AR model. This can be improved later as soon as we need it and this approach would not limit us doing that.
>> 3) Will LookupKey allow us to set other metadata (ui widget type,
>> etc -- or would we need to extend this model with a shadow table type
>> model -- i.e. OpenStackLookupKey with a 1-to-1 relationship with the
>> foreman one to include extra elements we need for UI generation.
> See workaround in the suggestion itself: Create OpenstackLookupKey model
> with link to foreman LookupKey and extra metadata.
LookupKeys already have most of these. They have type (so we can create widget based on that), default value, even validations (only regexp and list of possible values) and description (inline help). We could just add visibility_condition maybe few others. It's easy to add functionality to models in plugins using concerns (mixins), we already have some plugins doing this. Or if it's too much changes we can always use STI or wrap it by another object (composition) or as you suggest add some new object with 1-to-1 mapping.
Also since Foreman itself would benefit from loading more of these metadata from puppet modules we could share the effort here. But for first version I think it's ok to have all of them in seed.
>> 4) The new suggestion layout seems to have some issues:
>> OrganizationParameter makes it seem like it belongs to an
>> organization. Layout is a general model/object, which exists from
OrganizationParameter mentioned on the picture is existing class in Foreman, it's a child of Parameter and it is used to set global parameters for puppet classes. Each organization has it's parameters specific to the given OS deployment. Also if parameter is set here (like global password for all services according to wireframes), Foreman allows us to reuse this value in LookupKey matcher which means you can set value based on this organization parameter. You can also set these values based on organization parameters. Btw same works for default values.
>> seed data load before the first org is created. It's mapped to a
>> list of OpenStackRoles/HostGroups in seeds.rb, so
Since for April we support only HA and noHA which are not that much different from each other we are thinking to add a model for Layout later and for now just use predefined host-groups and copy them.
>> a) it needs to be able to be created before an Organization (and be
>> associated with more than one post-April)
>> b) we need to be able to associate Layouts/OrganizationParameters
>> with OpenStackRoles/HostGroups in a many-to-many manner in seeds.rb
We are afraid that this can only leads to problems when the layout definitions or its parts are shared between deployments. If something changes other deplyments may be affected accidentally. So just copying the template hostgroup is faster (no additional models) and safer.
Feel free to ask any further question, we'll be happy for any (even negative) feedback.
Thank you,
--
Marek
11 years, 1 month
