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

[Serge Hallyn]

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?)