Open Stack

inline.


On Wed, Oct 2, 2013 at 1:03 PM, McReynolds, Auston <amcreynolds at ebay.com>wrote:

> Awesome! I only have one follow-up question:
>
> Regarding #6 & #7, how will the clone behavior work given that the
> defaults are hydrated by a non-versioned jinja template?
>
I am not sure i understand "clone behavior" because there is not really a
concept of cloning here. The jinja template is created and passed in the
"prepare call" to the guest to write to the default my.cnf file.

When a configuration-group is removed the instance will return to the
"default" state. This does not exactly act as a clone behavior.


> Scenario Timeline:
>
> T1) Cloud provider begins with the default jinja template, but changes
>        the values for properties 'a' and 'b'. (Template Version #1)
> T2) User X deploys a database instance
> T3) Cloud provider decides to update the existing template by modifying
>        property 'c'. (Template Version #2)
> T4) User Z deploys a database instance
>
> I think it goes without saying that User Z's instance gets Template
> Version #2 (w/ changes to a & b & c), but does User X?
>
No User X does not get the changes. For User X to get the changes a
maintenance may need to be scheduled.


> If it's a "true" clone, User X should be isolated from a change in
> defaults, no?
>
User X will not see these default changes until a new instance is created.


>
> Come to think about it, this is eerily similar to security-groups:
> administratively, it can be beneficial to share a
> configuration/security-group across multiple instances, but it can
> also be a nightmare. Internally, it's extremely rare that we wish to
> apply a database change to multiple tenants at once, so I'd argue
> at a minimum to support a CONF opt-in for isolation, if not default
> to it.
>
If i understand this correctly my above statement means that its isolated
by default.


>
> On a related note: Will the default template for a service-type be
> represented as a default configuration-group? If so, I imagine it
> can be managed through the API (or MGMT API)?
>
The default template will not be represented as a configuration group.
This could potentially be a good fit but its more of a nice to have type of
feature.


>
>
> From:  Craig Vyvial <cp16net at gmail.com>
> Reply-To:  OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Date:  Wednesday, October 2, 2013 10:06 AM
> To:  OpenStack Development Mailing List <openstack-dev at lists.openstack.org
> >
> Subject:  Re: [openstack-dev] [trove] Configuration API BP
>
>
> I'm glad we both agree on most of these answers.
> :)
>
> On Oct 2, 2013 11:57 AM, "Michael Basnight" <mbasnight at gmail.com> wrote:
>
> On Oct 1, 2013, at 11:20 PM, McReynolds, Auston wrote:
>
> > I have a few questions left unanswered by the blueprint/wiki:
> >
> > #1 - Should the true default configuration-group for a service-type be
> >        customizable by the cloud provider?
>
> Yes
>
> >
> > #2 - Should a user be able to enumerate the entire actualized/realized
> >        set of values for a configuration-group, or just the overrides?
>
> actualized
>
> >
> > #3 - Should a user be able to apply a different configuration-group on
> >        a master, than say, a slave?
>
> Yes
>
> >
> > #4 - If a user creates a new configuration-group with values equal to
> >        that of the default configuration-group, what is the expected
> >        behavior?
>
> Im not sure thats an issue. You will select your config group, and it will
> be the one used. I believe you are talking the difference between the
> "template" thats used to set up values for the instance, and the config
> options that users are allowed to edit.
>  Those are going to be "appended", so to speak, to the existing template.
> Itll be up to the server software to define what order values, if
> duplicated, are read / used.
>
> >
> > #5 - For GET /configuration/parameters, where is the list of supported
> >        parameters and their metadata sourced from?
>
> i believe its a db tableŠ someone may have to correct me there.
>
> >
> > #6 - Should a user be able to reset a configuration-group to the
> >        current default configuration-group?
>
> Yes, assuming we have a "default config group", and im not sure we have a
> concept of that. We have what the install creates, the templated config
> file. Removing the association of your config from the instance will do
> this thought.
>
> >
> > #7 - Is a new configuration-group a clone of the then current default
> >        configuration-group with various changes, or will inheritence be
> >        utilized?
>
> I think clone will be saner for now. But you can edit your group with a
> PATCH, and that will not clone it. See [1] first paragraph.
>
> >
> > #8 - How should the state of pending configuration-group changes be
> >        reflected in GET /instances/:id ? How will this state be
> >        persisted?
>
> You are talking about changes that require a restart i believe. I think
> this falls into the same category as our conversation about minor version
> updates. We can have a pretty generic "restart required" somewhere there.
>
> >
> > #9 - Reminder: Once multiple service-types and versions are supported,
> >        the configuration-group will need a service-type field.
>
> Most def. You will only be able to assign relevant configs to their
> service-types, and the /configuration/parameters will need to be typed too.
>
> >
> > #10 - Should dynamic values (via functions and operators) in
> >          configuration-groups be supported?
> >          Example: innodb_buffer_pool_size = 150 * flavor['ram']/512
>
> Hmmmm. This is quite interesting. But no, not v1. I totally agree w/ the
> nice-to-have. Good idea though, we should add it to the blueprint.
>
> >
> > My Thoughts:
> >
> > #1 - Yes
> > #2 - Actualized
> > #3 - Yes
> > #4 - Depends on whether the approach for configuration-groups is to
> >        clone or to inherit.
> > #5 - ?
> > #6 - Yes
> > #7 - ?
> > #8 - ?
> > #9 - N/A
> > #10 - In the first iteration of this feature I don't think it's an
> >          absolute necessity, but it's definitely a nice-to-have. The
> >          design/implementation should not preclude this from being easily
> >          added in the future.
> >
> > Where "?" == "I'd like to think about it a bit more, but I have a gut
> > feeling"
> >
> > Thoughts?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.html
>  <
> http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.ht
> ml<http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.html>
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131003/82e0ae41/attachment.html>