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 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... -serge _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
