openstack team mailing list archive

[andi abes <andi.abes@xxxxxxxxx>]

On Sat, Nov 3, 2012 at 9:30 AM, Aniruddha Khadkikar
<askhadkikar@xxxxxxxxx> wrote:
> @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.

from my experience many of the problems encountered in deploying
openstack have to do with what you call "local parameters" which
depend on the node's configuration. For nova e.g. the name of the
interface/bridge. for swift e.g. the disks available on a node and so
on. The values that are common for the whole deployment are the easy
(or at least easier) part ;)


> 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).

for troubleshooting you'd want to look at resources available on the
node, and compare/match them to the configuration parameters. typical
configuration management systems (e.g. puppet , chef, juju etc)
provide you that information,  in a centralized location, with various
querying capabilities. Additionally, once you've found the problem,
you'd want to fix it...where CM systems shine

Other sources of problems configuration management systems can help
you with are:
- dependencies - other python modules and OS packages required to make
openstack happy.
- disk, network and other local resources' configuration (e.g
interface /bridge config, disk formatting etc)

I think there are good solutions out there, that provide more value
than just a db for parameters...
It might be worth your time to compare those to what would be gained
by just a parameter store.

>
> @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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp