Open Stack

Ah! Sorry for the mis-understanding.

In which case, would a simple fix of adding a "localrc.generated" be sufficient?

Produce a localrc which simply imports localrc.generated and replace localrc.generated in all cases - still allowing users to override it if needed?

Bob

From: Dean Troyer [mailto:dtroyer at gmail.com]
Sent: 18 September 2013 13:37
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [DevStack] Generalize config file settings

On Wed, Sep 18, 2013 at 4:46 AM, Bob Ball <bob.ball at citrix.com<mailto:bob.ball at citrix.com>> wrote:
I understand that there are some very good reasons that we can't make all modifications to localrc work on an unstack/stack -- but a very large number of the options are only read at run time and do not have any persistent state.

My apologies Bob, misunderstanding alert...it wasn't clear in the review message where I said "we can't change localrc" I meant stack.sh, not us as users.  The only time stack.sh will change localrc is to add  passwords entered at the prompts.  There can be problems when localrc changes between stack and unstack but we're a dev/test tool and some hands just are not going to be held.


The question I have is when we introduce local.conf, we can't source it directly to get the localrc values so currently it writes those to localrc if ther isn't already one present and continues as before.  The question is what is the 'least surprise' user experience next time stack.sh runs, overwrite localrc again to pick up any changes that might be made to local.conf?  Or stick with the current behaviour of never changing it and requiring the user to remove it before changes in local.conf get written back to it again.

I prefer the former, overwriting localrc every time but that is a significant change in behaviour, even if it is consistent with what we do to the other OpenStack config files (rewriting them every time).

dt

--

Dean Troyer
dtroyer at gmail.com<mailto:dtroyer at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130918/23f60be7/attachment.html>