Open Stack

One thing to bear in mind when considering a network API for this -
beyond the issue of dealing with network interruptions gracefully - is
dealing with version skew: while deploying a new release of Openstack,
the definition of truth may be different for each version, so you need
to either have very high quality accept-old-configurations-code in
openstack (allowing you to never need differing versions of truth), or
you need a system (such as Puppet) that can parameterise what it
delivers based on e.g. the software version in question.

-Rob

On Sat, Nov 3, 2012 at 8:17 AM, Jonathan Proulx <jon at csail.mit.edu> wrote:
> On Sat, Nov 03, 2012 at 12:19:58AM +0530, Aniruddha Khadkikar wrote:
> : However I feel that the parameters that
> :govern the behaviour of openstack components should be in a data store
> :that can be queried from a single data store. Also it would make
> :deployments less error prone.
>
> On one hand I agree having a single source of truth is appealing in
> many ways.  The simplicity of text configuration files and the shared
> nothing nature of having config local to each system is also very
> appealing.
>
> In my world my puppet manifest is my single source of truth which
> provides both a single config interface so there is no error prone
> manual duplication and also results in a fully distributed text
> configuration so the truth persists even if the source is down for a
> while.
>
> There's a number of things besides puppet to implement this type of
> management with but conceptually I very much think that is the right
> thing.
>
> -Jon
>
> :Aniruddha
> :
> :
> :On Fri, Nov 2, 2012 at 11:52 PM, Endre Karlson <endre.karlson at gmail.com> wrote:
> :> Are you thinking of something like a Hiera style thing?
> :>
> :> Endre.
> :>
> :> 2012/11/2 Aniruddha Khadkikar <askhadkikar at gmail.com>
> :>>
> :>> Hi Stackers,
> :>>
> :>> Are there plans to keep all configuration parameters in a central
> :>> location? Rather than having a lot of configuration files. By central
> :>> location I do not mean that its a single server but it could be a
> :>> distributed database with each node irrespective of purpose having a
> :>> copy of the configurations. Each node can refer to the parameters it
> :>> requires.
> :>>
> :>> This would ease understanding the myriad of configuration parameters
> :>> as elicited in the recent San Diego presentation that showed we have
> :>> now more than 500 configurable parameters in Nova
> :>>
> :>> (http://www.openstack.org/summit/san-diego-2012/openstack-summit-sessions/presentation/pimp-my-cloud-nova-configuration-hints-and-tricks).
> :>>
> :>> For configuration parameters which are essentially key-value pairs,
> :>> using a nosql database would suffice.
> :>> Currently its quite difficult to dig up the default values after
> :>> deployment. Or am I missing something here?
> :>>
> :>> Br
> :>> Aniruddha
> :>>
> :>> _______________________________________________
> :>> Mailing list: https://launchpad.net/~openstack
> :>> Post to     : openstack at lists.launchpad.net
> :>> Unsubscribe : https://launchpad.net/~openstack
> :>> More help   : https://help.launchpad.net/ListHelp
> :>
> :>
> :
> :_______________________________________________
> :Mailing list: https://launchpad.net/~openstack
> :Post to     : openstack at lists.launchpad.net
> :Unsubscribe : https://launchpad.net/~openstack
> :More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp