| 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:03 |
| davecheney | phase 1. complicated problem | 01:27 |
| davecheney | phase 2 .... | 01:27 |
| davecheney | phase 3. gnome shell! | 01:27 |
| davecheney | this week in silly juju tricks http://dave.cheney.net/2013/09/09/using-juju-to-build-gccgo | 01:45 |
| davecheney | has anyone tried compiling juju with gccgo ? | 02:11 |
| jam | morning all | 05:30 |
| axw | morning jam | 05:31 |
| jam | hey wallyworld_ I'm in whenever you're around | 05:58 |
| wallyworld_ | ok | 05:58 |
| 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:23 |
| 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:24 |
| 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:25 |
| wallyworld_ | jam: you froze? | 06:26 |
| 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:34 |
| davecheney | axw: ta | 06:36 |
| davecheney | that'll make life easier | 06:36 |
| 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:49 |
| davecheney | sweet | 06:50 |
| 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:51 |
| 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:52 |
| davecheney | actually more | 06:53 |
| davecheney | at least 4 people were involved | 06:53 |
| 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:56 |
| 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:57 |
| 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 | 06:58 |
| rogpeppe1 | mornin' all! | 07:26 |
| axw | hey rogpeppe1 | 07:31 |
| rogpeppe1 | axw: hiya | 07:31 |
| 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:43 |
| 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:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| dimitern | rogpeppe1: sweet! did she seemed interested? | 08:49 |
| rogpeppe1 | dimitern: i'm not sure it really fits their goals | 08:50 |
| dimitern | rogpeppe1: how so? | 08:50 |
| rogpeppe1 | dimitern: i don't think we're mature enough for them to consider yet | 08:51 |
| dimitern | rogpeppe1: ah, well we'll get there | 08:52 |
| dimitern | rogpeppe1: a trivial review? https://codereview.appspot.com/13292044/ | 09:25 |
| rogpeppe1 | dimitern: looking | 09:25 |
| rogpeppe1 | dimitern: LGTM | 09:26 |
| dimitern | rogpeppe1: cheers | 09:26 |
| dimitern | fwereade: ping | 09:35 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| dimitern | fwereade: so add RelationTag as a field to hook.Info and StateDir ? | 09:58 |
| dimitern | fwereade: and yeah - what about upgrading? | 09:58 |
| 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 | 09:59 |
| 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:00 |
| 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:01 |
| 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:40 |
| 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:45 |
| dimitern | rogpeppe1: and changing both Relation() and RelationById() | 10:47 |
| wallyworld_ | jam: since you asked :-) https://codereview.appspot.com/13619043/ | 11:23 |
| jam | fwereade: can I get a quick chat with you about HTTPS access? | 11:29 |
| fwereade | jam, ofc | 11:29 |
| jam | fwereade: https://plus.google.com/hangouts/_/50214d40bcd2c952197a41169820a83b41457d6b | 11:30 |
| dimitern | rogpeppe1: updated https://codereview.appspot.com/13238046/ | 12:17 |
| dimitern | rogpeppe1: thnaks for the review btw | 12:17 |
| rogpeppe1 | dimitern: responded | 12:28 |
| 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:29 |
| 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:30 |
| dimitern | rogpeppe1: ok, will do | 12:31 |
| 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:38 |
| dimitern | rogpeppe1: updated again https://codereview.appspot.com/13238046/ - is it good to land now? | 12:44 |
| rogpeppe1 | dimitern: yes, but without the "most likely" qualifier - the logic is only correct if that's the only possibility | 12:45 |
| 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:46 |
| rogpeppe1 | dimitern: the point is that we *never* want to mask state connection errors | 12:47 |
| dimitern | rogpeppe1: even when not authorized in the first place? | 12:48 |
| 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:49 |
| dimitern | rogpeppe1: ok | 12:50 |
| dimitern | rogpeppe1: so then LGTM -"most likely" ? :) | 12:55 |
| rogpeppe1 | dimitern: yeah | 12:55 |
| dimitern | rogpeppe1: thanks | 12:56 |
| dimitern | rogpeppe1: and the other CL - does it look ok? | 12:56 |
| rogpeppe1 | dimitern: just looking | 12:56 |
| dimitern | rogpeppe1: thanks again - updated https://codereview.appspot.com/13511044/ | 13:06 |
| rogpeppe1 | dimitern: hmm, i don't quite see why we're making Life not work on relations any more | 13:10 |
| dimitern | rogpeppe1: we don't need it | 13:11 |
| dimitern | rogpeppe1: we have Relation() and RelationById() that returns life | 13:11 |
| 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:12 |
| 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:13 |
| dimitern | rogpeppe1: coherency and agents' requirements | 13:14 |
| rogpeppe1 | dimitern: all entities are different from each other :-) | 13:14 |
| 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:15 |
| dimitern | rogpeppe1: well, i this particular case i chose less code, yes | 13:16 |
| rogpeppe1 | dimitern: fair enough | 13:16 |
| === marcoceppi_ is now known as marcoceppi | ||
| dimitern | rogpeppe1: so LGTM then? :) | 13:26 |
| rogpeppe1 | dimitern: yup | 13:28 |
| dimitern | rogpeppe1: cheers | 13:29 |
| === hazmat` is now known as hazmat | ||
| rogpeppe1 | is there a currently a juju command that lists the available tools? | 15:29 |
| 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:32 |
| mgz | how never is never? | 15:33 |
| mgz | just deleting the bucket manually should do, shouldn't it? | 15:34 |
| rogpeppe1 | mgz: yeah, probably, although you can't do that with juju itself, and deleting tools that are currently being used seems dubious itself. | 16:53 |
| === flaviamissi is now known as flavia_ | ||
| === flavia_ is now known as flaviamissi | ||
| * thumper waves | 22:47 | |
| davecheney | i love how even looking vaguely at the logging output from cmd/juju makes a raft of unrelated tests fail | 23:40 |
| davecheney | OI! | 23:44 |
| davecheney | what the frack has haapened to bootstrapo | 23:44 |
| davecheney | http://paste.ubuntu.com/6085693/ | 23:44 |
| davecheney | why did it suddenly start doing that | 23:45 |
| wallyworld_ | thumper: how was the weekend away? | 23:46 |
| wallyworld_ | davecheney: which bit about bootstrap? | 23:46 |
| 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:47 |
| 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:48 |
| bigjools | it would | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!