[01:03] <davecheney> lucky(~/charms/raring/gccgo) % juju destroy-service gccgo2
[01:03] <davecheney> juju delucky(~/charms/raring/gccgo) % juju destroy-machine 2
[01:03] <davecheney> lucky(~/charms/raring/gccgo) % juju destroy-service gccgo2
[01:03] <davecheney> juju delucky(~/charms/raring/gccgo) % juju destroy-machine 2
[01:03] <davecheney> juju sttauserror: no machines were destroyed: machine 2 has unit "gccgo2/0" assigned
[01:03] <davecheney> blarg, thanks asynchrony
[01:27] <davecheney> phase 1. complicated problem
[01:27] <davecheney> phase 2 ....
[01:27] <davecheney> phase 3. gnome shell!
[01:45] <davecheney> this week in silly juju tricks http://dave.cheney.net/2013/09/09/using-juju-to-build-gccgo
[02:11] <davecheney> has anyone tried compiling juju with gccgo ?
[05:30] <jam> morning all
[05:31] <axw> morning jam
[05:58] <jam> hey wallyworld_ I'm in whenever you're around
[05:58] <wallyworld_> ok
[06:23] <davecheney> axw: i have an urgent request
[06:23] <davecheney> 2013-09-09 06:05:37 DEBUG juju.provisioner provisioner_task.go:300 Stopping instances: [0xc2002a1be0 0xc2002a1c10 0xc2002a1c60 0xc2002a1c70 0xc2002a1c80 0xc2002a1cc0 0xc2002a1cd0 0xc2002a1b80 0xc2002a1ba0 0xc2002a1c20 0xc2002a1c50 0xc2002a1c90 0xc2002a1ca0 0xc2002a1cb0 0xc2002a1b60 0xc2002a1b70 0xc2002a1b90 0xc2002a1bb0 0xc2002a1bd0 0xc2002a1c30 0xc2002a1bc0 0xc2002a1bf0 0xc2002a1c40]
[06:24] <davecheney> 2013-09-09 06:05:38 DEBUG juju.provider.maas environ.go:303 error releasing instance &{0xc20030e870 0xc2002beb40}
[06:24] <davecheney> 2013-09-09 06:05:38 DEBUG juju.provider.maas environ.go:303 error releasing instance &{0xc20030e8a0 0xc2002beb40}
[06:24] <davecheney> 2013-09-09 06:05:38 DEBUG juju.provider.maas environ.go:303 error releasing instance &{0xc20030e960 0xc2002beb40}
[06:24] <davecheney> ^ can you pease figure out what type this is in gomaasapi and add a String() method too it
[06:24] <axw> ok
[06:24] <davecheney> axw: thanks
[06:25] <davecheney> sorry, that i haven't raised a bug
[06:25] <davecheney> this has been an all day job to get to this point
[06:25] <davecheney> axw: if you raise a bug for it
[06:25] <davecheney> please mark it critical for 1.14.0
[06:26] <wallyworld_> jam: you froze?
[06:34] <axw> davecheney: https://bugs.launchpad.net/juju-core/+bug/1222664
[06:34] <_mup_> Bug #1222664: maas provider's instance is not a Stringer <juju-core:New> <https://launchpad.net/bugs/1222664>
[06:34] <bigjools> should call them Peters
[06:36] <davecheney> axw: ta
[06:36] <davecheney> that'll make life easier
[06:49] <davecheney> axw: thanks for the quick turnaround, just checking with bigjools to make sure id() is good enough
[06:49] <axw> davecheney: ok
[06:49] <bigjools> it is
[06:50] <davecheney> sweet
[06:51] <bigjools> ID and hostname is better.  typing this in two channels. ..
[06:51] <axw> yeah ok, that would be useful I guess
[06:51] <axw> I'll add it in
[06:52] <davecheney> axw: thanks
[06:52] <davecheney> i know it's double underpants
[06:52] <davecheney> but it cost 2 man days to figure this out
[06:53] <davecheney> actually more
[06:53] <davecheney> at least 4 people were involved
[06:56] <axw> bigjools: is it possible for an instance's MAAS object to not have a hostname? I assume not...
[06:56] <axw> (I need to justify a panic)
[06:57] <bigjools> axw: impossible
[06:57] <bigjools> (famous last words)
[06:57] <axw> :)
[06:57] <axw> thanks
[06:57] <davecheney> i give that a week before we revert that
[06:58] <davecheney> https://bugs.launchpad.net/gomaasapi/+bug/1222671
[06:58] <axw> davecheney: alternatively I can encode the error in place of the hostname?
[06:58] <_mup_> Bug #1222671: maas provider must only attempt to stop machines it owns <Go MAAS API Library:New> <https://launchpad.net/bugs/1222671>
[06:58] <davecheney> axw: that would be better, just put UNKNOWN or something
[06:58] <davecheney> i know that in ec2 you can have an instance without a hostname
[06:58] <davecheney> for short periods
[07:26] <rogpeppe1> mornin' all!
[07:31] <axw> hey rogpeppe1
[07:31] <rogpeppe1> axw: hiya
[08:43] <dimitern> rogpeppe1: hey, welcome back!
[08:43] <rogpeppe1> dimitern: yo!
[08:43] <dimitern> rogpeppe1: good holiday?
[08:43] <rogpeppe1> dimitern: great thanks; just about recovered now :-)
[08:43] <dimitern> rogpeppe1: good :)
[08:44] <dimitern> rogpeppe1: we have a complete uniter api - finished off the client-side last week
[08:44] <rogpeppe1> dimitern: fantastic!
[08:44] <dimitern> rogpeppe1: now on to the actual uniter migration from state to the api
[08:46] <rogpeppe1> dimitern: BTW, interesting tidbit from my hols - my cousin was staying with us and her partner (also there) is product manager for a significant sized startup; i found out they were doing the whole thing in Go.
[08:46] <rogpeppe1> dimitern: which was a nice surprise
[08:47] <dimitern> rogpeppe1: nice! what's the product?
[08:47] <rogpeppe1> dimitern: i think it might be https://hailocab.com/
[08:47] <dimitern> rogpeppe1: even the iphone apps? :)
[08:48] <rogpeppe1> dimitern: naah, just the back end
[08:48] <rogpeppe1> dimitern: my cousin herself is in charge of migrating the BBC to use cloud services for scaling; i tried to get in a word for juju...
[08:49] <dimitern> rogpeppe1: sweet! did she seemed interested?
[08:50] <rogpeppe1> dimitern: i'm not sure it really fits their goals
[08:50] <dimitern> rogpeppe1: how so?
[08:51] <rogpeppe1> dimitern: i don't think we're mature enough for them to consider yet
[08:52] <dimitern> rogpeppe1: ah, well we'll get there
[09:25] <dimitern> rogpeppe1: a trivial review? https://codereview.appspot.com/13292044/
[09:25] <rogpeppe1> dimitern: looking
[09:26] <rogpeppe1> dimitern: LGTM
[09:26] <dimitern> rogpeppe1: cheers
[09:35] <dimitern> fwereade: ping
[09:51] <dimitern> rogpeppe1: how do you feel about having an api call taking a relation id and returning a uniter.Relation proxy? we already migrated to using relation tags as "relation-svc1.rel1#svc2.rel2", but relations are special in that we cannot convert between id and tag without a state call
[09:52] <dimitern> rogpeppe1: now we have a Relation API call taking a tag and returning the proxy
[09:52] <rogpeppe1> dimitern: what would the API call actually do?
[09:53] <dimitern> rogpeppe1: it will take an int relation id and return the same as Relation() currently returns
[09:53] <dimitern> rogpeppe1: params.RelationResults
[09:53] <rogpeppe1> dimitern: oh of course. that seems... reasonable at first glance
[09:54] <rogpeppe1> dimitern: what needs to do that operation?
[09:54] <dimitern> rogpeppe1: what bugs me is we decided to always use tags over the wire
[09:54] <rogpeppe1> dimitern: (the mapping from relation id to relation tag, that is)
[09:54] <dimitern> rogpeppe1: but not doing that and instead refactoring a big chunk of the uniter to always use tags seems costlier
[09:54] <dimitern> rogpeppe1: uniter:401 and uniter
[09:54] <dimitern> :446
[09:55] <dimitern> rogpeppe1: it's when it loads or updates the local relations disk cache
[09:55] <fwereade> dimitern, pong
[09:55] <dimitern> fwereade: hey
[09:55] <fwereade> dimitern, hey dude
[09:55] <dimitern> fwereade: take a look a bit up^^
[09:56] <rogpeppe1> dimitern: presumably the local disk cache could record the relation tag too... but then it would be backwardly incompatible i guess
[09:56] <fwereade> dimitern, I'm with rogpeppe1
[09:56] <fwereade> dimitern, cache it locally
[09:56] <dimitern> fwereade: where?
[09:56] <fwereade> dimitern, it's unchanging, and I think constructed from info that's guaranteed to be available
[09:57] <fwereade> dimitern, inside the relation state dir
[09:57] <rogpeppe1> fwereade: what about upgrading?
[09:57] <rogpeppe1> fwereade: good morning, BTW
[09:57] <fwereade> rogpeppe1, heya :)
[09:58] <dimitern> fwereade: so add RelationTag as a field to hook.Info and StateDir ?
[09:58] <dimitern> fwereade: and yeah - what about upgrading?
[09:59] <fwereade> dimitern, I hadn't been originally thinking on hook.Info
[09:59] <fwereade> dimitern, I had been imagining that the conversion to id would take place before then
[09:59] <dimitern> fwereade: ah
[09:59] <fwereade> dimitern, doesn't a hook queue get constructed with a state dir? or is it just the idealized contents of one?
[09:59] <dimitern> fwereade: well, if we have a RelationById() API call it'll solve all this
[10:00] <fwereade> dimitern, yeah, guess so, but it feels kinda ludicrous
[10:00] <fwereade> dimitern, that said go with it
[10:00] <dimitern> fwereade: it is kinda, but the relations are a special case
[10:00] <dimitern> fwereade: ok then, will do
[10:01] <fwereade> dimitern, yeah, they're somewhat unhelpfully shaped by the relationy-bits architecture in uniter I'm afraid
[10:01] <fwereade> dimitern, we shall iterate as we can
[10:01] <fwereade> sorry bbiab contract thingy
[10:40] <dimitern> rogpeppe1: and there it is https://codereview.appspot.com/13238046/
[10:40] <rogpeppe1> dimitern: looking
[10:40] <dimitern> rogpeppe1: btw we changed the standup time to be in 5m from now, 45m earlier
[10:40] <rogpeppe1> dimitern: ah, good to know, thanks
[10:45] <dimitern> rogpeppe1: I have a feeling you won't like the fact getting relations involves 2 server calls, but I'm happy to discuss that and possibly do a follow up that doesn't do that
[10:45] <jam> standup time everyone: https://plus.google.com/hangouts/_/fe0782db82ad005f124b51fd3035bf811cb05e5d
[10:45] <rogpeppe1> dimitern: you're psychic :-)
[10:45] <jam> dimitern, rogpeppe1, fwereade ^^
[10:45] <rogpeppe1> dimitern: was just writing comment to that effect
[10:45] <dimitern> rogpeppe1: which involves not using LifeGetter for relations as well
[10:47] <dimitern> rogpeppe1: and changing both Relation() and RelationById()
[11:23] <wallyworld_> jam: since you asked :-) https://codereview.appspot.com/13619043/
[11:29] <jam> fwereade: can I get a quick chat with you about HTTPS access?
[11:29] <fwereade> jam, ofc
[11:30] <jam> fwereade: https://plus.google.com/hangouts/_/50214d40bcd2c952197a41169820a83b41457d6b
[12:17] <dimitern> rogpeppe1: updated https://codereview.appspot.com/13238046/
[12:17] <dimitern> rogpeppe1: thnaks for the review btw
[12:28] <rogpeppe1> dimitern: responded
[12:29] <dimitern> rogpeppe1: so what's your suggestion?
[12:29] <dimitern> rogpeppe1: I'd like not to change state.Endpoint if possible
[12:29] <dimitern> rogpeppe1: better comment?
[12:30] <rogpeppe1> dimitern: perhaps a comment in both state.Endpoint (to say it can only fail if the endpoint isn't found) and in getOneRelationById (to say why ErrPerm is appropriate) ?
[12:31] <dimitern> rogpeppe1: ok, will do
[12:38] <dimitern> rogpeppe1: btw there's already a comment like this: state/relation.go:232
[12:38] <dimitern> rogpeppe1: so I'll just edit the comment in prepareRelationResult
[12:38] <rogpeppe1> dimitern: good point. yeah, that seems ok
[12:44] <dimitern> rogpeppe1: updated again https://codereview.appspot.com/13238046/ - is it good to land now?
[12:45] <rogpeppe1> dimitern: yes, but without the "most likely" qualifier - the logic is only correct if that's the only possibility
[12:46] <dimitern> rogpeppe1: "most likely" means the state connection might have dropped
[12:46] <dimitern> rogpeppe1: i.e. unrelated connection error
[12:46] <rogpeppe1> dimitern: if that's a possibility (it is not currently) then the logic is wrong
[12:46] <dimitern> rogpeppe1: ok, will drop the most likely then
[12:47] <rogpeppe1> dimitern: the point is that we *never* want to mask state connection errors
[12:48] <dimitern> rogpeppe1: even when not authorized in the first place?
[12:49] <dimitern> rogpeppe1: and here's the follow-up https://codereview.appspot.com/13511044
[12:49] <rogpeppe1> dimitern: if it wasn't authorized, we either know that (in which case we should already have returned ErrPerm) or we don't, in which case we need to return the connection error, because it might be a legitimate request and we can't tell because of the connection problem.
[12:50] <dimitern> rogpeppe1: ok
[12:55] <dimitern> rogpeppe1: so then LGTM -"most likely" ? :)
[12:55] <rogpeppe1> dimitern: yeah
[12:56] <dimitern> rogpeppe1: thanks
[12:56] <dimitern> rogpeppe1: and the other CL - does it look ok?
[12:56] <rogpeppe1> dimitern: just looking
[13:06] <dimitern> rogpeppe1: thanks again - updated https://codereview.appspot.com/13511044/
[13:10] <rogpeppe1> dimitern: hmm, i don't quite see why we're making Life not work on relations any more
[13:11] <dimitern> rogpeppe1: we don't need it
[13:11] <dimitern> rogpeppe1: we have Relation() and RelationById() that returns life
[13:12] <rogpeppe1> dimitern: i guess that's reasonable, though it seems like an arbitrary restriction when the Life call works on all the other kinds of entities that have a Life
[13:13] <rogpeppe1> dimitern: i suppose it depends whether we're trying to think of the API as something coherent in itself, rather than just an exact mirror of the agents' requirements
[13:13] <dimitern> rogpeppe1: relations are different from all other entities
[13:13] <dimitern> rogpeppe1: I don't see why we can't balance both
[13:14] <dimitern> rogpeppe1: coherency and agents' requirements
[13:14] <rogpeppe1> dimitern: all entities are different from each other :-)
[13:15] <dimitern> rogpeppe1: yes, but relations have 2 identifiers which are not convertable between each other without accessing state
[13:15] <rogpeppe1> dimitern: i don't really mind (and it's less code, which is always good) but i'm not quite sure why relations are different in this particular case.
[13:16] <dimitern> rogpeppe1: well, i this particular case i chose less code, yes
[13:16] <rogpeppe1> dimitern: fair enough
=== marcoceppi_ is now known as marcoceppi
[13:26] <dimitern> rogpeppe1: so LGTM then? :)
[13:28] <rogpeppe1> dimitern: yup
[13:29] <dimitern> rogpeppe1: cheers
=== hazmat` is now known as hazmat
[15:29] <rogpeppe1> is there a currently a juju command that lists the available tools?
[15:32] <rogpeppe1> ha, i've just discovered that once you've used --upload-tools once, you can never go back.
[15:32] <rogpeppe1> i know why we implemented that logic, but it still seems a bit dubious
[15:33] <mgz> how never is never?
[15:34] <mgz> just deleting the bucket manually should do, shouldn't it?
[16:53] <rogpeppe1> mgz: yeah, probably, although you can't do that with juju itself, and deleting tools that are currently being used seems dubious itself.
=== flaviamissi is now known as flavia_
=== flavia_ is now known as flaviamissi
[22:47]  * thumper waves
[23:40] <davecheney> i love how even looking vaguely at the logging output from cmd/juju makes a raft of unrelated tests fail
[23:44] <davecheney> OI!
[23:44] <davecheney> what the frack has haapened to bootstrapo
[23:44] <davecheney> http://paste.ubuntu.com/6085693/
[23:45] <davecheney> why did it suddenly start doing that
[23:46] <wallyworld_> thumper: how was the weekend away?
[23:46] <wallyworld_> davecheney: which bit about bootstrap?
[23:47] <bigjools> The MAAS integration tests currently use pyjuju.  Should we switch them to use gojuju yet?
[23:47] <wallyworld_> WCPGW?
[23:47] <bigjools> you sound confident
[23:47] <wallyworld_> do the tests use tags?
[23:48] <bigjools> don't think so
[23:48] <bigjools> it bootstraps and deploys a couple of charms
[23:48] <wallyworld_> in that case, it would be interesting to see how it goes
[23:49] <bigjools> it would