Open Stack

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?

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?

If it's a "true" clone, User X should be isolated from a change in
defaults, no?

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.

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)?


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>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev