[lxc-devel] 0.9.x versions before 1.0

Dwight Engen dwight.engen at oracle.com
Thu Jul 11 21:59:46 UTC 2013


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




More information about the lxc-devel mailing list