launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

Hi Martin.

We haven't announced setuplxc as a developer tool, AFAIK, even though it 
has had a commit or two in that direction, so I was somewhat surprised 
to hear that it was being used for that outside of our squad.  I guess I 
shouldn't have been.  So, first off, here's a warning for Launchpad 
developers.  I'm sorry we didn't send this out earlier.

======================================

setuplxc is primarily for the parallel testing project.  We use it to 
set up virtual machines for running tests, in a fully automated way.

The ability to also use it as a developer tool should be regarded as 
bleeding edge, and almost unmaintained.  I have used parts of it to set 
up my machine, and it was helpful.  It might not be for you.

Moreover, we are no longer working on it as a developer tool.  Francesco 
has a slack time project to create a replacement for setuplxc, 
rocketfuel-setup, and so on.  This will be a developer tool, and will 
have tests, and also support our use cases.  The experience with 
setuplxc is informing that project.  We'll announce that and ask for 
reviews and testing when it is farther along.

======================================

Now that the warning is done, I'll add a few in-line replies below.

On 03/16/12 03:26, Martin Pool wrote:
> I just spent a few hours debugging strange network behaviour, which
> turned out to be due to a DNS packet storm, with several dnsmasq
> processes talking furiously to each other and to my router.  The root
> cause of this seems to be that setuplxc modifies my dhclient.conf to
> add 10.0.3.1 as a DNS server.
> <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/956732>

I'm sorry that this caused such an annoyance and a time sink.

Adding the DNS server is reasonable and expected AFAIK, and can be 
convenient if it works.  We will check with the LXC developers to make 
sure that our understanding is correct.

> It's the second time setuplxc has damaged something on my machine
> which it had no good reason to be changing, the first being
> <https://bugs.launchpad.net/launchpad/+bug/936817>  that it also
> scrambles your bzr identity.

This has been fixed, AIUI.

> I realize software has bugs, especially new software, and I'm not mad
> with you.  But I do think there is something systematically wrong in
> the way setuplxc changes the host machine.  It's a bit ridiculous that
> attempting to create an isolated sandbox damages the host machine.
>
> If setuplxc is meant to be run on (would-be) developers' laptops,

As mentioned, we are no longer developing it as such, with Francesco's 
project intending to take that role.  Your points still apply to the new 
project, though.

> and
> if it wants to be run as root, it needs to be  careful what it
> changes, and my impression is at the moment it is not.  I would like
> to suggest you adopt these design rules for it:
>
>   * don't actually change the host, if you can avoid it!  For instance,
> I don't see why you would need to change the bzr user identity - ok,
> perhaps check it, and if it's wrong, complain.

For the primary use case of setuplxc, we do indeed want to change the 
host.  For a developer tool like the one Francesco is working on, agreed 
in general that we ought to be more careful.

> Similarly if a needed
> package is missing, just say so and bail out.

That won't work for the use case of setting up a test machine, but we 
can have an equivalent to a -y option for that use case.

>   * tell the user what you're going to change and get their permission,
> like rocketfuel-setup does

Again, agreed, though we need a -y for our use case to bypass any 
interactivity.

>   * make the changes in a way they can be easily reversed, eg by
> writing a new .d file
>   * when you edit a config file, add a comment saying launchpad
> setuplxc did it, and when

Agreed that a developer tool should do this.

>   * make it clearer in the source code what will be done on the host -
> when I looked a few weeks ago it was very tangled and unclear

IIRC, there is a single function that does all of the non-lxc host 
changes.  Another single function creates the lxc container, and another 
configures the lxc container.

Using a package instead of a module, as is happening in the new project, 
may help as well.

> rocketfuel-setup does at least some of these, and given the complaints
> about it over the years it would be nice if setuplxc can do at least
> as much.

Thanks for the heads up, and the notes.

Gary