Ticket #588 (assigned defect)
automated install tests
| Reported by: | geofft | Owned by: | wpreston |
|---|---|---|---|
| Priority: | normal | Milestone: | Current Semester |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
We should set up a VM that reinstalls debathena-cluster from PXE nightly, except using the -proposed repository, and have automated test scripts to make sure the machine successfully installed, athinfos as debathena-cluster, etc. etc.
Change History
comment:2 Changed 13 years ago by jrjarvis
- Owner set to jrjarvis
- Status changed from new to assigned
comment:3 follow-up: ↓ 4 Changed 13 years ago by jrjarvis
For now I have a semi-useful, somewhat functional prototype here auto-installing debathena into VMs for development/proposed/production. Hopefully the installs won't take as long on a decent machine.
http://terminus:8085/browse/NATTYPROD-INSTALL
A few more things that need to be worked out:
- where to run this, requirements will be a box with a decent amount of memory, vmware, a scheduler of some sort (cron/bamboo/jenkins/etc)
- what (if any) tests we should do after install, all tests are using the same hostname each time but we could get some more to run a few tests in parallel.
- how often to run the installs and what triggers to kick them off
comment:4 in reply to: ↑ 3 ; follow-up: ↓ 6 Changed 13 years ago by kaduk
Replying to jrjarvis:
For now I have a semi-useful, somewhat functional prototype here auto-installing debathena into VMs for development/proposed/production. Hopefully the installs won't take as long on a decent machine.
http://terminus:8085/browse/NATTYPROD-INSTALL
A few more things that need to be worked out:
- where to run this, requirements will be a box with a decent amount of memory, vmware, a scheduler of some sort (cron/bamboo/jenkins/etc)
I don't have any real thoughts on this one; it doesn't really feel like an ops-hosted VM is the right answer, and running from cron on a developer's workstation is probably not wrong. We could probably find a spare old cluster hardware machine and set it up, too.
- what (if any) tests we should do after install, all tests are using the same hostname each time but we could get some more to run a few tests in parallel.
Well, the big thing would be to test logging in.
Off the top of my head, it would also be good to test locker software (say, matlab) and some of the athena utilities such as moira and friends, maybe discuss or something.
Checking that the athinfo queries work as expected would also be good. (Do we run anything else other than a fingerd?)
- how often to run the installs and what triggers to kick them off
Our development pace seems to vary quite a bit; most of the time even weekly would probably be sufficient, but I would probably do nightly if it works.
comment:5 Changed 13 years ago by jdreed
We can run this on a 755 in the E17 server room, provided physical access is not an issue. There's also the W92 test cluster...
comment:6 in reply to: ↑ 4 ; follow-up: ↓ 7 Changed 13 years ago by jrjarvis
Well, the big thing would be to test logging in.
Off the top of my head, it would also be good to test locker software (say, matlab) and some of the athena utilities such as moira and friends, maybe discuss or something.
Checking that the athinfo queries work as expected would also be good. (Do we run anything else other than a fingerd?)
Anything that requires credentials may be tricky unless we have a test account or other approaches to testing software that's run out of a locker, logging in, etc.
The easiest thing to do would be to drop an init script at the end of install but I'm not sure how valuable that will be since it will be run outside of the chroot environment. For now I can wait until the reboot and make sure it's at the very least alive after the install.
comment:7 in reply to: ↑ 6 Changed 13 years ago by kaduk
Replying to jrjarvis:
Anything that requires credentials may be tricky unless we have a test account or other approaches to testing software that's run out of a locker, logging in, etc.
I feel confident we can get a test account (or just use an existing one, really).
The easiest thing to do would be to drop an init script at the end of install but I'm not sure how valuable that will be since it will be run outside of the chroot environment. For now I can wait until the reboot and make sure it's at the very least alive after the install.
I don't think that an init script would give much utility other than confirming that packages installed correctly (which your setup already does, I think?).
Ideally we could somehow script waiting for the reboot and logging in with stored (test account) credentials, and run a testing script from a well-known location.
