Open Stack

I'm glad we both agree on most of these answers.
:)
 On Oct 2, 2013 11:57 AM, "Michael Basnight" <mbasnight at 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 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/22957ea6/attachment.html>