I'm glad we both agree on most of these answers. :) On Oct 2, 2013 11:57 AM, "Michael Basnight" <mbasni...@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 > > _______________________________________________ > 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
