Merge lp://staging/~yellow/launchpad/lxcsetup into lp://staging/launchpad
Status: | Merged |
---|---|
Approved by: | Francesco Banconi |
Approved revision: | no longer in the source branch. |
Merged at revision: | 14733 |
Proposed branch: | lp://staging/~yellow/launchpad/lxcsetup |
Merge into: | lp://staging/launchpad |
Diff against target: |
823 lines (+819/-0) 1 file modified
utilities/setuplxc.py (+819/-0) |
To merge this branch: | bzr merge lp://staging/~yellow/launchpad/lxcsetup |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Benji York (community) | code | Approve | |
Graham Binns | Pending | ||
Review via email: mp+89660@code.staging.launchpad.net |
Description of the change
= Summary =
This branch adds a script that can be used to set up a Launchpad environment
inside a LXC, useful for testing Launchpad.
== Proposed fix ==
https:/
a cheap way to run tests in parallel using ephemeral instances, obtaining the
required isolation to workaround the existing globals (shared work dirs,
hardcoded tcp ports, etc.). The `setuplxc.py` script creates a Launchpad
environment from scratch, ready to be used by ephemerals (e.g. in a buildbot
slave context).
== Pre-implementation notes ==
During development we realized that the same approach (with few changes)
should work to set up a Launchpad development environment.
The developer can just:
- run the script (passing his current local username as user), e.g.::
./setuplxc.py -u username -e <email address hidden> -n 'Firstname Lastname'
-c lp-devel -d /home/username/
- ssh into the container (in the example above: ssh lp-devel)
- cd ~/lp-branches/devel
- make schema
- make run
- start hacking
== Implementation details ==
utilities/
* the script is implemented in Python
* requires Python 2.7
* must be run as root
* help on required arguments: utilities/
utilities/
* refactored so that it can be run by root
== Tests ==
The script uses internal helper functions providing doctests. To run them::
python -m doctest -v utilities/
A more extensive and complete testing approach would require to setup
a precise KVM.
== Demo and Q/A ==
To demo and Q/A this change, do the following:
* Install precise in a virtual machine (e.g. KVM)
* Copy the script inside the virtual machine, e.g. for kvm::
kvm -hda precise_HDA.img -boot c -m 2000 -redir tcp:2222::22 &
scp -P 2222 /utilities/
* Run the script, e.g.::
ssh -p 2222 root@localhost
cd /tmp/
./setuplxc [arguments]
== lint ==
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
utilities/
Here's what I have this far:
lxc-create and lxc-start use the "-n" option to specify the instance
name, we might want to do the same.
It would be nice if the script used the current user info (login name)
if none are provided as arguments. Taking that a step further, bzr
whoami produces consistent, easily parsable results that could make
--email and --name optional as well.
...Later: oh! The user info is required because the script is expecting
to be run as root. I suppose the easiest thing would be to leave it
as-is, but it'd be really nice to not have to provide all of those
arguments. Perhaps the script can be re factored into two halves: the
first starts as the user in question, and the second part is run under
sudo (prompting the user for a password if nectary).
I'm a big fan of doctest, but it's LP policy to not introduce any new
(non-documentation) doctests, so the embedded doctests should be
translated into unittest-style tests.
Is it really necessary to skip the "sudo" (in launchpad- database- setup)
if already running as root? I would expect the sudo to be a noop in
that scenario. Similarly, "sudo -u postgres" should work equally well
for root as it does for non-root users.
We've mostly transitioned away from the %-style string construction and
switched to the new .format() string method so the script should avoid
constructing strings with %.
On line 210 of the diff: The summary line of a docstring should fit on a
single line.
The file_append function doesn't have to rewrite the entire file.
Instead the file can be opened in append mode and the new line appended.
Also, when appending a line to a file you should check to see if the
last line of the file doesn't have a trailing newline, otherwise you can
end up adding your string to the last line of the file instead of
appending an entirely new line.
Since this script requires Python 2.7, I would use the print function
instead of the print keyword (from __future__ import print_function).
On line 366 of the diff, the description of the --name argument leaves
off the "r" in "for" ("used fo bzr").
The parenthesis around the multi-line constructions of the "help"
arguments aren't necessary.
Requiring an SSH private key without passphrase gives me some security
shivers and may raise a few eyebrows.