On Fri, May 30, 2014 at 6:41 PM, Serge Hallyn <[email protected]> wrote: > Quoting Serge Hallyn ([email protected]): >> Quoting S.Çağlar Onur ([email protected]): >> > On Wed, May 28, 2014 at 8:32 PM, S.Çağlar Onur <[email protected]> wrote: >> > > Hi Serge, >> > > >> > > On Tue, May 27, 2014 at 5:24 PM, Serge Hallyn <[email protected]> >> > > wrote: >> > >> Originally we kept snapshots under /var/lib/lxcsnaps. If a >> > >> separate btrfs is mounted at /var/lib/lxc, then we can't >> > >> make btrfs snapshots under /var/lib/lxcsnaps. >> > >> >> > >> This patch moves the default directory to /var/lib/lxc/c/snaps. >> > >> If /var/lib/lxcsnaps already exists, then we continue to use that. >> > >> >> > >> add c->destroy_with_snapshots() and c->snapshot_destroy_all() >> > >> API methods. c->snashot_destroy_all() can be triggered from >> > >> lxc-snapshot using '-d ALL'. There is no command to call >> > >> c->destroy_with_snapshots(c) as of yet. >> > >> >> > >> lxclock: use ".$lxcname" for container lock files >> > >> that way we can use /run/lock/lxc/$lxcpath/$lxcname/snaps as a >> > >> directory when locking snapshots without having to worry about >> > >> /run/lock//lxc/$lxcpath/$lxcname being a file. >> > >> >> > >> destroy: split off a container_destroy >> > >> container_destroy() doesn't check for snapshots, so snapshot_rename can >> > >> use it. api_destroy() now does check for snapshots (previously it only >> > >> checked for fs - i.e. overlayfs/aufs - snapshots). >> > >> >> > >> Add destroy to the manpage, as it was previously undocumented. >> > >> >> > >> Update snapshot testcase accordingly. >> > >> >> > >> Signed-off-by: Serge Hallyn <[email protected]> >> > > >> > > This version is not cleanly getting applied on top of current master >> > > so I ended up modifying the patch locally. I might have introduced a >> > > problem or two while doing that cause my tests started to fail with >> > > this. Unfortunately I haven't been able to find some time to debug it >> > > further. Will try again and catch you on irc tomorrow. >> > >> > So I found why my tests are failing and my first reaction was blaming >> > the Go bindings but then I realized that python bindings are also not >> > working. Somehow this patch is causing create to fail and I'm not >> > seeing how. Please see below, same thing happens with Go (a file named >> > as template argument appears in the directory but nothing else >> > happens) but lxc-create works just fine. >> > >> > [caglar@qop:~/t] pwd >> > /home/caglar/t >> > [caglar@qop:~/t] sudo lxc-ls >> > [caglar@qop:~/t] ls >> > [caglar@qop:~/t] sudo python3 >> > Python 3.4.0 (default, Apr 11 2014, 13:05:11) >> > [GCC 4.8.2] on linux >> > Type "help", "copyright", "credits" or "license" for more information. >> > >>> import lxc >> > >>> c = lxc.Container("r") >> > >>> c.create("ubuntu") >> > True >> > >>> >> > [caglar@qop:~/t] cat ubuntu >> > lxc.network.type = veth >> > lxc.network.flags = up >> > lxc.network.link = lxcbr0 >> > lxc.network.hwaddr = 00:16:3e:e6:0b:a0 >> >> Hey, >> >> ok so I tried to reproduce this just now and couldn't. Which tree did >> you apply this to? Can you maybe push the result as a git tree? Before > > Or, the whole tree I originally was using is at git://github.com/hallyn > #snaps5
I was testing this patch on top of current master (head is at c83462d56d). I have limited connectivity right now but I'll push it to a branch tomorrow and will let you know. >> I was just building from git and had no problems. This time I >> pushed against >> https://launchpad.net/~ubuntu-lxc/+archive/daily/+files/lxc_1.0.3%2Bmaster%7E20140525-1523-0ubuntu1%7Etrusty.dsc >> (which required some twiddling as the ppa appears to be out of date), >> but still creation through the api is working fine for me. Tried >> both busybox and ubuntu templates. >> >> Is it possible that you installed in a way that there are no available >> templates (or they are in the wrong place)? Still doesn't explain >> why 'ubuntu' would show up in your current path... > _______________________________________________ > lxc-devel mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-devel -- S.Çağlar Onur <[email protected]> _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
