On Nov 4, 2012 8:16 PM, "Nah, Zhongyue" wrote:
>
> https://blueprints.launchpad.net/nova/+spec/deployer-friendly-confs
>
> This blueprint seems to be planning to implement what is being discussed
for Nova.
Marvellous. I believe this discussion adds/reinforces to the ideas proposed
and hope this b
On 11/04/2012 04:45 PM, Nah, Zhongyue wrote:
https://blueprints.launchpad.net/nova/+spec/deployer-friendly-confs
This blueprint seems to be planning to implement what is being discussed for
Nova.
Great.
I assume that this will be done in OpenStack Common so that all of the
users of the comm
https://blueprints.launchpad.net/nova/+spec/deployer-friendly-confs
This blueprint seems to be planning to implement what is being discussed for
Nova.
-zhongyue
Sent from my iPhone
On Nov 4, 2012, at 3:26 PM, "Gary Kotton"
mailto:gkot...@redhat.com>> wrote:
It would also be nice if one coul
It would also be nice if one could change configuration settings at run
time instead of having to restart a process.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~o
On Sun, Nov 4, 2012 at 2:30 AM, Aniruddha Khadkikar
wrote:
> 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 i
On Sat, Nov 3, 2012 at 9:06 PM, Tim Bell wrote:
>
> Puppet is great for this sort of thing. There are various ways of querying
> parameters and making choices about them. A typical example would be where
> you want to adjust a configuration parameter due to memory configuration or
> network.
I ma
On Sat, Nov 3, 2012 at 7:53 PM, andi abes wrote:
> On Sat, Nov 3, 2012 at 9:30 AM, Aniruddha Khadkikar
> 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 befitt
Puppet is great for this sort of thing. There are various ways of querying
parameters and making choices about them. A typical example would be where
you want to adjust a configuration parameter due to memory configuration or
network.
Writing the puppet configuration is not difficult... Puppetlab
On Sat, Nov 3, 2012 at 9:30 AM, Aniruddha Khadkikar
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
@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
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 ver
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 agre
Well, I'm not really sure if the configuration parameters are
hierarchical. I haven't given much thought on the internal
organization of various parameters in all configuration files and
their inter-dependencies. However I feel that the parameters that
govern the behaviour of openstack components s
13 matches
Mail list logo
