Open Stack

These are some good q's.
responses inline


On Wed, Oct 2, 2013 at 1:20 AM, McReynolds, Auston <amcreynolds at ebay.com>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?
>
The true default configuration group should be customized by a provider.
This can be done via the jinja templates that are currently used.


>
> #2 - Should a user be able to enumerate the entire actualized/realized
>         set of values for a configuration-group, or just the overrides?
>
The user should be able to see what configurations they have overridden
from the defaults. The user should be able to see the defaults by querying
the db.


>
> #3 - Should a user be able to apply a different configuration-group on
>         a master, than say, a slave?
>
Yes they should be able to apply any configuration they want to each
instance they own.


>
> #4 - If a user creates a new configuration-group with values equal to
>         that of the default configuration-group, what is the expected
>         behavior?
>
The user should be capable of creating a configuration-group with any
values they would like that are in bounds to the variable to be set.


>
> #5 - For GET /configuration/parameters, where is the list of supported
>         parameters and their metadata sourced from?
>
There is a config file that has all the options available to the user. This
is sources and displayed via the GET call.
example of the file: https://gist.github.com/6796477


>
> #6 - Should a user be able to reset a configuration-group to the
>         current default configuration-group?
>
A user should be able to reset the configuration-group to the "default" in
the template and they can do this by unassigning the configuration to the
instance.
There is a test case for this.


> #7 - Is a new configuration-group a clone of the then current default
>         configuration-group with various changes, or will inheritence be
>         utilized?
>
A new configuration-group will be setting the override changes to the
default my.cnf template.
We include the overrides.cnf directory location in the my.cnf
!includedir /etc/mysql/conf.d/
The overrides.cnf will be written with the changes to the configuration
group and apply them dynamically if they can be, otherwise a restart will
be required of the instance.


> #8 - How should the state of pending configuration-group changes be
>         reflected in GET /instances/:id ? How will this state be
>         persisted?
>
All dynamic changes will be applied at the time they are either 1) applied
to the configuration group that is tied to an instance or 2) when a
configuration group is applied to an instance. If there are changes that
cannot be dynamically set then we will change the state of the instance to
RESTART_REQUIRED to apply the changes.


>
> #9 - Reminder: Once multiple service-types and versions are supported,
>         the configuration-group will need a service-type field.
>
Yes i agree with this and need a way of splitting the validation rules and
making sure that we dont allow applying a configuration-group to different
service types.


>
> #10 - Should dynamic values (via functions and operators) in
>           configuration-groups be supported?
>           Example: innodb_buffer_pool_size = 150 * flavor['ram']/512
>
I've thought about this but I do not this we should try to shoot for this
right now.
I have some ideas similar to what you are describing but not sure i want to
tackle this in the first iteration.


>
> 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.
> >
>
>
> _______________________________________________
> 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/20131002/d98742bf/attachment.html>