yellow team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

On 07/09/2012 05:00 PM, Benji York wrote:
> I have an MP up for the first integration test at
> https://code.launchpad.net/~benji/lpsetup/bug-1020734-first-integration-test/+merge/114044
> 

Yay!  Thank you!  The following are random thoughts while looking at the
code.  We can address all of them later, I think (post-landing) but I'd
like to address them one way or another.  Maybe #1 should be addressed now.

1) I'm not sure how we can run this in tarmac as is; it will need to
transfer the branch as currently tested over to the other machine, and
not a particular branch.  Maybe juju scp -r [the current code tree, as
calculated in the test by os.path fun with __file__] would be better for
transferring the code?  Once we have that ironed out, and this branch
landed, I'd really like a new card that hooks up the integration test on
tarmac to be created and started ASAP.

2) I understand why python-shelltoolbox is needed but not why apache is
needed.  Shouldn't lpsetup get apache?

3) I'm not sure why you have to set up bzr whoami, and I think lpsetup
is supposed to be able to do that.  The test should probably take a
non-root user as argument, though.  We can do that as a next step, though.

4) We can refine the time.sleep(30) later.

5) The lxc story will need to have lp-lxc-ip installed.  I'd suggest
making the setup run python setup.py install, and then have the test run
the lp-setup from the environment.

6) The lxc story also will need to install lpsetup in the lxc container.
 Normally that is done from the PPA, but we can't do that here, because
that would not test the branch that we currently are running.  Since the
home directories are shared in the host and the directory, I think we
could have an option to initlxc that passes a directory, and means
"instead of getting the PPA in the container, use python setup.py
install [this directory]".

#6 runs counter to what I wrote in my previous email about this, but
there are many upsides to your alternative approach and I think we ought
to stick with it.

Thanks again!

Gary