So I just rolled out an update to validation.linaro.org. This was interesting for a couple of reasons:
1) I did the whole thing with a single salt command:
./lava-upgrade production 2>&1 | tee /root/lava-upgrade-2013-02-08
2) I didn't do an changelog or tagging
Both things might be semi-controversial:
1) I know there was an outstanding MP for lp:lava-lab where problems were identified. I think I've fixed those, and you can look at the recent changes to that branch to verify.
Michael - the big thing I left out was to always run "lava-deployment-tool setup" before doing an install/upgrade with my new scripts. Here's my debatable logic: As you note this command is basically idempotent.
My thinking is that since it is idempotent, we should just always call this function for actions in lava-deployment-tool like upgrade/install/upgradeworker/installworker. As I said - this logic might be debatable, but I made a "midnight decision" :)
2) changelog / tagging - we are at a point where we don't *have* to do this. Things are up in the air with versiontools. however, I think in the future updates will look like this and that the only things we tag are things at the end of the month
On Thu, Feb 07, 2013 at 11:16:27PM -0600, Andy Doan wrote:
So I just rolled out an update to validation.linaro.org. This was interesting for a couple of reasons:
- I did the whole thing with a single salt command:
./lava-upgrade production 2>&1 | tee /root/lava-upgrade-2013-02-08
- I didn't do an changelog or tagging
Both things might be semi-controversial:
- I know there was an outstanding MP for lp:lava-lab where problems
were identified. I think I've fixed those, and you can look at the recent changes to that branch to verify.
Michael - the big thing I left out was to always run "lava-deployment-tool setup" before doing an install/upgrade with my new scripts. Here's my debatable logic: As you note this command is basically idempotent.
My thinking is that since it is idempotent, we should just always call this function for actions in lava-deployment-tool like upgrade/install/upgradeworker/installworker. As I said - this logic might be debatable, but I made a "midnight decision" :)
Agreed. One of the principles of configuration management is to make everything idempotent, so if it already is, we should always run it. This also gives us the benefit of not having to remember runnnig it by hand when the setup changes.
- changelog / tagging - we are at a point where we don't *have* to
do this. Things are up in the air with versiontools. however, I think in the future updates will look like this and that the only things we tag are things at the end of the month
That's exactly what I got from the thread about this a couple days ago.
Andy Doan andy.doan@linaro.org writes:
So I just rolled out an update to validation.linaro.org. This was interesting for a couple of reasons:
- I did the whole thing with a single salt command:
./lava-upgrade production 2>&1 | tee /root/lava-upgrade-2013-02-08
- I didn't do an changelog or tagging
Both things might be semi-controversial:
Pff. 2) is not controversial :-)
- I know there was an outstanding MP for lp:lava-lab where problems
were identified. I think I've fixed those, and you can look at the recent changes to that branch to verify.
Michael - the big thing I left out was to always run "lava-deployment-tool setup" before doing an install/upgrade with my new scripts. Here's my debatable logic: As you note this command is basically idempotent.
My thinking is that since it is idempotent, we should just always call this function for actions in lava-deployment-tool like upgrade/install/upgradeworker/installworker. As I said - this logic might be debatable, but I made a "midnight decision" :)
Yeah, I think so. I think we should also write evolutions like we do for instance config versions so that we don't have to run the slow bits of ldt setup (the apt stuff) over and over again.
Most of the things ldt setup does require sudo, of course and I don't really know how to address that. (We could have a mode where ldt runs as root, but sudos to instance-manager when needed? Not sure how you'd code that...)
- changelog / tagging - we are at a point where we don't *have* to do
this. Things are up in the air with versiontools. however, I think in the future updates will look like this and that the only things we tag are things at the end of the month
Makes sense to me. TBH, even tagging things at the end of the month is a little wasteful -- in principle all you need to do is tag a revision of lp:lava-manifest, and precise versions of everything else flows from there. But it might take a while to educate the PMs about this :-)
There is a thought in the back of my brain about project consolidation here too.
Cheers, mwh
linaro-validation@lists.linaro.org
-
Andy Doan -
Antonio Terceiro -
Michael Hudson-Doyle