openstack team mailing list archive

[Aniruddha Khadkikar <askhadkikar@xxxxxxxxx>]

@Rob - excellent points. It would be good to know in real life
deployments how often are configurations changed so the question of
network interruptions are handled in a befitting way. It is my
impression that once the database has synced the information, changes
would be infrequent. Regarding your second point, the solution lies in
how the records are maintained. One can design the structure to
include a 'version' column along with a boolean attribute for logical
deletion of records. This would allow storing information across
different versions. Puppet has its use, but the main point is that the
metadata should lie within openstack and not solely outside in a
configuration management tool (i.e. Puppet). With so many
configuration parameters in quantum, nova, swift, cinder, we need an
easy way to be able to query 'global' values and if required be able
to specify 'local' values applicable to nodes also, if such a need
arises. Areas where local values could be required could be location
of log files, different tuning parameters depending on hardware
configuration etc.
The data store design can be adapted to have the node level local
values and the individual daemons on start up would honour the local
values if defined. Also a common data store that can be queried (my
main point) within an openstack deployment would be extremely useful
for troubleshooting, rather than having to dig through each and every
configuration file (if I'm not using Puppet).

@Jon - I am happy that these ideas resonate with you. My moot point is
that the metadata should be within the openstack implementation and
not outside. I am not very familiar with Puppet - is there a way to
query the parameters set in the conf file. I would think that Puppet
would be given a conf file to deploy. The values within the conf file
would still remain abstracted and not be readily available. Please
correct me if I'm wrong in my presumption. Having the parameters with
their default values in the data store would allow a better
understanding of the different configuration parameters. Also if its
in a database then dependency and relationship rules or even
constraints (permissible values) could be defined.

On Sat, Nov 3, 2012 at 12:08 PM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxx> 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@xxxxxxxxx> wrote:
>> :> Are you thinking of something like a Hiera style thing?
>> :>
>> :> Endre.
>> :>
>> :> 2012/11/2 Aniruddha Khadkikar <askhadkikar@xxxxxxxxx>
>> :>>
>> :>> 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@xxxxxxxxxxxxxxxxxxx
>> :>> Unsubscribe : https://launchpad.net/~openstack
>> :>> More help   : https://help.launchpad.net/ListHelp
>> :>
>> :>
>> :
>> :_______________________________________________
>> :Mailing list: https://launchpad.net/~openstack
>> :Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> :Unsubscribe : https://launchpad.net/~openstack
>> :More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp