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 <j...@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.karl...@gmail.com> > wrote: > :> Are you thinking of something like a Hiera style thing? > :> > :> Endre. > :> > :> 2012/11/2 Aniruddha Khadkikar <askhadki...@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@lists.launchpad.net > :>> Unsubscribe : https://launchpad.net/~openstack > :>> More help : https://help.launchpad.net/ListHelp > :> > :> > : > :_______________________________________________ > :Mailing list: https://launchpad.net/~openstack > :Post to : openstack@lists.launchpad.net > :Unsubscribe : https://launchpad.net/~openstack > :More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
