Merge lp:~javier.collado/utah/provisioned_machine into lp:utah
Status: | Merged |
---|---|
Approved by: | Javier Collado |
Approved revision: | 821 |
Merged at revision: | 811 |
Proposed branch: | lp:~javier.collado/utah/provisioned_machine |
Merge into: | lp:utah |
Diff against target: |
235 lines (+117/-15) 4 files modified
examples/run_utah_tests.py (+27/-1) utah/provisioning/provisioning.py (+18/-4) utah/provisioning/ssh.py (+67/-9) utah/run.py (+5/-1) |
To merge this branch: | bzr merge lp:~javier.collado/utah/provisioned_machine |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Max Brustkern (community) | Approve | ||
Javier Collado (community) | Needs Resubmitting | ||
Review via email:
|
Description of the change
This branch creates a new class named ProvisionedMachine class that takes care
of running tests on a provisioned machine (physical or virtual).
The way to run test cases in such a machine with the implementation in this
branch would be as follows:
PYTHONPATH=. ./examples/
<machine_name> ./utah/
I don't consider this merge request yet ready to be committed, but I'd like to
get some feedback with regard the following:
- Flag
What do you think about using --skip-provisioning flag? I believe there are too
many flags already in run_utah_tests.py, so if you any suggestion would be
welcomed.
- Inventory
For now, no inventory is used to get the machine object. However, one must be
used to prevent jenkins jobs trying to make use of the same hardware
simultaneously. What kind of inventory do you suggest? I see there's a separate
inventory for cobbler machines and for VMs so probably it makes sense to have
one for provisioned machines, but I think that it can be confusing to have so
many inventories. I know there's a plan to use PostgreSQL, but I'm thinking
about having all inventories in a common database in MongoDB. This way we could
use a different schema for the machines collection depending on how it's
expected to be used.
- Class hierarchy
The workaround I had to implement to skip the initialization code in the
Machine class probably means that some refactoring is needed to have a simpler
generic machine class from which ProvisionedMachine can inherit and another one
used by all the machine classes that need an image to install the system before
running any test. Do you think this refactoring would make sense?
I'm going to comment on your questions before I actually look at the merge.
I think that flag is fine. I also think that script is overloaded with options, but I think at this point we're going to need a more thorough design overhaul to fix that, so adding another flag for now is probably the best thing to do.
I think at this point, an inventory that could handle physical machines, virtual machines, already installed machines, reinstalling existing machines, ARM boards, etc. is becoming a priority. It's something we've wanted for a long time. The PS team, in particular, would like to be able to request machines based on hardware info/tags rather than just always pulling one by name. I think that will help hardware testing scale much better as well. I've used SQL because that's what I know, but we do need different information for machines depending on whether they're virtual, physical, already installed, etc. If you want to put together something in Mongo, I'd enjoy looking at it, and I'm sure it'd be a good learning experience for me.
I think up until we did automatic ISO downloading, the base Machine class could run fine without an image, so I would be in favor of refactoring things so it can work that way again. If you want to prepare something for that, I'd be happy to test it, but if you're working on other things, that's something I can try to tackle at some point as well.