=== unreal_ is now known as Guest11281 [00:00] Are the various bugs (AFAIK, race conditions/filesystems not mounted) that "funk" my server when upgrading fixed yet? 11.04 is running fine, but I'm leaving for a few years and would like to upgrade. I tried and failed (thankfully I had a backup) [00:02] CT1: for such systems I've found it best to use the LTS's - 12.04 is coming up in april [00:05] & even then you may only want to automatically install the security patches, but whether or not you host will remain up/boot is so-so. Best to make use of a "cloud-based" solution (like amazon/rackspace/etc), to that you can administer the host remotely, rather than a physical box that you need to be physically present to "press F1 to continue" - or whatever [00:09] kieppie: I'd certainly go for 12.04 but I have time constraints. I need to leave before 12.04 is officially released (let alone becomes stable) It's a: HP Proliant ML370G5 who's task is to run 4 server guests in virtualbox (headless) [00:09] kieppie: Updates set to manual [00:11] :/ VB wouln't be my platform-of-choice.... In that case 10.4 should be what you'll need to use (I think it should still be supported up until the next LTS after this next release... 14.04 possibly), but probably better may be to keep things simple & use straight-up Debian [00:15] kieppie: "If it ain't broke, don't fix it"...? They all work with 11.04 but I'm paranoid about security fixes/patches/updates (which will cease for 11.04 sooner than I'd like). [01:36] hallyn, around ? [03:25] smoser: you want me to merge thant into cobbler? [03:25] (the import-fix-unkown distros branch) [03:26] well, please think about it first [03:26] and in general my update-existing stuff [03:26] it seems reasonable to me [03:27] do we expect that people would have distoros that were ubuntu that were not named like we're proposing? [03:27] (this will avoid them, but in general, i was wondering) [03:27] ie, was smb, "wrong" to have that distro there? or is there a valid reason for having it. [03:33] smoser: yeah I found of couple issues like that, but in general, cobbler automatically adds thei386 or x86_64 if they are not specified already [03:33] arch [03:34] smoser: sorry im on a crappy 3g connection [03:34] ah. [03:34] so were really only fighting the case where the user specified a name [03:34] smoser: but found situation on whic it double adds [03:35] so we're "claiming" precise-x86_64 [03:35] smoser: yea if you add a name like XYZ-bablabla and it detects or we specify the arch, then it will automatically add the arch [03:35] if the user had imported that name some other way, we could be potentially destroying some of their data i think. [03:35] smoser: yes I think it is best to do it that way -arch [03:35] i totally agree by having that standard, and maybe adding [03:36] the date of when the iso was imported [03:36] idont see a lot o f reason for multiple distro [03:36] do you? [03:36] like precise-YYYYMMDD-arch [03:36] nah. we're updating, and the update is safe. [03:36] i think [03:36] but we coudl ose data if the user had imported say a desktop DVD (and thus had local archive) [03:37] smoser: definitely not having multiple distros, or imports, unless we are doing something with ubuntu+1 [03:37] that requires some kind of record for comparison [03:37] but I don't really think that's the mojority of the cases [03:38] i guess we could tag some data in the distro [03:38] like "mini-iso" somewhere (not just in name) [03:38] and then only update if it had that [03:38] smoser: i think that'd actually be a good idea [03:38] you see what i'm concerned about? [03:39] i really dont think its a *big* deal [03:39] I guess we could a value for that in cobbler [03:39] smoser: and yeah I see your concerns [03:39] I think there's [03:39] much to improve [03:39] but, if its gonna get dictched next release then that much effort would be worthless [03:42] fair. [03:42] for each item (distro, profiel) is there no general "tag" mechanism ? [03:43] smoser: not really, but we could add something for each distro. it currently has os-version and breed [03:43] smoser: so adding something for ubuntu specific could be easily achieved [03:44] smoser: unless we use the comment section of a distro [03:44] i dont think its a big concern. [03:45] we could just warn or document on import [03:45] if they're importing "ubuntu-" and it isn't coming from a mini-iso [03:45] basically, we're claiming that namespace [03:45] smoser: yeah. Though importing a full server iso, alternate, or mini doesn't really make any difference befcause we don't use the "mirror" (debs that come with the ISO) for installation [03:46] oh, we don't? [03:46] then, yeah, its useless [03:47] QA people were ewanting the ability to do that [03:47] ie, they want to test "this ISO", not necessarily what is current [03:47] smoser: that's pretty simple, it is just changing 2 lines in the preseed were we specify the mirror [03:48] smoser: right, yeah I was trying to figure out what's the best wa to achieve that automatically [03:48] but since we were using the proxy, then there was no need anymore [03:48] but it is totally possible and just requires couple of lines of modification [03:49] well... [03:49] so for now, i guess unless you have other reservations, take the --update-existing fix [03:49] we own "-" [03:49] ok cool [03:52] smoser: will take it tomorrow, im off now. have a good one [04:06] New bug: #921921 in lxc (main) "add support to lxc tools for cloning with btrfs snapshots" [Undecided,New] https://launchpad.net/bugs/921921 [04:10] SpaceBass, hallyn https://code.launchpad.net/~smoser/ubuntu/precise/lxc/btrfs-clone-support/+merge/90236 [04:13] s/SpaceBass/SpamapS [04:15] hola, is a potential for creating an email server available for Linux? === james_ is now known as blitzkrieg3 [06:33] Hi I have powernap configured on my server because I would like it to shut down when not in use. That being said it isnt shutting down the computer as configured. [06:34] I have set verbose/debug to 3 so I can see everything and basically it triggers shut down but doesnt and resets the counters. === [1]MarcelT3 is now known as MarcelT3 [06:40] Here is my config file and my powernap logs. http://paste.pocoo.org/show/540898/ [06:41] as you can see ther powernap.log resets and never actually hibernates. [07:09] Oddly enough I can get powernap to work only if I restart my system and then it only works for a given number of times. The powernap.err file doesnt have anything in it. [08:19] hey guys im using virt-manager connected perfectly fine to a remote server. I create a guest and for some reason i am unable to pxe boot does anyone have any help or ideas as to how to remedy this issue [08:32] eagles0513875_, If you use the default virtual network you would have to have the remote host prepared to be the tftp server. [08:33] eagles0513875_: what have you done to debug this ? [08:33] The other stuff won't apply but the things under "EnablingPXE boot" may help: https://wiki.ubuntu.com/Kernel/Reference/Orchestra [08:33] eagles0513875_: have you setup pxe boot, have you setup the images/boot options, do you have dhcp setup ? [08:34] smb: ikonia well it seems like xen is possibly an issue as the guest boots tries to pxe then it instantly shutsdown [08:35] not what I asked [08:35] eagles0513875_: have you setup pxe/tftp/dhcp ? [08:35] ikonia: im using all default settings that came with ubuntu-orchestra [08:35] again - not what I asked [08:35] eagles0513875_: have you setup pxe/tftp/dhcp ? [08:36] ikonia: arent those part of the orchestra server ? or am i mistaken on that [08:36] eagles0513875_: CHECK ! [08:36] eagles0513875_: rather than coming saying "pxe doesn't work, help" - CHECK [08:36] eagles0513875_: how are we meant to advise you like that [08:36] eagles0513875_: check the basics, is pxe setup, is dhcp setup, is there a working tftp server [08:36] is there a working dhcp server [08:37] are they all configured to listen on the right network for your host [08:37] this is schoolboy basics [08:37] In theory orchestra sets things up (if you not declined that on installation) [08:37] you're supposed to be a professional Linux systems administrator and you ask for help 1.) not checking if these servics are even installed 2.) be if they are running 3.) are they configured 4.) you give the error problems "pxe is not working" - come on, help us out a bit [08:38] But all only works when the orchestra host is in the same network [08:38] tftp does not cross subnets [08:38] dhcp won't unless you relay it or bridge it [08:38] <_ruben> tftp can be routed just fine afaik? [08:38] this is why checking the basics of the components [08:39] _ruben, it did not for me (simply) [08:39] _ruben, I either had to modify the virtual network definitions or create a transparent bridge for it [08:39] <_ruben> smb: it does require the tftp netfilter helper modules indeed [08:40] <_ruben> as with ftp and the likes [08:40] _ruben, Ah ok. Did not think of those [08:41] _ruben, In the end the transparent bridge setup suited me best as the vm's now are seamlessly integrated in the same home net [08:42] _ruben: tftp is just udp, which runs over IP, which is routable [08:42] <_ruben> smb: in my case i have a seperate vlan for pxe installs, with the tftp and local repo on a different vlan [08:42] <_ruben> RoyK: it using random ports is the challenge [08:42] _ruben: that's where ipt_conntrack_tftp and friends come in :P [08:42] <_ruben> RoyK: yup [08:43] <_ruben> which is what i said :) [08:43] <_ruben> ipt_ is old tho ;) [08:43] <_ruben> nf_ ;) [08:44] whadevver [08:44] Random module renaming to keep people "interested"... ;) [08:44] :þ [08:56] <_ruben> :) [09:02] _ruben, Probably stupid, just out of interest as I have neglected fw stuff: would you need to set up a fw and rules for tftp conntrack to be useful or can that be done just by loading the module with the target port specified (think rather not) [09:03] I've always needed a iptables rules to forward === jtv is now known as jtv-eat === airtonix_ is now known as airtonix [09:05] Ok, that is along what I expected. Really need to play around more with that stuff... :/ [09:09] <_ruben> in my case the router is a fairly strict firewall .. but even then all it took was: load helper modules, allow the tftp port in FORWARD, allow RELATED and ESTABLISHED states in FORWARD [09:09] <_ruben> as it's more of a firewall issue than routing issue really [09:09] <_ruben> iirc, been a while since i set thi sup [09:09] I guess any helper will do, but at a base technology it's still a helper rule [09:16] I guess it depends on the approach. For tftp it is sort of a routing problem (and searching the net just with generic keywords does also lead to things like tftp-proxy). But defining that as part of the firewall setup makes a lot of sense as you fiddle around with what goes where anyway. === jtv-eat is now known as jtv [09:38] hi, i have installed the kernel update on 10.04 today(2.6.32-38-server). I also have drbd installed and the module is not longer working, error message as http://paste.ubuntuusers.de/405277/ [09:38] any hints what I can do? [09:40] or why dkms was not working well? [09:41] juliux_, Not sure why it did not recompile, but it sounds like that is what happened [09:42] To fix it you have to go trhough the pains of dkms uninstall, buiild and install the module [09:49] smb: i fixed it by aptitude reinstall drbd8-source [09:49] smb: but i am wondeirng why it is not triggered correctly… [09:51] juliux_, Hard to say. If it happens to me I am usually at fault for installing kernels of the same version but a bit different. [09:52] smb: ok [09:52] juliux_, Maybe you had been using a test kernel...? === jtv1 is now known as jtv [09:58] smb: i am only using the kernels from the repository so no custom build kernels [09:59] juliux_: I don't think kernel upgrades will autoinstall custom modules [09:59] I might be wrong, though [09:59] juliux_, Ah ok. Weird then. Should not be the differing in the [09:59] modversion if not a different abi [10:00] RoyK, There should be a hook called to update dkms modules [10:00] k [10:12] !ciao [10:12] !list [10:12] This is not a file sharing channel (or network); be sure to read the channel topic. If you're looking for information about me, type « /msg ubottu !bot ». If you're looking for a channel, see « /msg ubottu !alis ». === Hetep is now known as DarthCaeduces === uvirtbot` is now known as uvirtbot [12:31] > hey all.. im seeing a weird prob w/ ubuntul installer.. the partitioner doesnt see my hdd but i can see it when dropping to a shell and doing fdisk -l [12:31] list [12:32] fabro: huh? [12:33] ciao mi sono appena reggistrato e non so come funziona questo programma [12:34] conoscevo kvirc ma non credo che funzioni allo stesso modo [12:39] qualcuno puo aiutarmi??? === Hetep is now known as DarthCaeduces === Hetep is now known as DarthCaeduces [12:43] ne1? [13:56] good morning [14:05] Hm. Anyone know of a resonably maintained backport of a more recent openjdk to lucid? [14:06] maswan: which architecture? [14:07] xranby: amd64 [14:08] maswan: in my experience simply recompiling the latest openjdk sourcecode on older ubuntu releases usually work fine [14:08] maswan: unfortunally i do not host any premade .deb's [14:08] maswan: i track openjdk on arm [14:09] xranby: Ok. There is an openjdk ppa, but that doesn't look maintained. [14:11] maswan: in the icedtea project we recompile the latest openjdk sourcecode almost daily using debian squeeze so it should be all possible to do [14:14] xranby: thanks. I'll keep that option in mind. The other ones are suffering through bugs for another couple of months and/or pretend that sun-java doesn't *really* need updates until I can upgrade to precise. :) [14:14] maswan: you can try compile openjdk from source manually it sould be quite quick fist apt-get build-dep openjdk-6 apt-get mercurial then hg clone http://icedtea.classpath.org/hg/icedtea6 then cd icedtea6 [14:14] ./configure --disable-docs --disable-bootstrap [14:14] time make [14:14] on a fast machine this should complete within 30min [14:15] thanks. roughly how much diskspace is needed? is a few gigs enough? [14:16] yes 4 gig should be enough [14:27] smoser: btrfs is stable for you? [14:27] for that test [14:27] i did one clone [14:27] you should not gate that patch based on stability of the kernel though [14:28] (yeah, that sounds strange), because btrfs will be stable at some point, and is stable for some workloads [14:29] i've been saying "it'll be stable at some point" for years. [14:29] i'm growing dubious [14:30] well, for some workloads it is stable. [14:30] and it is extremely useful [14:30] smoser: i'm not sure about the way you're using it though [14:30] that's really waht's kept me from doing a trial implementation [14:31] explain? [14:31] ideally, we'd configure one path for all the rootfs's. so that 'subvolume' can be better used [14:31] i.e. /var/lib/lxc/btrfs would be the anchor for all btrfs rootfs's [14:32] lemme look at your clone again (was looking at create) [14:33] smoser: ok, so you assume /var/lib is entirely btrfs [14:33] does that work? i didn't think you used to be able to do that. (subvolume create /a/b/c /a/d/e) [14:33] if so that's an improvement [14:34] i dont follow. [14:34] i admit to only having ~ 90 minuts of btrfs expereicne [14:34] i dont assume anything is entirely btrfs [14:34] i try to create a subvolume at the rootfs [14:34] i thought that 'btrfs subvolume p/a p/b' required a and b to be children of the same dir [14:35] well regardless, my suggestion stands. let me rephrase it, and get your feedback: [14:35] i think use of btrfs for backing stores should be independent of rootfs fstype [14:36] so i recommend having a separate btrfs rootfs under /var/lib/lxc/btrfs, creating rootfs's there, and then bind-mounting them into /var/lib/lxc//rootfs (like we do with lvm mounts) [14:37] stgraber: ^ do you have any opinion? [14:37] i dont think you should bind mount. [14:37] i think un-necessary complication [14:37] smoser: but thanks for doing it. i really do want btrfs snapshot support [14:37] i think it fits nicely with how we will do all backing stores [14:37] at container startup, you figure out the backing store type, [14:38] and mount it (however necessary) into /var//lib/lxc/container/rootfs [14:38] it is independent of rootfs type [14:38] at shutdown, umount. [14:38] it just dpeends that somewhere in the filesystem chain above /var/lib/lxc there is a btrfs [14:38] if there is not, it will fail [14:39] i'm not ENTIRELY opposed, it just seems like it several limits flexibility [14:39] s/several/severely/ [14:39] smoser: i may well be off base. let's see what stgraber thinks. [14:39] smoser: if we do it your way, [14:40] then no need to specify '-B btrfs'. we can just detect fstype of /var/lib/lxc [14:40] this is correct [14:40] i didn't do that, but it could. [14:40] i do think generally, the lxc scripts need some notion of "source" like schroot manages [14:41] ? [14:41] i dont like that it creates a filesystme and then tries to "clean it" [14:41] it should create a source, and then clone the clean one [14:41] i think the cmdline is complicated enough already that the more we can not add args, the better [14:42] ... what do you mean by 'clean' it? [14:42] i think the command line could generally use some re-work, yes. [14:42] you do things like re-writing /etc/hostname in the guest [14:42] and some hacks like zeroing some dhcp leases file [14:42] dirty [14:42] ah, yes. well someone needs to. it's cleaner than cloud-init :) [14:42] as opposed to making a perfectly clean source [14:42]

[14:43] isn't hte source in /var/cache/lxc perfectly clean? [14:43] what source? [14:43] there is no notion of source. [14:43] only if the user manages that themselves [14:43] oh. [14:43] there is a clean debootstrapped copy in /var/cache/lxc/ [14:43] actually... i ddin't know aobut /var/cache/lxc [14:43] i completley missed that. [14:43] so clearely i'm a moron. [14:43] adam_g: are any of the labs free for me to use? [14:44] anywahy... [14:44] jamespage: ^^ [14:44] that's the thing we'd be replacing with 'lxc-download' [14:44] smoser: i see, you'd like to have /var/cache/lxc be btrfs too and have each lxc-create be a snapshot? [14:45] well., that would make sense to me, yeah. [14:45] when i got to looking at things, as you said,t he scripts were more complex than i had wanted. [14:45] smoser: do you have an ami for a btrfs-backed instance? or are you just mounting /dev/vdb as btrfs? [14:45] here, take a look [14:46] ubuntu@10.55.60.32 [14:46] thats a clean intsance, then i ran [14:46] http://paste.ubuntu.com/817705/ [14:46] that's what i figured, thanks [14:50] hallyn: I don't really have a strong opinion on this. I guess it'd make sense for the container rootfs to be a snapshot of the cache. Now if both /var/cache/lxc and /var/lib/lxc are on the same FS and are btrfs, I guess we shouldn't do any particular magic (other than doing a snapshot). Where we might want to do some magic is if /var/cache/lxc is btrfs but /var/lib/lxc isn't [14:51] hallyn: Using /var/lib/lxc/btrfs as some kind of LVM VG, then creating a sub-directory for the cache and then one snapshot for container would work too, then either use symlinks or bind mounts [14:51] stgraber: so you think we should support only that case, and not the separate -B btrfs with rootfs anchored elsewhere? [14:51] (so as you can see, no strong opinion ;)) [14:51] hm [14:51] maybe something to discuss at UDS [14:51] with dlezcano present [14:54] smoser: howdy!! So based on our discussion yesterday, I was also thi nking whether it would be a good idea for use to use -amd64 instead of x86_64 [14:54] no [14:54] :) [14:54] i dont think so. [14:54] i dont see a reason to fight cobbler [14:54] hallyn: that's actually the problem with btrfs, it's doing a whole bunch of stuff that our current filesystems don't do, so it's not always clear if we need to treat it as some storage backend like LVM or if we need to treat it as a regular filesystem :) [14:54] import takes 'amd64' and changes it to 'x86_64' and tells the user [14:55] smoser: cause issues like this (not that are *that* important) appear: bug #921597 [14:55] Launchpad bug 921597 in orchestra "Systems Architecture when importing apt repos does not match $(ARCH) in sources.list" [Low,Confirmed] https://launchpad.net/bugs/921597 [14:55] stgraber: ideally i'd say we support both, but i really don't want to complicate the script usage if we don't have to. [14:55] hallyn, stgraber i really do not understand why you'd complicate things with bind mounts [14:55] so, right now i'm leaning toward doing it by requiring /var/cache/lxc and /var/lib/lxc be (the same) btrfs entirely [14:55] smoser: nothing that a symlink could solve though [14:55] smoser: the bind mounts would only be for the duration of a container living. it's not really a complication - it's mounting the rootfs [14:56] smoser: actually, i guess we don't have to do it all [14:56] we can just set 'rootfs = /var/lib/lxc/btrfs/container' [14:56] so never mind the bind mount. my point was mainly that the rootfs be elsewhere [14:57] smoser: is this something you were hoping to get hammered out in the next week or two? or just something you're experimenting with long-term? [14:57] i think setting rootfs is complex [14:58] i would hope that we could have something functional for precise [14:58] btrfs is "supported" in ubuntu [14:59] well, maybe rootfs wouldn't be so bad [14:59] i'm guessing you're saying /var/lib/lxc// still contains 'config' [14:59] rootfs is fine as long as the user doesn't have to mess with it (which they won't in this case) [14:59] and then you could still have /var/lib/lxc//rootfs be a symlink to the source [15:00] stgraber, the user of 'lxc-create' is not likely the only thing expecting some behavior of lxc scripts [15:00] yes to first part. /ar/lib/lxc//rootfs wouldn't be a symlink, rather lxc-start would just use /var/lib/lxc/btrfs/ as the rootfs instead of using /var/lib/lxc//rootfs [15:00] there are other things that are likely built atop that make assuptions [15:01] hallyn, i'm suggesting the symlink to mak things that expect /rootfs to continue to work [15:01] stgraber: i have to agree with christian (in email) - lxc-start is taking too long [15:02] wel.. [15:02] i just pushed again to that branch, and it works for me. [15:02] smoser: so why not just have /var entirely be btrfs? [15:02] in my isntance? [15:02] its just more invasive [15:02] and just have the code silently detect that and snapshot ? [15:02] and more of a pain [15:02] no, for anyone wanting to use btrfs [15:03] i'm confused as to what you're asking [15:03] the branch i submitted doesn't care [15:03] hallyn: something seems to have regressed indeed. A precise container used to take 2-3s to boot here, it's now taking over 30s [15:03] really i'm saying either we trust btrfs for rootfs, or we don't trust it [15:03] the branc you submitted adds '-B btrfs'. [15:03] stgraber: i'll open a bug. (though not sure i can look at it today) [15:04] right,, but it doesn't care where the filesystem that houses the btrfs lives [15:04] buti'm fine to make it not even need '-B btrfs' [15:04] hallyn: it's the dhclient call that's slowing down the boot in my case. Moving to static networking and I get a boot in less than 2s [15:05] * stgraber is creating a new container cache to be fully up to date [15:05] stgraber: do you get that both using lxcbr0 and virbr0? [15:05] i just booted in under 6 seconds [15:05] (by human count) [15:05] hallyn: that test was with virbr0. I'll try the clean container with both [15:05] but to login prompt in < 6 with defaults everywhere. [15:06] hallyn: oh, I just noticed virbr0 now has STP turned on, I guess that explains [15:08] stgraber: hm, me too [15:09] whereas stp is off for lxcbr0. i wonder why [15:09] so what manages /var/cache/lxc ? [15:09] but it seems there's a kernel bug i need to look at. bbl [15:09] smoser: lxc-ubuntu template does it [15:14] hallyn: clean precise container on virbr0 without STP => took 2s to boot with DHCP [15:17] stgraber: so i wonder why libvirt is turning stp on. or is bridge-utils doing it? [15:17] hallyn, so what changes do you want to btrfs support? [15:18] New bug: #914257 in horizon (universe) "local_settings.py isn't installed as a config file" [Medium,Fix released] https://launchpad.net/bugs/914257 [15:18] you want roots to go in /var/lib/lxc/btrfs [15:18] smoser: I'm fine with your patch actually. jsut to verify though, [15:19] i see value in /var/lib/lxc/btrfs//rootfs [15:19] btrfs subvolume /var/lib/lxc/a/rootfs /var/lib/lxc/b/rootfs really works? [15:19] hallyn: I don't know but it's new. I'm 99% sure I didn't have stp turned on just a few weeks ago [15:19] hallyn, look at that instance [15:19] and either tell me i'm an idiot, or that it apparently does [15:19] (scrolling back up for the ip) [15:19] it definitely *succeeds* [15:19] and really quickly [15:25] smoser: your patch is good. we can always add the automatic detection of /var/cache/lxc and /var/lib/lxc being btrfs later [15:26] smoser: thanks. do you want to push a new lxc with that? [15:27] (i see jamespage assigned the bug to you :) [15:27] its trival to add [15:27] i can do it if you want [15:27] have at [15:27] yay, btrfs support! [15:28] i'll make it so lxc-create doesn't need -B [15:28] but i'm not going to touch the cache at this point [15:30] smoser: do you think there is any sense in support lxc-clone without -s for btrfs and not having it do snapshot? [15:31] (i'm not sure there is) [15:31] i dont follow the question [15:31] robbiew: hey so I talked to Daviey and we think #ubuntu-cloud should just redirect here [15:31] another channel makes no sense IMO [15:31] smoser: with lvm, if you don't say lxc-clone -s, it will do a copy, not snapshot [15:33] oh. [15:34] i'll try to make it so that if user explicitly does "-s none" then it will not auotmatically use btr [15:34] but will just copy [15:34] smoser: ok (that's what i was wondering, if there is any case where users would want that. apart from btrfs bugs, i'm not sure there are) [15:34] smoser: separately, do you mind taking a look at https://code.launchpad.net/~guilhem-fr/vmbuilder/oneiric-support/+merge/89858 ? [15:35] hallyn, i coudn't come up with a usec ase for it. [15:35] smoser: then always do snapshot [15:35] other than '-s overlayfs' [15:36] i'll add a option to lxc-clone to specify the type of clone [15:36] overlayfs is a funky case bc it wouldn't survive reboot [15:36] rather than just "-s" meaning "use a snapshot" [15:36] overlayfs would survie a reboot [15:36] i'd prefer doing the simplest btrfs for now and holding off on lxc-clone argument changes [15:36] if you did things right [15:36] lxc start would just have to re-mount stuff [15:37] done through /var/lib/lxc//fstab? [15:37] might work [15:38] might work nicely [15:40] so should i add '-S' to specify snapshot type? [15:40] and default to auto-detecting [15:41] jcastro: fine by me [15:46] smoser: lxc-clone is upstream, so whatever you do in that respect should be sent to lxc-users mailing list for discussion. But, [15:46] smoser: (thinking) [15:47] smoser: yeah i think that sounds fine. [15:47] i'm just thinking about how that interacts with the lvm stuff [15:47] lxc-clone -o old -n new -> just copies [15:48] lxc-clone -s -o oldlvm -n newlvm -> does lvm snapshot [15:48] lxc-clone -s -S overlayfs -o oldlvm -n newdir ? [15:49] i guess -EINVAL on that. either do lvm snapshot or overlayfs, not both [15:51] yeah, i think just fail on that case. [15:51] overlay would only work if 'old' was a directory [16:11] zul: do you have a machine that has your bzr credentials and is always online? [16:11] zul: i'm considering just doing skunkworks to keep the precise libvirt bzr tree uptodate [16:11] hallyn: yeah kind of [16:12] zul: script would basically watch the archive, and just do 'bzr import-dsc ; bzr push' any time a libvirt version is pushed [16:13] hallyn: but we are getting it from debian? [16:14] hallyn: thats what the openstack stuff basically does though [16:14] zul: ? i think we're talking different things [16:14] hallyn, ok. i did'nt do the '-S' bit for lxc-clone [16:14] i think we *should* do that [16:14] zul: i'm talking about 'bzr branch ubuntu:libvirt' being out of date with respect to ubuntu's precise archive [16:14] but just didn't want to right now. [16:15] hallyn, yea, fix that (ubuntu:libvirt) [16:15] smoser: ok - thanks! [16:15] hallyn: ah ok...yeah i would totally do that [16:15] zul: ok i'm bringing the tree uptodate now, but would like to see it automated [16:15] hallyn, i guess i should test it on something that isnt btrfs... [16:15] but really, does anyone not run btrfs as their root filesystem anymore? [16:15] ;) [16:15]