Cannot upgrade to another buildout config using "lava-deployment-tool upgrade"

[Paul Sokolovsky]

I first installed normal LAVA install using:

./lava-deployment-tool install -d -n normal-crowd

I then tried to upgrade it to another buildout config (which install extra packages):

LAVA_MANIFEST_BRANCH='lp:~pfalcon/lava-manifest/crowd-separate' \
LAVA_BUILDOUT_CFG='buildout-production-crowd.cfg' \
      ./lava-deployment-tool upgrade normal-crowd

The end result was that new buildout config wasn't used, old one apparently was, as confirmed by lack of extra package and same "LAVA_BUILDOUT_CFG='buildout-development.cfg'" in /srv/lava/instances/normal-crowd/instance.conf .

Expected result: upgrade to new buildout config. (Fairly speaking, this is confusing with current means of passing parameters to lava-deployment-tool. In this case, I really wanted to switch to new buildout cfg. But of course, I don't want random switches depending on what value is set (or not set) in the environment. So, proper way would be to pass --buildout-cfg= switch to lava-deployment-tool).

[Antonio Terceiro (terceiro)]

I think I led you into this problem - my fault.

When dealing with an existing instance, lava-deployment-tool will not use $LAVA_MANIFEST_BRANCH and $LAVA_BUILDOUT_CFG from the environment but will read them from the instance configuration file (/srv/lava/instance/$foo/instance.conf). So the proper upgrade procedure I should have told you about is:

- change LAVA_MANIFEST_BRANCH and LAVA_BUILDOUT_CFG in instance.conf
- run `lava-deployment-tool updrade $foo`

[Paul Sokolovsky (pfalcon)]

So, this bug was not about particular case I hit, it was about deficiency in lava-deployment-tool functionality/behavior. If it can support system upgrades, and supports working with multiple manifest branches/files, then it's natural to try and upgrade to another manifest, and someone sooner or later will try that. I just did, and external folks would do sooner or later too.

Granted, with this feature, not too soon and not too many will hit into it, but when someone does (especially a customer) does, telling "ah, sorry, we forgot to tell you that ..." is hardly a pro approach, if this is already a *known issue*, and should be documented (this bug does), and be in queue for fix if requested by enough number of customers.

[Paul Sokolovsky (pfalcon)]

Hitting this again, and reopening. The process described in Antonio's comment is confusing and non-intuitive (for what reason I would suddenly go randomly patch production instance config?). There should be better way to do this.

[Paul Sokolovsky (pfalcon)]

I propose patch for this at https://review.linaro.org/1047 . The patch is trivial, the user interface aspect of it is not. It's not sustainable way to suggest users to go patch their *current* production config to affect *future* upgrade. What if a user makes a change to config and forgets about it? What if user makes a typo or syntax error while patching? etc, etc.

[Paul Sokolovsky (pfalcon)]

Patch merged.