3:24 p.m.
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
3926
days inactive
3926
days old
0 comments
1 participants
participants (1)
-
Marek Hulan