[lxc-devel] [PATCH 2/3] c/r: get rid of dump_net_info()

[Tycho Andersen]

On Wed, Aug 12, 2015 at 04:20:29PM +0000, Serge Hallyn wrote:
> Quoting Tycho Andersen (tycho.andersen at canonical.com):
> > On Wed, Aug 12, 2015 at 03:28:07PM +0000, Serge Hallyn wrote:
> > > Quoting Tycho Andersen (tycho.andersen at canonical.com):
> > > > On Wed, Aug 12, 2015 at 03:09:22PM +0000, Serge Hallyn wrote:
> > > > > Quoting Tycho Andersen (tycho.andersen at canonical.com):
> > > > > > On Wed, Aug 12, 2015 at 02:54:14PM +0000, Serge Hallyn wrote:
> > > > > > > Quoting Tycho Andersen (tycho.andersen at canonical.com):
> > > > > > > > This was originally used to propagate the bridge and veth names across
> > > > > > > > hosts, but now we extract both from the container's config file, and
> > > > > > > 
> > > > > > > Is that the right thing to do?
> > > > > > 
> > > > > > I don't know, actually. I did it so that you could switch bridges
> > > > > > across hosts (and because the code is considerably simpler); it does
> > > > > > keep the MAC and all that the same, so in theory it should Just Work.
> > > > > > Someone who knows more about networks can probably correct me if I'm
> > > > > > wrong, though :)
> > > > > 
> > > > > I do prefer simple, in general.
> > > > > 
> > > > > My concern with this is that any change to the running container which
> > > > > was not reflected in the config will not be retained.  I wonder if it
> > > > > is better to fix dump_net_info() to give the information you actually
> > > > > want.
> > > > 
> > > > Yeah, it is true that if you change the container-side veth's name
> > > > it'll screw things up, so that's probably good to save. I think it is
> > > 
> > > Or if you use lxc-device to add a new nic, or the container simply creates
> > > a new veth pair internally for use by its application.
> > 
> > So the second case should be handled correctly (there's nothing
> > outward facing, so nothing can change relative to the config file).
> > The first case could also cause problems since there won't
> > necessarily be config entries for these devices.
> 
> Oh, right - this is only for 'leaked' interfaces to the host, got it.
> 
> So especially in that case my ack stands and let's go with this for now :)
> 
> > > > useful to be able to change the host bridge the container is attached
> > > > to, and in principle it shouldn't screw anything up. So I'm not quite
> > > > sure how to deal with that case.
> > > > 
> > > > (Note that none of this matters in LXD land, since LXD is managing all
> > > > the configuration for you and you can't change it. It is an issue with
> > > > lxc-checkpoint and the config file lxc, though.)
> > > 
> > > Well if we simply don't know what the right thing is, then doing the
> > > simplest thing for now is reasonable.
> > 
> > Ok. I think there's some stuff here that could still bite people, but
> > I'm not sure that it's a super high priority right now. I'll see about
> > fixing it "soon" :)
> 
> Well if you do that we need to first have a discussion about what exactly
> migration is meant to be.  In lxc, the 'running' container is one thing,
> the configured container is something different.  To the point that you
> can have running containers with no config.  So the question is what
> are we trying to migrate.  The running container, I guess.  So really the
> configuration stored on disk should be ignored.  The configuration we
> get from the API's save_config should be used.  (Is it?)

Right now it uses whatever the config in memory has set up. In the
case of the lxc-checkpoint tool, this is the configuration on disk.
In the case of LXD, it's whatever LXD sets before it calls
->checkpoint.

An advantage of this behavior for lxc-checkpoint is that it allows
users to change things like which bridge the container is on in their
config file (in the LXD case, if the config was modified in LXD
between the two hosts, then the bridge would change as well). If we
keep this state in a separate location (i.e. the checkpoint
directory), we won't be able to do this, which I think is not as nice.

There are a few things that we probably should think about though, for
example, what happens if the bridge in the configuration doesn't
exist? Perhaps we should save the bridge name, but let the config
file's version override it?

Tycho