[00:00] <CT1> 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] <kieppie> CT1: for such systems I've found it best to use the LTS's - 12.04 is coming up in april
[00:05] <kieppie> & 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] <CT1> 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] <CT1> kieppie: Updates set to manual
[00:11] <kieppie> :/ 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] <CT1> 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] <smoser> hallyn, around ?
[03:25] <roaksoax> smoser: you want me to merge thant into cobbler?
[03:25] <roaksoax> (the import-fix-unkown distros branch)
[03:26] <smoser> well, please think about it first
[03:26] <smoser> and in general my update-existing stuff
[03:26] <smoser> it seems reasonable to me
[03:27] <smoser> do we expect that people would have distoros that were ubuntu that were not named like we're proposing?
[03:27] <smoser> (this will avoid them, but in general, i was wondering)
[03:27] <smoser> ie, was smb, "wrong" to have that distro there? or is there a valid reason for having it.
[03:33] <roaksoax> 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] <roaksoax>  arch
[03:34] <roaksoax> smoser: sorry im on a crappy 3g connection
[03:34] <smoser> ah.
[03:34] <smoser> so were really only fighting the case where the user specified a name
[03:34] <roaksoax> smoser: but found situation on whic it double adds
[03:35] <smoser> so we're "claiming" precise-x86_64
[03:35] <roaksoax> 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] <smoser> if the user had imported that name some other way, we could be potentially destroying some of their data i think.
[03:35] <roaksoax> smoser: yes I think it is best to do it that way <release>-arch
[03:35] <roaksoax> i totally agree by having that standard, and maybe adding
[03:36] <roaksoax> the date of when the iso was imported
[03:36] <smoser> idont see a lot o f reason for multiple distro
[03:36] <smoser> do you?
[03:36] <roaksoax> like precise-YYYYMMDD-arch
[03:36] <smoser> nah. we're updating, and the update is safe.
[03:36] <smoser> i think
[03:36] <smoser> but we coudl ose data if the user had imported say a desktop DVD (and thus had local archive)
[03:37] <roaksoax> smoser: definitely not having multiple distros, or imports, unless we are doing something with ubuntu+1
[03:37] <roaksoax> that requires some kind of record for comparison
[03:37] <roaksoax> but I don't really think that's the mojority of the cases
[03:38] <smoser> i guess we could tag some data in the distro
[03:38] <smoser> like "mini-iso" somewhere (not just in name)
[03:38] <smoser> and then only update if it had that
[03:38] <roaksoax> smoser: i think that'd actually be a good idea
[03:38] <smoser> you see what i'm concerned about?
[03:39] <smoser> i really dont think its a *big* deal
[03:39] <roaksoax> I guess we could  a value for that in cobbler
[03:39] <roaksoax> smoser: and yeah I see your concerns
[03:39] <roaksoax> I think there's
[03:39] <roaksoax> much to improve
[03:39] <roaksoax> but, if its gonna get dictched next release then  that much effort would be worthless
[03:42] <smoser> fair.
[03:42] <smoser> for each item (distro, profiel) is there no general "tag" mechanism ?
[03:43] <roaksoax> smoser: not really, but we could add something for each distro. it currently has os-version and breed
[03:43] <roaksoax> smoser: so adding something for ubuntu specific could be easily achieved
[03:44] <roaksoax> smoser: unless we use the comment section of a distro
[03:44] <smoser> i dont think its a big concern.
[03:45] <smoser> we could just warn or document on import
[03:45] <smoser> if they're importing "ubuntu-" and it isn't coming from a mini-iso
[03:45] <smoser> basically, we're claiming that namespace
[03:45] <roaksoax> 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] <smoser> oh, we don't?
[03:46] <smoser> then, yeah, its useless
[03:47] <smoser> QA people were ewanting the ability to do that
[03:47] <smoser> ie, they want to test "this ISO", not necessarily what is current
[03:47] <roaksoax> smoser: that's pretty simple, it is just changing 2 lines in the preseed were we specify the mirror
[03:48] <roaksoax> smoser: right, yeah I was trying to figure out what's the best wa to achieve that automatically
[03:48] <roaksoax> but since we were using the proxy, then there was no need anymore
[03:48] <roaksoax> but it is totally possible and just requires couple of lines of modification
[03:49] <smoser> well...
[03:49] <smoser> so for now, i guess unless you have other reservations, take the --update-existing fix
[03:49] <smoser> we own "<codename>-<arch>"
[03:49] <roaksoax> ok cool
[03:52] <roaksoax> smoser: will take it tomorrow, im off now. have a good one
[04:06] <uvirtbot`> 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] <smoser> SpaceBass, hallyn https://code.launchpad.net/~smoser/ubuntu/precise/lxc/btrfs-clone-support/+merge/90236
[04:13] <smoser> s/SpaceBass/SpamapS
[04:15] <Hetep-AFK> hola, is a potential for creating an email server available for Linux?
[06:33] <Zanzacar> 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] <Zanzacar> I have set verbose/debug to 3 so I can see everything and basically it triggers shut down but doesnt and resets the counters.
[06:40] <Zanzacar> Here is my config file and my powernap logs. http://paste.pocoo.org/show/540898/
[06:41] <Zanzacar> as you can see ther powernap.log resets and never actually hibernates.
[07:09] <Zanzacar> 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] <eagles0513875_> 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] <smb> eagles0513875_, If you use the default virtual network you would have to have the remote host prepared to be the tftp server.
[08:33] <ikonia> eagles0513875_: what have you done to debug this ?
[08:33] <smb> The other stuff won't apply but the things under "EnablingPXE boot" may help: https://wiki.ubuntu.com/Kernel/Reference/Orchestra
[08:33] <ikonia> eagles0513875_: have you setup pxe boot, have you setup the images/boot options, do you have dhcp setup ?
[08:34] <eagles0513875_> smb: ikonia well it seems like xen is possibly an issue as the guest boots tries to pxe then it instantly shutsdown
[08:35] <ikonia> not what I asked
[08:35] <ikonia> eagles0513875_: have you setup pxe/tftp/dhcp ?
[08:35] <eagles0513875_> ikonia: im using all default settings that came with ubuntu-orchestra
[08:35] <ikonia> again - not what I asked
[08:35] <ikonia> eagles0513875_: have you setup pxe/tftp/dhcp ?
[08:36] <eagles0513875_> ikonia: arent those part of the orchestra server ? or am i mistaken on that
[08:36] <ikonia> eagles0513875_: CHECK !
[08:36] <ikonia> eagles0513875_: rather than coming saying "pxe doesn't work, help" - CHECK
[08:36] <ikonia> eagles0513875_: how are we meant to advise you like that
[08:36] <ikonia> eagles0513875_: check the basics, is pxe setup, is dhcp setup, is there a working tftp server
[08:36] <ikonia> is there a working dhcp server
[08:37] <ikonia> are they all configured to listen on the right network for your host
[08:37] <ikonia> this is schoolboy basics
[08:37] <smb> In theory orchestra sets things up (if you not declined that on installation)
[08:37] <ikonia> 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] <smb> But all only works when the orchestra host is in the same network
[08:38] <smb> tftp does not cross subnets
[08:38] <ikonia> dhcp won't unless you relay it or bridge it
[08:38] <_ruben> tftp can be routed just fine afaik?
[08:38] <ikonia> this is why checking the basics of the components
[08:39] <smb> _ruben, it did not for me (simply)
[08:39] <smb> _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] <smb> _ruben, Ah ok. Did not think of those
[08:41] <smb> _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] <RoyK> _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] <RoyK> _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] <RoyK> whadevver
[08:44] <smb> Random module renaming to keep people "interested"... ;)
[08:44] <RoyK> :þ
[08:56] <_ruben> :)
[09:02] <smb> _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] <ikonia> I've always needed a iptables rules to forward
[09:05] <smb> 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] <ikonia> I guess any helper will do, but at a base technology it's still a helper rule
[09:16] <smb> 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.
[09:38] <juliux_> 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] <juliux_> any hints what I can do?
[09:40] <juliux_> or why dkms was not working well?
[09:41] <smb> juliux_, Not sure why it did not recompile, but it sounds like that is what happened
[09:42] <smb> To fix it you have to go trhough the pains of dkms uninstall, buiild and install the module
[09:49] <juliux_> smb: i fixed it by aptitude reinstall drbd8-source
[09:49] <juliux_> smb: but i am wondeirng why it is not triggered correctly…
[09:51] <smb> 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] <juliux_> smb: ok
[09:52] <smb> juliux_, Maybe you had been using a test kernel...?
[09:58] <juliux_> smb: i am only using the kernels from the repository so no custom build kernels
[09:59] <RoyK> juliux_: I don't think kernel upgrades will autoinstall custom modules
[09:59] <RoyK> I might be wrong, though
[09:59] <smb> juliux_, Ah ok. Weird then. Should not be the differing in the
[09:59] <smb> modversion if not a different abi
[10:00] <smb> RoyK, There should be a hook called to update dkms modules
[10:00] <RoyK> k
[10:12] <pippo> !ciao
[10:12] <pippo> !list
[12:31] <kantxx> > 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] <fabro> list
[12:32] <kantxx> fabro: huh?
[12:33] <fabro> ciao mi sono appena reggistrato e non so come funziona questo programma
[12:34] <fabro> conoscevo kvirc ma non credo che funzioni allo stesso modo
[12:39] <fabro> qualcuno puo aiutarmi???
[12:43] <kantxx> ne1?
[13:56] <zul> good morning
[14:05] <maswan> Hm. Anyone know of a resonably maintained backport of a more recent openjdk to lucid?
[14:06] <xranby> maswan: which architecture?
[14:07] <maswan> xranby: amd64
[14:08] <xranby> maswan: in my experience simply recompiling the latest openjdk sourcecode on older ubuntu releases usually work fine
[14:08] <xranby> maswan: unfortunally i do not host any premade .deb's
[14:08] <xranby> maswan: i track openjdk on arm
[14:09] <maswan> xranby: Ok. There is an openjdk ppa, but that doesn't look maintained.
[14:11] <xranby> 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] <maswan> 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] <xranby> 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] <xranby> ./configure --disable-docs --disable-bootstrap
[14:14] <xranby> time make
[14:14] <xranby> on a fast machine this should complete within 30min
[14:15] <maswan> thanks. roughly how much diskspace is needed? is a few gigs enough?
[14:16] <xranby> yes 4 gig should be enough
[14:27] <hallyn> smoser: btrfs is stable for you?
[14:27] <smoser> for that test
[14:27] <smoser> i did one clone
[14:27] <smoser> you should not gate that patch based on stability of the kernel though
[14:28] <smoser> (yeah, that sounds strange), because btrfs will be stable at some point, and is stable for some workloads
[14:29] <hallyn> i've been saying "it'll be stable at some point" for years.
[14:29] <hallyn> i'm growing dubious
[14:30] <smoser> well, for some workloads it is stable.
[14:30] <smoser> and it is extremely useful
[14:30] <hallyn> smoser: i'm not sure about the way you're using it though
[14:30] <hallyn> that's really waht's kept me from doing a trial implementation
[14:31] <smoser> explain?
[14:31] <hallyn> ideally, we'd configure one path for all the rootfs's.  so that 'subvolume' can be better used
[14:31] <hallyn> i.e. /var/lib/lxc/btrfs would be the anchor for all btrfs rootfs's
[14:32] <hallyn> lemme look at your clone again  (was looking at create)
[14:33] <hallyn> smoser: ok, so you assume /var/lib is entirely btrfs
[14:33] <hallyn> 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] <hallyn> if so that's an improvement
[14:34] <smoser> i dont follow.
[14:34] <smoser> i admit to only having ~ 90 minuts of btrfs expereicne
[14:34] <smoser> i dont assume anything is entirely btrfs
[14:34] <smoser> i try to create a subvolume at the rootfs
[14:34] <hallyn> i thought that 'btrfs subvolume p/a p/b' required  a and b to be children of the same dir
[14:35] <hallyn> well regardless, my suggestion stands.  let me rephrase it, and get your feedback:
[14:35] <hallyn> i think use of btrfs for backing stores should be independent of rootfs fstype
[14:36] <hallyn> 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/<container>/rootfs (like we do with lvm mounts)
[14:37] <hallyn> stgraber: ^ do you have any opinion?
[14:37] <smoser> i dont think you should bind mount.
[14:37] <smoser> i think un-necessary complication
[14:37] <hallyn> smoser: but thanks for doing it.  i really do want btrfs snapshot support
[14:37] <hallyn> i think it fits nicely with how we will do all backing stores
[14:37] <hallyn> at container startup, you figure out the backing store type,
[14:38] <hallyn> and mount it (however necessary) into /var//lib/lxc/container/rootfs
[14:38] <smoser> it is independent of rootfs type
[14:38] <hallyn> at shutdown, umount.
[14:38] <smoser> it just dpeends that somewhere in the filesystem chain above /var/lib/lxc there is a btrfs
[14:38] <smoser> if there is not, it will fail
[14:39] <hallyn> i'm not ENTIRELY opposed, it just seems like it several limits flexibility
[14:39] <hallyn> s/several/severely/
[14:39] <hallyn> smoser: i may well be off base.  let's see what stgraber thinks.
[14:39] <hallyn> smoser: if we do it your way,
[14:40] <hallyn> then no need to specify '-B btrfs'.  we can just detect fstype of /var/lib/lxc
[14:40] <smoser> this is correct
[14:40] <smoser> i didn't do that, but it could.
[14:40] <smoser> i do think generally, the lxc scripts need some notion of "source" like schroot manages
[14:41] <hallyn> ?
[14:41] <smoser> i dont like that it creates a filesystme and then tries to "clean it"
[14:41] <smoser> it should create a source, and then clone the clean one
[14:41] <hallyn> i think the cmdline is complicated enough already that the more we can not add args, the better
[14:42] <hallyn> ...  what do you mean by 'clean' it?
[14:42] <smoser> i think the command line could generally use some re-work, yes.
[14:42] <smoser> you do things like re-writing /etc/hostname in the guest
[14:42] <smoser> and some hacks like zeroing some dhcp leases file
[14:42] <smoser> dirty
[14:42] <hallyn> ah, yes. well someone needs to.  it's cleaner than cloud-init :)
[14:42] <smoser> as opposed to making a perfectly clean source

[14:43] <hallyn> isn't hte source in /var/cache/lxc perfectly clean?
[14:43] <smoser> what source?
[14:43] <smoser> there is no notion of source.
[14:43] <smoser> only if the user manages that themselves
[14:43] <smoser> oh.
[14:43] <hallyn> there is a clean debootstrapped copy in /var/cache/lxc/<rleease>
[14:43] <smoser> actually... i ddin't know aobut /var/cache/lxc
[14:43] <smoser> i completley missed that.
[14:43] <smoser> so clearely i'm  a moron.
[14:43] <roaksoax> adam_g: are any of the labs free for me to use?
[14:44] <smoser> anywahy...
[14:44] <roaksoax> jamespage: ^^
[14:44] <hallyn> that's the thing we'd be replacing with 'lxc-download'
[14:44] <hallyn> smoser: i see, you'd like to have /var/cache/lxc be btrfs too and have each lxc-create be a snapshot?
[14:45] <smoser> well., that would make sense to me, yeah.
[14:45] <smoser> when i got to looking at things, as you said,t he scripts were more complex than i had wanted.
[14:45] <hallyn> smoser: do you have an ami for a btrfs-backed instance?  or are you just mounting /dev/vdb as btrfs?
[14:45] <smoser> here, take a look
[14:46] <smoser> ubuntu@10.55.60.32
[14:46] <smoser> thats a clean intsance, then i ran
[14:46] <smoser> http://paste.ubuntu.com/817705/
[14:46] <hallyn> that's what i figured, thanks
[14:50] <stgraber> 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] <stgraber> 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] <hallyn> stgraber: so you think we should support only that case, and not the separate -B btrfs with rootfs anchored elsewhere?
[14:51] <stgraber> (so as you can see, no strong opinion ;))
[14:51] <hallyn> hm
[14:51] <hallyn> maybe something to discuss at UDS
[14:51] <hallyn> with dlezcano present
[14:54] <roaksoax> 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] <smoser> no
[14:54] <smoser> :)
[14:54] <smoser> i dont think so.
[14:54] <smoser> i dont see a reason to fight cobbler
[14:54] <stgraber> 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] <smoser> import takes 'amd64' and changes it to 'x86_64' and tells the user
[14:55] <roaksoax> smoser: cause issues like this (not that are *that* important) appear: bug #921597
[14:55] <hallyn> 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] <smoser> hallyn, stgraber i really do not understand why you'd complicate things with bind mounts
[14:55] <hallyn> 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] <roaksoax> smoser: nothing that a symlink could solve though
[14:55] <hallyn> 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] <hallyn> smoser: actually, i guess we don't have to do it all
[14:56] <hallyn> we can just set 'rootfs = /var/lib/lxc/btrfs/container'
[14:56] <hallyn> so never mind the bind mount.  my point was mainly that the rootfs be elsewhere
[14:57] <hallyn> 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] <smoser> i think setting rootfs is complex
[14:58] <smoser> i would hope that we could have something functional for precise
[14:58] <smoser> btrfs is "supported" in ubuntu
[14:59] <smoser> well, maybe rootfs wouldn't be so bad
[14:59] <smoser> i'm guessing you're saying /var/lib/lxc/<name>/ still contains 'config'
[14:59] <stgraber> rootfs is fine as long as the user doesn't have to mess with it (which they won't in this case)
[14:59] <smoser> and then you could still have /var/lib/lxc/<name>/rootfs be a symlink to the source
[15:00] <smoser> stgraber, the user of 'lxc-create' is not likely the only thing expecting some behavior of lxc scripts
[15:00] <hallyn> yes to first part.  /ar/lib/lxc/<name>/rootfs wouldn't be a symlink, rather lxc-start would just use /var/lib/lxc/btrfs/<name> as the rootfs instead of using /var/lib/lxc/<name>/rootfs
[15:00] <smoser> there are other things that are likely built atop that make assuptions
[15:01] <smoser> hallyn, i'm suggesting the symlink to mak things that expect <name>/rootfs to continue to work
[15:01] <hallyn> stgraber: i have to agree with christian (in email) - lxc-start is taking too long
[15:02] <smoser> wel..
[15:02] <smoser> i just pushed again to that branch, and it works for me.
[15:02] <hallyn> smoser: so why not just have /var entirely be btrfs?
[15:02] <smoser> in my isntance?
[15:02] <smoser> its just more invasive
[15:02] <hallyn> and just have the code silently detect that and snapshot ?
[15:02] <smoser> and more of a pain
[15:02] <hallyn> no, for anyone wanting to use btrfs
[15:03] <smoser> i'm confused as to what you're asking
[15:03] <smoser> the branch i submitted doesn't care
[15:03] <stgraber> 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] <hallyn> really i'm saying either we trust btrfs for rootfs, or we don't trust it
[15:03] <hallyn> the branc you submitted adds '-B btrfs'.
[15:03] <hallyn> stgraber: i'll open a bug.  (though not sure i can look at it today)
[15:04] <smoser> right,, but it doesn't care where the filesystem that houses the btrfs lives
[15:04] <smoser> buti'm fine to make it not even need '-B btrfs'
[15:04] <stgraber> 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] <hallyn> stgraber: do you get that both using lxcbr0 and virbr0?
[15:05] <smoser> i just booted in under 6 seconds
[15:05] <smoser> (by human count)
[15:05] <stgraber> hallyn: that test was with virbr0. I'll try the clean container with both
[15:05] <smoser> but to login prompt in < 6 with defaults everywhere.
[15:06] <stgraber> hallyn: oh, I just noticed virbr0 now has STP turned on, I guess that explains
[15:08] <hallyn> stgraber: hm, me too
[15:09] <hallyn> whereas stp is off for lxcbr0.  i wonder why
[15:09] <smoser> so what manages /var/cache/lxc ?
[15:09] <hallyn> but it seems there's a kernel bug i need to look at.  bbl
[15:09] <hallyn> smoser: lxc-ubuntu template does it
[15:14] <stgraber> hallyn: clean precise container on virbr0 without STP => took 2s to boot with DHCP
[15:17] <hallyn> stgraber: so i wonder why libvirt is turning stp on.  or is bridge-utils doing it?
[15:17] <smoser> hallyn, so what changes do you want to btrfs support?
[15:18] <smoser> you want roots to go in /var/lib/lxc/btrfs
[15:18] <hallyn> smoser: I'm fine with your patch actually.  jsut to verify though,
[15:19] <smoser> i see value in /var/lib/lxc/btrfs/<name>/rootfs
[15:19] <hallyn> btrfs subvolume /var/lib/lxc/a/rootfs /var/lib/lxc/b/rootfs really works?
[15:19] <stgraber> 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] <smoser> hallyn, look at that instance
[15:19] <smoser> and either tell me i'm an idiot, or that it apparently does
[15:19] <hallyn> (scrolling back up for the ip)
[15:19] <smoser> it definitely *succeeds*
[15:19] <smoser> and really quickly
[15:25] <hallyn> 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] <hallyn> smoser: thanks.  do you want to push a new lxc with that?
[15:27] <hallyn> (i see jamespage assigned the bug to you :)
[15:27] <smoser> its trival to add
[15:27] <smoser> i can do it if you want
[15:27] <hallyn> have at
[15:27] <hallyn> yay, btrfs support!
[15:28] <smoser> i'll make it so lxc-create doesn't need -B
[15:28] <smoser> but i'm not going to touch the cache at this point
[15:30] <hallyn> smoser: do you think there is any sense in support lxc-clone without -s for btrfs and not having it do snapshot?
[15:31] <hallyn> (i'm not sure there is)
[15:31] <smoser> i dont follow the question
[15:31] <jcastro> robbiew: hey so I talked to Daviey and we think #ubuntu-cloud should just redirect here
[15:31] <jcastro> another channel makes no sense IMO
[15:31] <hallyn> smoser: with lvm, if you don't say lxc-clone -s, it will do a copy, not snapshot
[15:33] <smoser> oh.
[15:34] <smoser> i'll try to make it so that if user explicitly does "-s none" then it will not auotmatically use btr
[15:34] <smoser> but will just copy
[15:34] <hallyn> 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] <hallyn> smoser: separately, do you mind taking a look at https://code.launchpad.net/~guilhem-fr/vmbuilder/oneiric-support/+merge/89858  ?
[15:35] <smoser> hallyn, i coudn't come up with a usec ase for it.
[15:35] <hallyn> smoser: then always do snapshot
[15:35] <smoser> other than '-s overlayfs'
[15:36] <smoser> i'll add a option to lxc-clone to specify the type of clone
[15:36] <hallyn> overlayfs is a funky case bc it wouldn't survive reboot
[15:36] <smoser> rather than just "-s" meaning "use a snapshot"
[15:36] <smoser> overlayfs would survie a reboot
 i'd prefer doing the simplest btrfs for now and holding off on lxc-clone argument changes
[15:36] <smoser> if you did things right
[15:36] <smoser> lxc start would just have to re-mount stuff
[15:37] <hallyn> done through /var/lib/lxc/<name>/fstab?
[15:37] <hallyn> might work
[15:38] <hallyn> might work nicely
[15:40] <smoser> so should i add '-S' to specify snapshot type?
[15:40] <smoser> and default to auto-detecting
[15:41] <robbiew> jcastro: fine by me
[15:46] <hallyn> 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] <hallyn> smoser: (thinking)
[15:47] <hallyn> smoser: yeah i think that sounds fine.
[15:47] <hallyn> i'm just thinking about how that interacts with the lvm stuff
[15:47] <hallyn> lxc-clone -o old -n new -> just copies
[15:48] <hallyn> lxc-clone -s -o oldlvm -n newlvm -> does lvm snapshot
[15:48] <hallyn> lxc-clone -s -S overlayfs -o oldlvm -n newdir ?
[15:49] <hallyn> i guess -EINVAL on that.  either do lvm snapshot or overlayfs, not both
[15:51] <smoser> yeah, i think just fail on that case.
[15:51] <smoser> overlay would only work if 'old' was a directory
[16:11] <hallyn> zul: do you have a machine that has your bzr credentials and is always online?
[16:11] <hallyn> zul: i'm considering just doing skunkworks to keep the precise libvirt bzr tree uptodate
[16:11] <zul> hallyn: yeah kind of
[16:12] <hallyn> zul: script would basically watch the archive, and just do 'bzr import-dsc <x.dsc>; bzr push' any time a libvirt version is pushed
[16:13] <zul> hallyn: but we are getting it from debian?
[16:14] <zul> hallyn: thats what the openstack stuff basically does though
[16:14] <hallyn> zul: ?  i think we're talking different things
[16:14] <smoser> hallyn, ok. i did'nt do the '-S' bit for lxc-clone
[16:14] <smoser> i think we *should* do that
[16:14] <hallyn> zul: i'm talking about 'bzr branch ubuntu:libvirt' being out of date with respect to ubuntu's precise archive
[16:14] <smoser> but just didn't want to right now.
[16:15] <smoser> hallyn, yea, fix that (ubuntu:libvirt)
[16:15] <hallyn> smoser: ok - thanks!
[16:15] <zul> hallyn: ah ok...yeah i would totally do that
[16:15] <hallyn> zul: ok i'm bringing the tree uptodate now, but would like to see it automated
[16:15] <smoser> hallyn, i guess i should test it on something that isnt btrfs...
[16:15] <smoser> but really, does anyone not run btrfs as their root filesystem anymore?
[16:15] <smoser> ;)
[16:15] <hallyn> hm, imiport-dsc is hanging now
[16:16] <hallyn> oh, big new tree i guess, explains lag
[16:19] <koolhead17> congrats zul :)
[16:19] <zul> koolhead17: thanks
[16:20] <koolhead17> so testing starts from Monday!! :)
[16:24] <hallyn> utlemming: have you in fact worked on a new lxc template for cloud images?
[16:31] <smoser> hallyn, ok. thats tested.
[16:31] <smoser> i can upload if you'd like
[16:35] <hallyn> smoser: pls do
[16:39] <smoser> pushed
[16:39] <hallyn> smoser: thanks
[16:40] <hallyn> zul: pushing two fixes in libvirt.  do you have anything you need added to the queue?
[16:41] <zul> hallyn: nope
[16:41] <zul> which fixes?
[16:41] <hallyn> heh, bzr import-dsc went a lot faster at the rally with local archives :)
[16:41] <hallyn> zul: bug 921870, and a cherrypick of block migration fix (waiting for the submitter to file a bug on it)
[16:42] <zul> cool
[16:42] <hallyn> it's a cherrypick of commit d8916dc8e2f612ab3ce46f32c4bfeb0bd73f6007, "Fix default migration speed in qemu driver"
[16:43] <hallyn> smoser: do you know, if i go ahead and code up an lxc-ubucloud template, will i be stepping on utlemming's toes?
[16:46] <smoser> yeah, i dont know.
[16:46] <hallyn> ok
[16:46] <smoser> hallyn, and hazmat is also in that arena
[16:46] <smoser> and of course, i'm going to tell whoever did it that they did it wrong
[16:46] <smoser> :)
[16:47] <smoser> by asking to please use /query interface and accept 'released' or 'daily' to indicate the stream.
[16:47] <hazmat> i'm not actively working on it, i did some exploration with the cloud images and qemu-nbd and guestfs, but i'm happy to have someone else run with it.
[16:48] <hazmat> the loop mount of the raw seems like its less hassle (no deps)
[16:52] <hallyn> smoser: what do you mean by '/query' interface?
[16:52] <smoser> the other option... is for there to be a new deliverable in the images
[16:52] <hallyn> hazmat: ok, thanks.  we should probably have an open bug so we can associate a bzr tree with it, and take it when we're working on it
[16:52] <smoser> just a tar of /
[16:53] <smoser> hallyn. /query is http://uec-images.ubuntu.com/query/
[16:53] <smoser> ubuntu-cloudimg-query can query it for you (cloud-utils)
[16:53] <smoser> $ ubuntu-cloudimg-query precise daily --format "%{url}\n"
[16:53] <smoser> https://cloud-images.ubuntu.com/server/precise/20120126/precise-server-cloudimg-amd64.tar.gz
[16:54] <hallyn> and you think that's better than using .../precise/current/... ?
[16:54] <smoser> um... yes.
[16:54] <hallyn> ok
[16:54] <smoser> as i can fix /query if format changes
[16:55] <hallyn> smoser: are you willing to add a straight tarball?
[16:55] <smoser> and also...
[16:55] <smoser> $ ubuntu-cloudimg-query precise daily --format "%{pubname}.img %{url}\n"
[16:55] <smoser> ubuntu-precise-daily-amd64-server-20120126.img https://cloud-images.ubuntu.com/server/precise/20120126/precise-server-cloudimg-amd64.tar.gz
[16:56] <smoser> i'm not entirely opposed to it.
[16:56] <smoser> utlemming, ^
[16:56] <hallyn> is there space for that or will it cause issues?
[16:56] <smoser> well.... it will probaly cause space issues, yes.
[16:56] <smoser> but...
[16:57] <smoser> in the big scheme of things its not space that i'm worried about
[16:57] <smoser> i'm more worried about the confusing list of downloads
[16:57] <smoser> "which should i download"?
[16:58] <utlemming> smoser, hallyn: the new query format that I am working will expose all the files, so that you could download the manifest if you wanted to
[16:58] <smoser> right.
[16:59] <smoser> utlemming, i mentioned your name because of root.tar.gz
[16:59] <utlemming> ah...looking at the chatback
[17:00] <utlemming> hallyn: no, you won't be stepping on my toes -- go ahead :)
[17:08] <hallyn> i'll wait a bit and see if smoser blurts out "ok we'll put up root.tar.gz"
[17:11] <smoser> hallyn, well, cirros has the .tar.gz
[17:11] <smoser> so to put ubuntu on equal footing with competitors....
[17:12] <episteme> anyone know what would cause this error message and how to fix? -bash: /sbin/reboot: Input/output error
[17:15] <andol> episteme: disk error
[17:16] <andol> episteme: The system fails to read /sbin/reboot
[17:16] <episteme> yeah been searching online...got that much...it happens with every command i use
[17:16] <episteme> does that mean im sol?
[17:18] <episteme> andol: how can i fix this?
[17:19] <andol> episteme: Well, I guess it could be the disk controller, and that a power cycle might bring it back temporarily, maybe.
[17:19] <episteme> kk...thats what i was thinking
[17:19] <episteme> eh ill give it a shot
[17:19] <episteme> thanks for your help
[17:19] <andol> episteme: Still, my best guess would be the disk being bad, and the next prio would be to try saving any important data, if there are any such on it.
[17:20] <episteme> andol: cool heres hoping ty again
[17:36] <albrigha> Greetings, I'm trying to install Openstack from the daily build and it's not working. I'm getting an error from apt about nova conflict.
[17:52] <smoser> hallyn, ok.. i jfdi.
[17:52] <smoser> utlemming,
[17:53] <smoser> https://code.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/
[17:53] <hallyn> \o/
[17:54] <utlemming> smoser: ?
[17:54] <smoser> that will create (in unpacked/ righ tnow i think) <image>-root.tar.gz
[17:55] <hallyn> zul: have you ever seen a (libvirt or other) package build with sbuild fail with http://paste.ubuntu.com/817918/ ?
[17:55] <hallyn> maybe i need a local update
[17:56] <utlemming> smoser: okay
[17:56] <zul> no i havent
[18:03] <smoser> i kicked a build of precise server to test that code
[18:08] <adam_g> albrigha: which daily build?
[18:08] <hallyn> smoser: so how will i find that from ubuntu-cloudimg-query ?
[18:09] <albrigha> adam_g:  the percise server iso
[18:09] <albrigha> adam_g: i386
[18:09] <smoser> you wont
[18:09] <smoser> :-(
[18:09] <smoser> hallyn, but you'll find it in //query2
[18:10] <smoser> for /query you 'll just have to drop .tar.gz and add -root.tar.gz
[18:10] <smoser> but utlemming's /query2 will enumerate it better
[18:10] <smoser> and i will udpate ubuntu-cloudimg-query to use that data
[18:10] <hallyn> ok
[18:10] <smoser> gah!
[18:11] <smoser> test build failed.
[18:11] <smoser> archive not installable at moment
[18:12] <ninjai> is it safe for me to copy /etc/passwd from 1 server to the next, since I need the exact same user accounts on the next server?
[18:12] <ninjai> if not, what is the best way to accomplish this?"
[18:14] <adam_g> albrigha: what is the error?
[18:15] <albrigha> adam_g: during the install, I select no automatic updates, then select only openstack, continue
[18:15] <albrigha> adam_g: then I get an error 'an installation step failed'
[18:15] <albrigha> but if I look in syslog it says there is a nova package conflict
[18:16] <albrigha> the foloowing packages have unmet dependencies: nova-compute-kvm conflict nova-compute-hypervisor
[18:16] <albrigha> and nova-compute-lxc conflicts nova-compute-hypervisor
[18:22] <hallyn> hm, gues my schroots must be bad.
[18:22] <hallyn> drat!
[18:32] <robo_> hello: we have update-rc.d to add system v style startup scripts. Is there a nifty command to view what is supposed to startup at given runlevels?
[18:32] <robo_> i get confused with this aspect of ubuntu
[18:39] <hallyn> i think that's an open feature request
[18:44] <hallyn> stgraber: every time i start a container now, it resets my keyboard on my host
[18:45] <robo_> hallyn, and I think that might be because ubuntu seems to move more towards upstart
[18:45] <stgraber> hallyn: interesting. I noticed something similar with my sound mixer level :)
[18:45] <stgraber> hallyn: (we need a device namespace ;))
[18:45] <robo_> and that in itself i don't quite understand yet. How comes some ubuntu packages use upstart while others use system v style (snmpd.)
[18:46] <hallyn> robo_: some packages simply ahven't been converted to upstart.
[18:46] <hallyn> stgraber: which devices is it accessing though?  I think it might be proc/sys
[18:46] <robo_> sounds like a simple enough answer :-)
[18:46] <hallyn> robo_: but better visualization of what will be started by upstart *is* something we want
[18:47] <stgraber> hallyn: hmm, indeed, sound is probably through /proc/sys or /sys. Probably should be blocked by apparmor then
[18:47] <hallyn> stgraber: when the apparmor updates arrive, hopefully the proc/sys denials will fix it
[18:47] <stgraber> hallyn: for the console (keyboard), I'm not sure what in proc would do that
[18:47] <hallyn> stgraber: drat, t's really annoying
[18:52] <hallyn> true
[18:52] <hallyn> i'd say suggest
[18:52] <hallyn> i meant to mention that earlier :)
[18:52] <stgraber> yeah, suggest is fine
[18:54] <stgraber> hallyn: I had a quick look through /proc and /sys but couldn't find anything related to keyboard, would have to check the init scripts to find exactly what's being accessed
[18:54] <hallyn> I'll add it to my list of things to add in next upload.   meanwhile, i'm very happy to have lvm support in lxc-create :)
[18:55] <hallyn> how odd
[18:57] <ninjai> if I want to copy all my users from one server to the next server, can I jsut copy passwd?
[19:00] <patdk-wk> and shadow, and groups
[19:00] <patdk-wk> I wouldn't copy them, as much as just move the lines that you need
[19:13] <robbiew> zul: so is it worth sending something to the openstack mailing list about our CI testing?
[19:13] <robbiew> so folks there know?
[19:13] <robbiew> jamespage: adam_g: Daviey: ^?
[19:14] <zul> robbiew: i think so
[19:14] <zul> any publicity is good publicity
[19:23] <robbiew> zul...done
[19:23] <zul> robbiew: nifty
[19:23] <robbiew> of course I took all the credit...as any good leader does
[19:23] <robbiew> (j/k)
[19:23] <zul> of course
[19:23] <zul> i wouldnt have it any other way
[19:32] <drPoO> Hi all, I am running 10.04 LTS-server and the other day I got a "Kernel panic -not syncing VFS..." error that would prevent booting of the system. I fixed it by reverting to an older version of the kernel. Is there a way to permanently avoid this issue from happening again?
[19:33] <RoyK> drPoO: it really should not happen
[19:34] <RoyK> drPoO: if you can use a network console or similar to create a dump of what really happens, please do so and file a bug
[19:34] <drPoO> RoyK, I dont know if it's related but the OS is installed on a RAID-0 SSD array.
[19:34] <RoyK> shouldn't matter
[19:34] <RoyK> unless there's file corruption, that is
[19:34] <RoyK> a corrupt kernel won't work too well
[19:35] <drPoO> the machines work fine with the downgraded kernel
[19:35] <drPoO> how could i temporarily prevent the kernel from being updated?
[19:35] <RoyK> the downgraded kernel is another file
[19:35] <adam_g> robbiew: i plan to send a more detailed email outlining what we've done and how it works, to the relevant lists. hopefully this week
[19:36] <robbiew> adam_g: okay...I sent the short email...as I'm conscious of our limited presence in the project ;)
[19:36] <RoyK> drPoO: please run md5sum or sha1sum for the files in /boot and pastebin the result
[19:39] <drPoO> RoyK, would that imply running md5sum in /boot as root? -> sudo md5sum?
[19:42] <drPoO> RoyK, here it is http://pastebin.com/HzyZtCKE
[19:42] <drPoO> RoyK, that was generated by running sudo md5sum /boot/*
[19:43]  * patdk-wk wonders why sudo is needed
[19:44] <drPoO> patdk-wk, i guess it isnt really required
[19:45] <patdk-wk> your missing an initrd.img
[19:46] <patdk-wk> no wonder it won't boot
[19:48] <drPoO> patdk-wk, what about the /boot/initrd.img-2.6.32-21-server lines?
[19:48] <patdk-wk> what about them?
[19:48] <patdk-wk> I thought we where diagnosing the newest kernel, -35, not -21
[19:49]  * patdk-wk also notes -35 isn't very new
[19:49] <patdk-wk> it should be -38
[19:49] <drPoO> ok i got it
[19:49] <drPoO> so what can I do?
[19:49] <drPoO> to fix this issue
[19:53] <patdk-wk> find out what making the initrd failed
[19:53] <patdk-wk> no idea
[19:53] <robbiew> sudo apt-get update; sudo apt-get install linux-image
[19:53] <patdk-wk> maybe try manually making the initrd
[19:54] <drPoO>  would pinning apt to a known working kernel be a suitable alternative?
[19:55] <Daviey> adam_g: Yes, it is a bzr bug.
[20:06] <RoyK> drPoO: which kernel was it that killed the server?
[20:08] <drPoO> RoyK, 2.6.32-34
[20:09] <drPoO> sorry 2.6.32-35
[20:09] <RoyK> drPoO: what arch?
[20:10] <RoyK> looks like x86_64
[20:10] <patdk-wk> it is
[20:10] <drPoO> yup
[20:10] <drPoO> 64 bit
[20:10] <RoyK> f0294206e319b8f7874bb892c5ca6fa5  vmlinuz-2.6.32-35-server
[20:10] <RoyK> that's mine
[20:10] <patdk-wk> that is fine, it's missing the initrd file
[20:10] <RoyK> oh
[20:11] <RoyK> right
[20:11] <RoyK> http://manpages.ubuntu.com/manpages/karmic/man8/mkinitramfs.8.html
[20:14] <drPoO> hold on guys, in none of my other 5 working 10.04 LTS 64-bit servers do i have a initrd.img file in /boot
[20:14] <drPoO> and none of them died on me
[20:14] <patdk-wk> who said initrd.img?
[20:14] <drPoO> you did
[20:14] <drPoO> didnt you?
[20:14] <patdk-wk> no, I said it's missing the initrd file for that kernel
[20:14] <ninjai> can anyone help me out? I jsut installed ubuntu server 11.10 and I cannot use scponly.  I install it and whenever I go to log in it just says "connection closed"
[20:14] <patdk-wk> so that would be initrd.img-2.6.32-35-server
[20:15] <drPoO> ah, I misread you
[20:22] <Daviey> zul / adam_g: How long do you think, until we can push a diablo/stable proposed branch to the ci testing?
[20:23] <Daviey> is it outlined what we need to do?
[20:25] <kirkland> SpamapS: what would be the best way to trigger an upstart job at shutdown, but before networking dies?
[20:26] <kirkland> SpamapS: i have a bootmail user that wants to get a bootmail on shutdown, in addition to startup
[20:26] <kirkland> SpamapS: which I kinda like;  i'd use that on my ec2 instances
[20:26] <zul> Daviey: tomorrow
[20:28] <zul> Daviey: i need to sync up the branches and stuff
[20:28] <SpamapS> kirkland: start on starting rc RUNLEVEL=[06]
[20:28] <kirkland> SpamapS: sweet, thanks
[20:28] <Daviey> zul: is swift fixed?
[20:28] <SpamapS> kirkland: if you do runlevel [06] you will get a race with the sysvinit jobs, but starting rc RUNLEVEL=[06] will complete first
[20:29] <SpamapS> kirkland: also make *sure* you make it a 'task'
[20:29] <zul> Daviey: yeah this morning :P
[20:29] <kirkland> SpamapS: and what's the best equivalent of /etc/rc.local for running something at boot?
[20:29] <SpamapS> kirkland: otherwise it will unblock as soon as it starts running.. you want it to block the rest of the shutdown until it is finished
[20:29] <kirkland> SpamapS: right now, i'm using @reboot cronjob
[20:29] <SpamapS> kirkland: start on stopped rc RUNLEVEL=[2345]
[20:29] <kirkland> SpamapS: perfect, thanks
[20:30] <Daviey> zul: How can i re-trigger the job?
[20:30] <zul> Daviey: use the jenkins interface to do it
[20:30] <Daviey> zul: ah yes
[20:35] <Daviey> zul: is everything now pushed back to LP?
[20:35] <zul> Daviey: yep
[20:35] <Daviey> zul: sweet
[20:39] <adam_g> zul: iscsi/volume issues fixed with this https://review.openstack.org/#change,3479
[20:39] <adam_g> Daviey: doing that kind of testing is going to require some work
[20:40] <Daviey> adam_g: that is what i feared
[20:40] <zul> adam_g: good good..
[20:40] <zul> i think we need to add some volume testing to the deploy-test script
[20:41] <adam_g> Daviey: we'd need to have a whole seperate set of cobbler profiles, deployment scripts and tests
[20:42] <zul> but i can do the  jenkins stuff tomorrow
[20:43] <zul> ie packaging
[20:45] <Daviey> adam_g: is there /that/ much more complexity?
[20:45] <Daviey> ah, testing oneiric rather than precise.
[20:45] <Daviey> i see.
[20:46] <roaksoax> adam_g: btw.. it probably would e good idea to patch cobbler with your lvm volumes snippet
[20:47] <adam_g> Daviey: to do it in an automated way, i think so.. it might be reasonable to have a quick and easy way to manually pause the current testing, deploy oneiric and smoketest whats in -proposed, then switch back
[20:48] <adam_g> roaksoax: really? im doing all kinds of hacks in them, tho
[20:48] <hallyn> ahs3: so for that libnl patch i sent for sid to enable make check?  your compile fail was about xml right?  I needed to add '-lxml2' to LIBS in tests/Makefile (even though it's already in LIBEXSLT_LIBS)
[20:48] <hallyn> but, i'm still just trying to figure out why our buildd's choke on it :)
[20:49] <ahs3> hallyn: that sounds about right -- it looked like it was something simple like that
[20:51] <Daviey> adam_g: Okay, use case for intial scratch... I want to ssh to a server... run ./test_proposed-branch.sh git://review.openstack.org/bah/bar..  It grabs the ubuntu packaging from oneiric, updates the upstream code, bumps the d/changelog  ... builds a src package, and tests..
[20:51] <hallyn> ahs3: thouhg this autoconf (uh) stuff makes me unsure where to fix that
[20:52] <hallyn> -lxml2 isn't specified anywhere ...  this might be a toolchain breakage
[20:52] <ahs3> hallyn: nod.  i didn't look; is there a makefile.am somewhere?
[20:52] <hallyn> ahs3: yeah, it just has "LIBS= @LIBS@"
[20:53] <Daviey> roaksoax: Hey, did you make progress packaging those oops-* things?
[20:53] <hallyn> oh, no, that's Makefile.in
[20:54] <ahs3> ah, better.  that wasn't making sense :)
[20:55] <adam_g> Daviey: we can watch the git tree for updates and build packages automatically and continously. then, when ready to test, youd need to run a job/script that makes sure 1, the nodes are going to install oneiric 2, any current precisee tests are done, 3, no precise tests will overlap with oneiric deploy/tests, 4, deploy+test, 5 switch everything back to precise, 6 reenable the precise auto testing.   this may all be doable automatically with jenkins,
[20:59] <Daviey> adam_g: right, i thought phase 1 could be script triggered.
[21:00] <Daviey> as in by-hand
[21:01] <roaksoax> Daviey: on it atm
[21:01] <Daviey> roaksoax: How are they looking?
[21:01] <roaksoax> adam_g: and I thinkyour work would be great tohave as general snippets for people to use.. obviously they might not need as many hackjs as you are doing
[21:01] <roaksoax> Daviey: all seem pretty quick to package
[21:02] <Daviey> roaksoax: awesome. :)
[21:02] <Daviey> roaksoax: viable that they will be in NEW by EoW?
[21:03] <roaksoax> Daviey: mmm more likeley for early next week
[21:03] <roaksoax> da	btw... do we have a bp to track these changes yet?
[21:03] <Daviey> roaksoax: not really, did you see the kanban?
[21:05] <roaksoax> Daviey: i did. I will start offering help according to what I see there
[21:05] <Daviey> cool
[21:06] <roaksoax> Daviey: btw.. could you pass me the link again with all the new packages needed? (besides the oops) cause I can't find it
[21:06] <Daviey> roaksoax: wilco.
[21:06] <Daviey> roaksoax: also, can you make sure https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-powernap is current?
[21:07] <roaksoax> Daviey: will do
[21:07] <roaksoax> Daviey: nevermind found the link
[21:07] <adam_g> roaksoax: the main "hack" im wget'ing the dm-snapshot kernel module from a local host (that im manually extracting from the kernel package that corresponds to the cobbler distro kernel) because its not included with the rest of the storage modules in whatever udeb installs them.
[21:07] <Daviey> roaksoax: http://pb.daviey.com/5M6H/
[21:08] <adam_g> roaksoax: if we can get dm-snapshot addded to that udeb,  i think it could be generally useful, and perhaps extended to do kexec instead of reboot
[21:08] <roaksoax> adam_g: cool
[21:08] <roaksoax> adam_g: do you have those snippets in a branch
[21:12] <adam_g> roaksoax: ya lp:~openstack-ubuntu-testing/+junk/cobbler-lvm-snapshot
[21:12] <koolhead17> SpamapS: around. got this build error http://paste.ubuntu.com/818149/ :(
[21:13] <koolhead17> adam_g: hello there
[21:14] <Daviey> roaksoax: see updates on, https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-orchestra
[21:14] <roaksoax> Daviey: awesome!
[21:15] <Daviey> roaksoax: some of them are not needed TBH
[21:15] <Daviey> as in, some are already main
[21:16] <roaksoax> Daviey: the django ones ?
[21:16] <SpamapS> koolhead17: about to head to lunch.. will be back soon, but its possible libgd needs some fixes to deal with multi-arch.
[21:16] <Daviey> roaksoax: well, they need checking
[21:17] <Daviey> roaksoax: also, if you wanted to review https://code.launchpad.net/~maas-maintainers/maas/packaging that would be great.
[21:17] <koolhead17> SpamapS: shall i install it or sumthing?
[21:17] <roaksoax> Daviey: ok, that's inexpensive really
[21:17] <roaksoax> Daviey: cool will do
[21:17] <koolhead17> SpamapS: get done with lunch am here only for another 1 hr
[21:18] <roaksoax> this reminds me.... kirkland still thinking to come to Peru in Feb?
[21:19] <roaksoax> kirkland: ^^
[21:23] <adam_g> koolhead17: hi
[21:24] <koolhead17> adam_g: you are working on essex3/precious automatic install via juju
[21:26] <adam_g> koolhead17: ah, ya
[21:27] <koolhead17> adam_g: will need your help for it, incase you have wrote some blog sumwer point me to that please.
[21:27] <roaksoax> clear
[21:27] <koolhead17> planning to try in on monday
[21:28] <SpamapS> koolhead17: send me the steps you're taking to get to that error, and I'll try to reproduce
[21:28] <koolhead17> SpamapS: 2 mins
[21:29] <adam_g> koolhead17: hmm, no i haven't had time to do anything like that yet.
[21:29] <koolhead17> adam_g: i won`t mind documenting the same :P
[21:30] <koolhead17> SpamapS: i have installed php5-gd and executed the command again, let me see if i get same error
[21:32] <adam_g> koolhead17: have you got a juju ec2 environment?
[21:32] <koolhead17> adam_g: i have LXC :(
[21:32] <adam_g> koolhead17: is that where you plan on doing your openstack testing?
[21:33] <koolhead17> adam_g: no in lab infra using KVM
[21:34] <adam_g> koolhead17: ah
[21:34] <koolhead17> SpamapS: http://paste.ubuntu.com/818170/
[21:35] <koolhead17> adam_g: did you use orchestra and then juju on it 4 deployment?
[21:36] <koolhead17> SpamapS: srry am still using the same old long method :(
[21:39] <adam_g> koolhead17: ya
[21:39]  * adam_g lunch time
[21:39] <koolhead17> adam_g: k. I think there was a page 4 that earlier.
[21:47] <hallyn> Daviey: are you around, can you push new netcf with http://people.canonical.com/~serge/netcf-disable-make-check.debdiff for me?
[21:56] <Daviey> hallyn: will do, just doing the washing up :)
[22:00] <slicslak> so i haven't been paying attention but am aware of the recent hoopla in regard to removing Sun's java.  I just need to install java to run an app on a server (apache solr).  what java package is safe/recommended to install these days?  java7-runtime?  fortunately there are no descriptions for most of the java* packages..
[22:12] <Daviey> adam_g: I was thinking, would we need to 'pause' the precise jobs.. or could it just be added to the queue and have the cobbler lvm task check /etc/issue of the disk and reinstall if not = oneiric?
[22:12] <Daviey> and then preicse test would do the same?
[22:13] <SpamapS> koolhead17: actually, it looks like the bug was fixed in Debian in 5.3.9-2 ...
[22:13] <SpamapS> koolhead17: so I think we can just merge w/ Debian and that will fix the issue
[22:13] <Daviey> hallyn: bug 922304, can i suggest downloading the buildd chroot and using that as a test, rather than use pbuilder/sbuild created one?
[22:14] <hallyn> Daviey: infinity says he did that already
[22:14] <Daviey> hallyn: the chroots generated by those don't /quite/ match launchpads...
[22:14] <Daviey> oh
[22:14] <koolhead17> SpamapS: any pointer where i can read how to merge it or its the maintainers who are assigned for that
[22:15] <Daviey> hallyn: what did he say?
[22:15] <SpamapS> koolhead17: merges.ubuntu.com, use the 'grab-merge.sh' script
[22:15] <hallyn> Daviey: let's ask him (to make sure i didn't misunderstand) in #ubuntu-devel
[22:16] <Daviey> zul: have you seen the failures in https://jenkins.qa.ubuntu.com/view/Precise%20OpenStack%20Testing/job/precise-openstack-essex-nova-trunk/200/consoleFull ?
[22:21] <koolhead17> SpamapS: that is a shell script asked me if i want to delete all files in current directory and it exited
[22:24] <koolhead17> SpamapS: https://wiki.ubuntu.com/UbuntuDevelopment/Merging got it. :)
[22:35] <adam_g> Daviey: hmm, by the time cobbler would be looking at /etc/issue of any disk it would be booted into a precise or oneiric kernel, executing that release preseed.
[22:36] <adam_g> Daviey: i suppose we wouldn't need to puase the job, but let it queue up. i think the easiest way to choose distro release woudl be to just re-assign $release-x86_64-juju profile depending on what the test run targets
[22:36] <adam_g> (for all systems)
[22:36] <Daviey> adam_g: right, but i'm wondering if we have a task which does this:
[22:37] <Daviey> if /target/etc/issue == $release-we-want:
[22:37] <Daviey>    lvm + kexec
[22:37] <Daviey> else:
[22:37] <Daviey>   continue-install()
[22:40] <adam_g> Daviey: hmm
[22:41] <Daviey> adam_g: am i off the wall?
[22:42] <adam_g> Daviey: im still trying to wrap my head around it :) is that added to a preseed that gets shared between both releases?
[22:44] <Daviey> adam_g: well, i still think this should be a udeb TBH :)
[22:44] <Daviey> But yes, it could be done in preseed... with early
[22:44] <Daviey> hmm
[22:44] <adam_g> Daviey: i just see it as scripting jenkins jobs for each $release-deploy to do : for $s in `cobbler system list` ; do cobbler system edit --name=$s --profile-$release-we-want-$arch-juju` ; ./deploy
[22:44] <Daviey> mind you, disk isn't mounted at early..
[22:46] <Daviey> adam_g: right... but if the underlying image already on this disk == $release-we-want, we don't want to reinstall... just lvm restore... if it's NOT the release we want, we start fresh, right?
[22:47] <adam_g> Daviey: yeah, or we can just use a more specific name for the pristine lvm root that we restore from. pristine-root-oneiric or pristine-root-precise.
[22:47] <Daviey> adam_g: that is an interesting thought...
[22:47] <adam_g> that way we can avoid having to do much of anything in /target (which, btw, isn't even mounted by the installer when we're doing all this voodoo)
[22:48] <Daviey> adam_g: the thing with doing a fresh install, is that we can throw the server away and put a new one in, and not care about 'prepping' the system
[22:49] <adam_g> Daviey: not sure what you mean
[22:50] <Daviey> adam_g: I mean, If we have multiple lvm snapshots.. oneiric, precise and q-series in the future...
[22:50] <Daviey> if we rack a new server, or format the disks and loose it.. we'll need to prep the server with at least 3 lvm snapshots first, right?
[22:51] <Daviey> Oh.. in early, we could see if the lvm is there or not, and create it if not?
[22:52] <adam_g> Daviey: partman_early command only restores.  creation doesn't happen until after a full install, and (currently) if the system is tagged with the lvm-snapshot-create mgmt_class
[22:56] <Daviey> adam_g: right, so....  if $release-we-want in $(lvdisplay | grep etc): restore() else: continue
[22:57] <adam_g> Daviey: ya
[22:57] <Daviey> adam_g: so if we have the snapshot, we restore - otherwise we install.
[22:59] <adam_g> Daviey: yeah, thats how we've got it currently. but its looking for a generic pristine-root logvol. we can just make it more specific, but still keep the snippet generic across all release profiles
[22:59] <hallyn> Daviey: well, went and and tried, test still passes
[22:59] <adam_g> Daviey: that is, have the $release-we-want derived from the cobbler profile name or something
[22:59] <Daviey> hallyn: so, lets just upload?
[23:00] <hallyn> Daviey: i think so, yeah
[23:00] <hallyn> Daviey: i wonder when the buildds are moving to lucid
[23:00] <Daviey> adam_g: sounds awesome!
[23:01] <Daviey> hallyn: I don't think the hosts will..
[23:02] <Daviey> hallyn: so, you want it uploaded?
[23:02] <hallyn> Daviey: yes pls.  thanks.
[23:03] <trimeta> Question: When there's an updated kernel, and the changelog says the only difference is "Bump API" (or possibly changes to compat-wireless, which shouldn't matter to my wifi-less server anyway), is there any actual reason to reboot?
[23:05] <Daviey> trimeta: not really IMO .. the dkms modules if you use them will still be loaded from your old kernel...
[23:05] <Daviey> trimeta: fwiw, i only reboot if it's a sec update.
[23:05] <trimeta> That's what I though.
[23:06] <trimeta> I don't need new features, so the kernel I've got right now is good enough for me.
[23:06] <Daviey> hallyn: uploaded
[23:06] <hallyn> Daviey: thanks
[23:53] <kieppie> hi guys. I have a suspicion that cron isn't working on a host, but I can't be sure. why would that be?
[23:54] <trimeta> What's the recommended way to remove a PPA from a Lucid system? I could just delete the file in /etc/apt/sources.list.d, but I want to get rid of the public key entry too.
[23:55] <mgw> re cobbler — is there a convention as to where a firstboot script should be stored on the provisioning server?
[23:56] <kieppie> ...nevermind
[23:56] <mgw> (for retrieval by the provisioned machine)