[00:32] <fwereade> wallyworld, anastasiamac: if I wake up tomorrow with even a cursory pre-review of http://reviews.vapour.ws/r/263/diff/ I will be most grateful
[00:32]  * fwereade bed right now
[00:33] <wallyworld> ok, will do
[00:33] <fwereade> <3
[00:33] <wallyworld> good night :-)
[00:34] <anastasiamac> fwereade: k :-)
[00:52] <bigjools> hey folks, what's the quickest you've seen an LXC come up, given its image is already cached?
[00:52] <stokachu> bigjools: 32 seconds
[00:52] <bigjools> stokachu: precisely?  lol
[00:52] <stokachu> bigjools: yea ive got a counter
[00:53] <bigjools> that's fairly swift, thanks
[00:53] <stokachu> thats using ubuntu-cloud template btw
[00:53] <stokachu> regular ubuntu is slightly longer
[00:53] <bigjools> we're trying to work out if it's a problem when juju uses maas to make LXCs if the DNS entry takes up to a minute to appear
[00:53] <stokachu> and with lxc-clone enabled
[00:54] <stokachu> bigjools: im actually testing juju+maas 1.7 ill let you know if i see anything like that
[00:54] <bigjools> stokachu: well this feature is not present yetr
[00:54] <stokachu> ah ok
[00:54] <bigjools> we're working on it now, but trying to get a feel for what will be a problem
[00:54] <bigjools> we're having to make some compromises
[00:54] <stokachu> cool, understood
[00:54] <bigjools> https://code.launchpad.net/~gmb/maas/add-ptr-records-bug-1382190/+merge/239493 if you're interested
[00:55] <stokachu> nice will take a look
[00:56] <bigjools> stokachu: wait, are you working on your Sunday?!
[00:56] <stokachu> bigjools: yea :( trying to get our unmanaged installer ready for tuesday's lds release
[00:56] <stokachu> so we're testing daily maas 1.7 right now
[00:57] <bigjools> stokachu: ah ok. LXCs don't get DNS until that branch lands :)
[00:57] <stokachu> good to know, fortunately we're using KVM for our bootstrap node in maas
[00:57] <stokachu> so it works well
[00:59] <bigjools> stokachu: ok so what would be good to know is if a delay getting the DNS entry up after the LXC appears will be a problem in practice
[01:00] <stokachu> bigjools: ok cool, i subscribed the team to that bug and added a note on our tasklist to keep an eye on that
[01:00] <bigjools> great thanks
[01:01] <stokachu> np
[01:46] <anastasiamac> axw, wallyworld: isLoopback is great idea but it does not work for explicit "localhost"...
[01:46] <axw> anastasiamac: no, you'd still need a string comparison for that
[01:46] <axw> you're just cutting out the comparison to 127.0.0.1 and ::1
[01:47] <anastasiamac> axw: k... m with u :-)
[01:54] <anastasiamac> axw: it looks like it does not cater for ip where hostport is only ::1 either...
[01:54] <anastasiamac> axw: to be fair, I suspect that it's url.parse that does not cater for this case...
[01:55] <anastasiamac> axw: just how it does not cater for malformed urls...
[01:56] <axw> anastasiamac: ah, no, you're right, SplitHostPort expects there to be a port... in that case if you get an error you could tack on a ":0" and try again. starting to get a little convoluted...
[01:58] <anastasiamac> axw: hmm... do u think that mayb regular experession could work neater? it will abbrv8 the if- and is easier to modify to cater for "funny" cases...
[02:01] <axw> anastasiamac: actually, is the port even optional? I'm not sure there is a default port for apt proxies?
[02:03] <anastasiamac> axw: from apt.conf man page... "  http
[02:03] <anastasiamac>        HTTP URIs; http::Proxy is the default http proxy to use. It is in
[02:03] <anastasiamac>        the standard form of http://[[user][:pass]@]host[:port]/. Per host
[02:03] <anastasiamac>        proxies can also be specified by using the form http::Proxy::<host>
[02:03] <anastasiamac>        with the special keyword DIRECT meaning to use no proxies. If no
[02:03] <anastasiamac>        one of the above settings is specified, http_proxy environment
[02:03] <anastasiamac>        variable will be used."
[02:03] <axw> ok
[02:03] <anastasiamac> axw: it looks like port could be optional... unless square brakcets have other meaninng...
[02:03] <axw> nope, that would mean optiona
[02:03] <axw> l
[02:04] <anastasiamac> axw: ;-(
[02:04] <anastasiamac> i'll do a regexp for now... we can alsways neat it up once url.parse and net.IP.isLoopback cater for every possibility... :-)
[02:05] <axw> okey dokey
[02:05] <anastasiamac> axw: i do prefer to call on framework rathern than rely on regexp
[02:05] <anastasiamac> axw: thnx for pointing me in the right (i.e. proper) direction! :-)
[02:05] <axw> nps
[02:15] <bigjools> folks, when juju destroys an environment, does it keep issuing commands to destroy individual machines if it later notices that one is not in the state it expected (ie getting destroyed)?  This might be provider-specific, in which case I'm talking about maas.
[02:16] <bigjools> axw: you worked on the maas provider recently :) --^
[02:17] <axw> bigjools: I'll check what it does
[02:17] <bigjools> cheers
[02:17] <axw> I think it issues a single release call
[02:18] <axw> bigjools: http://pad.lv/1319016
[02:18] <axw> it does a single release API call
[02:18] <axw> bigjools: why do you ask?
[02:18] <bigjools> axw: because https://bugs.launchpad.net/maas/+bug/1381619
[02:18] <mup> Bug #1381619: Failed to destroy-environment when node is in commissioning or new state <cloud-installer> <oil> <juju-core:Triaged> <MAAS:Triaged> <https://launchpad.net/bugs/1381619>
[02:19] <bigjools> axw: ignore the bug title, look at what greg posted
[02:19] <bigjools> I'll need to explain some background perhaps:
[02:19] <bigjools> we added some more states. It used to go from ALLOCATED straight to READY as soon as an API call was issued to release the node, however now it goes via a RELEASING state
[02:20] <bigjools> but because this broke some API users, we folded RELEASING into ALLOCATED so that API users never see it
[02:20] <bigjools> I wondered if juju was issuing a release call, and still seeing ALLOCATED when in reality it's RELEASING, so juju issues another release?
[02:21] <axw> bigjools: ah ok. nope, we don't interpret the error or retry at the moment
[02:21] <bigjools> oh ,weird then
[02:21] <axw> good to know for the bug I mentioned tho...
[02:21] <bigjools> yeah
[02:21] <axw> I'll paste that in there
[02:22] <bigjools> axw: how does it know when the env is destroyed?  Or does it just fire and forget?
[02:23] <axw> bigjools: it'll do do a release of all nodes, and check if it passed/failed based on HTTP status code only
[02:23] <bigjools> ok
[02:23] <bigjools> hmmm
[02:23] <bigjools> that bug makes no sense then, unless people were mannually titting about with things first
[02:24] <axw> bigjools: hmm. actually, Bootstrap will do a release of the bootstrap node if it manages to acquire it and then something goes wrong
[02:24] <axw> then when the env is destroyed, it'll try to release it again
[02:25] <bigjools> ah
[02:25] <axw> I *think* anyway
[02:25] <bigjools> axw: so releasing twice?
[02:25] <axw> why did the instance stop showing up tho? i.e. why "ERROR bootstrap failed: refreshing addresses: no instances found
[02:25] <axw> Stopping instance..."
[02:25] <bigjools> NFI what was going on there
[02:26] <bigjools> it's a shame people don't report what actions they were taking, and just post log snippets
[02:27] <axw> bigjools: actually no, that error message greg pasted is from the first attempt to release
[02:28] <axw> there may or may not be a second attempt, depending on what MAAS returns to Juju when it tries to list nodes with agent-name later, but I don't think it's relevant
[02:28] <bigjools> axw: looking at the event log, it did fail while coming up
[02:28] <bigjools> well
[02:29] <bigjools> something caused bootstrap to release the node while it was deploying
[02:29] <axw> (the second attempt would occur after that error is listed)
[02:31] <bigjools> I asked greg to file another bug with more info
[03:28] <axw> wallyworld: can you please take a look at http://reviews.vapour.ws/r/137/diff/2-3/
[03:28] <wallyworld> sure, justing finishing a review, will look real soon
[03:28] <axw> there's a drive by fix to ssh/run_test.go, which failed when I tried to land my change once
[03:28] <axw> yep no rush
[03:29] <axw> the main change is that I've made the metadata commands use environs.New, rather than environs.Prepare; i.e. they require an existing env now
[03:47] <wallyworld> axw: i think the changes are ok - any env should already be existing when using those metadata commands
[03:48] <axw> wallyworld: thanks. utils/ssh is used by testing, so can't use the existing ShortWait/LongWait
[03:48] <wallyworld> ah ok
[03:50]  * wallyworld -> get more coffee, it's an emergency
[04:11] <axw> wallyworld: I've removed myself from that credential bug and moved it back to the planning lane. azure and joyent still need doing.
[04:31] <wallyworld> axw: ok, np
[08:08] <mattyw> morning everyone
[08:42] <wallyworld> axw: if you get a chance before your EOD, cloud you look at http://reviews.vapour.ws/r/264/ ? it's a large number of file but 99% of the changes are mechanical - the tools stream needs to be added as a parameter to many test methods
[08:43] <axw> wallyworld: ok
[08:43] <wallyworld> ty, if you don't get to it, that;s fine
[08:44] <axw> nah I need a break from storage, will look now
[09:04] <voidspace> morning all
[09:09] <lazyPower> o/ morning core devs
[09:27] <wallyworld> axw: thanks for review :-) i prefer to use string literals in tests to cause breakage when things change, so that tests are thought about
[09:28] <jam> morning voidspace
[09:29] <jam> voidspace: did you see: https://github.com/juju/juju/pull/962 wallyworld wants to cache your lookup, which I think we were talking about doing a different way
[09:30] <jam> ah, read it wrong, you proposed it :)
[09:30] <jam> the email comes as "no-reply" and then is responded by "ian" so the mail preview always gives me the wrong impression
[09:30]  * wallyworld doesn't want to cache the lookup - the pr implements a cache and i had a query about it
[09:31] <jam> wallyworld: we can't change vpc at all for the lifetime of an environment
[09:31] <axw> wallyworld: ok
[09:31] <jam> wallyworld: instances in 1 vpc can't communicate via private network to instances in another vpc
[09:31] <jam> wallyworld: so the "lifetime of juju process" is a misnomer
[09:31] <jam> it is "lifetime of a juju environment"
[09:31] <wallyworld> jam: ok, thanks. the pr said the vpc *could* change
[09:31] <wallyworld> it was unclear if that would be in the lifetime of an env or not
[09:31] <jam> wallyworld: first thoughts were that it could, further thinking realized "no we can't actually support that"
[09:32] <wallyworld> ok, np. i think then my only concern (from memory) is that a muctex should be used
[09:32] <wallyworld> mutex
[09:34] <voidspace> yeah, my mistake in the description
[09:34] <voidspace> the vpc changing would be "bad" for an environment - but it isn't likely to happen during the lifetime of a process anyway
[09:34]  * TheMue wonders about the Google Calendar. It shows the correct time now after switching back from DST, but the alerts are for a false time?!?!?!
[09:35] <voidspace> wallyworld: I'll add the mutex
[09:35] <wallyworld> voidspace: ok, thanks, that then conforms to existing practice
[09:35] <voidspace> wallyworld: that's in code already committed - it was just missed in the review of that code
[09:35] <voidspace> easy to add it now
[09:36] <wallyworld> voidspace: np. i also had a question about one of the tests
[09:36] <voidspace> wallyworld: yes, I just answered that
[09:36] <voidspace> wallyworld: the test is the same because I want to *prove* that cached value is used
[09:36] <voidspace> wallyworld: so even after changing what the api would return I expect to get the previous value back
[09:36] <wallyworld> ah, let me take another look
[09:36] <voidspace> wallyworld: proving that a second api call wasn't made
[09:36] <voidspace> wallyworld: that's the intent
[09:40] <wallyworld> voidspace: i may be dumb, but from what i can tell, the code could still make an api call and return those result values and make the test pass. the more correct approach would be to mock out the api call and put in an assert that it is not called
[09:42] <jam> TheMue: you didn't get your reminder for our 1:1? I didn't see you around, I should have pinged, I guess
[09:42] <voidspace> wallyworld: if it made an api call it would get the opposite result
[09:42] <voidspace> wallyworld: if you remove the caching and run the test it fails
[09:42] <voidspace> wallyworld: I did check that
[09:42] <voidspace> wallyworld: also, with the mutex
[09:43] <wallyworld> voidspace: ok, then i was being dumb :-)
[09:43] <TheMue> jam: I got it, for in 18 minutes. And later I thought that it would conflict with our standup.
[09:43] <voidspace> wallyworld: there is a mutex in the call to e.ec2()
[09:43] <voidspace> wallyworld: the common pattern in ec2.go where e.ec2() is used seems to be *not* to use an extra mutex
[09:43] <TheMue> jam: but no I got the alert for the standup, also one hour too late.
[09:43] <wallyworld> voidspace: ok, np. i missed that nuance
[09:44] <jam> TheMue: are these email alarms or popup ones?
[09:44] <TheMue> jam: email
[09:44] <voidspace> wallyworld: the mutex in use seems to be a config mutex - preventing the ec2 configuration changing whilst we're building the ec2 instance
[09:44] <voidspace> although it doesn't prevent it changing whilst we're using it :-/
[09:45] <wallyworld> voidspace: yeah, that was my worry
[09:45] <wallyworld> voidspace: anyway, that's a separate issue it seems, so i marked it lgtm
[09:45] <voidspace> wallyworld: locking every use would serialise all our api calls though
[09:45] <voidspace> wallyworld: awesome, thanks
[09:45] <wallyworld> np, thanks for putting up with my questions
[09:45] <voidspace> heh :-)
[09:45] <TheMue> jam: but simply won't care for them in the future now as I now it :D and will be at standup at the correct time
[09:46] <voidspace> wallyworld: I'll change the PR description before merging, so the comment about default-vpc is correct
[09:46] <wallyworld> awesome, ty
[09:55] <fwereade> wallyworld, thanks for the review
[09:55] <fwereade> wallyworld, lots of that stuff is preexisting, but now someone's complained about them I can muster up the emotinal strength to work on some of them a bit ;p
[09:55] <wallyworld> fwereade: np, it looks great but as i said, i am unfamiliar with the finer detail
[09:56] <fwereade> wallyworld, it needs more steps before it's really approaching properly sane tbh
[09:56] <wallyworld> fwereade: yeah, i figured as much, hard to tell what was new vs moved
[09:56] <fwereade> wallyworld, that's the trouble
[09:56] <wallyworld> eat an elephant one bite at a time
[09:57] <fwereade> wallyworld, exactly
[09:57] <fwereade> wallyworld, and I've only really been going on this path for a week and it's already feeling noticeably better
[09:57] <wallyworld> yep :-)
[09:57] <fwereade> wallyworld, actions needs a bunch of work too
[09:57] <wallyworld> if it all works, i reckon commit what you've done so far
[09:57] <wallyworld> so it doesn't bit rot
[09:57] <fwereade> wallyworld, well, it's worth another pass to fix your suggestions
[09:57] <wallyworld> ok
[09:57] <wallyworld> they were not mandatory
[09:58] <wallyworld> if the code was existing
[09:58] <wallyworld> but would be nice to see them fixed sometime
[09:58] <fwereade> wallyworld, yeah, I reserve the right to ignore the ones that turn out to be rabbit holes
[09:58] <fwereade> wallyworld, at least for this branch
[09:58] <wallyworld> yep, np there
[09:59] <jam> TheMue: standup ?
[09:59] <fwereade> wallyworld, but I am very firmly trying to steer a happy course between fix-only-what's-needed and FIX-ALL-THE-THINGS, cos the former leads where we are today and the latter stops me doing anything directly
[09:59] <wallyworld> fwereade: +100
[10:00] <TheMue> jam: coming, my clock say :59 ;)
[10:28] <fwereade> wallyworld, just pushed a couple of updates, would you give it a quick once-over? I didn't fix the yucky docstring because whenever I start trying to edit that file I start pulling on loose threads everywhere and get sucked in
[10:28] <wallyworld> sure
[10:37] <wallyworld> fwereade: changes look sound
[10:37] <fwereade> wallyworld, awesome
[10:38] <fwereade> wallyworld, is that a ship-it, then? :)
[10:41] <wallyworld> fwereade: if you are happy, yeah :-) as i said, take my +1 with a little skepticism :-)
[10:41] <wallyworld> but i like the direction it is heading very much
[10:42] <fwereade> wallyworld, cool
[10:42] <fwereade> wallyworld, I'm making a big effort to avoid changing functionality
[10:43] <fwereade> wallyworld, not that it always works, I just realised that I broke relation settings caching in one of the previous branches, so that's th enext one before I can fix actions
[10:43] <wallyworld> yep, tests will tell us :-)
[11:06] <hazmat> something in 1.21alpha2 seems to have broken the allwatcher
[11:06] <hazmat> its no longer reporting all the services in an environment
[11:15] <perrito666> morning
[11:15] <natefinch> morning
[11:16] <mattyw> tasdomas, as OCR could you take a look at this http://reviews.vapour.ws/r/265/?
[11:16]  * perrito666 tries to convince his ubuntu that it can upgrade to a new version
[11:18] <voidspace> jam: so I haven't yet found the neutron api for assigning a private p address
[11:19] <voidspace> jam: one example I saw created a port to reserve the address
[11:20] <voidspace> http://blog.felipe-alfaro.com/2014/05/09/fixed-ip-addresses-with-openstack-neutron-for-tenant-networks/
[11:21] <voidspace> I'm not sure a port is quite what we want
[11:21] <voidspace> https://wiki.openstack.org/wiki/Neutron/APIv2-specification#Create_Port
[11:21] <voidspace> The APIv2 spec doesn't seem to have an alternative api though
[11:21] <voidspace> I'll look and see if dimiter has written about this in the networking spec
[11:26] <jam> voidspace: I'm back in our 1:1 hangout
[11:26] <voidspace> jam: ok
[11:27] <jam> I found "UpdatePort" which I think is what we want
[11:27] <voidspace> jam: except the addresses you provide overwrite the existing ones
[11:27] <jam> voidspace: yeah
[11:27] <voidspace> jam: so effectively that would be manual management
[11:27] <jam> I don't see a way to "request a new one"
[11:27] <jam> voidspace: I'm seriously considering manual management
[11:28] <jam> voidspace: as that gives us a token
[11:28] <jam> "this IP address that I'm assigning is going to go to this LXC"
[11:29] <perrito666> I would really appreciate a review on this http://reviews.vapour.ws/r/238/ looks big but its not
[11:29] <tasdomas> mattyw, reviewed your PR - looks good
[11:40] <mattyw> tasdomas, thanks very much
[12:08] <TheMue> Hmm, did something changed on runTransaction()? My so far working migration now aborts since I merged master.
[12:08] <TheMue> Sadly it doesn't says why it is aborting.
[12:16] <fwereade> perrito666, LGTM with trivials
[12:16] <fwereade> perrito666, good change, thanks
[12:20] <perrito666> fwereade: tx for the review
[12:20] <fwereade> jam, can I send you into #juju-gui to have a talk with frankban about something networky-looking please?
[12:20]  * perrito666 visists a friend company for coworking for the day and he gets his space bar fixed
[12:21] <fwereade> jam, no public networks from the AllWatcher: http://pastebin.ubuntu.com/8703311/ (although I see a localhost with public scope..?)
[12:23] <frankban> fwereade: yeah, but no ipv4 address with public scope
[12:24] <fwereade> frankban, indeed, but localhost doesn't helpmost people very much ;p
[12:24] <frankban> fwereade: yeah, and this breaks local quickstart usage
[12:25] <fwereade> frankban, I'm sorry I can't give you my full attention right now -- dimitern may be on a swap day? otherwise jam or TheMue are most likely to have something relevant to say about networking
[12:25] <fwereade> frankban, it sounds like a critical bug regardless, please go ahead and report it
[12:27] <frankban> fwereade: this seems to be part of a more general problem with the mega-watchers: hazmat filed bug 1386143
[12:27] <mup> Bug #1386143: 1.21 alpha 2 broke watch api, no longer reports all services <api> <regression> <juju-core:Confirmed> <https://launchpad.net/bugs/1386143>
[12:28] <fwereade> frankban, ok, cool, would you add it to that bug then (assuming status gives you what you want, but the watcher is broken?)
[12:29] <frankban> fwereade: sure, and thanks
[12:29] <fwereade> waigani, heads up: ^^ I think you/menn0/thumper have been in state lately?
[12:32] <jw4> fwereade: morning; were you saying you were going to do a bunch of refactoring in actions?
[12:33] <fwereade> jw4, have you been seeing the changes going by in uniter?
[12:33] <fwereade> jw4, it's an extension of that really -- trying to move context/runner related stuff out of uniter
[12:34] <jw4> fwereade, ah, you mean the hook context stuff?  I haven't caught up the last 24 hours yet :)
[12:34] <jw4> fwereade: sure  I remember now
[12:34] <fwereade> jw4, in particular, I think the validation stuff needs to move into the context package
[12:34] <jw4> fwereade: kk
[12:34] <fwereade> jw4, and the RunActions stuff needs at least *some* explicit testing beyond "RunAction fails on a non-action context"
[12:34] <fwereade> jw4, but, I'm getting there
[12:35] <fwereade> jw4, I'm 90% focused on structural stuff and testability
[12:35] <jw4> fwereade: you're on a tear... did you rest this weekend at all?
[12:35] <fwereade> jw4, I just managed to ignore everything else and focus on code for the week :)
[12:35] <fwereade> jw4, the weekend was mostly relaxed
[12:35] <jw4> fwereade: lol... good
[12:36] <fwereade> jw4, once I've got a load of the uniter stuff out of the way I should be able to rework the modes into an explicit hook queue
[12:36] <fwereade> jw4, it's what I "should" be doing right now but I need to clear the underbrush first iyswim
[12:36] <jw4> fwereade: yep, yep
[13:14] <jam> frankban: is this on EC2? And do you have default-vpc available there?
[13:14] <jam> 172.* looks suspiciously like the cloud-local addresses EC2 likes to give out
[13:15] <jam> ah, I guess this was a local environ
[13:15] <jam> so not ec2
[13:16] <jam> voidspace: since you're on at this time, do you have a chance to look at the networking part of bug #1386143 ?
[13:16] <mup> Bug #1386143: 1.21 alpha 2 broke watch api, no longer reports all services <api> <regression> <juju-core:Confirmed> <juju-gui:Triaged> <juju-quickstart:Triaged> <https://launchpad.net/bugs/1386143>
[13:25] <frankban> jam: the addresses problem is on a local env, yes
[13:25] <jam> frankban: so I think the issue is that the 10.* address *is* the public address on local
[13:25] <frankban> jam: exactly, and it was previously
[13:41] <voidspace> jam: sure
[13:49] <sinzui> natefinch, jam, can you find someone to fix a test that fails when we increment to alpha3? bug 1386204
[13:49] <mup> Bug #1386204:  metadataSuite.TestAsJSONBuffer fails when version is alpha3 <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1386204>
[13:51] <mgz> eric wrote the test, but should be pretty simple for anyone to fix up
[13:51] <jam> voidspace: so I'm guessing how we determine public vs private cahnged,
[13:52] <voidspace> jam: ok
[13:52] <voidspace> *looks* like it should be easy...
[13:57] <voidspace> a backup test
[13:58] <voidspace> jam: ah, I thought you were referring to 1386204
[13:58] <voidspace> sinzui: jam: 1386204 we can fix by formatting the current version into the test data
[13:59] <voidspace> currently it's hardcoded and will fail every time the version changes
[13:59] <voidspace> sinzui: jam: I'll propose a branch for that
[14:00] <sinzui> thank you voidspace
[14:01] <sinzui> voidspace, you might want to merge https://github.com/juju/juju/pull/970 to get the version change too.
[14:04] <perrito666> natefinch: ericsnow wwitzel3 getting there
[14:08] <voidspace> sinzui: I have a branch that works with trunk (trivial) and also passes with the version changed manually
[14:08] <voidspace> sinzui: I'll just propose it separately
[14:09] <sinzui> thank you voidspace
[14:13] <voidspace> https://github.com/juju/juju/pull/971/
[14:13] <voidspace> There's no reviewboard url yet
[14:14] <voidspace> natefinch: care for a (hopefully) easy review?
[14:14] <mgz> voidspace: seems fine to me
[14:14] <voidspace> mgz: cool, will this merge or do I need to force?
[14:16]  * voidspace is grabbing coffee
[14:17] <mgz> it is the blocking bug, so you just need to mark as fixes-NNN
[14:28] <perrito666> ericsnow: natefinch wwitzel3 the call got unusable
[14:37] <sinzui> natefinch, jam I have escalated Bug #1385289 because the last 8 devel revisions tested failed because upgrades consistently timeout on all providers...including stable and devel maas
[14:37] <mup> Bug #1385289: local storage migration is very slow <ci> <regression> <test-failure> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1385289>
[14:38] <natefinch> perrito666: np
[14:44] <voidspace> ericsnow: I didn't see a reviewboard review created for this PR
[14:44] <voidspace> ericsnow: https://github.com/juju/juju/pull/971
[14:44] <ericsnow> voidspace: checking
[14:46] <ericsnow> voidspace: looks like github is rate-limiting the requests
[14:47] <ericsnow> voidspace: I'll see if I can work around that better (may not happen immediately)
[14:47] <voidspace> ericsnow: does it just drop them you think?
[14:47] <voidspace> ericsnow: ok, np
[14:48] <ericsnow> voidspace: I'm thinking it drops requests ("API rate limit exceeded ...")
[14:48] <ericsnow> voidspace: I should be able to work around that though
[14:49] <ericsnow> voidspace: did it not create a review request at all?
[14:49] <voidspace> ericsnow: as far as I can tell not
[14:49] <voidspace> sinzui: how can tell which revision was used for the 1.21alpha2 release?
[14:49] <voidspace> sinzui: looking for the version number change in the commit history?
[14:49] <ericsnow> voidspace: bummer (I would have expected it to make one)
[14:50] <ericsnow> voidspace: in the meantime you can use rbt post
[14:50] <voidspace> ericsnow: no need on this occasion, but thanks
[14:50] <ericsnow> voidspace: k
[14:50] <sinzui> voidspace, https://github.com/juju/juju/releases
[14:51] <sinzui> voidspace, reports.vapour.ws will one day republish that ^ info
[14:51] <voidspace> sinzui: ah, cool - thanks
[14:52] <voidspace> I checked my tags in my local clone, but I don't have them all
[14:52] <voidspace> maybe this is a git thing
[14:52] <voidspace> I have the major release tags, but not the alphas
[14:52] <voidspace> well, minor release tags
[14:53] <voidspace> ah
[14:53] <voidspace> git pull upstream master  --tags
[14:53] <voidspace> now I have them
[14:55] <voidspace> sinzui: my fix for issue 1386204 landed
[14:55] <voidspace> sinzui: I've marked it as fix committed
[14:55] <sinzui> voidspace, rock
[15:34] <TheMue> Gna, first needed to find why PR failed (overlapping change regarding DocID) and now the fixes block it. :)
[15:47] <voidspace> Is anyone else looking at bug 1386143
[15:47] <voidspace> https://bugs.launchpad.net/juju-core/+bug/1386143
[15:47] <mup> Bug #1386143: 1.21 alpha 2 broke watch api, no longer reports all services <api> <regression> <juju-core:Triaged> <juju-gui:Triaged> <juju-quickstart:Triaged> <https://launchpad.net/bugs/1386143>
[15:50] <voidspace> frankban: ping
[15:58] <voidspace> now do I get the megawatcher output?
[15:59] <voidspace> Bug report above states "Probably a side effect of this regression: on local environments, the mega-watcher for machines no longer reports the ipv4 address in the public scope"
[16:02] <frankban> voidspace: pong
[16:02] <voidspace> frankban: hey
[16:02] <voidspace> frankban: see above
[16:02] <voidspace> frankban: I'd like repro instructions for getting the mega-watcher log
[16:03] <voidspace> frankban: as you reported for bug 1386143
[16:03] <mup> Bug #1386143: 1.21 alpha 2 broke watch api, no longer reports all services <api> <regression> <juju-core:Triaged> <juju-gui:Triaged> <juju-quickstart:Triaged> <https://launchpad.net/bugs/1386143>
[16:03] <frankban> voidspace: ok
[16:05] <frankban> voidspace: do you have quickstart installed? otherwise I can quickly write a script to see the mega-watcher output
[16:06] <voidspace> frankban: I don't have it installed no
[16:06] <voidspace> frankban: I'm happy to install it if it helps
[16:06] <voidspace> is it just from juju-plugins?
[16:07] <frankban> voidspace: no, ok I am adding dupe instraction re quickstart to the bug
[16:07] <voidspace> frankban: cool, thanks
[16:16] <voidspace> Ok, I now have juju-quickstart installed
[16:19] <voidspace> frankban: so, running juju-quickstart dies with:
[16:19] <voidspace> http://pastebin.ubuntu.com/8706138/
[16:19] <voidspace> frankban: is this the error you're getting?
[16:20] <voidspace> I'd still like to be able to see the megawatcher output directly
[16:20] <frankban> voidspace: no, this is a very old version of quickstart
[16:20] <voidspace> frankban: hah, ok
[16:20] <voidspace> I need to add the right ppa then
[16:20] <voidspace> I assumed I had it already
[16:20] <voidspace> frankban: is the version in the juju-stable ppa correct?
[16:20] <frankban> voidspace: yeah, added instructions for that too in https://bugs.launchpad.net/juju-core/+bug/1386143
[16:20] <mup> Bug #1386143: 1.21 alpha 2 broke watch api, no longer reports all services <api> <regression> <juju-core:Triaged> <juju-gui:Triaged> <juju-quickstart:Triaged> <https://launchpad.net/bugs/1386143>
[16:20] <voidspace> or should I get from source
[16:20] <voidspace> frankban: thanks
[16:21] <frankban> voidspace: did not mention it, but the current version in the PPA is juju quickstart v1.4.4
[16:25] <frankban> voidspace: FWIW sometimes I use this quick and dirty script to observe the juju megawatcher: http://pastebin.ubuntu.com/8706233/
[16:26] <voidspace> frankban: awesome, thanks
[17:37]  * perrito666 just now realizes that the build is blocked
[18:00] <voidspace> frankban: so I've relinked the /usr/bin/juju* binaries to my built ones (so I can use juju-quickstart) and I'm doing git bisect
[18:00] <voidspace> see if I can tell where this broke
[18:00] <voidspace> frankban: as the bug is reported against alpha2 I'm assuming alpha 1 is known good
[18:03] <frankban> voidspace: I am not sure about that
[18:03] <frankban> voidspace: FYI the env var JUJU can be used in quickstart to override the JUJU binaty location, so that you don't have to relink the distro juju
[18:04] <frankban> binary even
[18:04] <voidspace> frankban: hah
[18:04] <voidspace> frankban: that would be better...
[18:05] <voidspace> frankban: so we're not sure that 1.21 alpha 1 is good
[18:05] <voidspace> frankban: so I need to go back and find the last good release and bisect from there
[18:05] <frankban> voidspace: I did not test that
[18:06] <voidspace> frankban: ok, thanks
[18:06] <tvansteenburgh> voidspace: i've been using deployer with alpha1 since it came out w/ no problem
[18:06] <frankban> np, thank you for looking at that
[18:06] <tvansteenburgh> voidspace: (fwiw), i think this broke in alpha2
[18:07] <voidspace> tvansteenburgh: cool, thanks
[18:08] <voidspace> tvansteenburgh: I'm mid-bisect so stopping to double check would be "inconvenient"
[18:08] <voidspace> although I'll probably check on my laptop anyway
[18:08] <voidspace> wasting time on a bisect that can never work would be *worse*
[18:08] <frankban> voidspace: I suppose you already noticed that, but FYI the addresses bug (quickstart) is only part of the bigger problem (and we assumed to be related but we are not really sure), the bigger problem being entities (e.g. services) not listed in the mega-watcher responses
[18:09] <frankban> voidspace: if you are tackling also that, then my watch script can be useful while bisecting, e.g. bisect, bootstrap, deploy one or two services, run the script to see the watcher response reflect the status, etc.
[18:24] <hazmat> tvansteenburgh, alpha2 is the breaker
[18:24] <hazmat> alpha1 is fine
[18:24] <hazmat> tvansteenburgh, this has nothing to do with deployer per se
[18:24] <hazmat> tvansteenburgh, this is just core having broken the all|mega-watcher
[18:24] <tvansteenburgh> hazmat: understood, i was just trying to help voidspace limit the breadth of his bisect :)
[18:25] <hazmat> right
[18:25] <hazmat> voidspace, you have a script already?
[18:25] <hazmat> the issue is that you'll need to cross grade your api servers to match your bisect or bootstrap per.. ick
[18:50] <voidspace> hazmat: no, but it's not a comlex set of steps
[18:50] <voidspace> hazmat: I'll destroy-environment and go install ./... in between each bisect
[18:51] <voidspace> hazmat: (had to stop - restarting now)
[18:51] <voidspace> hazmat: it's building a local environment, so not complex
[18:51] <voidspace> hazmat: I'll probably script it
[19:02] <natefinch> perrito666: your restore worker is LGTM
[19:47] <perrito666> natefinch: tx, I just got power back
[19:47] <perrito666> apparently 40°C exceeds what the power converters can handle
[19:50] <ericsnow> what would cause "state changing too quickly; try again soon" when running a transaction?
[19:53] <wwitzel3> ericsnow: not sure, the only place that error comes from is the txn transactionRunner.Run
[19:53] <perrito666> ericsnow: wwitzel3 most likely too many retries to run a tx.Op with no success
[19:54] <ericsnow> wwitzel3: yeah, and I'm not exactly sure what I did to change the existing behavior
[19:54] <wwitzel3> ericsnow: and the body of that is just a for loop that used nrRetries (set to 3) .. so after 3 attempts, the if none of the return paths in the for loop hit, you get that error.
[19:54] <ericsnow> perrito666: what does the retries?
[19:54] <cmars> ericsnow, that error is often (though not always) a bug in the logic for state changes.
[19:55] <ericsnow> cmars: I'm introducing a separate DB just for backups and running backups-related queries against that
[19:56] <cmars> ericsnow, a transaction that fails to maintain the assert condition for the duration of the operation will error out that way
[19:56] <ericsnow> cmars: I'll look into that
[19:56] <cmars> ericsnow, for example your operation negated the assert condition, that'd be a logic bug
[19:57] <cmars> ericsnow, could also be a concurrency issue, in which you're requiring conditions that fail to converge when you'd expect
[20:02] <fwereade> cmars, hey, did you come to a conclusion about service-owner?
[20:02] <cmars> fwereade, service-owner.. the context escapes me atm
[20:03] <fwereade> cmars, we added it to hook contexts as part of the initial abortive metrics spike
[20:03] <fwereade> cmars, AFAIK nobody uses it
[20:03] <fwereade> cmars, I'd really like to just delete it and hope nobody notices
[20:05] <fwereade> cmars, also, would you confirm that we'll be dropping the allow-add-metrics-only-in-some-hooks? because I'd like to drop it right now ;p
[20:31] <thumper> natefinch: hey
[20:31] <natefinch> thumper: yo coming
[20:33] <natefinch> wwitzel3: lxc meeting?
[20:57] <perrito666> rick_h_: how do you remove the tool bar form gvim?
[20:57] <natefinch> perrito666: install emacs ;)
[20:59] <katco> did someone say emacs?
[21:01] <natefinch> heh
[21:01] <perrito666> natefinch: sadly I only have 10 fingers in my hand
[21:01] <katco> no worries, they sell foot pedals now!
[21:08] <menn0> perrito666, katco: I use Emacs with Evil which reduces the need for non-standard appendages
[21:08] <menn0> https://gitorious.org/evil/pages/Home
[21:08] <menn0> it also requires that your brain has been rewired for Vim bindings but mine already was :)
[21:08] <menn0> it's a really well written extension anyway
[21:10] <katco> menn0: i've used that when vim ppl try to help me out at my keyboard
[21:10] <katco> menn0: i hear good things
[21:15] <natefinch> evidenly redhat is branching out.  My daughter played with some of these at school: http://2.bp.blogspot.com/-3c1hIpxVvms/T5CvbwxJV7I/AAAAAAAABZ0/xDYY4yOkm9E/s1600/easter+scentos.jpg
[21:18] <waigani> thumper/menn0 what should I test for when a machine has not instanceid and there is no instanceData doc?
[21:18] <menn0> waigani: I think so. The test should ensure that a warning is logged.
[21:19] <waigani> menn0: okay, cheers
[21:34] <menn0> waigani, thumper: bug 1386143 could be due to migration changes ...
[21:34] <mup> Bug #1386143: 1.21 alpha 2 broke watch api, no longer reports all services <api> <regression> <juju-core:Triaged> <juju-gui:Triaged> <juju-quickstart:Triaged> <https://launchpad.net/bugs/1386143>
[21:35] <alexisb> waigani, hey there
[21:36] <alexisb> I need to chat with mramm before we meet, mind if I am a few minutes late?
[21:39] <thumper> menn0: hmm... ya think?
[21:39] <menn0> waigani, thumper: in fact I think we already fixed that bug but it didn't make alpha2. this is probably due to the doubled up env UUID prefixing in the allwatcher.
[21:40] <thumper> ah...
[21:40] <fwereade> wallyworld, ping
[21:40] <thumper> sinzui: what is the process for broken alphas?
[21:40] <waigani> alexisb: when are we meeting?
[21:40] <menn0> thumper: the fix is part of the machines colleciton change
[21:40] <thumper> sinzui: do we just try the next alpha?
[21:40]  * thumper nod
[21:40] <thumper> s
[21:41] <menn0> thumper: shall I dig in to this a bit?
[21:41] <wallyworld> fwereade: am in a meeting, will ping soon
[21:41] <thumper> menn0: yeah, have a quick dig and see if the machine fixes did fix it
[21:41] <cmars> wallyworld, ping me as well when you're done
[21:41] <menn0> thumper: k
[21:42] <waigani> alexisb: just ping we when you're ready
[21:44] <fwereade> wallyworld, cool, talking to cmars about the interactions between metrics and status
[21:44] <fwereade> wallyworld, rough eta?
[21:44] <fwereade> thumper, menn0, waigani: o/
[21:44] <thumper> o/
[21:44] <wallyworld> fwereade: 30 mins?
[21:44] <waigani> fwereade: hey
[21:45] <fwereade> thumper, menn0, waigani: hazmat had a bug about AllWatcher not notifying about important stuff; frankban had probable confirmation; can I rest assured that you guys are loking into  it/on it?
[21:46] <waigani> fwereade: sounds like the above bug?
[21:46] <thumper> fwereade: yeah, menn0 is looking into it now
[21:46] <fwereade> waigani, menn0, thumper: yay, you're already on it, I am redundant :)
[21:49] <sinzui> thumper, we fix them in the next alpha. We want to release alpha3 this week
[21:50] <fwereade> wallyworld, cmars: please talk when you're both free
[21:50] <fwereade> wallyworld, cmars: will try to be back in half an hour, if not I think you have enough to talk about
[21:51]  * fwereade goes to play some lego star wars
[22:06] <alexisb> waigani, sent you a reschedule
[22:06] <waigani> alexisb: sweet, thanks
[22:08] <waigani> menn0: http://reviews.vapour.ws/r/177/
[22:09] <menn0> waigani: I'm going to be a while... looking at this regression
[22:10] <waigani> menn0: all good, I'll move onto sequences
[22:10] <menn0> waigani: sounds good. that's not going to rely on the instancedata branch
[22:10] <waigani> menn0: I'll put my initials next to what I'm working on in the MESS doc
[22:11] <menn0> waigani: good idea
[22:12] <menn0> waigani: I'll do the same
[22:12] <menn0> waigani: remember to add LK cards as you go as well
[22:13] <waigani> menn0: sigh, I'll add those now. I added your username in the MESS doc
[22:13] <menn0> waigani: cheers
[22:20] <voidspac_> menn0: ping
[22:20] <menn0> voidspac_: hey
[22:20] <voidspac_> menn0: hi, how's it going?
[22:20] <voidspac_> menn0: are you working on 1386143?
[22:21] <menn0> voidspac_: not too bad
[22:21] <menn0> voidspac_: I am indeed
[22:21] <menn0> voidspac_: I suspect it's already been fixed by Jesse and I
[22:21] <voidspac_> menn0: I started to look at it - my intention was to do a git bisect
[22:21] <ericsnow> voidspac_: thanks for taking care of that backup metadata test :)
[22:21] <menn0> voidspac_: we noticed the problem and fixed it but the branch didn't land before alpha2 was fixed
[22:21] <voidspac_> menn0: but following the repro instructions on the bug I couldn't get juju-quickstart working even with 1.20!
[22:21] <voidspac_> menn0: hah
[22:22] <menn0> voidspac_: s/fixed/cut/
[22:22] <voidspac_> menn0: what is the problem?
[22:22] <voidspac_> ericsnow: no problem, easy fix
[22:22] <menn0> voidspac_: a buggy change introduced as part of env UUID migrations
[22:22] <voidspac_> menn0: ah right, can I look at your branch?
[22:23] <voidspac_> menn0: I started looking through the diff between 1.21 alpha 1 and alpha 2
[22:23] <voidspac_> it's about 8000 lines or something...
[22:23] <menn0> if it's what I think it is then the fix is already merged.
[22:25] <menn0> voidspac_: it'll be part of 69c60b6fb293a7e6ea3a32d6365cf5eccd257fa5
[22:25] <voidspac_> menn0: doesn't look like anything landed on trunk
[22:25] <menn0> voidspac_: the bottom of megawatcher.go
[22:26] <voidspac_> menn0: ah, right - so trunk should already be unbroken
[22:26] <menn0> voidspac_: the docID method was adding the environment UUID onto ids that already had it
[22:26] <voidspac_> menn0: I'll try it with the repro instructions
[22:26] <menn0> voidspac_: I'm doing the repro with master now
[22:27] <voidspac_> menn0: cool
[22:32] <menn0> voidspac_: looking better so far. there's unit deltas coming out of the allwatcher with master where there wasnt with alpha2
[22:32] <rick_h_> perrito666: https://github.com/mitechie/pyvim/blob/master/.vimrc#L116
[22:34] <menn0> voidspac_: quickstart works with master so it looks like the problem is fixed \o/
[22:34] <voidspac_> menn0: awesome, great news
[22:35] <wallyworld> fwereade: sorry, free now, too late?
[22:35] <menn0> voidspac_: I'll try one more thing to confirm and then will update the ticket
[22:36] <wallyworld> cmars: hi, did we need to talk?
[22:37] <fwereade> wallyworld, cmars: heyhey
[22:37] <cmars> wallyworld, yeah, wanted to catch up on status stuff
[22:37] <wallyworld> sure
[22:37] <cmars> and other things
[22:37] <wallyworld> hangout?
[22:37] <fwereade> one of you statr one please :)
[22:38] <wallyworld> we can use this one https://plus.google.com/hangouts/_/canonical.com/ian-tim
[22:39] <fwereade> wallyworld, joined
[22:39] <wallyworld> fwereade: cmars posted one aove
[22:39] <wallyworld> https://plus.google.com/hangouts/_/gqzen7cwgsho4s6fxwqrgoc7dma?hl=en
[23:00] <menn0> voidspac_, thumper, waigani: regarding bug 1386143... quickstart and the GUI are definitely working with master. still doing a few more checks though.
[23:00] <mup> Bug #1386143: 1.21 alpha 2 broke watch api, no longer reports all services <api> <regression> <juju-core:Triaged by menno.smits> <juju-gui:Triaged> <juju-quickstart:Triaged> <https://launchpad.net/bugs/1386143>
[23:00] <waigani> menn0: good to hear!
[23:03] <thumper> menn0:  good
[23:03] <thumper> thanks
[23:04] <waigani> menn0/thumper manual upgrade testing, deploy wordpress and mysql before upgrade?
[23:04] <waigani> anything else?
[23:05] <menn0> waigani: I have a script which also sets up some subordinate units
[23:05] <menn0> waigani: I think I've sent it to you before
[23:05] <waigani> menn0: yeah I just remembered that, looking for it now...
[23:05] <menn0> waigani: that's what I've been using
[23:20] <waigani> thumper/menn0: http://reviews.vapour.ws/r/269/
[23:28] <perrito666> katco: but tell me, does you editor clean and refreshes like mine? https://dl.dropboxusercontent.com/u/7254758/Photo%2027-10-14%2019%2017%2054.jpg
[23:29] <perrito666> and no, I did not go to te supermarket just for the sake of this discussion
[23:30] <waigani> perrito666: lol
[23:59] <rick_h_> menn0: <3 glad to hear about bugs already fixed