axwffs. one of these days I'll learn to do mp's right02:57
thumperI've had a very broken day03:10
thumperand it looks like that'll continue03:10
* thumper sighs03:10
axwthumper: heya. broken day?03:23
=== tasdomas_afk is now known as tasdomas
thumperaxw: bitsy, where I have other things breaking up the day into small parts04:51
thumperlike kids sports04:51
thumperand errands04:52
axwI thought something bad had happened04:52
axwthumper: are there any component diagrams of the juju internals around?04:57
axwI'm slowly understanding the relationships between things (worker, api, etc.), but a diagram would probably help04:58
thumperno, nothing bad, just a little frustrating05:19
thumperaxw: not a diagram that would be any good05:19
axwno worries05:20
thumperaxw: I could probably describe the world reasonably succinctly in a hangout05:20
thumperI have a glass of wine now05:20
thumperit is after wine O'clock05:20
axwhehe - just, I'll just get a glass of water05:20
axwit is nowhere near wine o'clock here05:20
thumperI'm sure there are some ways around the rules05:21
thumperlike if you are talking to someone where it is past the yard arm05:21
axwthumper:  https://plus.google.com/hangouts/_/5d3396bb74d23c8b35414d4c66c7aa4e1c4b7bad?hl=en-GB05:24
axwnot sure if that's the right URL ...05:24
=== jam1 is now known as jam
TheMuemorning guys, back again07:09
noodles775Are changes to goose done just via a Launchpad MP? If so, could someone take a look at https://code.launchpad.net/~michael.nelson/goose/test-instance-state/+merge/180788 pls?07:21
* noodles775 checks if lbox works with goose also.07:24
noodles775So also at https://codereview.appspot.com/12897044/07:28
noodles775dimitern: Morning! no rush, or pressure, but (one implementation of) the goose change we talked about on Friday: https://codereview.appspot.com/12897044/07:31
dimiternnoodles775: hey! will take a look shortly07:31
dimiternnoodles775: reviewed07:41
noodles775Thanks dimitern. With the first change (new status), did you mean you just want s/HP //, or actually truncate the comment?07:55
noodles775dimitern: nm, I hadn't expanded your comment.07:56
dimiternnoodles775: my point was to mention HP Cloud, not just HP07:57
noodles775dimitern: done - the second change was slightly different than suggested. Should I lbox submit it now (ie. one LGTM, or still wait for a second?)08:06
dimiternnoodles775: according to the mail today, now only one LGTM is needed (a month's experiment, let's hope it doesn't go wrong)08:07
dimiternnoodles775: but lbox submit won't work, because goose also uses tarmac08:07
jamdimitern, noodles775: https://codereview.appspot.com/12897044/ looks fine to land, I can mark it as such if you want.08:07
dimiternnoodles775: so you'll need to do it the same way as for juju-core - set commit message on the MP and mark it approved08:07
jamdimitern: I'm not sure if noodles775 is in the right group to approve his own MPs.08:08
jambut if he is, more power to him :)08:08
dimiternjam: ah, right, that might be the case08:08
noodles775Nope, I'm not.08:08
jamnoodles775: I just did it08:08
noodles775Thanks jam08:09
axwjam: "This is the email I want to send to juju-dev" - sent to juju-dev? :)08:09
jamaxw: I had run a preview copy of it by others, forgot to remove that line :)08:09
axwheh ok08:09
dimiternjam: :) busted!08:10
dimiternfwereade: hey08:10
fwereadedimitern, heyhey08:10
dimiternfwereade: I have a review for you if you have 10m ?08:11
jamfwereade: heyheyheyhey08:11
fwereadejam, let's not get geometric here08:11
fwereadedimitern, sure08:11
dimiternfwereade: roger and I discussed it on friday, he raised some concerns, but in the end I think we decided it's not that bad to land08:11
dimiternfwereade: https://codereview.appspot.com/13055043/08:11
dimiternfwereade: his concerns were about properly deleting settings keys and not doing a mongo read+write for every write, possibly having a RelationUnit.WriteSettings call that bypasses the state.Settings caching magic altogether08:13
TheMue*phew* many mails, many code changes - and that in only two weeks ;)08:19
dimiternTheMue: hey! welcome back :)08:19
fwereadedimitern, sorry, offhand, what's a params.Settings?08:20
rogpeppe  mornin' all08:20
TheMuedimitern: heya08:20
dimiternfwereade: map[string]interface{}08:20
TheMuerogpeppe: morning08:20
dimiternrogpeppe: morning08:20
rogpeppefwereade: i wondered about that too08:20
fwereadedimitern, rogpeppe: needs to be map[string]string for relation settings, doesn't it?08:21
rogpeppefwereade: i suggested just using a charm.Settings08:21
dimiternrogpeppe: could you send you draft comments if you have them?08:21
fwereadedimitern, rogpeppe: whoa, what's that for? charm settings can hold non-strings, can't they?08:21
rogpeppefwereade: that actually seems like a better idea08:21
fwereadedimitern, rogpeppe: a possible reason to use m[s]i is to allow nil for delete though08:22
dimiternfwereade: so coerce everything to a string on the settings when sending?08:22
rogpeppefwereade: alternatively just treat empty string as delete08:22
dimiternfwereade: yeah, rogpeppe suggested that08:22
rogpeppefwereade: as, presumably, the uniter does anyway?08:22
fwereadedimitern, they all have to be strings anyway08:22
rogpeppeyeah, there's no settings schema08:23
fwereaderogpeppe, dimitern: empty string == delete is probably sensible, it's effectively what we do anyway08:23
TheMuerogpeppe: empty string as delete reminds me of options. but then empty strings never can be used as valid value. is this the case here?08:23
dimiternfwereade: rogpeppe was also concerned that some charms might send set huge settings once and change smaller ones often, and with the API implementation we send all changes on Write(), so it might incurr more bandwidth08:24
rogpeppeTheMue: config options are different because there's a schema08:24
TheMuerogpeppe: yep, only question is, if an empty string could be a valid value here too?08:24
rogpeppefwereade: yeah, i thought that we could apply the same intelligence client-side, so we could write only the settings that have changed08:24
rogpeppeTheMue: it can, yes08:24
dimiternfwereade: maybe after you review it we can gather for a quick g+ with rogpeppe?08:25
rogpeppeTheMue: but as a charm, you can't tell the difference between empty string and deleted08:25
fwereadedimitern, rogpeppe: I don't quite understand that one, we should definitely do that, but I don't see how that's relevant to this CL08:25
rogpeppefwereade: it isn't08:25
fwereadedimitern, rogpeppe: isn't that purely about the client-side implementation?08:25
rogpeppefwereade: well, it depends08:25
rogpeppefwereade: on the semantics we give to the write operation08:25
dimiternfwereade: well, it the s-side endpoint is just WriteSettings, there's no incremental Update08:25
rogpeppefwereade: dimitern's original thought was to have WriteSettings delete all unmentioned attrs08:26
fwereadewell, yeah, I'd rather call it update if that's what it does ;p08:26
fwereaderogpeppe, -100008:26
rogpeppefwereade: agreed08:26
dimiternfwereade: so we need WriteSettings which overwrites and UpdateSettings that deletes empty keys and only updates the rest?08:27
fwereadedimitern, that breaks really hard as soon as there's more than one source of relation unit settings events08:27
fwereadedimitern, and addressability stuff is very likely to cause that08:27
rogpeppefwereade: hmm, is that possible?08:27
rogpeppefwereade: ah, interesting point08:27
fwereadedimitern, I don't think there's any reason for Write when Update exists08:27
dimiternfwereade: I don't quite get that one08:27
rogpeppefwereade: +108:27
dimiternfwereade: still g+?08:28
fwereadedimitern, when machine addressses change, we'll need to write them into unit settings08:28
rogpeppedimitern: i'm probably happier on IRC tbh as my network connectivity isn't great here08:28
dimiternfwereade: ah08:28
dimiternfwereade: so you're saying rename WriteSettings to UpdateSettings08:29
dimiternfwereade: also: treat empty keys as deletes and still update the rest08:29
rogpeppei think WriteSettings is probably still ok08:29
fwereaderogpeppe, well, I'd kinda prefer Update08:30
* noodles775 wonders if it's normal for tarmac to take 20mins to pick up an approved branch?08:30
rogpeppenoodles775: have you set the commit msg?08:30
fwereadenoodles775, not unheard of especially if others are approved, but what rogpeppe said :)08:30
rogpeppefwereade: fair enough08:30
dimiternnoodles775: it could happen at times if there are a lot queued up08:30
dimiternnoodles775: but it doesn't seem to be the case08:30
rogpeppefwereade: i'm fine with UpdateSettings too08:31
fwereaderogpeppe, cool08:31
dimiternfwereade: please leave comments on what needs to change, it'll be easier for me that way08:31
fwereadedimitern, sure, just doing that08:32
dimiternfwereade: cheers08:32
fwereadedimitern, needed to discuss first though :)08:32
dimiternfwereade: sure :)08:32
jamnoodles775: so by your "10s timeout" comment. Does that mean the machine still hasn't showed up after 10s? Or is this that HP treats the machine as BUILDING(something) which we should probably just treat as BUILD?08:32
dimiternfwereade: also, are you ok with having a mongo read for every write as it is now? Should I add a TODO to optimize this if we find it inefficient?08:33
jamnoodles775: It normally takes about 15min to run the test suite.08:33
noodles775rogpeppe, fwereade: Yep, commit msg set, (it's a goose branch) https://code.launchpad.net/~michael.nelson/goose/test-instance-state/+merge/18078808:33
dimiternrogpeppe: yeah, we really should land that change on goamz that reduces environs/ec2 tests from 3m to 6s08:33
rogpeppedimitern: it's landed08:34
fwereadedimitern, my gut says "meh, fix it when it's a problem"08:34
dimiternrogpeppe: cool! haven't tried yet08:34
rogpeppedimitern: but i haven't update juju-core to use it yet08:34
dimiternfwereade: ok, I'd still like to add a TODO just as a reminder lest we forget08:34
dimiternrogpeppe: ahh08:35
fwereadedimitern, fair enough08:35
jamnoodles775: ah, for goose it should be faster, but if it got queued behind a juju-core branch. I'll check what the bot is up to.08:35
noodles775jam: It's a goose branch (local tests run in a few seconds). RE the HP bug, I still need to update that juju-core branch once the goose branch lands (with the dependency), but yes, the machine turns up as BUILD(spawning) after 8-9 seconds and status continues to success (once mongod is up etc.).08:35
rogpeppedimitern: i agree. there's no point in reading a Settings object when we know exactly what updates we need to perform without reading anything08:35
dimiternrogpeppe: but not for now08:36
noodles775jam: I'll run a bootstrap 10 times or so, and if it's always around the 8-9 second mark, I'll update shortAttempt to 15s?08:36
fwereadedimitern, rogpeppe, my only problem is with half-fixing it, because IIRC Settings is still kinda crack08:36
rogpeppedimitern: yeah, as we agreed08:36
jamnoodles775: so the machine doesn't show up at all before 8-9s ?08:36
rogpeppefwereade: we'd bypass Settings entirely08:36
rogpeppefwereade: and have a RelationUnit.WriteSettings, or something08:37
dimiternfwereade: it's one of the crackiest for sure :)08:37
noodles775jam: it does - shows up as BUILD(networking), but if you continue from that point we never connect to mongod.08:37
* noodles775 finds paste.08:37
rogpeppefwereade: RelationUnit.UpdateSettings08:37
dimiternjam: HP just uses more fine-grained BUILD status codes08:38
fwereaderogpeppe, hmm, something's bugging me about that08:38
noodles775jam: previous conversation about that (with the link to the paste): http://irclogs.ubuntu.com/2013/08/16/%23juju-dev.html#t07:2408:38
rogpeppefwereade: oh, go on08:38
fwereaderogpeppe, I'm trying to figure out what it is08:39
jamnoodles775: your patch was merged, but didn't get pushed up properly, fixing now.08:39
dimiternnoodles775: nice! I didn't know we have such nice logs :)08:39
rogpeppefwereade: BTW i did that audit of all the charms i could find in the charm store for relation names08:40
rogpeppefwereade: nothing funky08:40
fwereaderogpeppe, oh yes?08:40
* fwereade cheers08:40
rogpeppefwereade: all quite normal08:40
rogpeppefwereade: in the process i made a little command for downloading all charms:08:40
rogpeppefwereade: launchpad.net/juju-utils/cmd/getallcharms08:40
* fwereade dances, sings, was fully expecting someone to be insane08:40
fwereaderogpeppe, isn't there a `charm getall` or something already?08:41
rogpeppefwereade: and an even smaller command for iterating over all the metadata of all charms in a directory08:41
fwereaderogpeppe, (not in juju)08:41
dimiternfwereade: yep, it seems we need something like [a-z][a-z0-9]*(-[a-z0-9]+)*08:41
fwereaderogpeppe, that sounds nice08:41
rogpeppefwereade: oh, yeah, there is a getall :-)08:41
rogpeppefwereade: launchpad.net/juju-utils/cmd/charmmeta08:41
fwereaderogpeppe, that's cool, thanks08:42
rogpeppefwereade: i hadn't seen "charm getall", but my getallcharms will be much faster, i think08:42
rogpeppefwereade: as it downloads bundles directly from the charm store08:43
fwereaderogpeppe, nice08:43
rogpeppefwereade: it actually doesn't take long to download them all - try it08:43
fwereaderogpeppe, dimitern: RelationUnitPair is interesting08:43
fwereaderogpeppe, dimitern: the LocalUnit echoes all the others, but should not really be required08:44
rogpeppefwereade: i think i suggested that08:44
fwereaderogpeppe, dimitern: whether or not RemoteUnit is accessible is a permissions question08:44
fwereaderogpeppe, dimitern: *but* if the local unit is inferred internally in that call, we should probably be doing so in all the others, and that feels out of whack itself08:45
dimiternfwereade: exactly!!08:45
dimiternfwereade: we shouldn't do that08:45
rogpeppefwereade: personally i think that would be fine, but i realise you like those bulk calls08:45
dimiternfwereade: otherwise we might get to "why we need bulk ops at all when we infer what to return by the auth'ed entity alone?"08:46
fwereaderogpeppe, dimitern: however I *think* there's a disticntion in this case08:46
rogpeppedimitern: ooh, don't ask that question! that way lies madness.08:47
fwereaderogpeppe, dimitern: it's only required in this case because of how state is implemented08:47
fwereaderogpeppe, ;p08:47
dimiternfwereade: so you're saying let's open the door there08:47
fwereaderogpeppe, dimitern: it's a side effect of a weird underlying implementation08:47
rogpeppefwereade: the fact that we don't know what entity the calls are being executed on behalf of?08:48
rogpeppefwereade: (in state, that is)08:48
dimiternrogpeppe: of couse we know - it's still the same unit, just there's a relation involved as well08:49
fwereaderogpeppe, dimitern: I think the symetry makes it ok, but we need to be sure to translate permissions errors from ReadSettings into api permissions errors08:49
dimiternfwereade: sure08:50
rogpeppefwereade: you mean not-found errors, presumably?08:50
fwereaderogpeppe: I think I mean permission08:50
rogpeppefwereade: i'm not sure we'd need to do that, would we?08:50
rogpeppefwereade: oh... one mo08:51
rogpeppefwereade: i'm not sure what you mean.08:51
fwereaderogpeppe, ha, it's that ReadSettings bug we already discussed08:51
rogpeppefwereade: isn't ReadSettings itself an API call, so it can just return an ErrPerm08:51
fwereaderogpeppe, so NotFound is one case08:51
fwereaderogpeppe, that should indeed be translated08:52
rogpeppefwereade: i'm not sure actually08:52
fwereaderogpeppe, but ReadSettings should itself barf if you try to ask for a unit on the wrong side of the relation08:52
rogpeppefwereade: i'm a bit wary of this blanket "translate not-found in to perm-denied" thing08:52
rogpeppefwereade: how can a unit ask for its own settings then?08:53
fwereaderogpeppe, it mustn't!08:53
fwereaderogpeppe, ah08:53
fwereaderogpeppe, its own I guess is ok, hadn't thought through the shape of the API08:53
fwereaderogpeppe, but it dfinitely shouldn't ask for its siblings08:53
rogpeppefwereade: yeah, i thought its own is ok, but not any siblings, yeah08:53
fwereaderogpeppe, *at the moment* ReadSettings is never called for itself08:54
fwereaderogpeppe, dimitern: I'm at least a little inclined to suggest that maybe reading one's own settings and reading one's relatives' are different enough operations to want to be separate calls08:55
fwereaderogpeppe, dimitern: tell me why that's crazy08:55
rogpeppefwereade: i thought that they both read the settings of a unit and have exactly the same params08:55
rogpeppefwereade: so why not have them as the same call08:56
fwereaderogpeppe, because it complicates the permissions to a maybe unhealthy degree08:56
fwereaderogpeppe, and because RemoteUnit doesn't really fit in the self case08:56
rogpeppefwereade: if we omit LocalUnit (as i think we've now agreed) it can just be "Unit"08:57
fwereaderogpeppe, I didn't think we'd done that08:57
rogpeppefwereade: ah, i misunderstood then08:57
fwereaderogpeppe, sorry08:57
rogpeppefwereade: when you said "the symmetry makes it ok" i was assuming the opposite to what you meant, i think08:58
fwereaderogpeppe, dimitern: how would you real about the equivalent of ReadSettings(rel, unit) and ReadRelatedSettings(rel, unit, remote)08:58
* fwereade wonders how his brain generated that typo08:59
fwereadeTheMue, not sure I said hi, welcome back08:59
fwereademgz, morning08:59
rogpeppefwereade: you meant "the symmetry makes it ok to have a bulk call for ReadSettings, i'm now presuming?08:59
fwereaderogpeppe, sorry, yeah08:59
mgzfwereade: hey!08:59
rogpeppefwereade: ah. oh well :-|09:00
fwereaderogpeppe, remember that we're open to just dropping those params across the board one day and nothing'll break ;p09:00
rogpeppefwereade: so... let's just drop 'em now!09:00
fwereaderogpeppe, but if we're going to do that I would like to do so consistently09:00
rogpeppefwereade: well, we can't really drop the params across the board without being left with calls that still take slice of params, but aren't actually bulk calls.09:01
fwereaderogpeppe, and there are definite implementation advantages to including the caller at the moment, in terms of shared passthrough implementations09:01
rogpeppefwereade: but i suppose historical artifacts like that are par for the course in aging APIs09:01
TheMuefwereade: not yet, but heya back from me too :D09:02
rogpeppefwereade: i agree to an extent about the shared impl thing (it works well for Life for example)09:03
fwereaderogpeppe, dimitern: so, how about two calls, including the remote unit only when asking for a remote unit?09:06
fwereaderogpeppe, dimitern: they're used in rather different contexts09:07
rogpeppefwereade: i'm not quite sure what you're suggesting.09:07
fwereaderogpeppe, ReadSettings(relation, unit); ReadRelatedSettings(relation, unit, remote)09:08
dimiternfwereade, rogpeppe: sorry, got a little side-tracked, catching up with the backlog09:08
rogpeppefwereade: i still think it's weird having two calls there where we could have one, but there y'go09:09
dimiternfwereade, rogpeppe: RS() and RRS() sgtm - I had originally done them like that09:11
rogpeppedimitern: yeah, i'm sorry for suggesting you do it differently09:11
dimiternrogpeppe: no worries, it was for different reasons iirc09:11
dimiternfwereade: so how about permissions in the "own settings" case?09:12
rogpeppedimitern: similar reasons really - i didn't see why we had two calls when we could use one09:12
fwereadedimitern, not sure what you're asking re permissions? you only get to RS your own, you only get to RRS others'09:13
dimiternfwereade: so no notfound->errPerm translation for your own settings, assuming you're auth'ed for that unit-tag ?09:16
fwereadedimitern, I hadn't really been thinking about your own09:16
fwereadedimitern, for remote settings, it would be ideal if we could figure out the permissions errors before even needing to read them (although NotFound->ErrPerm for supposedly-accessible ones that don't exist also sounds sensible)09:17
dimiternfwereade: not sure how we can know which units are supposed to be related to your unit09:18
fwereadedimitern, is it a member of the other service in the relation? then it's ok09:19
dimiternfwereade: I mean, from the relation you can get all units somehow, but how to know which ones you are supposed to be able to see or not09:19
fwereadedimitern, visibility is I think purely service-level here09:20
dimiternfwereade: so 1) we get the RU from the given rel-id + our unit (the auth'ed), 2) get the remote unit, its service and get the related endpoints for it from the relation09:20
dimiternfwereade: if we have any related endpoints, we're fine09:21
fwereadedimitern, if you want to be pedantic, you should beable to read the settings of any unit that's a member of a service in the relation, so long as (1) the service's role is related to your own and (2) the unit is not the one asking09:21
fwereadesorry (2) was not expressed well; was meaning clear anyway?09:22
dimiternfwereade: mine 2 or your 2 ? :)09:22
fwereadedimitern, mine, I'm trying to see if I can simplify yours a bit09:22
fwereadedimitern, we could ofc just translate notfounds at the api level09:23
dimiternfwereade: so let me rephrase it as I understood it09:23
fwereadedimitern, and separately fix ReadSettings itself to inject fake NotFounds if you're trying to read sibling data09:23
dimiternfwereade: 1) the service's role is related: that's what RelatedEndoints(serviceName) returns anyway09:24
fwereadedimitern, ah! bingo, yeah, I'd forgotten that method09:24
dimiternfwereade: so any results there - we can proceed09:24
jamnoodles775: sorry about the delay (lunch). I read over the context a bit, does the IP address change after BUILD(networking) into BUILD(spawning) ?09:24
dimiternfwereade: we can pretty much filter 2) out before trying 1)09:24
fwereadedimitern, sounds sane I think09:25
dimiternfwereade: e.g. GetAuthTag() != thisEntityWeReChecking.Tag09:25
fwereadedimitern, yeah09:25
dimiternfwereade: ok, sgtm, thanks09:25
dimiternfwereade: did you notice my sleazy InScope hack?09:26
fwereadedimitern, that seemed fine to me, if anything it should probably have gone further -- would potentially simplify a bunch of scope tests in state, I think09:27
dimiternfwereade: :) wasn't sure you'd like it, but I couldn't make the tests pass with a RelationScopeWatcher through the API and it seemed too much hassle anyway09:27
noodles775jam: I've not looked into why it fails to connect if we continue from BUILD(networking). I can check though.09:28
fwereadedimitern, one day I think I'd like a Relations() method returning all RUs for which the unit is in scope09:28
fwereadedimitern, that'd fix the local-relation-state problem in uniter09:29
dimiternfwereade: ah, that sounds nice09:29
jamaxw: bug #1213832 I don't know of  an 'upgrade-tools'. Do you mean 'juju bootstrap --upload-tools" or "juju sync-tools" or ?09:29
_mup_Bug #1213832: Intermittent errors during upgrade-juju with local provider <juju-core:New> <https://launchpad.net/bugs/1213832>09:29
jamaxw: (I'm guesing --upload). I'll also just check that you're using go 1.109:29
axwyes go 1.1, and sorry that was a typo09:30
axwthe real command is in the one liner09:30
axwI'll remove the bit about me isolating it, because that's bunk09:31
dimiternfwereade: so my plan for today is, to land this CL, then add a skeleton of the client-side API with all files, no tests and all TODOs written in them. If I manage, I'd like to do the unit calls as well, but might not manage09:31
dimiternfwereade: I moved to the new place and need to sort out some stuff this afternoon09:32
fwereadedimitern, <3, I'll just do a quick skip through the CL for anything I've missed09:32
dimiternfwereade: thanks09:32
dimiternfwereade: and also, the car really helped with moving all the stuff, thanks again!09:33
fwereadedimitern, cool, glad it came in handy :)09:33
fwereadedimitern, oh, just a thought, when will you be back again?09:33
dimiternfwereade: on the 30th09:34
noodles775jam: Yes, it gets a second private address after the initial BUILD(networking) but before BUILD(spawning), and it's that address which is used to connect to mongod: http://paste.ubuntu.com/6002242/09:34
dimiternfwereade: updated the team calendar09:34
fwereadedimitern, sweet, cath will need the keys again the following day sometime )09:34
jamnoodles775: second "private" which is actually the public one.09:34
jamI see BUILD(scheduling) right away09:34
jamand then BUILD(networking), etc.09:34
jammgz: ^^ would it make sense to included re-querying HP at a logical time during 'first status' ?09:35
dimiternfwereade: well, technically on the 30th I'm still off, but I'll drop by to give you the keys; or you could come and see the new flat :)09:35
noodles775jam: yep, the full set are listed here: http://docs.hpcloud.com/api/compute#ServerStates09:35
fwereadedimitern, sounds good, ping me when you're back and I'll come round09:36
dimiternfwereade: sure thing09:36
noodles775jam: just in case, but pls don't update the status of that MP yet, I'm still adding a test.09:36
jamnoodles775: so.... I'd like us to handle more BUILD states, and I'd really like us to handle address changes, but that is certainly out of scope for what you are doing.09:36
mgzjam: yes, hp does have its own little world of statuses09:37
jammgz: so we can handle treating BUILD* as BUILD. but the question is how will the addressing changes poke at stuff like this.09:37
jamnoodles775: I've even seen BUILD(networking) that for 1s had only private address, and then in another second had a public address.09:38
mgzwell, it's good to know that it doesn't go from having no addresses to having all in one step09:38
jamPresumably it would have to have the public address at the point we get to spawning.09:38
mgzas the obvious poll logic is to stop when a macine has anything09:38
jammgz: BUILD(scheduling) no addresses, BUILD(networking) 10.* address, BUILD(networking) 10.* + 15.*, BUILD(spawning) 10.*+15.*09:39
jamthat is from doing "watch -n1 nova list" as I do a bootstrap.09:39
noodles775Similar here with a log.Infof: http://paste.ubuntu.com/6002242/09:40
jammgz: well we know that on HP we must end up with 2? Could we hack that in?09:40
mgzwell, the likely adptation is to force one more address check at a later boot stage, either from machine status, or when the machine is up and the machine agent reports in09:40
dimiternjam, noodles775: I believe an update to goose on the bot is in order due to that change?09:41
jammaybe something in DNSName that knows to wait until we have a public address?09:41
jamdimitern: goose is updated on the bot from noodles landing the patch.09:41
dimiternjam: perhaps even a juju-dev email09:41
mgzwe're not guarenteed to get a public address on boot, is one thing there09:41
jamdimitern: well I don't think noodles patch depending on the goose change has landed.09:41
noodles775dimitern: we can email if/when the juju-core branch lands right?09:42
jammgz: not guaranteed by who?09:42
jamor by HP09:42
dimiternnoodles775: right09:42
fwereadedimitern, reviewed -- but, one thing, you shouldn't send the settings up in EnterScope09:42
mgzclouds in general. hp and aws do give you a public address09:42
fwereadedimitern, we can keep that behind the api09:42
dimiternfwereade: you mean always call EnterScope with nil?09:43
fwereadedimitern, I mean get the private address inside the API version of EnterScope09:43
fwereadedimitern, we still need to put it in, but the uniter doesn't need to worry about it any more I think09:43
dimiternfwereade: not sure I get you09:44
fwereadedimitern, inside the API EnterScope method, you have the unit available09:44
fwereadedimitern, construct the settings map there09:44
fwereadedimitern, don't require that the uniter send it up09:44
dimiternfwereade: and drop the settings field from the args?09:44
fwereadedimitern, yeah, please09:44
dimiternfwereade: how should the map look like when constructed?09:45
jammgz: "clouds in general" sure, but we could just require it, and have people do stuff like use-floating-ip:true or sshuttle. I suppose if our polling said "10.* doesn't count as routable" but then you are using sshuttle, then we aren't playing nicely09:45
dimiternfwereade: "private-address": unit.PrivateAddress() ?09:45
jammgz: note that elmo specifically feels that we should be using floating ips by default on canonistack now.09:45
fwereadedimitern, {"private-address": <unit's private address>}09:45
jamas they got (2?) /24 blocks for it.09:45
dimiternfwereade: ok09:45
fwereadejam, mgz: isn't that a matter of using an existing config setting?09:46
dimiternthe use-floating-ips is false by default09:46
jamfwereade: use-floating-ip is, the main discussion about "how can we poll appropriately to be sure we are actually getting a routable address for 'juju status'" is the other question.09:46
jamfwereade: and the root discussion there09:46
jamfwereade: is that HP will show us the machine before it has finished building09:46
mgzI guess my point is it's simple enough to do the right thing for hp without stopping juju from working on more basic setups09:46
fwereadejam, got you, just confiirming I remembered use-floating-ips accurately :)09:46
jamand will give it a private IP address that we don't want to treat as canonical location09:46
jamuntil we get the public address.09:46
jammgz: which is don't treat a machine as alive until it gets to BUILD(spawning) ?09:47
mgzjam: for addresses? it'd just be check again later as well.09:48
jamnoodles775: yeah, the only state here http://docs.hpcloud.com/api/compute#ServerStates I haven't seen is "BUILD(block_device_mapping)" but since we don't mount devices, we won't really see that one :)09:48
jammgz: when ?09:48
mgzat some point after BUILD09:49
jammgz: so looking at the openstack/provider.go code, we just always select the last of the list of private IPs. Which happens to work on HP?09:51
jamSelectPublicAddress seems to try to find an address labeled public, otherwise it overwrites "mostpublic" with each entry in the list until it gets to the end.09:52
mgzjam: yup, it's a cute hp-influenced hack09:52
mgzthere's not a slightly fancier way of doing that, which I've not yet committed09:52
jammgz: sort with 10.* and 127.* treated as more local?09:53
jam(less public)09:53
mgzauto-detect private addresses as private, yeah09:53
jamnoodles775: so after diving into this, treating BUILD* as BUILD would be ~ok, but as a short-term just treating BUILD(spawning) as BUILD would be a great step forward.09:55
noodles775jam: k - I'll finish adding my test and re-propose. Thanks.09:58
* fwereade coffee, bbiab10:17
* TheMue => lunchtime10:40
noodles775dimitern, jam: I've updated the description with a bit of info (in particular, one thing which I couldn't find a way to test which I would like to test - let me know if you've ideas): https://codereview.appspot.com/12795045/11:03
* noodles775 -> lunch11:03
rogpeppefwereade, dimitern, TheMue, mgz: huge but trivial: https://codereview.appspot.com/1294004411:25
dimiternrogpeppe: great! will have a look after the standup11:26
fwereaderogpeppe, if it's really just the gc fix, LGTM sight unseen11:26
rogpeppefwereade: it is, yeah11:26
rogpeppefwereade: i hacked up some code to make the change automatically11:27
fwereaderogpeppe, nice11:27
TheMuefwereade: trust as LGTM, nce :D11:31
TheMuerogpeppe: automated change?11:32
rogpeppeTheMue: yeah11:32
TheMuerogpeppe: ok11:33
jamTheMue: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 standup?11:33
mgzrog: try the lowest bandwidth mode if you've not yet11:35
rogpeppemgz: i am using that11:35
rogpeppemgz: (audio only)11:35
rogpeppemgz: it all *started* quite well!11:35
TheMuejam: oh, shit, yes11:35
rogpeppejam, fwereade: apologies. it looks like i can't do this.11:36
jamrogpeppe: np11:36
fwereaderogpeppe, np11:36
jamyou can just text what you'reup to on IRC11:36
jamif there's anything11:36
rogpeppejam: i'm getting 10-of-a-second bursts of audio11:36
rogpeppeah, i hear dimitern!11:37
rogpeppemgz: was there some problem with me submitting that enormous branch?11:39
mgzrogpeppe: no, I was just joking that I wanted to land my branches first, rather than have to deal with conflicts :)11:40
rogpeppemgz: too late, sorry!11:40
mgzgah, and I get kicked11:45
dimiternjam, TheMue, rogpeppe, mgz, natefinch: fwereade just texted me he has some issues with this connection and will try to resolve them, but he'll be doing "some damn programming" :) there's also a bug assigned to him which he'll work on11:49
rogpeppe1gah! my laptop just crashed11:49
dimiternit's a bad case of mondays11:50
rogpeppe1dimitern, mgz: more conflict fuel:  https://codereview.appspot.com/1310504312:03
natefinchman.. I don't know if it's my wifi or my internet connection, but I've been getting like 500kbps upload speed, when my connection is supposed to be 25 megs up :/12:03
rogpeppe1natefinch: that's as good as i ever get! :-)12:03
natefinchrogpeppe1: wow, I'm sorry :)12:04
dimiternrogpeppe1: LGTMed12:04
rogpeppe1dimitern: ta12:04
dimiternrogpeppe1: how is the last batch coming along?12:28
rogpeppe1dimitern: i was just waiting for 2nd batch to merge :-)12:29
rogpeppe1dimitern: will propose last batch now12:29
dimiternrogpeppe1: great! I wanted to wait for all of them to land before I branch off12:29
dimiternrogpeppe1: probably the last bit of massive automatic changes like that is to make sure all imports everywhere are grouped12:31
rogpeppe1dimitern: just resolving conflicts in relationunit_test.go12:32
dimiternrogpeppe1: yep, sorry about that - they are mostly just additions12:32
rogpeppe1dimitern: yeah, but additions i need to change all of, and there are quite a few! (that's fine though, par for the course)12:34
dimiternrogpeppe1: you're running all the tests before proposing, right? saves a bit of time from having to go back and fix stuff the bot bounced12:36
rogpeppe1dimitern: tbh i just made sure everything compiled12:38
rogpeppe1dimitern: although i'm running the tests where i've manually fixed conflicts12:38
dimiternrogpeppe1: ok12:38
rogpeppe1dimitern: last one: https://codereview.appspot.com/1310504412:43
dimiternrogpeppe1: LGTM12:44
rogpeppe1dimitern: ta12:45
noodles775This is ready for Status->Approved if someone has a moment: https://code.launchpad.net/~michael.nelson/juju-core/1208504-post-bootstrap-hp-no-instances-found-try2/+merge/17989913:16
dimiternnoodles775: please always include a link to the CL on rietveld when setting the commit message13:19
dimiternnoodles775: also in this specific case I think a bit more is needed in the message, although surely not the full CL description13:20
noodles775dimitern: Yeah - I found it strange that `lbox submit` (which I've only continued to use because it does everything up until changing the status) copies the MP description to the commit msg (which was way to big), so I manually updated the MP. Let me update the commit msg again.13:23
dimiternnoodles775: instead of lbox submit, you can just use lbox propose to do all the work and the change the commit message on the MP13:24
noodles775dimitern: k, will do. Updated - let me know if you still want further changes (or you can probably update the commit msg yourself?).13:25
dimiternnoodles775: thanks, i'll just quickly go through it13:26
dimiternnoodles775: a couple of comments13:29
rogpeppe1noodles775: in general, i really like having the whole codereview description in the commit msg13:31
rogpeppe1noodles775: it means you can look at the commit log and see all the relevant trunk changes and links to their code review13:31
noodles775rogpeppe1: oh - OK, I'll do that then (makes it easier - I just thought people would think it noise).13:31
dimiternnoodles775: otherwise lgtm, but you already have one, so it's ok13:32
sidneirogpeppe1: dimitern: any clues on this one: https://pastebin.canonical.com/96004/13:32
noodles775heh, thanks dimitern. I'll update after the call and ping you for the status update.13:32
rogpeppe1sidnei: looking13:32
rogpeppe1sidnei: hmm, is that happening repeatedly?13:34
sidneirogpeppe1: as in every x secs? let me ask pedronis. it happened with local provider after rebooting the machine.13:35
rogpeppe1sidnei: ah, that makes sense perhaps13:35
rogpeppe1sidnei: i guess the socket has survived the machine rebooting (do unix domain sockets do that?)13:35
sidneiwhich would explain a different issue im having with a charmed service that uses unix sockets (supervisord)13:36
rogpeppe1sidnei: i'm slightly surprised actually, if that's what's happening13:37
sidneirogpeppe1: confirmed with pedronis it's printed repeatedly13:37
rogpeppe1sidnei: hmm, he could try removing it13:38
rogpeppe1sidnei: that's perhaps what the code should be doing, becasue EADDRINUSE should never happen in normal circumstances for a uniter13:38
rogpeppe1fwereade: what do you think?13:39
* fwereade reads back a mo13:39
fwereaderogpeppe1, sidnei: I think davecheney hit that the other day, there's a bug, proposed fix looks sane... just a mo...13:40
fwereaderogpeppe1, sidnei: https://bugs.launchpad.net/juju-core/+bug/121291613:42
_mup_Bug #1212916: uniter/worker: unit agent MUST remove stale unix socket <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1212916>13:42
rogpeppe1more bikeshed colour suggestions anyone? https://codereview.appspot.com/13053043/13:42
fwereaderogpeppe1, it should obviously be puce13:42
rogpeppe1fwereade: using the @ namespace sounds sane (insofar as unix sockets are sane at all, which is a difficult call)13:43
* rogpeppe1 shall try to avoid using names starting with '@' in the future (WTF?!)13:43
rogpeppe1fwereade: it is now indeed a delicate shade of puce13:44
noodles775dimitern: Updated with your changes. Pls approve when you've time. Thanks!13:49
noodles775dimitern: btw, do you or someone from juju-core want to send out the email re updating goose, otherwise I can send it.13:49
dimiternnoodles775: thanks; approved13:51
dimiternnoodles775: I'd appreciate if you send the mail please13:51
dimiternnoodles775: i'm elbow-deep in the API now :)13:51
=== tasdomas is now known as tasdomas_afk
noodles775dimitern: sure thing.13:56
noodles775dimitern: sorry, did you possibly have the Launchpad MP already open when you approved it? (It's complaining that there are new revs since you approved). Can you pls refresh and re-approve?13:57
dimiternnoodles775: I did! sorry, will do13:58
dimiternnoodles775: approved13:59
mgznoodles775: the approve that matters for that error is the mark on the proposal, not the vote, so setting back to needs review then approved again is all that's needed14:03
mgz(or are you not in ~juju yet?)14:03
noodles775mgz: I'm not - hence the ping :)14:04
mgzwell, we should fix that :)14:05
* noodles775 hears dimitern breathing a sigh of relief.14:05
dimiternnoodles775: uh? sorry missed that14:06
dimiternnoodles775: :)14:06
noodles775dimitern: heh, I just meant I won't need to ping you to update the status :)14:06
dimiternnoodles775: ah, ok :) no trouble at all14:07
mgzniemeyer: can you add ~michael.nelson to ~juju please? :)14:08
fwereadedammit, my mgo-munging mental structures have atrophied14:10
fwereadeor possibly they've matured, and have allowed me to realise something's harder than I thought14:11
mgzyou have not taken your medicine enough recently14:11
* fwereade ponders the wisom of afternoon caffeine14:11
niemeyermgz: Sure14:13
rogpeppe1my network connectivity is likely to be dodgy for the next couple of hours14:32
geme_I've just deployed the tomcat6 charm on a private openstack instance and port 8080 hasn't been added to the security group rules after the service has been exposed. Is this a known problem ?14:45
noodles775Do I need another LGTM after re-merging trunk and updating to fix some test failures? (failures due to moved code/new namespaces in trunk) Rev 1662 at https://code.launchpad.net/~michael.nelson/juju-core/1208504-post-bootstrap-hp-no-instances-found-try2/+merge/17989914:49
mgzgeme_: seems the charm doesn't call open-port at all14:50
mgzgeme_: maybe try the branch linked in bug 1015202 instead?14:52
_mup_Bug #1015202: new-charm Tomcat <Juju Charms Collection:New for negronjl> <https://launchpad.net/bugs/1015202>14:52
mgzthat actually calls open-port14:52
noodles775mgz: care to re-Approve my MP ^^ (seems I'm not yet part of ~juju)14:55
mgznoodles775: done14:55
mgzniemeyer: ^ poke? thanks.14:56
geme_mgz: ok15:03
geme_mgz: do you have a deploy url for that ? The link reporting page not found15:05
mgzgeme_: ? `bzr branch` the url listed in the bug report, and deploy from local15:08
dimiternrogpeppe1, fwereade, jam: for consideration https://codereview.appspot.com/1310704315:13
rogpeppe1dimitern: looking15:13
dimiternrogpeppe1: it's not final, some things will probably still change along the way, but I think it's good to have a roadmap-in-code like this15:15
rogpeppe1dimitern: erm, *would* look, if i had more than itty bitty connectivity15:15
rogpeppe1dimitern: i think i know what the CL is likely to be, and i approve :-)15:16
dimiternrogpeppe1: cheers :)15:17
dimiternrogpeppe1: it's mostly stuf like this http://paste.ubuntu.com/6003214/15:18
dimiternrogpeppe1: does that open?15:18
rogpeppe1dimitern: yup, i can see that, thanks15:18
rogpeppe1dimitern: i thought as much15:18
geme_mgz: Could you repeat the tomcat6 bug report again pls. Chat session drop out15:19
dimiternrogpeppe1: can you at least send the LGTM? or rietveld is not opening for you15:20
mgzgeme_: bug 101520215:20
_mup_Bug #1015202: new-charm Tomcat <Juju Charms Collection:New for negronjl> <https://launchpad.net/bugs/1015202>15:20
rogpeppe1dimitern: i'd like to review the API proposal properly before LGTMing15:20
dimiternrogpeppe1: sure15:21
dimiternrogpeppe1: no rush15:21
=== mthaddon is now known as mthaddon`
* dimitern gtg, back here in a couple of hours15:21
rogpeppe1dimitern: i'll do that when i get back home in a couple of hours15:21
niemeyermgz: Done15:27
niemeyermgz: Btw, William is an admin as well15:27
fwereadedimitern, LGTM, just a few extra notes that'd be worth adding15:28
natefinchI don't understand... how can c.Check(foo, <checker>, bar) AND c.Check(foo, gc.Not(<checker>), bar) BOTH fail?  Shouldn't that be impossible?15:29
mgzniemeyer: thanks!15:31
mgznatefinch: I can think of various cases where that might be the case, not sure which apply in go (funny float values, for instance)15:31
natefinchmgz: this is just some pretty boring equals stuff, like length of two slices...15:32
natefinchmgz: I wrote a new checker to compare the unordered contents of slices, and the first few checks in the function are just stuff like "are the two slices the same length" ... the code in the function is returning false at the right spot...  but when I wrap it in a gc.Not(), it's still saying the check failed.... with the message I gave from the function15:34
mgznatefinch: my guess is then that your checker is borked somehow :)15:35
natefinchbut... regardless of the code in the function.... it always returns true or false.... and gc.not should flip that, and it's  not somehow15:36
mgzgeme_: are you having any luck?15:37
natefinchmgz: seems like if I put anything in the error string, gc.Not has no effect and it's treated as a failure regardless of what the result is15:52
natefinchtested by just putting return false, "something"  at the top of the check function15:52
natefinch(same thing with return true, "something"15:53
natefinchmgz: I think it's just me misunderstanding the Checker interface... which could use slightly better documentation imo.  I think the error string is for errors in the test that just don't make sense, like nil pointers or comparing different types.  Whereas I was using error as a way to explain why the test failed15:57
natefinchmgz: yeah, the code in c.Check is clear, it treats any non-empty error string as a failure15:58
natefinchand gc.Not() just passes up the error string from the thing it wraps15:58
mgzthat sounds somewhat sensible15:58
natefinchmgz: docmentation would make it clearer.  I still wish I could control the error msg16:00
geme_mgz: I've been using robert ayres tomcat charm previously with the python version. Just setting up these charms.16:07
fwereadenatefinch, I'm not quite sure, but are you looking for http://godoc.org/launchpad.net/gocheck#Commentf ?16:26
geme_mgz: Robert Ayres tomcat charms look good. Security group rules added16:28
mgzgeme_: ace. maybe you could comment on that bug as well?16:30
natefinchfwereade: that looks like something you write at the test site, not inside the test function.16:31
fwereadenatefinch, ah, sorry, I misunderstood what you were saying16:32
natefinchfwereade: I was looking for a way to pass back information from the test as to why it failed, rather than just saying "failed" and printing out the two values, forcing the dev to figure out why those values failed16:32
* rogpeppe1 is back in the world of wi-fi16:42
geme_mgz: sure16:45
=== mthaddon` is now known as mthaddon
rogpeppe1done for the day.18:10
rogpeppe1g'night all18:10
=== tasdomas_afk is now known as tasdomas
=== marcoceppi__ is now known as marcoceppi
thumpermorning folks21:12
thumperhi fwereade21:12
thumperfwereade: are you perhaps around?21:12
=== tasdomas is now known as tasdomas_afk
fwereadethumper, heyhey22:02
thumperhi fwereade22:03
thumperfwereade: got time for a quick hangout?22:04
fwereadethumper, sure22:04
* thumper getting pinged all over22:05
fwereadethumper, I think I'll be around for a bit if you'd prefer22:06
thumperthat's fine, I'll start one22:06
arosalesis there a juju command to create juju tools locally?22:11
thumperarosales: not really22:30
thumperarosales: although the local provider does it22:30
arosalesthumper, ok so I assume your core guys do some magjc to generate tools for aws and hp?22:31
thumperif by magic you mean run a script, then yes22:31
thumperarosales: although dave probably knows most about that22:31
arosalesthumper, ok22:32
arosalesbigjools, around?23:05
wallyworld_thumper: z'up23:19
thumperhi wallyworld_23:19
thumperwallyworld_: how are you doing today?23:19
thumperI half thought you wouldn't be around23:20
wallyworld_ok. not too sore. a nice scar on the side of my head23:20
wallyworld_nah, stuff to do23:20
wallyworld_you working on addressability stuff?23:21
thumperno, working of refactoring agent.Conf23:23
thumperalthough wondering how deep to hit this23:23
thumperseveral things depend on it23:23
wallyworld_i'm not too familiar with that bit of the code base23:23
wallyworld_if the change driving towards HA?23:24
thumperdiving towards a consistent manner of handling "pseudo environment variables", and a more readable and less duplicated agent config file23:26
thumperwith parts that will be writable23:26
thumperlike addresses of endpoints23:26
thumperand other parts that shouldn't be changed23:27
thumperlike agent tag23:27
wallyworld_sounds nice23:27
thumperso will be used for HA bits too23:27
thumperand some of the pending work I have23:27
thumperwith logging23:27
wallyworld_+1 for logging :-)23:28
arosalesbigjools, ping me when you return on juju provider tools23:28
_mup_Bug #1214181: Azure Provider always uploading 1.12 tools <juju-core:New> <https://launchpad.net/bugs/1214181>23:28

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!