[lxc-devel] 0.9.x versions before 1.0

[Serge Hallyn]

Quoting Dwight Engen (dwight.engen at oracle.com):
> On Thu, 11 Jul 2013 16:24:43 -0500
> Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> 
> > Quoting Dwight Engen (dwight.engen at oracle.com):
> > > On Thu, 11 Jul 2013 09:22:47 -0500
> > > Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > > 
> > > > Quoting Stéphane Graber (stgraber at ubuntu.com):
> > > > > To add to the "you broke my lxc-create" list, the new version
> > > > > also dropped the fancy header I introduced a while back
> > > > > (showing the template name, the arguments passed to it and the
> > > > > checksum of the template used at the time.
> > > > > 
> > > > > An example was:
> > > > > # Template used to create this container: ubuntu
> > > > > # Parameters passed to the template: -a amd64 -r precise
> > > > > # Template script checksum (SHA-1):
> > > > > b1f15036868c53cca0698f1efcadd88dfefaee9b
> > > > 
> > > > So as it stands, when you clone a container etc the comments
> > > > get dropped.  When you use the API to add a config item and
> > > > rewrite it, you lose comments.
> > > 
> > > Hi Serge, I also noticed that when you clone the lxc.id_map items
> > > get dropped as well. Maybe this is intentional though, I guess the
> > > clone should really get some new, unique range but we'd have to
> > > figure out what that range is and also shift the ids in the rootfs
> > > so that seems like not an easy problem.
> > 
> > I did not do this intentionally.  I think this is a bug (missing block
> > of code) in the save_config code.
> > 
> > I think it woudl be better to have lxc-clone maintain the uid
> > mappings, then have a separate minimal utility (or api function) to
> > shift the uids.  Really the 'container-userns-convert' script should
> > become an api function and should shift from any uid mapping to any
> > other (not just non-mapped to newly mapped).
> 
> Yeah that makes sense to be able to shift independent of lxc-clone, but
> I was thinking it would also be nice if the thing that is doing the
> shift could automatically find a large enough hole in the id space, so
> that (maybe with a flag to lxc-clone?) when a container (that has
> id_mappings) is cloned it could be shifted so as not to share id space

Consider snapshot clones.  Those can't very well be uid-shifted without
a huge cost.  We can exempt those (or just let the user beware), but
the number of possibilities is become larger and larger.

I'm not saying we can't reconsider this later, just that I'd rather
punt on it for now.  And if we find later on that

	c = lxc.Container("a1");
	c2 = c.clone(...);
	c2.idshift(newrange);

is clunky enough to integrate idshift straight into clone, we can do it
then.

Hell I can't even get lxc-create right :)

> with the parent. Where the 'map' of the whole space comes from so we can
> find holes though is the tricky part (all the configs in all lxcpath's +
> the new shadow-utils dbs? ug).
> 
> I think for now having lxc-clone just maintain the mapping and manually
> managing the chunks of id space is fine.