[17:03] <roddy> I have ubuntu 24.04 on dell xps 8940 6.6 kernel refuses to boot. 6.5 boots fine
[17:04] <roddy> Does anyone notice issues with the 6.6 kernel not booting on ubuntu 24.04 and other versions?


[01:26] <jhobbs> cherylj: got bootstrap to work, hitting another issue trying to deploy an instance https://bugs.launchpad.net/juju-core/+bug/1595360
[01:26] <mup> Bug #1595360: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New> <https://launchpad.net/bugs/1595360>
[01:27] <cherylj> jhobbs: try restarting jujud on the controller
[01:27] <cherylj> the "lease manager stopped" error has been seen recently and usually a restart of jujud brings things back
[01:33] <mup> Bug #1595360 opened: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New> <https://launchpad.net/bugs/1595360>
[01:38] <jhobbs> cherylj: that made the lease manager stopped errors go away, but it's still failing. It looks like it's trying to go back to the internet for the image stream instead of using the image-metadata-url i bootstrapped with
[01:39] <jhobbs> cherylj: do i have to set the image-metadata-url for non bootstrap stuff some other way?
[01:42] <cherylj> jhobbs: it may be falling back because it can't access the streams from the client
[01:42] <cherylj> and by client I mean machine
[01:42] <mup> Bug #1595360 changed: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New> <https://launchpad.net/bugs/1595360>
[01:42] <cherylj> let me look at the output again, one sec
[01:45] <mup> Bug #1595360 opened: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New> <https://launchpad.net/bugs/1595360>
[01:52] <cherylj> jhobbs: can you attach /var/log/cloud-init-output.log for one of the machines that's in "waiting for agent initialization"?
[01:54] <jhobbs> cherylj: there is no machine
[01:54] <cherylj> bleh, sorry
[01:56] <cherylj> anastasiamac: would you be able to help jhobbs with bug 1595360?  I need to eod
[01:56] <mup> Bug #1595360: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New> <https://launchpad.net/bugs/1595360>
[01:57] <anastasiamac> cherylj: jhobbs: sure.. gimme 30 mins to catch up :)
[01:57] <cherylj> thanks, anastasiamac!
[02:00] <jhobbs> cherylj: anastasiamac: thanks, i need to EOD too, if you comment on the bug i will pick it up tomorrow
[02:02] <anastasiamac> jhobbs: will do \o/
[02:23] <anastasiamac> jhobbs: is there any chance, you could also attach the other file from machine-0 log directory?
[02:23] <anastasiamac> jhobbs: and if u get a chance, could you pleas also send `juju status --format=yaml` output?
[02:25] <jhobbs> anastasiamac: http://paste.ubuntu.com/17727508/
[02:27]  * anastasiamac wondering how jhobbs got machine-0 log if there are no machines according to status :D
[02:28] <anastasiamac> jhobbs: have u been able to bootstrap juju 1.25 on the same cloud?
[02:32] <jhobbs> anastasiamac: ah well that's for the model i added, here is the juju status for the controller model http://paste.ubuntu.com/17727730/
[02:32] <jhobbs> anastasiamac: i did bootstrap with 1.25 (and 2.0 now) but I didn't try deploying anything after bootstrapping on 1.25
[02:34] <jhobbs> oO do i need to set image-metadata-url as config on the model i added maybe?
[02:35] <anastasiamac> jhobbs: i think it would help
[02:36] <anastasiamac> jhobbs: atm  m not seeing images being picked at all and we are falling throught to trying to pull images from streams-canonical and getting gpg error - signature differences..
[02:36] <jhobbs> can't juju set-model-config image-metadata-url, get "WARNING key "image-metadata-url" is not defined in the current model configuration: possible misspelling
[02:38] <anastasiamac> hmm
[02:38] <anastasiamac> jhobbs: m not sure that it will help on already created model.. I would have thought it makes a difference at bootstrap..
[02:39] <jhobbs> anastasiamac: it did make a difference at bootstrap - i wasn't able to bootstrap without passing that as a config option
[02:39] <jhobbs> it's like it's forgotten about it after bootstrap though
[02:39] <anastasiamac> jhobbs: it shouldn't have, these images (metadata) would have been put into controller db
[02:40] <anastasiamac> jhobbs: is there another file in logs directory that u could attach to the bug?
[02:40] <anastasiamac> jhobbs: besides the machine-0 one
[02:40] <anastasiamac> ?
[02:40] <jhobbs> logsink.log
[02:40] <anastasiamac> yep
[02:42] <jhobbs> anastasiamac: https://bugs.launchpad.net/juju-core/+bug/1595360/+attachment/4688820/+files/logsink.log
[02:42] <mup> Bug #1595360: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New for anastasia-macmood> <https://launchpad.net/bugs/1595360>
[02:42] <anastasiamac> jhobbs: is there anyway, u could do a db dump before u eod so that I can have a look at what u have there?
[02:42] <anastasiamac> jhobbs: tyvm for logsink :)
[02:43] <jhobbs> anastasiamac: yeah, how do i do a db dump?
[02:44] <anastasiamac> jhobbs: gimme a sec, I'll dig it up :)
[02:45] <anastasiamac> jhobbs: I'll email u details :)
[02:45] <jhobbs> anastasiamac: k
[03:45] <axw> wallyworld: looks like my neighbours are getting their power line sunk today, so if I go AWOL it's because I've got no power
[03:46] <wallyworld> no worries
[04:04] <thumper> fuckity fuckity fuck fuck
[04:04]  * thumper sighs
[04:26] <wallyworld> axw: the current destroy semantics are to nuke the model to which the incoming connection belongs. thus destroy-model -m foo establishes a connection to model foo and kills it. introducing a bulk api sounds ok but does it make sense to allow models to be destoryed over a different connection. for whatever reason, sadly model create is not bulk either :-(
[04:27] <wallyworld> thumper: do you know why model create api is not bulk?
[04:27] <thumper> reasons
[04:27] <axw> wallyworld: true, but I think you're more likely to destroy multiple models at once rather than create multiple at once...
[04:27] <thumper> and probably not good ones
[04:27]  * wallyworld sighs
[04:28] <axw> wallyworld: doesn't seem like a huge change, but if it is, defer
[04:28] <wallyworld> axw: let me land it as is, and i'll follow up with a change to look at making create and delete bulk
[04:28] <wallyworld> at least it will allow the gui to be updated
[04:28] <axw> wallyworld: thanks
[04:29] <axw> wallyworld: my upcoming cloud rejiggering changes will conflict with yours I think, so the sooner it lands the better anyway
[04:29] <wallyworld> yep
[04:32] <wallyworld> thumper: why were you headesking?
[04:33] <thumper> wallyworld: converting apiserver/params structs with embedded charm.v6-unstable structures to things that don't use those structures
[04:33] <thumper> would have been so much easier if we caught it when they were created
[04:33] <wallyworld> thumper: should we change the charm.v6 stuff in that repo then
[04:33] <wallyworld> it is still unstable
[04:33] <thumper> no
[04:34] <thumper> we shouldn't be using external structs
[04:34] <thumper> fullstop
[04:34] <thumper> too easy for things to change without us catching it
[04:34] <wallyworld> yes true
[04:36] <thumper> it is just boring work
[04:36] <thumper> work we should do
[04:36] <thumper> but boring
[04:39] <thumper> well... it builds now
[04:39]  * thumper wonders how many tests fail
[04:39] <thumper> bored
[04:39] <thumper> bored
[04:39] <thumper> bored
[04:39]  * thumper waits
[04:39] <blahdeblah> Boredom is a delicious luxury; use it wisely.
[04:40] <mup> Bug #1571477 changed: juju 1.25.3: juju-run symlink to tmpdir <landscape> <juju-core:Expired> <https://launchpad.net/bugs/1571477>
[04:40] <thumper> :)
[04:47]  * thumper is trashing this laptop's cpu
[04:48] <thumper> load 20, cpu 100%
[04:49] <davecheney> engineer reports 105% on the reactor is possible, but not recommended
[04:58] <thumper> wallyworld: http://reviews.vapour.ws/r/5148/
[04:58] <wallyworld> looking
[04:58] <thumper> munging types
[04:58] <thumper> mostly trivial but annoying
[05:07] <wallyworld> thumper: i had one thing to fix and a suggestion or 2
[05:09] <thumper> k
[06:43] <axw> wallyworld: FYI: http://reviews.vapour.ws/r/5149/
[06:43] <axw> no rush I guess, probably need to rebase on your changes
[06:44] <wallyworld> ok
[06:44] <wallyworld> we have meeting soon then i have soccer
[06:44] <axw> wallyworld: I've gotta go get Charlotte soon, will miss the beginning of the meeting
[06:46] <wallyworld> axw: ok, btw we gotta hide those certs http://paste.ubuntu.com/17734075/
[06:46] <axw> yup
[06:46] <axw> wallyworld: I think we can just add them to SecretAttrs for now, I'll go ahead and do that
[06:46] <wallyworld> axw: maybe also authorized keys
[06:46] <wallyworld> not secret but annoying
[06:47] <wallyworld> we don't need to see those in get-config
[06:47] <axw> wallyworld: yeah. I kinda think they shouldn't be in config, since they're not managed through config... but not sure
[06:47] <wallyworld> maybe that will break stuff though
[08:32] <voidspace> babbageclunk: ping
[08:32] <babbageclunk> poong
[08:33] <babbageclunk> voidspace: ^^
[08:34] <voidspace> babbageclunk: I sent you a PM
[08:38] <dimitern> voidspace, babbageclunk: morning :) if you can, please take a look at http://reviews.vapour.ws/r/5134/
[08:40] <dimitern> frobware: ^^
[08:50] <babbageclunk> dimitern: morning! looking now.
[08:50] <dimitern> babbageclunk: thanks!
[09:01] <frobware> dimitern: taking a look
[09:02] <dimitern> frobware, jam, fwereade, dooferlad: standup?
[09:30] <frobware> dimitern: LGTM. thanks
[09:30] <dimitern> frobware: tyvm
[09:41] <_thumper_> night all
[09:46] <fwereade> axw, http://reviews.vapour.ws/r/5151/ should be trivial if you have a moment
[09:55] <TheMue> hello to my former colleagues ;)
[10:01] <dimitern> TheMue: o/ ;)
[10:04] <TheMue> dimitern: heya, are all our British colleagues voting? I hope they do vote #remain.
[10:06] <dimitern> TheMue: yeah, same here! today's a bit quiet, not completely though :)
[10:08] <TheMue> dimitern: btw, my try to return to Canonical doesn't look so good. currently extreme few potential matching positions
[10:09] <dimitern> TheMue: yeah? :/ well, I'm sure something will come up sooner or later!
[10:09] <dimitern> babbageclunk: review poke? :)
[10:10] <TheMue> dimitern: I'll keep up looking, but I've already got other interesting contacts. so we'll see.
[10:10] <dimitern> TheMue: good luck though!
[10:12] <TheMue> dimitern: thanks
[10:34] <hoenir> could anyone merge it ? http://reviews.vapour.ws/r/4924/
[10:34] <hoenir> I think now the CI is not locked down http://juju.fail/
[10:47] <dimitern> hoenir: done - it should land soon, I'll keep an eye on it
[10:51] <hoenir> dimitern, thanks !
[10:51] <dimitern> np :)
[10:54] <babbageclunk> dimitern: Sorry! Got distracted! Doing it right now.
[10:55] <dimitern> babbageclunk: no worries, ta!
[11:01] <babbageclunk> dimitern: done, sorry for the holdup
[11:01] <dimitern> babbageclunk: thanks!
[11:04] <babbageclunk> dimitern: just bootstrapping, noticed the gui installation message - does that mean that the gui is available straight away in a newly bootstrapped controller?
[11:04] <babbageclunk> dimitern: How do I get to it?
[11:05] <dimitern> babbageclunk: haven't tried, but there is 'juju help gui' you can check
[11:06] <babbageclunk> dimitern: ooh, will try it once this bootstrap finishes.
[11:07] <dimitern> babbageclunk: YMMV though, as the bundled gui might still be broken due to thumper's recent API rename changes
[11:07] <babbageclunk> dimitern: oh, of course
[11:11] <babbageclunk> dimitern: Yup, you're right: "unknown object type: Client". Pretty slick up until then though - will be a really nice experience once it works! ;)
[11:13] <dimitern> babbageclunk: it works if you switch to a commit earlier than https://github.com/juju/juju/commit/769aeb4b45068389a88f9fef34f3d61915d28562
[11:14] <babbageclunk> dimitern: thanks - mostly just curiosity after seeing the message scrolling past in a few bootstraps..
[11:31] <anastasiamac> macgreagoir: cherylj: standup?
[11:47] <voidspace> babbageclunk: my headphones arrivedd
[11:48] <voidspace> babbageclunk: they're huuuuuuge. Headphone quality and build quality seem reasonable though.
[11:48] <babbageclunk> voidspace: ooh, exciting
[11:48] <voidspace> babbageclunk: they're very white
[11:52]  * babbageclunk goes for a run.
[12:17] <axw> fwereade: sorry for the delay, LGTM
[12:29] <mup> Bug #1595514 opened: destroy-controller fails <juju-core:New> <https://launchpad.net/bugs/1595514>
[12:35] <fwereade> axw, ta
[12:59] <mup> Bug #1595514 changed: destroy-controller fails <juju-core:New> <https://launchpad.net/bugs/1595514>
[13:01] <dimitern> frobware: sync?
[13:09] <babbageclunk> cherylj: ping?
[13:31] <frobware> dimitern: power just restored
[13:31] <dimitern> frobware: we're still in the call btw
[13:31] <frobware> dimitern: omw
[13:54] <cherylj> babbageclunk: what up
[13:56] <babbageclunk> cherylj: oh hey - I just wanted to check about the email about blocking master you sent the other day.
[13:56] <cherylj> I was surprised no one responded :)
[13:56] <cherylj> did you have a specific question?
[13:57] <babbageclunk> cherylj: I've got something that I'd like to get into the rc - is it legit to JFDI it?
[13:57] <cherylj> babbageclunk: yes, provided you have done manual testing, run with -race, etc.
[13:57] <babbageclunk> cherylj: (it's the state changes for workload version)
[13:57] <cherylj> babbageclunk: yeah, that's fine
[13:58] <babbageclunk> cherylj: ok, great - that's how I was interpreting the email, just checking.
[13:58] <cherylj> np, thanks for asking :)
[13:58] <babbageclunk> :)
[14:29] <mup> Bug #1581157 changed: github.com/juju/juju/cmd/jujud test timeout on windows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by natefinch> <juju-core 1.25:Fix Released by natefinch> <https://launchpad.net/bugs/1581157>
[14:29] <mup> Bug #1591290 changed: serverSuite.TestStop unexpected error <blocker> <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Fix Released by thumper> <juju-core 1.25:Fix Released by thumper> <https://launchpad.net/bugs/1591290>
[14:36] <natefinch> cherylj: whatchoo got for me?
[14:36] <natefinch> cherylj: and go easy on me, it's my birthday ;)
[14:37] <cherylj> natefinch: in that case, let me see what the worst one is!
[14:37] <cherylj> ;)
[14:37] <marcoceppi> hey
[14:38] <marcoceppi> I've shared a model with someone
[14:38] <marcoceppi> but they can't ss
[14:38] <marcoceppi> ssh*
[14:38] <natefinch> cherylj: haha... as long as you wait until my next birthday for the next really bad one ;)
[14:38] <marcoceppi> how do I get their keys into the system
[14:38] <cherylj> natefinch: did you see anastasia's email about 1595155
[14:38] <cherylj> bug 1595155
[14:38] <mup> Bug #1595155: new systemd and dbus dependencies are broken <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1595155>
[14:38] <natefinch> cherylj: oh yeah, I'll jump on that, forgot about that.
[14:40] <cherylj> marcoceppi: is it a perm denied error?  or a timeout?
[14:40] <marcoceppi> cherylj: perm denied
[14:40] <marcoceppi> tvansteenburgh: ^^
[14:40] <marcoceppi> cherylj: I ran: `juju import-ssh-keys lp:tvansteenburgh` after I added tvansteenburgh as a user and shared a model with him
[14:40] <marcoceppi> cherylj: he can juju status, but not ssh
[14:41] <perrito666> fwereade_: can you go back to your usual nickname so I can privmsg you without having 2 different logs plz?
[14:45] <tvansteenburgh> cherylj: i have lots of ssh keys, how does `juju ssh` know which one to use? is there a way to tell it?
[14:53] <fwereade> perrito666, sorry :)
[14:55] <cherylj> tvansteenburgh: it uses a lot of keys.  You can see the actual ssh command if you run:
[14:55] <cherylj>  JUJU_LOGGING_CONFIG="<root>=TRACE" juju ssh <machine>
[14:56] <cherylj> tvansteenburgh:  you'll see something like this:
[14:56] <cherylj> 2016-06-23 14:55:22 TRACE juju.utils.ssh ssh_openssh.go:131 running: ssh -o "StrictHostKeyChecking no" -o "ProxyCommand /usr/bin/juju ssh --proxy=false --pty=false <IP_ADDRESS> nc %h %p" -o "PasswordAuthentication no" -o "ServerAliveInterval 30" -t -t -o "UserKnownHostsFile /dev/null" -i /home/cherylj/.juju/ssh/juju_id_rsa -i /home/cherylj/.ssh/id_rsa<EMAIL_ADDRESS>[14:57] <cherylj> (this is a 1.25 example, but the same should work for 2.0)
[15:08] <tvansteenburgh> cherylj: http://pastebin.ubuntu.com/17749178/
[15:09] <cherylj> tvansteenburgh: sorry, you need --debug
[15:09] <cherylj> JUJU_LOGGING_CONFIG="<root>=TRACE" juju --debug ssh <machine>
[15:10] <tvansteenburgh> http://pastebin.ubuntu.com/17749251/
[15:10] <tvansteenburgh> cherylj:  ^
[15:11] <cherylj> oh...  it's not even getting to running the ssh command
[15:11] <cherylj> there have been changes to store keys in state
[15:13] <cherylj> tvansteenburgh: I'm on a call right now, but will dig into this after
[15:13] <tvansteenburgh> cherylj: thanks!
[15:18] <babbageclunk> voidspace, frobware: review please? http://reviews.vapour.ws/r/5152/
[15:20] <katco> natefinch: oh happy birthday! just saw that :)
[15:25] <katco> ericsnow: lol sorry
[15:25] <katco> ericsnow: i heard "oh w-"
[15:26] <ericsnow> katco: was just going to see about a ship-it on that patch
[15:26] <katco> ericsnow: gave it one
[15:26] <ericsnow> ta
[15:26] <katco> ericsnow: provisional to other issues i opened
[15:27] <ericsnow> katco: yep
[15:31] <katco> elmo: hey re. bug 1425808, what version were you experiencing this problem on?
[15:31] <mup> Bug #1425808: OpenStack provider doesn't try another AZ if the scheduler fails to find a valid host <openstack-provider> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1425808>
[15:32] <elmo> katco: err, it's been a while since we tried so probably early 1.2x's
[15:34] <katco> elmo: i did some work on that in early april; would anyone have bandwidth to test with 2.0 and provide fresh logs?
[15:35] <elmo> katco: unfortunately it's a little hard to test - if we create a private host aggregate on prodstack, it'll break all juju 1.2x users :)
[15:35] <mup> Bug #1595600 opened: bundle parsing rejects strings containing hex values <juju-core:New> <https://launchpad.net/bugs/1595600>
[15:36] <elmo> katco: we'd have to spin up a test cloud - but if you think it's fixed in 2.x, I'll ask someone to do that
[15:37] <katco> elmo: i just updated the bug with relevant info/code. it does look like we try and handle that properly; just a flaw in some error checking probably
[15:37] <alexisb> btw natefinch Happy Bday!
[15:38] <katco> elmo: but we need to reconfirm that this is still happening.
[15:44] <natefinch> alexisb: thanks :)
[15:44] <mup> Bug #1595600 changed: bundle parsing rejects strings containing hex values <juju-core:New> <https://launchpad.net/bugs/1595600>
[15:48] <ericsnow> natefinch: yeah, happy happy happy
[15:52] <redir> happy bday natefinch
[15:57] <mup> Bug #1292156 changed: add-machine help docs don't mention kvm <bitesize> <docs> <juju-core:Fix Released> <https://launchpad.net/bugs/1292156>
[15:57] <mup> Bug #1595600 opened: bundle parsing rejects strings containing hex values <juju-core:New> <https://launchpad.net/bugs/1595600>
[15:57] <natefinch> thanks everybody
[15:58] <redir> ericsnow: got a minute for a HO?
[15:58] <ericsnow> redir: sure
[15:58] <redir> moonstone
[15:58] <redir> ?
[16:09] <babbageclunk> natefinch: happy birthday!
[16:09] <natefinch> babbageclunk: thanks :)
[16:13] <TheMue> natefinch: Oh, just seen it, Happy Bday also from the other side of the Atlantic. o/
[16:44] <mup> Bug #1595617 opened: Subordinate charm dies when deployed with --storage option <juju-core:New> <https://launchpad.net/bugs/1595617>
[16:52] <cherylj> oh yay
[16:52] <cherylj> cloud-images.ubuntu.com is down
[16:52] <rick_h_> cherylj: yes, and some others are noting other urls
[16:52] <rick_h_> so probably something DC related
[16:53] <cherylj> wish I hadn't destroyed my previous env :(
[17:15] <cherylj> perrito666: ping?
[17:19] <perrito666> cherylj: pong, gimme a sec otp
[17:32] <cherylj> natefinch: any luck with bug 1595155?
[17:32] <mup> Bug #1595155: new systemd and dbus dependencies are broken <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1595155>
[17:41] <mup> Bug #1595636 opened: Cannot kill manual cloud controller <juju-core:New> <https://launchpad.net/bugs/1595636>
[17:44] <perrito666> cherylj: sorry, phone was not letting me
[17:44] <perrito666> cherylj: here now
[17:45] <natefinch> cherylj: no... it's weird, because the original bug was reported before that change was made :/
[17:47] <cherylj> hey perrito666 - just wanted to see if the message in this bug is improved with your ACL work:  bug 1594440
[17:47] <mup> Bug #1594440: juju gives weird errors about macaroons when a read-only user <juju-core:Triaged> <https://launchpad.net/bugs/1594440>
[17:48] <perrito666> cherylj: checking
[17:49] <perrito666> cherylj: nope, I dont think so :( (at least not conciously)
[17:53] <mup> Bug #1595636 changed: Cannot kill manual cloud controller <juju-core:New> <https://launchpad.net/bugs/1595636>
[18:02] <mup> Bug #1595636 opened: Cannot kill manual cloud controller <juju-core:New> <https://launchpad.net/bugs/1595636>
[18:21] <natefinch> man, I hate that I have to remember to pass in configuration values every time I bootstrap now
[18:22] <rick_h_> natefinch: good thing there's work to allow you to set it in the cloud settings
[18:22] <natefinch> rick_h_: oh thank goodness
[18:33] <cherylj> hey natefinch, sorry I didn't get back to you earlier - was on a call
[18:33] <cherylj> natefinch: regarding the HA bug
[18:33] <cherylj> natefinch: the original problem was something else
[18:34] <cherylj> natefinch: and that godbus / systemd bug from anastasia was raised as something they hit when trying to verify the fix we gave them for the HA issue
[18:34] <cherylj> does that make sense?
[18:35] <redir> anyone free for a review? http://reviews.vapour.ws/r/5153/
[18:52] <natefinch> cherylj: trying to understand it.  Sounds like there was a bug, and that got fixed, but then the deps update I did somehow re-broke it?
[18:53] <cherylj> natefinch: it didn't re-break it.  It broke things in a different way such that we can't confirm the HA fix works on xenial
[18:54] <natefinch> cherylj: Maybe there's something special about MAAS?  It works fine on Azure and LXD, at least.  I've tested those in the last couple days.
[18:54] <cherylj> natefinch: it could be
[18:54] <natefinch> er... at least on master, not 1.25
[19:06] <natefinch> sinzui, mgz: do we have CI tests that test HA on MAAS?
[19:08] <sinzui> natefinch: No. It will not take much effort to add one...when our mass comes back
[19:08] <natefinch> lol
[19:08] <natefinch> classic
[19:08] <sinzui> natefinch: the outage took out all of the canonical host machines
[19:08] <sinzui> natefinch: munna and silcoon are still not operational
[19:09] <natefinch> sinzui: ouch
[19:10] <sinzui> natefinch: is maas 2.0 or maas 1.9 the substrate that needs the test?
[19:10] <mgz> sinzui: did we run it on maas before? we've had the terminate code for maas for agest
[19:11] <sinzui> mgz: several bundles use HA. but we never had a regular test for ha recovery on maas
[19:11] <natefinch> sinzui: the bug I'm looking at is using maas 1.9
[19:11] <sinzui> mgz: this related to the current pressure to stop testing on all substrates
[19:11] <perrito666> bbl
[19:12] <sinzui> natefinch: okay, when munna returns, I will add the test
[19:12] <natefinch> why is there pressure to stop testing on all substrates?
[19:12] <natefinch> that seems like the opposite of what we want
[19:12] <sinzui> natefinch: testing is fast if we only test on lxd...but there are two many substrate nuances for that to be realistic
[19:12] <sinzui> the same is true for arch and series
[19:13] <natefinch> sinzui: in theory they should all be able to run in parallel, right? So the only problem is the one slowest test.  Which, granted, will be slower than LXD, but the benefits would seem to outweigh the problems
[19:13] <sinzui> natefinch: exactly what I wrote today :)
[19:25]  * redir goes for lunch
[19:29] <sinzui> natefinch: the test is added. We are just waiting for the host to comeback to life
[19:44] <natefinch> sinzui: thanks
[19:58] <alexisb> thumper, do you know when menn0 will be around today?
[19:59] <thumper> alexisb: normally sometime in the next hour
[19:59] <alexisb> thumper, ok
[19:59] <alexisb> natefinch, how long on you on todya?
[20:01] <natefinch> alexisb: one more hour... I could make time for a meeting later, but it's both my birthday and my wife's birthday, so working late before the kids go to bed is a no-go.
[20:01] <alexisb> you and your wife have the same bday?
[20:01] <natefinch> alexisb: yep :) and my twin sister :)
[20:02] <alexisb> lol
[20:02] <alexisb> makes it harder to forget :)
[20:02] <alexisb> natefinch, nevermind
[20:02] <alexisb> enjoy your bday
[20:02] <natefinch> alexisb: met my wife on a dating service, I got her to notice me by mentioning we had the same birthday ;)
[20:02] <alexisb> heh
[20:03] <alexisb> I leaned some interesting finch trival today
[20:03] <natefinch> :)
[20:03] <natefinch> makes for fun when we all go out to eat and they ask whose birthday it is :)
[20:03] <katco> natefinch: what is the plural of finch? finches? finchii?
[20:03] <natefinch> katco: finches :)
[20:04] <katco> natefinch: happy birthday to the finches
[20:04] <natefinch> btw the collective noun is a charm of finches :)
[20:04] <katco> lol
[20:05]  * natefinch doesn't know who makes up this crap.
[20:05] <natefinch> katco: and thanks :)
[20:12] <mup> Bug #1595636 changed: Cannot kill manual cloud controller <juju-core:New> <https://launchpad.net/bugs/1595636>
[20:12] <mup> Bug #1595686 opened: Cannot get status after restore is denied <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1595686>
[20:37] <katco> does anyone know if the modelUUID is something that could change without restarting the machine agent? or ever for that matter?
[20:41] <natefinch> katco: good god I hope not
[20:42] <natefinch> katco: it's stored all over the DB, I can't imagine it's mutable
[20:42] <katco> natefinch: kk ta
[21:10] <cherylj> tvansteenburgh: FYI - bug 1595720
[21:10] <mup> Bug #1595720: Problems using `juju ssh` with shared models <ssh> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1595720>
[21:13] <tvansteenburgh> cherylj: thanks
[21:33] <mup> Bug #1595720 opened: Problems using `juju ssh` with shared models <ssh> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1595720>
[21:50]  * redir pokes the review queue again. http://reviews.vapour.ws/r/5153/
[22:12] <menn0> alexisb: internet troubles?
[22:13] <menn0> alexisb: you just sounded like a very unhappy robot :)
[22:13] <alexisb> menn0, yes
[22:13] <alexisb> yes I am
[22:13] <alexisb> lol, yes I am not happy with my internet provider at the moment
[22:14] <menn0> alexisb: shall we finish on IRC? how much did you get before your link went bad?
[22:14] <alexisb> they keep trying to "fix" bandwidth issues by changing to different frequencies and it makes things very unreliable
[22:14] <alexisb> sure
[22:14] <redir> unhappy robot makes me think of Marvin the paranoid android
[22:15] <menn0> redir: alexis did sound somewhat like marvin on the call :)
[22:15] <alexisb> the last I got was that there where some potential issues with read only mode, and it was unclear if all the watchers were actually being stopped
[22:15] <alexisb> but that overall progress was good this week
[22:15] <alexisb> and htat you were going to work on status next
[22:15] <menn0> alexisb: workers not watchers but yes
[22:16] <alexisb> sorry, yes workers
[22:16] <menn0> alexisb: yes, status and tidying up some loose ends with the read-only mode
[22:16] <menn0> alexisb: and it looks like voidspace has already done the ssh host key import work
[22:16] <menn0> which is great
[22:16] <alexisb> nice
[22:17] <redir> heh
[22:17] <menn0> alexisb: it would be great to have fwereade back but he seems to be getting pulled onto other things
[22:17] <menn0> alexisb: it's great that he landed the read-only mode work though. that's a big step forward.
[22:17] <alexisb> menn0, yes and unfortunately I dont see that changing
[22:17] <menn0> alexisb: ok, well I'll keep plugging away. it's getting better every day.
[22:18] <menn0> alexisb: oh and another good development
[22:18] <menn0> alexisb: ... rogpeppe has done work to do controller login redirections
[22:18] <menn0> alexisb: which is very close to what we need for login redirections after a model has migrated
[22:19] <alexisb> nice
[22:19] <menn0> alexisb: so that's going to take some work off our plate
[22:19] <alexisb> free help is always good :)
[22:19] <menn0> alexisb: indeed :)
[22:20] <menn0> alexisb: so the summary is: good progress but there's still plenty to do, could do with more people
[22:21] <alexisb> menn0, understood
[22:21] <alexisb> we will roll folks back on MM as they free up, but we are struggling with many high priority peices for 2.0
[22:23] <wallyworld> katco: quick catchup?
[22:23] <katco> wallyworld: sure sec
[22:25] <katco> wallyworld: i'm in tanzanite
[22:25] <wallyworld> ah ok sec
[22:27] <alexisb> well I have solid bandwidth again now
[22:27] <alexisb> but it will probably only lsat so long
[22:30] <perrito666> alexisb: having issues with your isp?
[22:37] <alexisb> perrito666, yes
[22:37] <perrito666> alexisb: sorry to hear
[22:50]  * thumper afk for some pre-sprint errands
[22:57] <katco> wallyworld: aforementioned pr pushed: http://reviews.vapour.ws/r/5154/
[22:58] <wallyworld> ty


[00:00] <poolie> k
[00:31] <poolie> abentley: so the final gpg one: staging is oopsing too much to test it
[00:32] <poolie> i don't seem to have broken anything at least :/
[00:35] <abentley> poolie: did you create that merge proposal, or did it already exist?
[00:36] <abentley> poolie: I think you're hitting the bug where the staging librarian oopses instead of falling back to the production one.
[00:36] <abentley> poolie: I bet you won't have that issue if you create a fresh merge proposal.
[00:46] <poolie> ah, it already existed
[00:46] <poolie> ok
[01:06] <poolie> abentley: everything is qa-ok now, i believe
[01:07] <abentley> poolie: great.
[01:08] <poolie> can you tell me the url where i can check the unreleased changes?
[01:23] <thumper> what is the name of the single signon project?
[01:23] <wgrant> canonical-identity-provider
[01:25] <thumper> ta
[03:03] <lifeless> poolie: you might like the buffer bloat stuff thats getting airtime right now
[03:03] <lifeless> poolie: vis-a-vis bzr network perf issues
[03:03] <poolie> where?
[03:04] <lifeless> http://gettys.wordpress.com/category/bufferbloat/
[03:15] <poolie> interesting
[03:18] <lifeless> [03:18] <lifeless>     Hard / Soft  Page ID
[03:18] <lifeless>      286 / 6529  Archive:+index
[03:18] <lifeless>      110 /  328  BugTask:+index
[03:18] <lifeless>       36 /  268  Distribution:+bugs
[03:18] <lifeless>       21 /  143  ProjectGroupSet:CollectionResource:#project_groups
[03:18] <lifeless>       15 /   32  DistroSeries:+queue
[03:18] <lifeless>       14 /    0  BinaryPackageBuild:+retry
[03:18] <lifeless>       13 /   18  Archive:+copy-packages
[03:18] <lifeless>       10 /  264  Distribution:+bugtarget-portlet-bugfilters-stats
[03:18] <lifeless>       10 /   39  MailingListApplication:MailingListAPIView
[03:18] <lifeless>        9 /    7  Person:+bugs
[03:25] <lifeless> mwhudson: hey, how is vostok
[03:26] <mwhudson> lifeless: resting
[03:26] <lifeless> ah
[03:28] <poolie> there are so many intranet hosts called portal.*.com, and so few of them actually let you play the game :-(
[03:49] <spiv> poolie: haha
[03:50] <poolie> :)
[03:50] <poolie> how are you?
[03:50] <poolie> i'm doing one of max's reviews
[03:51] <poolie> i was looking into splunk earlier and it looks very good
[03:56] <spiv> Good, about to flood the review queue slightly :)
[03:57] <poolie> :)
[03:57]  * spiv shifts to #bzr
[07:14] <poolie> thumper: don't suppose you're still here?
[08:22] <thumper> poolie: not really
[08:36] <adeuring> good morning
[09:10] <mrevell> Morning
[09:13] <bigjools> morning people
[09:18] <wgrant> Morning.
[09:31] <jelmer> hi mrevell, wgrant
[09:31] <wgrant> Morning jelmer.
[11:30] <bigjools> wgrant: yo
[11:31] <wgrant> bigjools: Hi.
[11:32] <bigjools> wgrant: so the zombie sources are all these I think: http://pastebin.ubuntu.com/540590/
[11:32] <bigjools> does that query look sane to you?
[11:32] <wgrant> It does.
[11:32] <bigjools> it probably needs to ignore some more
[11:32] <bigjools> stuff that went superseded in the minutes before the query runs will get picked up
[11:33] <bigjools> maybe I can ignore stuff newer than an hour old
[11:33] <wgrant> Yeah. Filter for older datesuperseded.
[11:33] <wgrant> Or datecreated.
[11:33] <bigjools> I'm going to convert that to an UPDATE to set spph.datepublished
[11:33] <wgrant> Er.
[11:33] <wgrant> Why?
[11:33] <bigjools> fail
[11:33] <bigjools> spph.scheduleddeletiondate
[11:33] <bigjools> paste pebkac
[11:34] <wgrant> The "Why?" still stands.
[11:34] <wgrant> Mark the binaries Deleted, and the sources will be condemned automatically.
[11:34] <bigjools> yes
[11:35] <bigjools> I guess so, was gonna do binaries separately
[11:35] <wgrant> The minimal hacker is to set the status and datesuperseded of the binaries.
[11:35] <wgrant> Everything else will follow.
[11:35] <wgrant> And I like minimal production DB hackery :)
[11:36] <bigjools> yes ;)
[11:37]  * bigjools cooks query to find associated binaries
[11:58] <bigjools> wgrant: sane? http://pastebin.ubuntu.com/540597/
[11:58] <bigjools> 5744 binaries!  (I forgot the time constraint)
[12:00] <bigjools> http://pastebin.ubuntu.com/540605/ is better
[12:07] <wgrant> bigjools: You need to constrain bpph.archive, but otherwise it looks OK.
[12:07] <bigjools> yeah was just making that change
[12:07] <bigjools> trying to think whether I need to constrain on distroseries too
[12:08] <wgrant> Also constrain the status.
[12:08] <wgrant> We only care about published ones.
[12:08] <bigjools> yes
[12:08] <wgrant> Thinking about the distroseries thing... it probably won't make a difference, but try it both with and without.
[12:09] <bigjools> hmmm, zero rows
[12:10] <bigjools> removing the archive constraint makes it 1684
[12:10] <bigjools> 1584
[12:11] <wgrant> Which archive constraint? bpph.archive = spph.archive?
[12:13] <bigjools> yeah
[12:13] <wgrant> That has to be there.
[12:13] <wgrant> So sounds like we've got something wrong.
[12:27] <bigjools> wgrant: I think I know
[12:27] <wgrant> Oh?
[12:27] <bigjools> they are probably all copied
[12:27] <bigjools> but that doesn't explain the lack of binaries causing domination to not set scheduleddeletiondate
[12:28]  * bigjools looks at the code
[12:28] <wgrant> Right, they have to be in the same archive.
[12:29] <bigjools> so they should get comdemned :/
[12:29] <wgrant> Well, no. Our query is wrong.
[12:29] <bigjools> that is the other obvious problem :)
[12:30] <bigjools> http://pastebin.ubuntu.com/540608/
[12:30] <bigjools> that's the current one
[12:30] <wgrant>         bpph.id = binarypackagerelease.id and
[12:31] <wgrant> Wut?
[12:31] <bigjools> sigh
[12:32] <bigjools> 2237 rows.  hurray
[12:32] <wgrant> I love typesafety :)
[12:32] <bigjools> now to restrict on series
[12:32] <wgrant> And status.
[12:32] <wgrant> Status is far more pressing.
[12:32] <bigjools> heh
[12:32] <bigjools> down to 141
[12:33] <bigjools> which is odd, that's less than the number of source rows
[12:33] <wgrant> Not terribly odd.
[12:33] <wgrant> More relevant is how the number of archives in those rows compares to the number processed each time.
[12:35] <bigjools> 141 again restricting the series
[12:35] <bigjools> so that's pleasing
[12:35] <wgrant> Excellent.
[12:35] <bigjools> time to sweep up some cruft then
[12:35] <wgrant> I'd compare the list of archives first...
[12:36] <bigjools> mmm
[12:37] <bigjools> 14 of them
[12:56] <bigjools> wgrant: so there's actually 23 PPAs that come up on the query.  However 4 of them don't appear in the publisher log.
[12:57] <wgrant> bigjools: Are those archives disabled or unpublishable?
[12:57] <bigjools> ah let me check
[12:59] <bigjools> yup that's it
[12:59] <bigjools> all deleted
[13:00] <bigjools> no harm in fixing those publications anyway
[13:00] <wgrant> How many of the archives in the log does that leave unfixed?
[13:00] <wgrant> We need to do a mass-fixup of deleted archives' publications anyway.
[13:00] <bigjools> I don't know, it's very hard to see what's genuine and what's not
[13:00] <bigjools> the only way to tell is to see it repeated in the log each run
[13:01] <wgrant> Right.
[13:02] <bigjools> wgrant: http://pastebin.ubuntu.com/540616/
[13:03] <wgrant> bigjools: Do not touch SPPH. Set BPPH.status = Deleted and BPPH.datesuperseded = NOW()
[13:03] <bigjools> wgrant: gah
[13:04] <bigjools> right
[13:04] <bigjools> I clearly need more coffee
[13:05] <bigjools> if we set status=Deleted, I need to set the person who deleted it
[13:05] <bigjools> or the UI will go bong
[13:06] <bigjools> wgrant: http://pastebin.ubuntu.com/540622/
[13:08] <wgrant> bigjools: I don't think the UI will go bang. But I guess it might.
[13:08] <bigjools> it's bad data either way
[13:10] <wgrant>         spph.datepublished is null and
[13:10] <wgrant> I'm pretty sure that is crack, but it will only restrict the set to something less than it should be.
[13:10] <wgrant> Otherwise it looks OK.
[14:25] <deryck> gmb, I meant to ask you to look at bug 380362 if you could.
[14:25] <_mup_> Bug #380362: Launchpad couldn't import several bugs from Debian Bug tracker. <Launchpad Bugs:New> <https://launchpad.net/bugs/380362>
[14:25] <deryck> may be an old one that is fixed, but the linked bug watches still have "can't find bug" or some such error.
[14:26] <gmb> Ah, the neverending saga of debbugs watches.
[14:26] <gmb> deryck: It's on my list for today. I'll try to poke at it when the LOSAs are available (they're currently tied up with another issue).
[14:27] <deryck> gmb, ok, thanks.
[14:49] <flacoste> deryck, abentley: the revert is missing qa tags and isn't recognised by qa-tagger, you should probably manually tag the bug
[14:50] <deryck> flacoste, abentley did.  That was my fault sorry.
[14:50]  * deryck should never take theraflu during work days
[14:51] <abentley> flacoste: Because deryck did not use --rollback, I have tried to emulate it from the documentation, which says "The bug will be tagged as bad-commit-*, all the qa-* tags will be remove..."
[14:52] <abentley> flacoste: I think there's some difference between documentation and implementation, but I'm not sure what's supposed to be done in this situation.  Maybe roll it back to "in progress"?
[16:10] <gary_poster> sinzui: A few questions about https://bugs.launchpad.net/launchpad-foundations/+bug/684668 : May I toss it to registry, since we have no knowledge of these bits?  If not, my impression is that this is not of high importantance: am I wrong?
[16:10] <_mup_> Bug #684668: Unable to delete messages from list archive <canonical-losa-lp> <Launchpad Foundations:New> <https://launchpad.net/bugs/684668>
[16:11] <sinzui> gary_poster, yes
[16:11] <gary_poster> thank you
[16:11] <sinzui> gary_poster, I am sure it is an ml-archive-sucks bug. We know the message was deleted, but the page generator/squid cache wont show it gone
[16:12] <gary_poster> ah, gotcha
[18:12] <jml> hello
[18:12] <pitti> hello
[18:13] <pitti> benji, gary_poster: how are you? jml said you are the right persons to talk about this new keyring thing?
[18:13] <gary_poster> pitti: hi, yes.  did you see benji's reply on the pertinent bug
[18:13] <pitti> yes, I just replied
[18:13] <gary_poster> oh, lemme go look
[18:13] <pitti> but I wondered why we deliberately broke existing API, instead of creating a new login_keyring() thing for keyrings
[18:14] <pitti> that's not .. nice
[18:14] <pitti> it suddenly breaks each and every script and cron job we've written
[18:14] <pitti> and isn't noninteractive
[18:15] <benji> your cron jobs use login_with?
[18:15] <pitti> (and using a keyring by default is total overkill -- after all, you can just snatch the cookie from firefox)
[18:15] <pitti> benji: sure
[18:15] <benji> that's unfortunate
[18:15] <pitti> that was _the_ primary function to get a Launchpad lib so far
[18:16] <pitti> and it's also what the documentation said
[18:16] <pitti> (e. g. https://help.launchpad.net/API/Examples)
[18:19] <benji> even without the changes in the latest version, cron scripts using login_with are in a precarious sitution; if the credentials cache is ever removed or if the token is revoked on the server-side they will attempt to re-authenticate with a web browser
[18:21] <benji> not to say that the situation isn't worth discussing, but one of the outcomes apparently needs to be some form of better advertising when the different APIs should be used
[18:22] <pitti> benji: not really
[18:22] <pitti> benji: first, it had a credentials_file argument, so that you can store them in a well-known placed
[18:22] <pitti> and second, if you run the cron job manually the first time, it showed the URL to you, you could open it locally, and then you were fine
[18:23] <gary_poster> benji, pitti, I'm a big +1 on getting pitti's scripts happy, both as an important user and as a representative.  I'm happy to weigh in if needed, but mostly intend to get out of the way.  A few notes:
[18:23] <gary_poster> - the security implications of this have been looked at by many (including Kees, importantly), and I'd really prefer not to reopen them.
[18:23] <gary_poster> - as you might expect, we believed that we were doing the right thing; what benji described was our understanding of the usage, and our expected usage.  The examples you cite were part of the general difficulty we find ourselves in: we want to make the right thing happen by developers who don't want to worry about it, and who have not worried about it in the past.
[18:23] <gary_poster> - we changed the behavior of login_with because it meant users that we were interacting with would not have to make a change to get the uniform behavior.  uniformity on the desktop is very important for this effort.
[18:23] <gary_poster> - our docs obviously needed and need improvement in this regard in particular.
[18:23] <gary_poster> - leonardr, the person most connected with these changes, is not around this week, though benji and I should be able do a reasonable job.
[18:23] <pitti> benji: I opened https://bugs.launchpad.net/launchpadlib/+bug/686690 about this
[18:23] <_mup_> Bug #686690: 1.8.0 completely breaks login_with() API (and forces keyrings) <launchpadlib :New> <https://launchpad.net/bugs/686690>
[18:23] <pitti> I think we should probably discuss it there, to have a better paper trail
[18:23] <gary_poster> pitti, your "and second" is exactly the kind of thing benji was describing
[18:24] <gary_poster> pitti, the paper trail is the upside.  The decreased speed is the downside.
[18:25] <gary_poster> in this particular case, with leonardr not around, maybe the paper trail wins anyway
[18:25] <pitti> I understand that you might want a different API on "desktopish" programs
[18:26] <gary_poster> and we are dealing with an installed base
[18:26] <gary_poster> that needs to be uniform
[18:26] <pitti> but as it happens, most of our use cases (QA scripts, apport, ubuntu-archive-scripts, sru report, and what not) are not desktop apps
[18:26] <pitti> the only non-"server"ish use case I know of is Ubuntu One
[18:27] <gary_poster> nit: non-desktop apps are not a particular problem for this; cronscrpts are.
[18:27] <gary_poster> ...a subclass...
[18:27] <gary_poster> Ground Control
[18:27] <gary_poster> others, I believe
[18:27] <pitti> or in general, taking a well-established existing API and turning it into something entirely different
[18:28] <pitti> even for desktop apps
[18:28] <pitti> it now means that suddenly every desktop user needs to reauthenticate
[18:28] <pitti> as their existing credentials files are ignored
[18:31] <gary_poster> pitti, I think you are stretching your description ("entirely different").  from our perspective, the API presented a black box.  the credentials files are generally not intended to be the domain of a launchpadlib-using script.  But I also think that this part of the conversation is counter-productive.
[18:31] <gary_poster> We have a use case and approach that has been vetted by more people than us.  There is a reason that it is the way it is, and it has been discussed.  I believe you have a valid, concrete concern for cronscripts that we did not foresee.  We need to determine a way around this.
[18:32] <gary_poster> One obvious approach is to change the scripts to use our expected approach.  That is admittedly unfriendly, so even though I think that's the longer-term desire, we should do better now.
[18:32] <pitti> couldn't we get a new API for using keyrings, and make keyrings optional?
[18:32] <pitti> at least for a transition period of a year or so
[18:32] <pitti> so that we have the new keyring API available for some time
[18:33] <pitti> and everyone has time to port their stuff
[18:36] <benji> we could; part of the motivation for the keyring integration is to support better desktop integration without the need for clients to change their API use.  It would be great if we can fulfill that goal while also addressing the cron script problem.
[18:36] <gary_poster> pitti, keyrings are "optional" right now in that, if there is not one available, the keyring library will do something else.  You know that already.  I *think* what is more important to you is that, if legacy credentials files exist, they are used.  Is that in fact sufficient, or am I missing a detail?
[18:36] <pitti> gary_poster: how can I make them optional?
[18:36] <pitti> (and no, I don't know that already)
[18:36] <gary_poster> oh
[18:36] <pitti> if I run a script now, it creates a new keyring
[18:36] <pitti> asks me for a passworrd
[18:36] <pitti> (which can't be empty)
[18:36] <pitti> and then subsequently asks me for that password again
[18:37] <pitti> Waiting to hear from Launchpad about your decision...
[18:37] <pitti> Please input your password for the keyring
[18:37] <gary_poster> they are optional in the sense that, if there is not one around (e.g., not Gnome or KDE), it is not used.
[18:37] <pitti> Password:
[18:37] <pitti> that's what I get
[18:38] <benji> I'm fairly certain that's the prompt for the encrypted file storage used when no keyring is available.
[18:38] <pitti> well, I have GNOME running
[18:39] <pitti> I didn't test it on a server with ssh yet
[18:39] <gary_poster> right, the keyring library does not require a keyring implementation.  It provides a backup.
[18:39] <benji> apparently python-keyring can't communicate with the keyring for some reason
[18:40] <gary_poster> (my comment is pertinent to "I  didn't test it on a server with ssh yet")
[18:41]  * gary_poster is going to be quiet about details because benji knows more than he about them
[18:43] <pitti> benji: note that we currently have a very old version of p-keyring in the archive; did you test this with 0.5? it might work better
[18:43] <gary_poster> so far it sounds to me like (1) python-keyring is not happy on pitti's machine, which is worrisome; and (2) I'm not sure yet whether, if the first problem didn't exist, my proposal ("if legacy credentials files exist, they are used") is a sufficient compromise for this backwards compatibility problem.
[18:43] <pitti> gary_poster: if the credentials_file parameter and existing cred files could continue to work, that'd pretty much solve the API break, I think
[18:44] <pitti> as for (1), I have no idea, I'm afraid
[18:44] <pitti> as I pointed out in the MIR, we should update to the current 0.5 upstream version first
[18:44] <gary_poster> pitti, do you always use the credentials_file parameter in your scripts?
[18:45] <pitti> it drops its own gnome-keyring module and uses libgnome-keyring, which is the right thing
[18:45] <benji> pitti: yep, the latest launchpadlib is meant to be used with python-keyring 0.5, but I'm not sure if using an older version would work more pooly
[18:45] <pitti> gary_poster: only for apport; for most scripts we just use the default in ~/.launchpadlib/
[18:45] <gary_poster> ah
[18:45] <pitti> benji: ah, that could be it then
[18:45] <pitti> (see above)
[18:46] <pitti> sorry, need to leave for today
[18:47] <pitti> thanks for the discussion so far!
[18:47] <gary_poster> pitti, ack.  I was hoping to only accept existing cred files if credentials_file were passed, and then issue a deprecation warning
[18:47] <gary_poster> but that still sounds not good enough
[18:47] <gary_poster> ok thanks
[18:47] <gary_poster> benji or I will summarize in the bug
[18:47] <pitti> ah, thanks
[18:49] <pitti> I also sent a summary
[18:49] <pitti> thanks, and good night!
[18:49] <gary_poster> excellent, thanks
[18:49] <gary_poster> night
[21:57] <bdmurray> How come the apidoc lists getSpecification but it doesn't actually appear with a launchpadlib client?
[22:00] <benji> bdmurray: does the version of the docs you're looking at and verion of the API match?
[22:00] <bdmurray> benji: yes I'm using devel for both
[22:03] <benji> hrm, might be a bug
[22:06] <sinzui> benji, ping
[22:06] <benji> sinzui: hi
[22:07] <sinzui> benji, I want to subclass a Choice field to guard conflicting transitions between values. I am not sure if I should redefine _constraint() or _validate()
[22:12] <sinzui> benji, The crux of the issue is that while the value is valid, it cannot be accepted because it violates another relationship. (something like a invariant, but between a hierarchy of objects)
[22:14] <bdmurray> salgado-afk: I'm having some troubles using ubuntu.getSpecifications() that should work on devel right?
[22:15] <benji> sinzui: I suspect using constraint() (no leading underscore) will be slightly easier.
[22:15] <sinzui> benji, yes, sorry for the underscores
[22:16] <benji> sinzui: note the interface difference between the two: constraint() should return a boolean, validate() should raise an exception (or not)
[22:17] <sinzui> ah
[22:17] <james_w> bdmurray, it should yes
[22:18] <sinzui> benji, so I think I may want to define both for their respecting uses.
[22:18] <benji> makes sense
[22:18] <james_w> bdmurray, do other specifications things work? natty.valid_specifications worked for me on qastaging last week
[22:18] <sinzui> validate() could call constraint() and convert False to TeamSubscriptionPolicyError
[22:19] <bdmurray> james_w: no valid_specifications doesn't show up either but I'm production which seems to have the right revision
[22:20] <james_w> bdmurray, you get "AttributeError"?
[22:21] <benji> sinzui: the default implmentation (from Field) does something similar, validate() is responsible for calling constraint() and raising a ConstraintNotSatisfied error if a false value is returned
[22:21] <bdmurray> james_w: yeah
[22:21] <james_w> bdmurray, are you using it anonymously?
[22:22] <bdmurray> james_w: no, I've seen that bug report too
[22:22] <benji> sinzui: (ConstraintNotSatisfied is a subclass of ValidationError)
[22:22] <james_w> bdmurray, it's working for me using "edge"
[22:23] <sinzui> benji, thanks. I will follow that pattern. I was thinking or returning a very specific class of error with a meaningful reason.
[22:23] <benji> yep; the default "Constraint not satisfied" isn't real helpful.
[22:30] <james_w> bdmurray, works for me against production too. My guess would be cached wadl or it not actually using devel for some reason.
[22:31] <bdmurray> james_w: okay, thanks I'll poke at it some more
[22:31] <james_w> np


[10:15] <dadaumpa> hello
[10:16] <dadaumpa> someone can tell me how can I get ip address of an instance when i launch command ec2-run-instances?
[10:16] <dadaumpa> or there is another command to know ipaddress during instance starting?
[10:49] <dadaumpa> ping
[11:00] <dadaumpa> thanks


[02:03] <nhaines_> pleia2: a bit late, but thanks for all the amazing work you do for the Ubuntu community. :)
[02:03] <pleia2> nhaines_: never too late :)
[02:04] <nhaines_> pleia2: it works out anyway because you're always doing more amazing work.
[02:04] <pleia2> haha, thanks
[02:04] <pleia2> can do more not getting emotionally worn out by giant leadership positions
[02:05] <nhaines> No doubt.
[02:05] <nhaines> How do you feel about small leadership positions?
[02:05] <pleia2> should probably steer clear until my book is done
[02:06] <nhaines> It was worth a try.  :)
[02:09] <nhaines> Books are actually a lot of work.
[22:47] <nhaines> Just a heads up for anyone interested, our Meetup group is now live at: http://www.meetup.com/Ubuntu-California/
[22:47] <darthrobot> [403] Title: [Attention Required! | CloudFlare]
[22:51] <pleia2> nhaines: shall I share on the social media?
[22:52] <pleia2> nhaines: I guess we should talk about how to add events first and thins
[22:52] <pleia2> things
[22:53] <nhaines> Yeah.  I think it's social media-safe, though.  We can get people to sign up perhaps.
[22:53] <nhaines> http://www.ubucon.org/ should be live almost everywhere now.
[22:53] <darthrobot> Error opening URL: [Errno -2] Name or service not known
[22:53] <pleia2> hee
[22:53] <nhaines> *almost* everywhere.  :)
[22:53] <pleia2> nhaines: well, if we're going to use it for events, it may be nice to have a couple seeded before we tell people about it
[22:54] <pleia2> but I could go either way
[22:54] <nhaines> True, true.  I set it up mostly so we can get Ubucon Summit set up.
[22:55]  * pleia2 nods
[23:00] <nhaines> http://ubucon.org/en/ does seem to be live...  So I'll have to poke someone about CNAME records, ugh.
[23:00] <darthrobot> Title: [Home | UbuCon portal]
[23:24] <pleia2> oh hey, I should be home in time for the meeting on sunday
[23:24]  * pleia2 updates agenda
[23:25] <nhaines> yay!
[23:26] <nhaines> Thanks, pleia2.


[04:36] <jtv> bigjools: I get the impression our support for DNS management is brittle in the face of multiple networks...  we always map a node's hostname to its first-registered NIC, instead of picking a NIC that's on the DNS-managed network.
[04:37] <jtv> The right thing to do AIUI is to map the hostname to each IP address that the node has on a network for which we manage DNS.
[04:39] <jtv> This means AFAICS that the fix will change DNS mappings for setups where the nodes are on multiple networks, when the first interface that gets registered is not on the network for which we manage DNS.
[05:05] <bigjools> "for which", I like it :)
[05:06] <bigjools> jtv: I think we need to set the "primary" network to which the first IP is assigned in the DNS
[05:06] <bigjools> jtv: however not fixing this now would not be a regression
[05:07] <bigjools> anyway can you get "make run" actually serving anything on trusty?
[05:08] <jtv> I'll try it.
[05:09] <jtv> My gramatically awkwardly laboured point is that this behaviour _does_ change if we're going to manage DNS for multiple networks.
[05:09] <bigjools> jtv: what I meant was that we don't have to manage multiple DNS networks
[05:09] <bigjools> stick to the single for now
[05:10] <bigjools> and we can solve this problem later
[05:10] <jtv> !
[05:10] <bigjools> why the !
[05:10] <jtv> That's what I documented in my phased approach, and you said absolutely we have to do DNS on multiple interfaces.
[05:10] <bigjools> we do - but I am saying it can wait until the end
[05:11] <jtv> The end of what?
[05:11] <bigjools> the cycle/feature
[05:11] <bigjools> anyway there's two things getting conflated here
[05:12] <bigjools> management of cluster interfaces does not have anything to do with which NIC on a node has its IP used as its dns lookup
[05:12] <bigjools> since the cluster may not be connected to all the same networks as the node
[05:12] <bigjools> they only need to share one
[05:13] <bigjools> jtv: want to do a hangout to talk more?
[05:13] <jtv> Yes please.  Meanwhile, no dice on Trusty — ISE.  :(
[05:13] <jtv> Let me get my equipment ready for a hangout.
[05:13] <bigjools> fnar
[05:13] <jtv> This will include a heavy object to hurl at the crying baby.
[05:13] <bigjools> I didn't want that kind of hangout
[05:13] <jtv> Oh zark off.
[05:15] <bigjools> call me when yer ready
[05:16] <jtv> Well, _that_ boot didn't work, so let me try another one.
[05:16] <jtv> Logging in with your password sort of requires a response to keyboard input.
[05:18] <jtv> Ah, I can switch to a text console and back, and then the login screen accepts input.
[05:19] <bigjools> !
[05:19] <jtv> It's an alpha.
[05:19] <jtv> By the way, the error I get from maas running from branch in Trusty is an import error involving django's debug toolbar.  Let's try uninstalling that.
[05:19] <jtv> Good thing we have oops reports!
[05:19] <bigjools> all I get is an oops page
[05:20] <jtv> Me too, but it does generate an oops report with the traceback.
[05:20] <lifeless> oops
[05:20] <bigjools> jtv: I don't get any traceback or nuffink
[05:20] <bigjools> hey lifeless
[05:20] <bigjools> you lurker you
[05:21] <lifeless> noone expects the NZ inquisition!
[05:23] <jtv> Hey there lifeless
[06:02] <bigjools> jtv: so I think our django debug toolbar is an old egg, I'm trying to get a new one
[06:04] <jtv> Trying that here too.
[06:05] <bigjools> jtv: setting it to 1.0.1
[06:05] <bigjools> jtv: btw djorm-ext-pgarray is at 0.9 now
[06:05] <jtv> Oh, then we may no longer need our workaround.
[06:06] <bigjools> have a looksee and let me know
[06:06] <jtv> Prioritising the nodegroupinterface work though...
[06:08] <bigjools> debug_toolbar/base.html missing now
[06:08] <bigjools> fair enough
[06:09] <bigjools> hurray fixed
[06:10] <jtv> \o/
[06:10] <jtv> Failing for me:
[06:10] <jtv> Error: Picked: sqlparse = 0.1.10
[06:11] <bigjools> landing a branch
[06:11] <jtv> While installing repl.
[06:11] <bigjools> one mo
[06:11] <jtv> OK
[06:13] <bigjools> give the lander 10 minutes
[06:13]  * bigjools makes coffee
[06:55] <jtv> bigjools: works for me too now!
[06:55] <bigjools> hurray!
[08:22] <roaksoax> bigjools: ping
[08:23] <jtv> Hi roaksoax — try again in an hour, or after our standup.
[08:23] <roaksoax> jtv: hehe, i'll be asleep in an hour (and probably should be sleeping now)
[08:23] <jtv> !
[08:23] <jtv> I thought you were just up early!
[08:23] <roaksoax> nah
[08:23] <roaksoax> i'
[08:23] <roaksoax> :)
[08:24] <roaksoax> jtv: anyway going to bed but will leave bigjools with my opne question
[08:24] <jtv> OK nn!
[08:24] <roaksoax> bigjools: since otherwise we wont be able to talk until sunday night (my time), your monday morning, I was wondering what's the status of adding upstream support to MAAS for HA? The charm is coming along pretty good and will soon start looking at that HA stuff for maas-region!
[08:25]  * roaksoax out
[08:26] <jtv> rvba: I put a few cards on the board for immediate next steps towards multiple-managed-interfaces.  They have detailed descriptions.
[08:26] <rvba> jtv: okay, I'll have a look.
[08:27] <jtv> Thanks.
[08:35] <rvba> jtv: AFAIK, we can have the same DHCP server listen to multiple interfaces and have one config per interface.  That's all good.  But can we do something similar with DNS?
[08:36] <jtv> rvba: depends on how similar you mean...  that's the region controller, of course, so it's going to listen on all of the controller's interfaces.
[08:37] <jtv> But any given node is only going to be on one managed network, apparently.
[08:37] <jtv> And that's why there is no confusion between the networks.
[08:37] <rvba> Do you mean that there is one (and only one) network marked as "the management network"?
[08:42] <jtv> From the cluster controller's perspective, no.  But from the node's perspective, yes.
[08:51] <rvba> Care to explain?
[08:56] <rvba> jtv: also, shouldn't we try splitting the card named "Handle multiple cluster net interfaces" into smaller tasks?
[09:00] <jtv> rvba: why do you think there are cards for jobs that are part of that project?
[09:01] <jtv> About the networks: a cluster will manage multiple networks, and a node will be in only one of them.
[09:01] <rvba> jtv: then I think there are things that are missing :).  Like update the generated DHCP config to account for the multiple interfaces.
[09:02] <rvba> Also, the parsing of the lease file will have to be changed (I think).
[09:03] <jtv> You're right — we'll have to update the DHCP config for multiple networks.
[09:04]  * rvba adds a card
[09:07] <jtv> That's currently all built around the assumption of a single network.  :(
[09:08] <rvba> Right, that's why I'm saying it will probably have to be changed.
[09:10] <jtv> I can't think of anything that would need changing in the parser.
[09:11] <rvba> Well, I'm just saying that's worth a look :).
[09:19] <rvba> jtv: btw, did you fix the problem in maas-test where the machine was not cleaned up?
[09:21] <jtv> rvba: no, and I can't test it now.  :(
[09:21] <rvba> jtv: you mean you can't reproduce the problem?
[09:22] <jtv> That's right.
[09:22] <jtv> And as I said I just don't see how the "finally" clause could fail to run...
[09:22]  * rvba tries
[09:53] <bigjools> roaksoax: HA is not going to happen I'm afraid.
[09:53] <bigjools> unless we find time out of nowhere
[11:48]  * gmb lunches
[13:37] <gmb> allenap: Are you able to help me unfuck my dev box? I accidentally rebooted halfway through apt-get remove maas last night and now maas-region-controller can't be fully installed or removed.
[13:50] <allenap> gmb: Sure :)