On Thu, 11 Jul 2013 18:05:53 -0500 Serge Hallyn <serge.hal...@ubuntu.com> wrote:
> Quoting Dwight Engen (dwight.en...@oracle.com): > > On Thu, 11 Jul 2013 16:24:43 -0500 > > Serge Hallyn <serge.hal...@ubuntu.com> wrote: > > > > > Quoting Dwight Engen (dwight.en...@oracle.com): > > > > On Thu, 11 Jul 2013 09:22:47 -0500 > > > > Serge Hallyn <serge.hal...@ubuntu.com> wrote: > > > > > > > > > Quoting Stéphane Graber (stgra...@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. ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
