.lpconfig and /etc/launchpad/config no longer work

Since no one has complained before, I expect the importance is low.

That said, should be easy to do. I attached a branch. Please let me know if this has the right characteristics.

Your branch has the right characteristics. r=stub

I'm not sure in what situation $LPCONFIG ever needs to be set. The only code that should use it is canonical.config.__init__ to load the relevant config.

Fixed in stable r11704 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/11704>.

Stuart, Chex and I tried to QA we were not sure what in production actually wants this facility. For instance, on staging, LPCONFIG is set when Make is run, it seems, so it is cooked: https://pastebin.canonical.com/38749/ .

Can you give us an idea of what to QA?

Thank you

On Tue, Oct 19, 2010 at 7:12 AM, Gary Poster <email address hidden> wrote:
> Stuart, Chex and I tried to QA we were not sure what in production
> actually wants this facility.  For instance, on staging, LPCONFIG is set
> when Make is run, it seems, so it is cooked:
> https://pastebin.canonical.com/38749/ .
>
> Can you give us an idea of what to QA?

check that staging and qastaging services all come up properly; done.
I guess 'look at the config the services report that they are using'
(if thats not possible, we've a transparency issue to fix too).

For instance, the librarian issue you encountered might be this patch
breaking its config.

-Rob

"look at the config the services are using": the pastebin showing the cooked version seems to be indicative; moreover, Chex confirms that "./bin/py -c 'from canonical.config import config; print config.instance_name'" returns "staging" as it should (the librarian uses the same Python configuration as bin/py, via parts/scripts).

I could look further into the librarian issue--and indeed, I am going to because I'm concerned about bug 662912--but I don't think it is pertinent to this bug/change. The change I made for this bug was for when the instance name is *not* cooked.

In fact...the question for QAing this is "where on staging or production is the instance name not cooked?" It doesn't appear to have an obvious answer to the LOSAs, but I will pursue it with them further.

mbarnett did a lot of digging, and I did a little. As far as we can tell, staging's LPCONFIG is handled in staging_restore.sh, where it is hardcoded with ``make compile LPCONFIG=staging``.

I'm going to mark this qa-ok because things don't appear to be broken. stub will have to show us how we have improved things when he gets back from vacation.

On Wed, Oct 20, 2010 at 3:27 AM, Gary Poster <email address hidden> wrote:
> mbarnett did a lot of digging, and I did a little.  As far as we can
> tell, staging's LPCONFIG is handled in staging_restore.sh, where it is
> hardcoded with ``make compile LPCONFIG=staging``.

The setting of LPCONFIG during compile shouldn't hardcode anything.
The config needs to be determined at runtime, and we frequently
compile with a different LPCONFIG to what is used at runtime.

The patch seems to have the desired behavior and I can make use of it
after the next rollout.

--
Stuart Bishop <email address hidden>
http://www.stuartbishop.net/