Open Stack

Craig, thanks for update. I'm going to re-review it tomorrow.

Best regards, Denis Makogon.


2013/11/13 Craig Vyvial <cp16net at gmail.com>

> I have updated the reviews related to configuration groups.
>
> Trove - https://review.openstack.org/#/c/53168/
> Python-TroveClient - https://review.openstack.org/#/c/53169/
>
> Please review at your leisure.
>
> TODOs:
> * add pagination support for configuration on instances
> * mark configuration groups as deleted instead of doing a hard delete in
> the db.
>
>
> Thanks,
> Craig Vyvial
>
>
> On Thu, Oct 3, 2013 at 3:48 PM, Craig Vyvial <cp16net at gmail.com> wrote:
>
>> Oops forgot the link on BP for versioning templates.
>>
>>
>> https://blueprints.launchpad.net/trove/+spec/configuration-templates-versionable
>>
>>
>> On Thu, Oct 3, 2013 at 3:47 PM, Craig Vyvial <cp16net at gmail.com> wrote:
>>
>>> I have been trying to figure out where a call for the "default"
>>> configuration should go. I just finished adding a method to get the
>>> [mysqld] section via an api call but not sure where this should go yet.
>>>
>>> Currently i made it:
>>> GET - /instance/{id}/configuration
>>>
>>> This kinda only half fits in the path here because it doesnt really
>>> describe that this is the "default" configuration on the instance. On the
>>> other hand, it shows that it is coupled to the instance because we need the
>>> instance flavor to give what the current values are in the template applied
>>> to the instance.
>>>
>>> Maybe other options could be:
>>> GET - /instance/{id}/configuration/default
>>> GET - /instance/{id}/defaultconfiguration
>>> GET - /instance/{id}/default-configuration
>>> GET - /configuration/default/instance/{id}
>>>
>>> Suggestions welcome on the path.
>>>
>>> There is some wonkiness showing this information to the user because of
>>> the difference in the values used. [1] This example shows that the template
>>> uses "50M" as a value applied and the configuration-group would apply the
>>> value equivalent to 52428800. I dont think we should worry about this now
>>> but this could lead to confusion by a user. If they are a power-user type
>>> then they might understand compared to a entry level user.
>>>
>>> [1] https://gist.github.com/cp16net/6816691
>>>
>>>
>>>
>>>  On Thu, Oct 3, 2013 at 2:36 PM, McReynolds, Auston <
>>> amcreynolds at ebay.com> wrote:
>>>
>>>> If User X's existing instance is isolated from the change, but there's
>>>> no snapshot/clone/versioning of the current settings on X's instance
>>>> (via the trove database or jinja template), then how will
>>>> GET /configurations/:id return the correct/current settings? Unless
>>>> you're planning on communicating with the guest? There's nothing
>>>> wrong with that approach, it's just not explicitly noted anywhere in
>>>> the blueprint. For some reason I inferred that it would be handled
>>>> like trove security-groups.
>>>>
>>> So this is a great point. There are talks about making the templating
>>> versioned in some form or fashion. ekonetzk(irc) said he would write up a
>>> BP around versioning.
>>>
>>>
>>>>
>>>> On a slightly different note: If the default template will not be
>>>> represented as a default configuration-group from an api standpoint,
>>>> then how will you support the ability for a user to enumerate the list
>>>> of default configuration-group values for a service-type?
>>>> GET /configurations/:id won't be applicable, so will it be
>>>> something like GET /configurations/default?
>>>>
>>> see above paragraph.
>>>
>>>
>>>>
>>>>
>>>>
>>>> From:  Craig Vyvial <cp16net at gmail.com>
>>>> Reply-To:  OpenStack Development Mailing List
>>>> <openstack-dev at lists.openstack.org>
>>>> Date:  Thursday, October 3, 2013 11:17 AM
>>>> To:  OpenStack Development Mailing List <
>>>> openstack-dev at lists.openstack.org>
>>>> Subject:  Re: [openstack-dev] [trove] Configuration API BP
>>>>
>>>>
>>>> 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>
>>>> <
>>>> http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.htm
>>>> l>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20131113/4c583918/attachment.html>