[lxc-devel] 0.9.x versions before 1.0

[Dwight Engen]

On Thu, 11 Jul 2013 18:05:53 -0500
Serge Hallyn <serge.hallyn at ubuntu.com> wrote:

> 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.

Yeah I was wondering how bad it would be on btrfs where it should just
have to write new inode metadata so I did a snapshot clone of a 350M
(13570 inodes) container and then uid shifted it. df used went from
366M to 393M. That looks like ~8% expansion, at this inode/data ratio.
Not horrible, but certainly not cheap. LVM snapshots may be worse.
 
> 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

Yep, totally agree on punting it for now.