[Rdo-list] [OFI] data model reusing Foreman's AR models

[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