=== Trevinho|Holiday is now known as Trevinho
[09:28] <sil2100> Hello release team! I need to disable the system importer for a few minutes to do some copy-image operations without disruptions
[09:34] <sil2100> ...and done, re-enabled again
=== boiko_ is now known as boiko
[14:20] <jamespage> arges, hey - I'd like to stick through oslo.messaging 1.8.3 as an SRU to vivid; it contains fixes only for rabbitmq and zeromq drivers - does that sound reasonable? it does *not* have a MRE
[14:21] <arges> jamespage: so I think technically that's the Tech Board call. But if the SRU is bugfix only that seems reasonable. Also why isn't that package under the openstack MRE umbrella?
[14:23] <jamespage> arges, https://bugs.launchpad.net/ubuntu/+source/oslo.messaging/+bug/1467959
[14:23] <ubot93> Launchpad bug 1467959 in oslo.messaging (Ubuntu) "[SRU] update to 1.8.3" [Undecided,New]
[14:23] <coreycb> RAOF, Hi, the latest openstack stable icehouse release is ready for sru review in the trusty-proposed queue.  there's also a smal python-keystonemiddleware sru in the utopic-proposed queue.
[14:24] <jamespage> arges, MRE makes sense for this - I'll make an application to the TB alongside uploading this SRU.
[14:24] <arges> jamespage: What other packages use oslo.messaging?
[14:24] <jamespage> arges, just openstack
[14:25] <jamespage> arges, we would run it through are standard -proposed validation testing - for both zeromq and rabbitmq
[14:25] <arges> jamespage: i think given its isolated to openstack + it looks like bugfix only updates, I think this is a reasonable SRU. The MRE stuff would be helpful though in teh future to make any updates easier
[14:25] <jamespage> arges, ack
[14:28] <jamespage> arges, uploaded - emailing TB as well
[14:28] <jamespage> between meetings :-)
[14:29] <arges> jamespage: so productive
[14:46] <coreycb> RAOF, can I also have python3-tempest-lib promoted to main?
[15:20] <slangasek> infinity: have you seen that IS has asked about taking nusakan's /srv offline today to upgrade the space?  does that impact alpha-1 prep?
[15:21] <slangasek> sil2100, robru, rsalveti: ^^ can you also let me know if this will interfere with phone or snappy work, to have no image generation between 2200 and 0000 UTC today?
[15:26] <sil2100> slangasek: hey! The phone should be fine I suppose, I already did the image copies I needed and we don't need to build anything new
[15:26] <sil2100> At least not today
[15:26] <slangasek> sil2100: ok, thanks
[16:17] <infinity> slangasek: It does, I've not gotten to my email yet.
[16:18] <infinity> ... assuming I have email about that.
=== pgraner is now known as pgraner-afk
=== _bjf is now known as bjf
=== fginther is now known as fginther|lunch
[19:04] <wxl> what are these respins about?
[19:21] <stgraber> wxl: what respin?
[19:22] <wxl> stgraber: on lubuntu alternates
[19:23] <stgraber> last build for lubuntu alternate was yesterday
[19:28] <wxl> stgraber: true, but i didn't request it…
[19:30] <stgraber> that's the original build right after I setup the milestone
[19:30] <wxl> huh, ok, didn't think so, but i'll take your word for it :)
[19:30] <cjwatson> wxl: he mentioned it on this channel in advance
[19:31] <stgraber> the .1 in the version is simply because there had been an automated (cronned) build earlier that day
[19:31] <cjwatson> http://irclogs.ubuntu.com/2015/06/22/%23ubuntu-release.html#t17:18
[19:31] <wxl> okie dokie
[19:31] <wxl> sorry for harassing you guys :)
[19:32] <stgraber> wxl: there's a link on the iso tracker page to see the build history for the milestone ("See removed and superseded builds too"). If you click that link, you'll see every build that ever made it to the milestone.
[19:32] <stgraber> and in this case, you'd notice that there was only a single alternate build for lubuntu, so no respins
=== pgraner-afk is now known as pgraner
[20:15] <utlemmin`> stgraber: it looks like we have a serious blocker for Alpha-1 -- EC2 instances do not boot https://bugs.launchpad.net/ubuntu/+bug/1468091
[20:15] <ubot93> Launchpad bug 1468091 in Ubuntu "Ubuntu 15.04 Alpha-1 candidates do not boot in EC2" [Undecided,New]
[20:16] <stgraber> oh, that's pretty bad indeed
[20:17] <utlemmin`> stgraber: yup...I can't put my finger on the exact cause, but at first blush it looks like udev is not creating the /dev/disk/by-* targets for Xen block devices
=== utlemmin` is now known as utlemming`
[20:23] <utlemming`> stgraber: at this point, Cloud Images are likely to miss Alpha-1.
[20:23] <stgraber> utlemming`: ok
[20:23] <stgraber> utlemming`: not much point releasing just on the other clouds I guess?
[20:24] <utlemming`> stgraber: we could flag Azure and GCE and others, but with broken Xen, I would rather delay.
[20:25] <stgraber> ok
[20:45] <utlemming`> stgraber: we've confirmed that the issue is most likely systemd
[20:46] <stgraber> so there's some hope for this to get fixed in time after all
[20:46] <stgraber> systemd is a bit easier to update on short notice than a kernel
[21:05] <stgraber> turning all cronjobs off on nusakan in preparation for a disk resize
[21:05] <stgraber> pjdc: ^
[21:06] <pjdc> stgraber: great, thanks
[21:06] <stgraber> pjdc: looks like we've got nothing running on nusakan at the moment, so you can go ahead whenever you want
[21:07] <stgraber> pjdc: I suspect most of us have shells open on /srv, so you'll probably have to kick all those ssh connections before you can umount
[21:08] <pjdc> there are a few indeed
[21:13] <infinity> stgraber: I'd hope it's not the kernel, since it's the wily kernel still.
[21:13] <infinity> Err, vivid.
[21:13] <infinity> The other wily.
[21:16] <infinity> utlemming`: Do you have a console on a failed Xen instance that one can play with?
[21:16] <infinity> utlemming`: I'm curious if the block devices are there at all, and if one can force udev to love them.
[21:40] <pjdc> stgraber: all done
[21:40] <stgraber> pjdc: perfect, re-enabling cron jobs now
[21:40] <stgraber> and done
[21:45] <slangasek> hum, so we didn't wait until 2200? :)
[21:46] <slangasek> well I'm glad it came back up, since I didn't see any answer to my question about backups of keymatter :/
[21:46] <infinity> Maybe someone decided on 2200 BST instead of 2200 UTC.
[21:47] <infinity> pjdc: Not that I'm complaining, but only an extra 1T?
[21:47] <pjdc> no, i jumped the gun on my own recognizance
[21:47] <infinity> (I think I can clean out some bits anyway, so we're not at 73% anymore)
[21:47] <infinity> Like... All of lucid.
[21:50] <slangasek> pjdc: right; do you happen to be able to tell me what kind of backups we have of the irreplaceable bits on nusakan's /srv?  I fear the answer might be "none"
[21:50] <pjdc> our impression in IS was that /srv was all recreatable - is that not the case?
[21:50] <slangasek> hahahano
[21:50] <slangasek> I was going to back up the gpg key directories before the maintenance window just in case, but that apparently came early ;)
[21:50] <pjdc> good times
[21:51] <infinity> I was pretty sure lamont and I had a discussion about signing key backups for ftpmaster and cdimage a few months ago, and he devised a plan.
[21:51] <infinity> lamont: ^
[21:51] <infinity> (devised and executed, I believe)
[21:51] <pjdc> we have a new backup system in place but it's probably especially suited for key material
[21:51] <pjdc> er, *not* especially suited
[21:52] <infinity> pjdc: No, I mean, I think lamont did something very specific just for keys.
[21:52] <slangasek> pjdc: the web trees are recoverable from the mirrors; the ftp mirror is obviously just a cache that will repopulate itself if needed; the code and config is all in bzr and I have it mirrored locally if nothing else
[21:52] <infinity> pjdc: At least, we had discussions about how to do so.
[21:52] <slangasek> but the keys are not recreatable, and not replaceable without people booking flights
[21:53] <infinity> pjdc: Though, if this was done, but only documented in lamont's brain, that's about as good as not done.
[21:53] <slangasek> so it would be good to have confirmation if there is a backup
[21:53] <lamont> infinity: I have no recollection of this thing of which you speak
[21:53] <slangasek> hah
[21:53] <infinity> lamont: Excellent.  Way to be old.
[21:53] <lamont> kids!
[21:54] <infinity> lamont: We had a discussion ages ago (you started it) about good ways to backup ftpmaster and cdimage's signing keys to adelie, and I was pretty sure you even wrote something.
[21:54] <infinity> lamont: The second half might be a lie, though.
[21:56] <infinity> lamont: If you log our queries, you might even have evidence of this.  I do not. :/
[21:56] <lamont> infinity: timeframe?
[21:56] <infinity> lamont: This is where my own aging is problematic.  As has been pointed out by young kids like stgraber and wgrant, I often refer to last week as "months ago" and last year as "a few weeks back".
[21:57] <lamont> ah, yes, time dialation
[21:57] <lamont> that or hanging with the Doctor.
[21:59] <lamont> infinity: I presume it would have been PM and cnaonical's srefver?
[21:59] <infinity> lamont: Seems likely.
[22:00] <lamont> discussion involving sycamore and nusakan in 2012-02-16
[22:01] <infinity> lamont: That seems like a few too many months ago. :)
[22:01] <infinity> lamont: Maybe "grep gpg adconrad*.log"?
[22:01] <infinity> lamont: Since I think you were playing with code examples.
[22:02] <infinity> lamont: Or this is all an elaborate (and super boring) dream.
[22:02] <infinity> lamont: Which I wouldn't rule out.  I dream of some amazingly mundane things.
[22:03] <lamont> I am finding nothing
[22:05] <infinity> lamont: Huh.  Okay.  Chalk it up to me being weird.
[22:05] <infinity> lamont: Or old age taking us both.  Pick one.
[22:11] <lamont> I choose "3"
[23:07] <pjdc> slangasek: infinity: i've created RT#82293 for the key backup
[23:10] <slangasek> pjdc: thanks
[23:17] <infinity> pjdc: Ta.
[23:25] <RAOF> coreycb: Can do the SRU review; don't have the authority to promote python3-tempest-lib :)