openstack team mailing list archive

[Aniruddha Khadkikar <askhadkikar@xxxxxxxxx>]

On Sat, Nov 3, 2012 at 7:53 PM, andi abes <andi.abes@xxxxxxxxx> wrote:
> 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)

Agreed. Puppet scores at managing dependencies. No question about that.
Puppet is used for managing software that has its own metadata. The
way I have understood Puppet is that it uses this metadata as 'facts'
to take decisions while deploying a 'recipe'. In our case the metadata
is stored in conf files. The sample conf file for Nova has 500
parameters. So, in order to be able to query all known configuration
parameters (even if I'm happy with the defaults), my conf file would
need to have all of them listed. If we assume that the next version of
Nova has greater or lesser and/or different configuration parameters,
then my recipes have to be revisited so that all new configuration
parameters are documented in Puppet.

I still feel Openstack components need to manage their metadata (conf
data) in a better way than conf files, and allow Puppet/Chef to query
this metadata to manage an Openstack implementation efficiently. I am
not arguing for/against an configuration management approach. Rather I
feel it would be safer in the long run that conf data is managed
independently of any non-core component of openstack.
>
> 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.
>

The parameter store is just one component of the implementation. The
larger issue concerns change management of the metadata 'dictionary'
(I borrow the term liberally, as I have a database background).

>>
>> @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