These are some good q's. responses inline
On Wed, Oct 2, 2013 at 1:20 AM, McReynolds, Auston <amcreyno...@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" <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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev