Open Stack

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?

#2 - Should a user be able to enumerate the entire actualized/realized
        set of values for a configuration-group, or just the overrides?

#3 - Should a user be able to apply a different configuration-group on
        a master, than say, a slave?

#4 - If a user creates a new configuration-group with values equal to
        that of the default configuration-group, what is the expected
        behavior?

#5 - For GET /configuration/parameters, where is the list of supported
        parameters and their metadata sourced from?

#6 - Should a user be able to reset a configuration-group to the
        current default configuration-group?

#7 - Is a new configuration-group a clone of the then current default
        configuration-group with various changes, or will inheritence be
        utilized?

#8 - How should the state of pending configuration-group changes be
        reflected in GET /instances/:id ? How will this state be
        persisted?

#9 - Reminder: Once multiple service-types and versions are supported,
        the configuration-group will need a service-type field.

#10 - Should dynamic values (via functions and operators) in
          configuration-groups be supported?
          Example: innodb_buffer_pool_size = 150 * flavor['ram']/512

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?



On 10/1/13 7:55 PM, "Michael Basnight" <mbasnight at gmail.com> wrote:

>On Oct 1, 2013, at 7:19 PM, Vipul Sabhaya wrote:
>> 
>> So from this API, I see that a configuration is a standalone resource
>>that could be applied to N number of instances.  It's not clear to me
>>what the API is for 'applying' a configuration to an existing instance.
>
>https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.2
>8PUT.29
>
>> Also if we change a single item in a given configuration, does that
>>change propagate to all instances that configuration belongs to?
>
>Thats a good question. Maybe PATCH'ing a configuration is not a good
>thing. We either have 1) drift between an attached config on an instance
>vs the template, or 2) a confusing situation where we are potentially
>updating configurations on running instances. Another possibility is that
>a PATCH would in effect, clone the existing template, if its in use,
>giving it a new UUID with the updated parameters. But im not sure i like
>that approach eitherŠ Its really not a PATCH at that point anyway id
>think.
>
>Blueprint designers, im looking to you for clarity.
>
>> What about making 'configuration' a sub-resource of /instances?
>> 
>> Unless we think configurations will be common amongst instances for a
>>given tenant, it may not make sense to make them high level resources.
>
>As in /instances/configurations, or /instances/{id}/configurations ? I do
>see commonality between a configuration and a bunch of instances, such
>that a configuration is not unique to a single instance. I can see a
>reseller having a tweaked out "works with _insert your favorite CMS
>here_" template applied to all the instances they provision.
>