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" <mbasni...@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.
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
