[00:13] <davecheney> great, now my ppc64 machines are offline
[01:09] <davecheney> thumper: http://paste.ubuntu.com/11087681/
[01:09] <davecheney> what is this test trying to test ?
[01:09] <davecheney> what should be listening on port 19034
[01:20] <natefinch> katco: you still around?
[01:27] <natefinch> davecheney: I'd like your insight on a review comment.  I have a struct that implements an interface from the same package. The struct has no exported methods other than the ones on the interface, and no exported data fields.  I have a constructor function for the struct... I had made the struct non-exported and had the constructor just return the interface. I was given a review comment that returning an interface is an an
[01:27] <natefinch> tipattern, and to just have it return the concrete value.  I had made it return the interface to keep the package's API smaller.  What are your thoughts?
[01:28] <davecheney> natefinch: link to review ?
[01:28] <natefinch> davecheney: http://reviews.vapour.ws/r/1619/
[01:29]  * davecheney looks
[01:29] <natefinch> I converted cmd/jujud/agent/AgentConf from a struct to an interface to make it testable... I don't necessarily like making an interface just to make something testable, but it seemed like the most reasonable solution.
[01:33] <natefinch> davecheney: the relevant changes are from revision 1 to revision 2
[01:34] <davecheney> kk
[01:41] <thumper> davecheney: looking now
[01:42] <menn0> wallyworld, thumper: update on the CI blocker. I have a working fix that I've manually tested in a variety of bootstrap, upgrade and HA scenarios.
[01:42] <menn0> wallyworld, thumper: tests need updating though and that'll take a while
[01:42] <thumper> menn0: ETA?
[01:45] <menn0> thumper: no idea. anywhere from 30 to 90 mins?
[01:45] <thumper> menn0: ack
[01:46]  * natefinch thinks he has a different definition than menn0 has of what "no idea" means.
[01:46] <menn0> natefinch: :)
[01:47] <natefinch> :)
[01:55] <mwhudson> somewhere between a femtosecond and a millenium
[01:55] <natefinch> now that's more like it.
[01:59] <davecheney> thumper: any idea what is going on there ?
[01:59] <thumper> davecheney: sorry, there wasn't quite enough context
[02:00] <thumper> davecheney: which test?
[02:00] <thumper> davecheney: the proxy detection was probably part of the auto-proxy detection
[02:00] <thumper> but the error I'm guessing would be the test trying to get to cdimages
[02:00] <thumper> no?
[02:02] <natefinch> davecheney: any thoughts on that review?  No big deal if you don't have time, just wanted anything you had off the top of your head.
[02:31] <davecheney> thumper: http://paste.ubuntu.com/11087681/
[02:31] <menn0> wallyworld, thumper: here's the blocker fix for 1.23. http://reviews.vapour.ws/r/1654/
[02:32] <davecheney> what is this test looking for on port 19034 ?
[02:32] <wallyworld> looking
[02:34] <thumper> davecheney: likely to be the random port number assigned to either mongo or the api server
[02:37] <davecheney> not random
[02:37] <davecheney> happens over and over again
[02:37] <thumper> hmm..
[02:37] <davecheney> all the way through the test
[02:37] <davecheney> all the way through the test suite
[02:37] <thumper> /home/tim/go/src/github.com/juju/juju/testing/environ.go:
[02:37] <thumper>    52: 		"state-port":                19034,
[02:38] <davecheney> so the state server didn't start up ?
[02:38]  * thumper shrugs...
[02:38] <thumper> maybe
[02:38] <davecheney> righto
[02:38] <davecheney> thanks
[02:38] <thumper> davecheney: or...
[02:38] <davecheney> hang on
[02:38] <thumper> davecheney: the test isn't a mgo suite so no mongo started, but the code is expecting it to be started?
[02:39] <davecheney> if that port isn't random
[02:39] <davecheney> and two tests using that suite run at the same time ...
[02:39] <davecheney> they'll fight over the port
[02:39] <thumper> ack
[02:39] <davecheney> how the f did this ever work ?
[02:39] <thumper> I didn't think we ran things in parallel
[02:39] <davecheney> go test github.com/juju/juju/...
[02:40] <thumper> don't we compile in parallel, but run in serial?
[02:40] <davecheney> ^ will run n cores of tests concurrently
[02:40] <thumper> not sure that is how gocheck works
[02:40] <davecheney> gocheck is a test
[02:40] <wallyworld> menn0: lgtm, a question about var name
[02:40] <davecheney> but each packge is it's own test runner
[02:40] <davecheney> and up to n cores of them will be running at any time
[02:41] <thumper> davecheney: I thought that for most of the tests, we used random port assignment
[02:41] <thumper> davecheney: and the fixed numbers were only used for static checks
[02:41] <davecheney> indeed
[02:41] <thumper> but perhaps I'm wrong
[02:42] <davecheney> maybe this suite is only used by one provider
[02:42] <davecheney> the local provider tests
[02:42] <thumper> I have certainly run tests in parallel before
[02:42] <thumper> in multiple terminals
[02:42] <menn0> wallyworld: yeah, I might call it needReplicasetInit and change the sense. good call.
[02:42] <davecheney> if you pass multiple packages to go test
[02:42] <davecheney> they will be run in parallel
[02:46] <thumper> ah fark
[02:46] <thumper> adding lxd ppa brought in golang 1.3.3
[02:47] <thumper> my build .a files are now all fubared
[02:47]  * thumper goes to delete stuff
[02:48] <thumper> ...
[02:48] <thumper> why is rm -r pkg not working?
[02:50]  * thumper is going crazy
[02:51] <thumper> davecheney: sanity check plz
[02:54] <thumper> damn it
[02:54]  * thumper reboots
[03:12] <bradm> anyone about?  I'm seeing weird errors from a juju bootstrap
[03:12] <bradm> WARNING juju.replicaset replicaset.go:87 Initiate: fetching replication status failed: cannot get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG)
[03:13] <davecheney> natefinch: i read that review twice
[03:13] <davecheney> are you testing AgentConf ? or the thing that consumes AgentConf ?
[03:14] <natefinch> davecheney: the thing that consumes it
[03:14] <natefinch> davecheney: which is why I wanted to make it an interface so that I could mock out its behavior
[03:14] <davecheney> in that case, I agree
[03:14] <natefinch> that returning the interface is ok?
[03:14] <davecheney> although dogmatic, it seems like a good rule of thumb that functions should return concrete types and consume interfaces
[03:14] <natefinch> oh, ok
[03:15] <natefinch> I'm cool with that
[03:15] <davecheney> and consuming an interface gives you heaps of flexibilty to control the _outputs_ of that interface
[03:15] <davecheney> so i think this change is good
[03:16] <davecheney> but i am reminded of this quote
[03:16] <davecheney> Don’t be trapped by dogma – which is living with the results of other people’s thinking.
[03:28] <bradm> ah, LP#1412621 and LP#1441913 seems similar-ish.
[03:38] <_thumper_> davecheney: got a minute? I have an x509 cert question, and I found your name in the source :)
[03:43]  * thumper stabs x509 and asn.1 in the face
[03:44]  * thumper goes to make coffee
[03:44]  * thumper guesses davecheney is having lunch
[03:53] <menn0> wallyworld: trying to merge this CI blocker but so far i've had good ol' "bad record mac" and EC2 failures
[03:53] <wallyworld> ffs
[03:53] <thumper> :(
[03:53] <menn0> bad record MAC happens so often
[03:54] <wallyworld> fixed in 2.6, we need to get off 2.4
[03:55]  * thumper nods
[03:57] <wallyworld> thumper: menn0: we need to get onto 2.8+ to get rid of the noisy logs, but W only has 2.6 so there's a packaging process that has to be followed
[03:57]  * thumper grunts
[03:57] <davecheney> thumper: i'm just off for lunch
[03:58] <davecheney> what line ?
[03:58] <davecheney> this was probabl somethig about the ASN.1 decoding
[03:58] <thumper> wallyworld: we need some packaging monkey at our beck and call
[03:58] <wallyworld> yes we do
[03:58] <thumper> davecheney: I have a cert pool, and I get the subjects out
[03:58] <thumper> davecheney: I was wanting some meaningful decoding for the test
[03:59] <thumper> davecheney: but asn1.Unmarshall with a pkix.Name fails
[03:59] <thumper> when I assumed it would work
[03:59] <thumper> given that it is what is passed in to the cert
[03:59] <davecheney> what's the error
[03:59] <thumper> asn1.StructuralError{Msg:"tags don't match (16 vs {class:0 tag:17 length:13 isCompound:true}) {optional:false explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0 set:false omitEmpty:false}  @2"}
[04:00] <davecheney> urgh, it's been 4 years since I left that comment turd
[04:00] <thumper> asn1 marshalling looks a bit ick
[04:00] <davecheney> yueah, there are lots of non obivious differences between a stirng
[04:00] <davecheney> a mature string (or seomthing)
[04:00] <thumper> looking at the raw bytes, it looks like it definitely has the Org and CN
[04:00] <davecheney> an empty string
[04:00] <davecheney> a raw string
[04:00] <davecheney> a set of raw bytes
[04:00] <davecheney> etc
[04:01] <davecheney> none of them map cleanly on to the string "tim"
[04:01] <davecheney> 16	SEQUENCE, SEQUENCE OF
[04:01] <davecheney> 17	SET, SET OF
[04:01] <davecheney> map vs [] i'd say
[04:01] <davecheney> whatever you're doing now
[04:01] <davecheney> do the opposite
[04:01] <thumper> davecheney: ugh... I'm using pxik.Name which uses []string for members
[04:02] <davecheney> nfi sorry
[04:02] <davecheney> it's been 4 years
[04:02] <davecheney> and I think I only fixed it enogh last time to decode some SNMP records
[04:03] <thumper> hmm... for the test, the CN would be fine
[04:03] <thumper> perhaps I should just define a struct that uses just that...
[04:05] <thumper> davecheney: don't stress, I'm just kinda gunna ignore it
[04:05] <thumper> and assume if the loading of the pool worked, a count of certs should be fine
[04:17] <menn0> wallyworld: while testing upgrades of HA envs (1.20 to 1.23 on EC2) I ran into a failure of the "migrate tools into environment storage" upgrade step
[04:17] <menn0> wallyworld: something about an invalid URL
[04:17] <wallyworld> oh joy
[04:17] <wallyworld> got an error message?
[04:18] <menn0> pgrade step "migrate tools into environment storage" failed: cannot find tools in provider storage: cannot read product data, invalid URL "https://s3-us-west-2.amazonaws.com/46494ee31f7046468790ca9b1ac37795/tools/streams/v1/com.ubuntu.juju:released:tools.json?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NTF6NNI5343APQ%2F20150512%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20150512T040240Z&X-Amz-Expires=604800&X-Amz-Signature=3
[04:18] <menn0> 131f68ef4919a36267d56a20490b4746208423247196fbac578dc637d370144&X-Amz-SignedHeaders=host" not found
[04:22] <wallyworld> menn0: i *think* we have now switched to V4 auth for S3, perhaps there's an issue in that region or something
[04:23] <menn0> wallyworld: file a bug?
[04:23] <wallyworld> hmmm, i think i truncated to url, fixing that gave a sig mismatch which i think might be expected if i just cut and paste
[04:24] <wallyworld> but it could also be a real issue
[04:24] <wallyworld> did it happen all the time?
[04:24] <wallyworld> or just the once?
[04:25] <menn0> i've only tried this particular upgrade (1.20 to 1.23) once
[04:25] <wallyworld> aws does not always work all the time
[04:25] <wallyworld> CI needs to often retry
[04:26] <menn0> wallyworld: but there were a bunch of attempts to hit that URL and they all failed
[04:26] <wallyworld> sometimes though there are cloud outages
[04:26] <wallyworld> i can't see offhand where any juju bug would be
[04:26] <menn0> wallyworld: ok it could be that
[04:26] <wallyworld> the url looks correct
[04:27] <menn0> wallyworld: the upgrade retried 5 times and has now given up
[04:28] <wallyworld> not sure what to do - juju is asking S3 for a file and S3 says f*ck off
[04:30] <menn0> wallyworld: so we hit that URL something like 50 times over 10 minutes and it didn't work
[04:32] <wallyworld> hmmmm, NFi offhand
[04:35] <wallyworld> menn0: if i try the url without the auth stuff i get a weird redirect from aws. not sure if that's relevant but i've not seen that before
[04:36] <menn0> wallyworld: here's the full correct URL
[04:36] <menn0> https://s3-us-west-2.amazonaws.com/46494ee31f7046468790ca9b1ac37795/tools/streams/v1/com.ubuntu.juju:released:tools.json?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NTF6NNI5343APQ%2F20150512%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20150512T043517Z&X-Amz-Expires=604800&X-Amz-Signature=3754e068be3d7588022c5ed7d485fff4f3c2df1fd917ed12c29fa7bd9a430a12&X-Amz-SignedHeaders=host
[04:36] <menn0> wallyworld: the error is about signing: The request signature we calculated does not match the signature you provided. Check your key and signing method.
[04:36] <wallyworld> yes, but i've seen that will url pastes before
[04:37] <menn0> wallyworld: ok right
[04:37] <wallyworld> it may be relevant here but i can't be sure off hand
[04:37] <menn0> wallyworld: i've just searched the logs and I see the same error there
[04:37] <wallyworld> i wonder if you specified an explicit region would it work
[04:37] <wallyworld> hmmm, maybe that region is having issues with V4
[04:41] <thumper> menn0: it merged \o/
[04:43] <menn0> thumper: thank $deity for that
[04:43] <thumper> menn0: I think $deity should be Odin
[04:43] <thumper> was always partial to Norse
[04:43] <menn0> thumper: that fits you so well
[04:46] <menn0> getting the 1.24 and master merges ready now
[04:49] <thumper> menn0: although perhaps it should be Loki as he was god of mischief, and that fits the intermittent nature better I think
[04:50] <menn0> thumper:  ha :)
[04:50] <mup> Bug #1454043 was opened: Machine.SetAddresses should not generate transactions for noop changes <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1454043>
[04:57] <anastasiamac_> thumper: if we r voting, i'd say Odin
[04:58] <anastasiamac_> thumper: Odin's "special" warriors were berserkers
[05:23] <thumper> davecheney: remember this 10 minute go test timeout thing...
[05:23] <thumper> davecheney: are you sure that `go test -test.timeout=1200s ` doesn't increase that to 20 minutes?
[05:42] <menn0> wallyworld, thumper: the fix for the CI blocker is now merged into 1.23, 1.24 and master
[05:42] <wallyworld> huzah
[05:44] <menn0> wallyworld: CI hasn't run the functional-ha-backup-restore job with the new code yet
[05:44] <wallyworld> yeah, have to wait to unblock
[05:45] <menn0> wallyworld: i'll add a note to the ticket to make it clear when it can be unblocked
[05:46] <wallyworld> sounds good, ty
[05:48] <thumper> menn0: hoo ray
[05:52] <jam> axw: ping
[05:54] <mup> Bug #1454059 was opened: SetTools fills up transaction log <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1454059>
[06:30] <jam> TheMue: ping
[07:53] <TheMue> morning
[07:53] <TheMue> jam: pong
[07:53] <jam> hi TheMue just looking for someone from the team. We found a bug in the instance poller and were wondering who did the Addresses consolidation.
[07:54] <jam> dimiter might be more knowledgeable if he's around today
[07:54] <TheMue> jam: yeah, but he's out until thursday
[07:55] <TheMue> jam: Address poller? hmm, could you tell me more about it?
[07:58] <jam> TheMue: basic bug is https://bugs.launchpad.net/juju-core/+bug/1454043
[07:58] <mup> Bug #1454043: Machine.SetAddresses should not generate transactions for noop changes <stakeholder> <juju-core:Triaged> <https://launchpad.net/bugs/1454043>
[07:58] <jam> TheMue: essentially the InstancePoller is doing a check
[07:58] <jam> If machine.Addresses() != cloud.Addresses() { machine.SetAddresses(cloud.Addresses))
[07:58] <jam> TheMue: however, machine.Addresses() merges "machine" addresses with "cloud" addresses
[07:59] <jam> thus once you have any machine addresses, the comparison *always* fails.
[07:59] <TheMue> iiirks
[07:59] <jam> TheMue: essentially SetAddress() && Addresses() gives you a different value
[07:59] <jam> which isn't a great API internally :)
[08:00] <TheMue> hmmm, will be hard to disagree ;)
[08:01] <voidspace> morning all
[08:02] <TheMue> voidspace: heya
[08:02]  * TheMue is taking a deeper look
[08:04] <mattyw> voidspace, morning
[08:05] <mattyw> voidspace, you did work on the networking stuff right?
[08:08] <voidspace> TheMue: o/
[08:08] <voidspace> mattyw: uhm... yes...
[08:08] <mattyw> voidspace, I've not really started looking at it - so be prepared for a totally daft question....
[08:09] <voidspace> mattyw: back in a minute, ask the question and I'll answer
[08:09] <mattyw> voidspace, is it possible to move a unit from one space to another?
[08:09] <voidspace> mattyw: oh
[08:09] <voidspace> mattyw: units aren't "in spaces"
[08:09] <voidspace> mattyw: units are on machines, machines are on networks / have interfaces - and those networks / interfaces have subnets that are in spaces
[08:10] <voidspace> mattyw: you specify the space constraints at *deploy time* (so we can pick a machine0
[08:10] <voidspace> mattyw: and then a unit endpoint can get an address on any subnet available to the machine
[08:10] <voidspace> mattyw: that is how it *will* work  I believe
[08:10] <voidspace> mattyw: not implemented yet
[08:11] <mattyw> voidspace, ok understood - so I can't use networking to cause partitions in a running service (for testing purposes)
[08:11] <voidspace> mattyw: but it's machines that are "in spaces", and we pick a machine for the unit based on the spaces you specify (for endpoint bindings) at deploy time
[08:11] <voidspace> mattyw: not dynamically no
[08:12] <mattyw> voidspace, understood
[08:15] <TheMue> mattyw: as I understand it you can install a charm with a different name in a different space, but not different units of one service
[08:15] <mattyw> TheMue, that makes a lot of sense
[08:32] <TheMue> jam: I like your solution, always had my troubles with the mixing of both address sets.
[08:45] <mup> Bug #1454143 was opened: Deployer failure upgrading to proposed 1.23.3 from 1.23.2 client <landscape> <juju-core:New> <juju-deployer:New> <https://launchpad.net/bugs/1454143>
[09:02] <dooferlad> voidspace: hangout
[09:02] <voidspace> dooferlad: omw
[11:12] <voidspace> TheMue: dooferlad: oh, forgot to mention in standup - but last night I spent a bit of time on my HP Microserver
[11:12] <TheMue> voidspace: and now, up and running?
[11:12] <voidspace> TheMue: dooferlad: got the ram and HD fitted. Unfortunately failed to get an OS installed as the flash drive I made from 15.04 was corrupt
[11:12] <voidspace> TheMue: dooferlad: I did find a python interface to the OneView HP RESTful API
[11:12] <voidspace> * ashipika has quit (Quit: Leaving.)
[11:12] <voidspace> oops...
[11:13] <TheMue> hehe
[11:13] <voidspace> https://github.com/HewlettPackard/python-hpOneView
[11:13] <voidspace> Not clear if it supports the functionality we need - but a good place to start.
[11:13] <TheMue> voidspace: could you point me with an URL to the HW?
[11:14] <voidspace> TheMue: the doc by dooferlad has a link to the device on ebuyer (UK site of course)
[11:14] <voidspace> https://docs.google.com/document/d/1jjw80acrwVMITCiAKI3UJ5FoZFuN9kuBcG0mtHRmMIA/edit
[11:14] <voidspace> it's the G1610T HP Proliant Microserver
[11:14] <TheMue> voidspace: thx
[11:14] <ashipika> ?
[11:16] <voidspace> ashipika: heh
[11:16] <voidspace> ashipika: I managed to get the wrong thing in my copy-paste buffer...
[11:16] <voidspace> ashipika: meant to post a link instead... sorry
[11:17] <ashipika> voidspace: np :)
[11:20] <dooferlad> voidspace, TheMue: The API spec is in that document. We only need a single endpoint: {"Action": "Reset", "ResetType": <foo>} where <foo> can be "On", "ForceOff". That is it.
[11:21] <dooferlad> As long as you can find the IP address that the management interface is listening on we are fine.
[11:22] <dooferlad> voidspace: you don't need to install an OS, you just need to get in the BIOS to set up network booting.
[11:35] <voidspace> dooferlad: sure, but I want to make sure it works and have something to play with :-)
[11:35] <voidspace> dooferlad: pretty sure it network boots by default
[11:35] <voidspace> dooferlad: it's definitely looking for pxe
[11:36] <wallyworld> TheMue: hey, did you see that 1.24 bug i assigned you? it appeared as if you were the last one to touch that code :-) looks like a simple fix. are you able to fix it?
[11:37] <TheMue> wallyworld: not yet seen, one moment
[11:37] <perrito666> morning
[11:37] <TheMue> wallyworld: #1437266?
[11:38] <TheMue> perrito666: heya
[11:38] <wallyworld> perrito666: morning, i haven't landed the 1.24 merge into master which will bring in the charm.v5 stuff you need because 1.24 was blocked; should be unblocked soon
[11:38] <perrito666> np
[11:43] <wallyworld> TheMue: yeah, that's the one
[11:44] <TheMue> wallyworld: ok, will do it
[11:44] <TheMue> ... now
[11:44] <wallyworld> \o/ ty
[11:52] <voidspace> wallyworld: as you're here, quick question
[11:53] <voidspace> wallyworld: when setting the instance ID on a newly provisioned machine I need to set the instance id on a bunch (potentially) of IP addresses as well
[11:53] <voidspace> wallyworld: state already has a method to fetch all the IP addresses associated with the machine
[11:53] <voidspace> wallyworld: after the successful transaction, ok to just call addr.SetInstanceId on them all
[11:54] <voidspace> wallyworld: or is it significantly preferred that I build this in as part of the transaction (by extending []txn.Op for setting the instance id on the instanceData record)
[11:54] <voidspace> ?
[11:54] <wallyworld> voidspace: give me a few minutes to check, i can't recall the code 100%
[11:55] <voidspace> wallyworld: well, it's mostly new code
[11:55] <voidspace> wallyworld: specifically I'm looking at state.Machine.SetProvisioned
[11:56] <voidspace> setting the instance id is a method call on machine, so it seems having a method to set the instance id on the addresses fits
[11:56] <voidspace> but it means a few extra DB calls instead of building it into a single transaction
[11:57] <wallyworld> voidspace: if the method is on state and hence talking to mongo directly, a few extra calls isn't so bad in general
[11:57] <wallyworld> we do that elsewhere
[11:57] <voidspace> wallyworld: well, it's on state.IPAddress which has a direct connection to state
[11:57] <voidspace> wallyworld: cool, thanks
[11:57] <voidspace> it's directly working with state entities, no extra layers
[11:58] <wallyworld> if depends if we expect all the data to be written at once for integrity
[11:58] <voidspace> hmmm... although these are cross collection anyway
[11:58] <voidspace> so the transaction doesn't guarantee that I don't think
[11:59] <voidspace> instanceDataC and ipaddressesC
[11:59] <voidspace> IIRC
[11:59] <wallyworld> yeah, cross collection txns i think can be an issue
[12:00] <wallyworld> is it an issue if the instance ids are not all set at once?
[12:01] <voidspace> wallyworld: nope. They're only used on machine destruction.
[12:02] <voidspace> wallyworld: so unless you can set the instance id on the machine and then destroy the machine (EnsureDead *and* Remove) before they're set
[12:02] <voidspace> which I'm pretty sure you can't...
[12:02] <wallyworld> voidspace: i think then it sounds ok to set individually via repeated direct calls to mgo from state
[12:02] <wallyworld> seing the final code would help
[12:04] <voidspace> wallyworld: cool, thanks
[12:05] <voidspace> wallyworld: I'll link you to the wip code to get a clearer idea.
[12:05] <wallyworld> sorry i was only vague
[12:06] <voidspace> hmmm... problem as always is what to do with the error
[12:06] <voidspace> if setting the id on an address fails *after* the transaction succeeds returning an error will make it look like setting the instance id failed
[12:07] <voidspace> maybe better to do it in the transaction so we get a single failure
[12:07] <voidspace> slightly more fiddly code which I was hoping to avoid
[12:12] <perrito666> davecheney: are you still around?
[12:13] <wallyworld> voidspace: another option is to rollback using a defer
[12:21] <voidspace> wallyworld: right, thanks
[12:39] <wallyworld> rogpeppe1: hiya, i have a question for you if  you are free at some point
[12:39] <rogpeppe1> wallyworld: go ahead.
[12:40] <rogpeppe1> wallyworld: i am fairly busy but will time-slice :)
[12:41] <wallyworld> rogpeppe1: so, there's a bug. deployer calls AllWatcher.Next(). this errors with an error that appears to come from an update() call at some point on one of the backing objects. 1. does this sound plausible that an error generated during an update() callback on megawatcher would appear when Next() is called?
[12:41] <wallyworld> 2. the error seems "impossible"
[12:42] <wallyworld> the error is due to a missing status record for a unit
[12:42] <wallyworld> but when units are created, they get a status record as part of the txn ops
[12:42] <rogpeppe1> wallyworld: perhaps Next is returning the error from an underlying tomb?
[12:43] <wallyworld> could be i guess. i didn't realise the update() on the mulitwatcher set the tomb error
[12:43] <rogpeppe1> wallyworld: if that tomb is killed with an error, all watchers will die with that error.
[12:43] <rogpeppe1> wallyworld: i don't know either
[12:43] <rogpeppe1> wallyworld: it's a random guess without looking at the code
[12:43] <rogpeppe1> wallyworld: (which i haven't looked at in ages and ages)
[12:44] <wallyworld> ok, , i'll keep digging, ty
[12:44] <rogpeppe1> wallyworld: np, good luck!
[12:44] <wallyworld> i'll need it :-)
[13:07] <wallyworld> sinzui: can we unblock 1.24? bug 1453805 seem sot have fixed the HA functional tests in CI
[13:09] <sinzui> wallyworld, Not until i understand all the failures.
[13:10] <wallyworld> sinzui: you talking about the maas 1.7 failure?
[13:11] <sinzui> wallyworld, I am talking about all maas failures and kvm failures
[13:11] <sinzui> no maas passed.
[13:11] <wallyworld> oh ok, i just saw the onw maas 1.7 one
[13:12] <sinzui> wallyworld, CI will unblock when the branch was blessed, so CI thinks wont unblock until QA proves Juju wasn't at fault for any of the failures
[13:13] <wallyworld> ok, i was hoping that as soon as the recorded blocking bug was seen to be fixed we could unblock
[13:14] <sinzui> wallyworld, yes, and CI recognises that as a blessed branch. CI doesn't care about a specific test. It cares about having a releasable branch
[13:16] <wallyworld> ok, so that means that even though the bug causing the original blockage is fixed, we still need to wait in case there are new bugs oto be raised
[13:22] <sinzui> katco, We need someone to look into bug 1454143. We may not be able to the finale release of 1.23.3
[14:04] <wwitzel3> katco: sorry, omw, was chatting with cory_fu and lost track of time
[14:04] <katco> dpb1: hey can you provide any guidance on bug 1454143
[14:05] <dpb1> #1454143
[14:05] <cory_fu> Don't go blaming me.  ;)
[14:05]  * dpb1 kicks mup
[14:05] <katco> <fake mup>: hi! here's bug https://bugs.launchpad.net/juju-core/+bug/1454143
[14:05]  * ericsnow worries that mup might not be well
[14:05] <dpb1> LOL
[14:06]  * perrito666 kicks his computer in anger because nothing works well today
[14:06] <dpb1> niemeyer has been pinged, he's probably looking at it
[14:15] <jcastro> mgz, still no luck on dreamcompute, I'm stuck, any help someone on your team could provide would be most welcome!
[14:18] <mgz> jcastro: okay, I'll try to have a go myself today
[14:18] <mgz> I saw you hadn't got a response to your mail
[14:18] <jcastro> heh
[14:19] <jcastro> Will we be testing on dreamcompute in the future for releases?
[14:19] <mgz> we haven't got a plan to at the moment, it seems reasonable though
[15:29] <sinzui> ericsnow, wallyworld 1.23 and 1.24. bug 1392407 was the involved in a system failure caused by a held lock
[15:30] <sinzui> ericsnow, wallyworld CI blessed and opened 1.24. I opened 1.23 because I think I accounted for every failure as a cloud or substrate issue
[15:30] <ericsnow> sinzui: cool, thanks!
[15:40] <lazyPower> o/  - Juju's amazon provider does not understand how to leverage the VPC correct? Thats still something we do manually, and then use the manual provider to consume?
[15:47] <alexisb> lazyPower, that is correct VPC support is still under development
[15:47] <lazyPower> alexisb: thanks, thast what I thought :)
[15:47] <lazyPower> just making sure i hadn't missed an update
[16:24] <natefinch> ericsnow: you around?
[16:24] <ericsnow> natefinch: otp
[16:24] <ericsnow> natefinch: what's up?
[16:27] <mgz> ocr: can I get a stamp on backport http://reviews.vapour.ws/r/1660/
[17:26] <lazyPower> I'm running into a weird issue bootstrapping on AWS in a VPC w/ 1.24 and 1.23 - i've confirmed the issue affects both - https://bugs.launchpad.net/juju-core/+bug/1412621
[17:26] <mup> Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap <bootstrap> <maas-provider> <mongodb> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1412621>
[17:26] <lazyPower> i attached here as it was the same issue - but the bug title seems to scope it to maas.
[17:29] <lazyPower> and I think i see whats happening, its inserted a host that is the NAT'd address as the replset configuration, and not the local address of the unit
[17:40] <lazyPower> updated the bug w/ the workaround/steps to fix the bootstrap issue - now the system appears stuck when issuing "juju status"
[17:41] <mup> Bug #1454359 was opened: Unexpected api shutdown followed by panic <juju-core:New> <https://launchpad.net/bugs/1454359>
[17:42] <mgz> is there anyone around to do reviews atm?
[18:36] <katco> cherylj: perrito666: wwitzel3: have time for a hangout?
[18:37] <cherylj> katco: sure
[18:37] <katco> cherylj: perrito666: wwitzel3: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
[18:37] <katco> getting some tea brt
[18:38] <mup> Bug #1453805 changed: Juju takes more than 20 minutes to enable voting <blocker> <ci> <ensure-availability> <intermittent-failure> <regression> <juju-core:Fix
[18:38] <mup> Released by menno.smits> <juju-core 1.23:Fix Released by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1453805>
[18:40] <katco> cherylj: i'm in there now. is perrito666 out today?
[18:41] <cherylj> katco: can't seem to join.  keeps timing out :(
[18:41] <katco> cherylj: weird...
[18:50] <mup> Bug #1453805 was opened: Juju takes more than 20 minutes to enable voting <blocker> <ci> <ensure-availability> <intermittent-failure> <regression> <juju-core:Fix
[18:50] <mup> Released by menno.smits> <juju-core 1.23:Fix Released by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1453805>
[18:53] <mup> Bug #1453805 changed: Juju takes more than 20 minutes to enable voting <blocker> <ci> <ensure-availability> <intermittent-failure> <regression> <juju-core:Fix
[18:53] <mup> Released by menno.smits> <juju-core 1.23:Fix Released by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1453805>
[18:53] <alexisb> katco, can you have cmars join that
[18:53] <alexisb> katco, he mgiht have some volunteers available on his team as well
[18:54] <katco> alexisb: sure, cmars you're welcome to join
[18:56] <sinzui> mgz, katco can either of you take a moment to review http://reviews.vapour.ws/r/1663/
[18:57] <mgz> sinzui: shipit
[18:57] <sinzui> thank you mgz
[19:26] <mgz> perrito666: I have three backport branches up, 1660, 1664, 1665, when you have a minute can you eyeball and stamp them?
[19:28] <katco> mgz: i haven't heard anything from him since this morning
[19:29] <katco> mgz: he mentioned nothing working well, so i wonder if his computer is on the blink
[19:29] <mgz> katco: hm, do I have to bug you then? have seen a dearth of other reviewers on this afternoon
[19:29] <katco> mgz: if i can find a spare moment... how big are the diffs?
[19:30] <mgz> small, nice sane ones (hardest bit is one dep change)
[19:48] <perrito666> Hey quick update I am working offline until tonight when I get the time to fix whatever the last update of vivid broke on my laptops network
[19:48] <perrito666> If you need me please reach me through email as the constant up and down of irc drives me crazy
[19:49] <mgz> perrito666: aha!
[19:49] <mgz> perrito666: how offline?
[19:49] <mgz> too offline to do reviews?
[19:49] <perrito666> Meh no matter how many times I type it, this phone keeps trying to correct irc as Orc
[19:49] <perrito666> Mgz nope shoot
[19:50] <mgz> perrito666: I have three backport bug fixes up, 1660, 1664, 1665
[19:50] <mgz> they should all be straightforward to stamp
[20:55] <perrito666> mgz: are you sure 1665 doesn' t break backup restore CI tests?
[21:12] <wallyworld> perrito666: i also need you to look at http://reviews.vapour.ws/r/1658/ if you have time
[21:13] <perrito666> ffs man do you ever sleep?
[21:17] <wallyworld> sometimes
[21:25] <katco> wallyworld: thumper: sorry i reversed the meeting invites
[21:25] <wallyworld> :-)
[21:27] <katco> isn't menn0 in NZ?
[21:27] <katco> how was he talking to me this morning?
[21:27] <menn0> katco: yes, I am in NZ
[21:28] <perrito666> katco: nobody in this team sleeps anymore
[21:28] <katco> menn0: what time was it for you when we talked yesterday (my this morning)?
[21:30] <wallyworld> katco: fyi i can't make the very next sky meeting as i have a conflict with another meeting
[21:30] <katco> wallyworld: no worries, but do need at least 1 lead to hand off to
[21:31]  * wallyworld looks at thumper 
[21:31] <davecheney>  sinzui is arm64 tested as part of ci ?
[21:31] <thumper> standup
[21:31] <davecheney> sinzui: or to say it another way, some tests are being run on ppc64, are those also being run on arm64 ?
[21:31]  * thumper has calls for the next 1.5 hours
[21:31] <thumper> right now
[21:32] <perrito666> wallyworld: shipit
[21:33] <wallyworld> perrito666: tyvm :-)
[21:33] <katco> menn0: sorry for the meeting spam... my brain was playing tricks on me
[21:33] <menn0> katco: did we actually talk during your morning?
[21:33] <sinzui> davecheney, not in many months. and even then. not really. The machine we were given never had to power to run unit tests, are do a local deployment.
[21:33] <menn0> katco: I thought it was your evening
[21:33] <katco> menn0: i don't think so haha
[21:33] <katco> menn0: i think i was thinking of your yesterday morning
[21:34] <sinzui> davecheney, the slave is up and listed as dead by jenkins.
[21:34] <davecheney> sinzui: ah
[21:34] <menn0> katco: that make sense
[21:34] <davecheney> thanks for confirming
[21:57] <thumper> cmars: I'm going to have to skip out on our call again
[21:57] <thumper> cmars: have yet another clash
[21:57] <cmars> thumper, ok, i see how it is
[21:58] <cmars> thumper, :) np. we should catch up at some point though
[21:58] <thumper> cmars: yeah, sorry, but katco is more important
[21:58] <thumper> cmars: definitely
[21:58] <cmars> thumper, sky?
[21:58] <thumper> cmars: blue today, slight cloud
[21:58] <thumper> thanks for asking
[21:58] <cmars> thumper, rainy here all day
[21:59]  * thumper smirks to himself
[21:59] <thumper> oh man, so much rain yesterday
[21:59] <thumper> at least today I should get outside at some stage
[21:59] <thumper> get that vitamin D
[22:00] <katco> cmars: https://plus.google.com/hangouts/_/canonical.com/sky-handoff?authuser=1
[22:53] <wallyworld> ericsnow: ffs
[22:53] <wallyworld> provider/vsphere/ova_import_manager.go:166: arg resp.StatusCode for printf verb %s of wrong type: int
[22:53] <wallyworld> provider/vsphere/ova_import_manager.go:251: missing verb at end of format string in Debugf call
[22:53] <ericsnow> wallyworld: gah
[22:53] <wallyworld> go vet is sad
[22:53] <ericsnow> wallyworld: will fix
[22:53] <wallyworld> ty :-)
[22:53] <ericsnow> wallyworld: I could swear I fixed those (twice)
[22:54] <wallyworld> we've all been there :-)
[22:55] <ericsnow> wallyworld: hmm, I'm not seeing any problems with 1.24, nor with the branch that's merging right now
[22:56] <ericsnow> wallyworld: (rather, just merged :) )
[22:58] <voidspace> wwitzel3: ping
[23:46] <katco> ericsnow: make sure you're taking time off from work please