| axw | ffs. one of these days I'll learn to do mp's right | 02:57 |
|---|---|---|
| thumper | :) | 03:10 |
| thumper | I've had a very broken day | 03:10 |
| thumper | and it looks like that'll continue | 03:10 |
| * thumper sighs | 03:10 | |
| axw | thumper: heya. broken day? | 03:23 |
| === tasdomas_afk is now known as tasdomas | ||
| thumper | axw: bitsy, where I have other things breaking up the day into small parts | 04:51 |
| thumper | like kids sports | 04:51 |
| thumper | and errands | 04:52 |
| axw | ah | 04:52 |
| axw | I thought something bad had happened | 04:52 |
| axw | :) | 04:52 |
| axw | thumper: are there any component diagrams of the juju internals around? | 04:57 |
| axw | I'm slowly understanding the relationships between things (worker, api, etc.), but a diagram would probably help | 04:58 |
| thumper | no, nothing bad, just a little frustrating | 05:19 |
| thumper | axw: not a diagram that would be any good | 05:19 |
| thumper | :) | 05:20 |
| axw | no worries | 05:20 |
| thumper | axw: I could probably describe the world reasonably succinctly in a hangout | 05:20 |
| thumper | I have a glass of wine now | 05:20 |
| thumper | it is after wine O'clock | 05:20 |
| axw | hehe - just, I'll just get a glass of water | 05:20 |
| axw | it is nowhere near wine o'clock here | 05:20 |
| thumper | :) | 05:20 |
| thumper | I'm sure there are some ways around the rules | 05:21 |
| thumper | like if you are talking to someone where it is past the yard arm | 05:21 |
| axw | thumper: https://plus.google.com/hangouts/_/5d3396bb74d23c8b35414d4c66c7aa4e1c4b7bad?hl=en-GB | 05:24 |
| axw | not sure if that's the right URL ... | 05:24 |
| === jam1 is now known as jam | ||
| TheMue | morning guys, back again | 07:09 |
| noodles775 | Are 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 | |
| noodles775 | So also at https://codereview.appspot.com/12897044/ | 07:28 |
| noodles775 | dimitern: Morning! no rush, or pressure, but (one implementation of) the goose change we talked about on Friday: https://codereview.appspot.com/12897044/ | 07:31 |
| dimitern | noodles775: hey! will take a look shortly | 07:31 |
| dimitern | noodles775: reviewed | 07:41 |
| noodles775 | Thanks dimitern. With the first change (new status), did you mean you just want s/HP //, or actually truncate the comment? | 07:55 |
| noodles775 | dimitern: nm, I hadn't expanded your comment. | 07:56 |
| dimitern | noodles775: my point was to mention HP Cloud, not just HP | 07:57 |
| noodles775 | dimitern: 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 |
| dimitern | noodles775: 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 |
| dimitern | noodles775: but lbox submit won't work, because goose also uses tarmac | 08:07 |
| jam | dimitern, noodles775: https://codereview.appspot.com/12897044/ looks fine to land, I can mark it as such if you want. | 08:07 |
| dimitern | noodles775: so you'll need to do it the same way as for juju-core - set commit message on the MP and mark it approved | 08:07 |
| jam | dimitern: I'm not sure if noodles775 is in the right group to approve his own MPs. | 08:08 |
| jam | but if he is, more power to him :) | 08:08 |
| dimitern | jam: ah, right, that might be the case | 08:08 |
| noodles775 | Nope, I'm not. | 08:08 |
| jam | noodles775: I just did it | 08:08 |
| noodles775 | Thanks jam | 08:09 |
| axw | jam: "This is the email I want to send to juju-dev" - sent to juju-dev? :) | 08:09 |
| jam | axw: I had run a preview copy of it by others, forgot to remove that line :) | 08:09 |
| axw | heh ok | 08:09 |
| dimitern | jam: :) busted! | 08:10 |
| dimitern | fwereade: hey | 08:10 |
| fwereade | dimitern, heyhey | 08:10 |
| dimitern | fwereade: I have a review for you if you have 10m ? | 08:11 |
| jam | fwereade: heyheyheyhey | 08:11 |
| fwereade | jam, let's not get geometric here | 08:11 |
| fwereade | dimitern, sure | 08:11 |
| dimitern | fwereade: 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 land | 08:11 |
| dimitern | fwereade: https://codereview.appspot.com/13055043/ | 08:11 |
| dimitern | fwereade: 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 altogether | 08:13 |
| TheMue | *phew* many mails, many code changes - and that in only two weeks ;) | 08:19 |
| dimitern | TheMue: hey! welcome back :) | 08:19 |
| fwereade | dimitern, sorry, offhand, what's a params.Settings? | 08:20 |
| rogpeppe | mornin' all | 08:20 |
| TheMue | dimitern: heya | 08:20 |
| dimitern | fwereade: map[string]interface{} | 08:20 |
| TheMue | rogpeppe: morning | 08:20 |
| dimitern | rogpeppe: morning | 08:20 |
| rogpeppe | fwereade: i wondered about that too | 08:20 |
| fwereade | dimitern, rogpeppe: needs to be map[string]string for relation settings, doesn't it? | 08:21 |
| rogpeppe | fwereade: i suggested just using a charm.Settings | 08:21 |
| dimitern | rogpeppe: could you send you draft comments if you have them? | 08:21 |
| fwereade | dimitern, rogpeppe: whoa, what's that for? charm settings can hold non-strings, can't they? | 08:21 |
| rogpeppe | fwereade: that actually seems like a better idea | 08:21 |
| fwereade | dimitern, rogpeppe: a possible reason to use m[s]i is to allow nil for delete though | 08:22 |
| dimitern | fwereade: so coerce everything to a string on the settings when sending? | 08:22 |
| rogpeppe | fwereade: alternatively just treat empty string as delete | 08:22 |
| dimitern | fwereade: yeah, rogpeppe suggested that | 08:22 |
| rogpeppe | fwereade: as, presumably, the uniter does anyway? | 08:22 |
| fwereade | dimitern, they all have to be strings anyway | 08:22 |
| rogpeppe | yeah, there's no settings schema | 08:23 |
| fwereade | rogpeppe, dimitern: empty string == delete is probably sensible, it's effectively what we do anyway | 08:23 |
| TheMue | rogpeppe: 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 |
| dimitern | fwereade: 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 bandwidth | 08:24 |
| rogpeppe | TheMue: config options are different because there's a schema | 08:24 |
| TheMue | rogpeppe: yep, only question is, if an empty string could be a valid value here too? | 08:24 |
| rogpeppe | fwereade: yeah, i thought that we could apply the same intelligence client-side, so we could write only the settings that have changed | 08:24 |
| rogpeppe | TheMue: it can, yes | 08:24 |
| dimitern | fwereade: maybe after you review it we can gather for a quick g+ with rogpeppe? | 08:25 |
| rogpeppe | TheMue: but as a charm, you can't tell the difference between empty string and deleted | 08:25 |
| fwereade | dimitern, rogpeppe: I don't quite understand that one, we should definitely do that, but I don't see how that's relevant to this CL | 08:25 |
| rogpeppe | fwereade: it isn't | 08:25 |
| fwereade | dimitern, rogpeppe: isn't that purely about the client-side implementation? | 08:25 |
| rogpeppe | fwereade: well, it depends | 08:25 |
| rogpeppe | fwereade: on the semantics we give to the write operation | 08:25 |
| dimitern | fwereade: well, it the s-side endpoint is just WriteSettings, there's no incremental Update | 08:25 |
| rogpeppe | fwereade: dimitern's original thought was to have WriteSettings delete all unmentioned attrs | 08:26 |
| fwereade | well, yeah, I'd rather call it update if that's what it does ;p | 08:26 |
| fwereade | rogpeppe, -1000 | 08:26 |
| rogpeppe | fwereade: agreed | 08:26 |
| dimitern | fwereade: so we need WriteSettings which overwrites and UpdateSettings that deletes empty keys and only updates the rest? | 08:27 |
| fwereade | dimitern, that breaks really hard as soon as there's more than one source of relation unit settings events | 08:27 |
| fwereade | dimitern, and addressability stuff is very likely to cause that | 08:27 |
| rogpeppe | fwereade: hmm, is that possible? | 08:27 |
| rogpeppe | fwereade: ah, interesting point | 08:27 |
| fwereade | dimitern, I don't think there's any reason for Write when Update exists | 08:27 |
| dimitern | fwereade: I don't quite get that one | 08:27 |
| rogpeppe | fwereade: +1 | 08:27 |
| dimitern | fwereade: still g+? | 08:28 |
| fwereade | dimitern, when machine addressses change, we'll need to write them into unit settings | 08:28 |
| rogpeppe | dimitern: i'm probably happier on IRC tbh as my network connectivity isn't great here | 08:28 |
| dimitern | fwereade: ah | 08:28 |
| dimitern | fwereade: so you're saying rename WriteSettings to UpdateSettings | 08:29 |
| dimitern | fwereade: also: treat empty keys as deletes and still update the rest | 08:29 |
| rogpeppe | i think WriteSettings is probably still ok | 08:29 |
| fwereade | rogpeppe, well, I'd kinda prefer Update | 08:30 |
| * noodles775 wonders if it's normal for tarmac to take 20mins to pick up an approved branch? | 08:30 | |
| rogpeppe | noodles775: have you set the commit msg? | 08:30 |
| fwereade | noodles775, not unheard of especially if others are approved, but what rogpeppe said :) | 08:30 |
| rogpeppe | fwereade: fair enough | 08:30 |
| dimitern | noodles775: it could happen at times if there are a lot queued up | 08:30 |
| dimitern | noodles775: but it doesn't seem to be the case | 08:30 |
| rogpeppe | fwereade: i'm fine with UpdateSettings too | 08:31 |
| fwereade | rogpeppe, cool | 08:31 |
| dimitern | fwereade: please leave comments on what needs to change, it'll be easier for me that way | 08:31 |
| fwereade | dimitern, sure, just doing that | 08:32 |
| dimitern | fwereade: cheers | 08:32 |
| fwereade | dimitern, needed to discuss first though :) | 08:32 |
| dimitern | fwereade: sure :) | 08:32 |
| jam | noodles775: 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 |
| dimitern | fwereade: 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 |
| jam | noodles775: It normally takes about 15min to run the test suite. | 08:33 |
| noodles775 | rogpeppe, fwereade: Yep, commit msg set, (it's a goose branch) https://code.launchpad.net/~michael.nelson/goose/test-instance-state/+merge/180788 | 08:33 |
| dimitern | rogpeppe: yeah, we really should land that change on goamz that reduces environs/ec2 tests from 3m to 6s | 08:33 |
| rogpeppe | dimitern: it's landed | 08:34 |
| fwereade | dimitern, my gut says "meh, fix it when it's a problem" | 08:34 |
| dimitern | rogpeppe: cool! haven't tried yet | 08:34 |
| rogpeppe | dimitern: but i haven't update juju-core to use it yet | 08:34 |
| dimitern | fwereade: ok, I'd still like to add a TODO just as a reminder lest we forget | 08:34 |
| dimitern | rogpeppe: ahh | 08:35 |
| fwereade | dimitern, fair enough | 08:35 |
| jam | noodles775: 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 |
| noodles775 | jam: 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 |
| noodles775 | :) | 08:35 |
| rogpeppe | dimitern: i agree. there's no point in reading a Settings object when we know exactly what updates we need to perform without reading anything | 08:35 |
| dimitern | rogpeppe: but not for now | 08:36 |
| noodles775 | jam: 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 |
| fwereade | dimitern, rogpeppe, my only problem is with half-fixing it, because IIRC Settings is still kinda crack | 08:36 |
| rogpeppe | dimitern: yeah, as we agreed | 08:36 |
| jam | noodles775: so the machine doesn't show up at all before 8-9s ? | 08:36 |
| rogpeppe | fwereade: we'd bypass Settings entirely | 08:36 |
| rogpeppe | fwereade: and have a RelationUnit.WriteSettings, or something | 08:37 |
| dimitern | fwereade: it's one of the crackiest for sure :) | 08:37 |
| noodles775 | jam: 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 | |
| rogpeppe | fwereade: RelationUnit.UpdateSettings | 08:37 |
| dimitern | jam: HP just uses more fine-grained BUILD status codes | 08:38 |
| fwereade | rogpeppe, hmm, something's bugging me about that | 08:38 |
| noodles775 | jam: previous conversation about that (with the link to the paste): http://irclogs.ubuntu.com/2013/08/16/%23juju-dev.html#t07:24 | 08:38 |
| rogpeppe | fwereade: oh, go on | 08:38 |
| fwereade | rogpeppe, I'm trying to figure out what it is | 08:39 |
| jam | noodles775: your patch was merged, but didn't get pushed up properly, fixing now. | 08:39 |
| dimitern | noodles775: nice! I didn't know we have such nice logs :) | 08:39 |
| rogpeppe | fwereade: BTW i did that audit of all the charms i could find in the charm store for relation names | 08:40 |
| rogpeppe | fwereade: nothing funky | 08:40 |
| fwereade | rogpeppe, oh yes? | 08:40 |
| * fwereade cheers | 08:40 | |
| rogpeppe | fwereade: all quite normal | 08:40 |
| rogpeppe | fwereade: in the process i made a little command for downloading all charms: | 08:40 |
| rogpeppe | fwereade: launchpad.net/juju-utils/cmd/getallcharms | 08:40 |
| * fwereade dances, sings, was fully expecting someone to be insane | 08:40 | |
| fwereade | rogpeppe, isn't there a `charm getall` or something already? | 08:41 |
| rogpeppe | fwereade: and an even smaller command for iterating over all the metadata of all charms in a directory | 08:41 |
| fwereade | rogpeppe, (not in juju) | 08:41 |
| dimitern | fwereade: yep, it seems we need something like [a-z][a-z0-9]*(-[a-z0-9]+)* | 08:41 |
| fwereade | rogpeppe, that sounds nice | 08:41 |
| rogpeppe | fwereade: oh, yeah, there is a getall :-) | 08:41 |
| rogpeppe | fwereade: launchpad.net/juju-utils/cmd/charmmeta | 08:41 |
| fwereade | rogpeppe, that's cool, thanks | 08:42 |
| rogpeppe | fwereade: i hadn't seen "charm getall", but my getallcharms will be much faster, i think | 08:42 |
| rogpeppe | fwereade: as it downloads bundles directly from the charm store | 08:43 |
| fwereade | rogpeppe, nice | 08:43 |
| rogpeppe | fwereade: it actually doesn't take long to download them all - try it | 08:43 |
| rogpeppe | ! | 08:43 |
| fwereade | rogpeppe, dimitern: RelationUnitPair is interesting | 08:43 |
| fwereade | rogpeppe, dimitern: the LocalUnit echoes all the others, but should not really be required | 08:44 |
| rogpeppe | fwereade: i think i suggested that | 08:44 |
| fwereade | rogpeppe, dimitern: whether or not RemoteUnit is accessible is a permissions question | 08:44 |
| fwereade | rogpeppe, 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 itself | 08:45 |
| dimitern | fwereade: exactly!! | 08:45 |
| dimitern | fwereade: we shouldn't do that | 08:45 |
| rogpeppe | fwereade: personally i think that would be fine, but i realise you like those bulk calls | 08:45 |
| dimitern | fwereade: 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 |
| fwereade | rogpeppe, dimitern: however I *think* there's a disticntion in this case | 08:46 |
| rogpeppe | dimitern: ooh, don't ask that question! that way lies madness. | 08:47 |
| fwereade | rogpeppe, dimitern: it's only required in this case because of how state is implemented | 08:47 |
| fwereade | rogpeppe, ;p | 08:47 |
| dimitern | fwereade: so you're saying let's open the door there | 08:47 |
| dimitern | :) | 08:47 |
| fwereade | rogpeppe, dimitern: it's a side effect of a weird underlying implementation | 08:47 |
| rogpeppe | fwereade: the fact that we don't know what entity the calls are being executed on behalf of? | 08:48 |
| rogpeppe | fwereade: (in state, that is) | 08:48 |
| dimitern | rogpeppe: of couse we know - it's still the same unit, just there's a relation involved as well | 08:49 |
| fwereade | rogpeppe, dimitern: I think the symetry makes it ok, but we need to be sure to translate permissions errors from ReadSettings into api permissions errors | 08:49 |
| dimitern | fwereade: sure | 08:50 |
| rogpeppe | fwereade: you mean not-found errors, presumably? | 08:50 |
| fwereade | rogpeppe: I think I mean permission | 08:50 |
| rogpeppe | fwereade: i'm not sure we'd need to do that, would we? | 08:50 |
| rogpeppe | fwereade: oh... one mo | 08:51 |
| rogpeppe | fwereade: i'm not sure what you mean. | 08:51 |
| fwereade | rogpeppe, ha, it's that ReadSettings bug we already discussed | 08:51 |
| rogpeppe | fwereade: isn't ReadSettings itself an API call, so it can just return an ErrPerm | 08:51 |
| fwereade | rogpeppe, so NotFound is one case | 08:51 |
| fwereade | rogpeppe, that should indeed be translated | 08:52 |
| rogpeppe | fwereade: i'm not sure actually | 08:52 |
| fwereade | rogpeppe, but ReadSettings should itself barf if you try to ask for a unit on the wrong side of the relation | 08:52 |
| rogpeppe | fwereade: i'm a bit wary of this blanket "translate not-found in to perm-denied" thing | 08:52 |
| rogpeppe | fwereade: how can a unit ask for its own settings then? | 08:53 |
| fwereade | rogpeppe, it mustn't! | 08:53 |
| fwereade | rogpeppe, ah | 08:53 |
| fwereade | hmm | 08:53 |
| fwereade | rogpeppe, its own I guess is ok, hadn't thought through the shape of the API | 08:53 |
| fwereade | rogpeppe, but it dfinitely shouldn't ask for its siblings | 08:53 |
| rogpeppe | fwereade: yeah, i thought its own is ok, but not any siblings, yeah | 08:53 |
| fwereade | rogpeppe, *at the moment* ReadSettings is never called for itself | 08:54 |
| fwereade | rogpeppe, 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 calls | 08:55 |
| fwereade | rogpeppe, dimitern: tell me why that's crazy | 08:55 |
| rogpeppe | fwereade: i thought that they both read the settings of a unit and have exactly the same params | 08:55 |
| rogpeppe | fwereade: so why not have them as the same call | 08:56 |
| fwereade | rogpeppe, because it complicates the permissions to a maybe unhealthy degree | 08:56 |
| fwereade | rogpeppe, and because RemoteUnit doesn't really fit in the self case | 08:56 |
| rogpeppe | fwereade: if we omit LocalUnit (as i think we've now agreed) it can just be "Unit" | 08:57 |
| fwereade | rogpeppe, I didn't think we'd done that | 08:57 |
| rogpeppe | fwereade: ah, i misunderstood then | 08:57 |
| fwereade | rogpeppe, sorry | 08:57 |
| rogpeppe | fwereade: when you said "the symmetry makes it ok" i was assuming the opposite to what you meant, i think | 08:58 |
| fwereade | rogpeppe, dimitern: how would you real about the equivalent of ReadSettings(rel, unit) and ReadRelatedSettings(rel, unit, remote) | 08:58 |
| fwereade | ? | 08:58 |
| fwereade | s/real/feel/ | 08:58 |
| * fwereade wonders how his brain generated that typo | 08:59 | |
| fwereade | TheMue, not sure I said hi, welcome back | 08:59 |
| fwereade | mgz, morning | 08:59 |
| rogpeppe | fwereade: you meant "the symmetry makes it ok to have a bulk call for ReadSettings, i'm now presuming? | 08:59 |
| fwereade | rogpeppe, sorry, yeah | 08:59 |
| mgz | fwereade: hey! | 08:59 |
| rogpeppe | fwereade: ah. oh well :-| | 09:00 |
| fwereade | rogpeppe, remember that we're open to just dropping those params across the board one day and nothing'll break ;p | 09:00 |
| rogpeppe | fwereade: so... let's just drop 'em now! | 09:00 |
| fwereade | rogpeppe, but if we're going to do that I would like to do so consistently | 09:00 |
| rogpeppe | fwereade: 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 |
| fwereade | rogpeppe, and there are definite implementation advantages to including the caller at the moment, in terms of shared passthrough implementations | 09:01 |
| rogpeppe | fwereade: but i suppose historical artifacts like that are par for the course in aging APIs | 09:01 |
| TheMue | fwereade: not yet, but heya back from me too :D | 09:02 |
| rogpeppe | fwereade: i agree to an extent about the shared impl thing (it works well for Life for example) | 09:03 |
| fwereade | rogpeppe, dimitern: so, how about two calls, including the remote unit only when asking for a remote unit? | 09:06 |
| fwereade | rogpeppe, dimitern: they're used in rather different contexts | 09:07 |
| rogpeppe | fwereade: i'm not quite sure what you're suggesting. | 09:07 |
| fwereade | rogpeppe, ReadSettings(relation, unit); ReadRelatedSettings(relation, unit, remote) | 09:08 |
| dimitern | fwereade, rogpeppe: sorry, got a little side-tracked, catching up with the backlog | 09:08 |
| rogpeppe | fwereade: i still think it's weird having two calls there where we could have one, but there y'go | 09:09 |
| dimitern | fwereade, rogpeppe: RS() and RRS() sgtm - I had originally done them like that | 09:11 |
| rogpeppe | dimitern: yeah, i'm sorry for suggesting you do it differently | 09:11 |
| dimitern | rogpeppe: no worries, it was for different reasons iirc | 09:11 |
| dimitern | fwereade: so how about permissions in the "own settings" case? | 09:12 |
| rogpeppe | dimitern: similar reasons really - i didn't see why we had two calls when we could use one | 09:12 |
| fwereade | dimitern, not sure what you're asking re permissions? you only get to RS your own, you only get to RRS others' | 09:13 |
| dimitern | fwereade: so no notfound->errPerm translation for your own settings, assuming you're auth'ed for that unit-tag ? | 09:16 |
| fwereade | dimitern, I hadn't really been thinking about your own | 09:16 |
| fwereade | dimitern, 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 |
| dimitern | fwereade: not sure how we can know which units are supposed to be related to your unit | 09:18 |
| fwereade | dimitern, is it a member of the other service in the relation? then it's ok | 09:19 |
| dimitern | fwereade: 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 not | 09:19 |
| fwereade | dimitern, visibility is I think purely service-level here | 09:20 |
| dimitern | fwereade: 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 relation | 09:20 |
| dimitern | fwereade: if we have any related endpoints, we're fine | 09:21 |
| fwereade | dimitern, 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 asking | 09:21 |
| fwereade | sorry (2) was not expressed well; was meaning clear anyway? | 09:22 |
| dimitern | fwereade: mine 2 or your 2 ? :) | 09:22 |
| fwereade | dimitern, mine, I'm trying to see if I can simplify yours a bit | 09:22 |
| fwereade | dimitern, we could ofc just translate notfounds at the api level | 09:23 |
| dimitern | fwereade: so let me rephrase it as I understood it | 09:23 |
| fwereade | dimitern, and separately fix ReadSettings itself to inject fake NotFounds if you're trying to read sibling data | 09:23 |
| dimitern | fwereade: 1) the service's role is related: that's what RelatedEndoints(serviceName) returns anyway | 09:24 |
| fwereade | dimitern, ah! bingo, yeah, I'd forgotten that method | 09:24 |
| dimitern | fwereade: so any results there - we can proceed | 09:24 |
| jam | noodles775: 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 |
| dimitern | fwereade: we can pretty much filter 2) out before trying 1) | 09:24 |
| fwereade | dimitern, sounds sane I think | 09:25 |
| dimitern | fwereade: e.g. GetAuthTag() != thisEntityWeReChecking.Tag | 09:25 |
| fwereade | dimitern, yeah | 09:25 |
| dimitern | fwereade: ok, sgtm, thanks | 09:25 |
| dimitern | fwereade: did you notice my sleazy InScope hack? | 09:26 |
| fwereade | dimitern, that seemed fine to me, if anything it should probably have gone further -- would potentially simplify a bunch of scope tests in state, I think | 09:27 |
| dimitern | fwereade: :) 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 anyway | 09:27 |
| noodles775 | jam: I've not looked into why it fails to connect if we continue from BUILD(networking). I can check though. | 09:28 |
| fwereade | dimitern, one day I think I'd like a Relations() method returning all RUs for which the unit is in scope | 09:28 |
| fwereade | dimitern, that'd fix the local-relation-state problem in uniter | 09:29 |
| dimitern | fwereade: ah, that sounds nice | 09:29 |
| jam | axw: 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 |
| jam | axw: (I'm guesing --upload). I'll also just check that you're using go 1.1 | 09:29 |
| axw | yes go 1.1, and sorry that was a typo | 09:30 |
| axw | the real command is in the one liner | 09:30 |
| axw | I'll remove the bit about me isolating it, because that's bunk | 09:31 |
| dimitern | fwereade: 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 manage | 09:31 |
| dimitern | fwereade: I moved to the new place and need to sort out some stuff this afternoon | 09:32 |
| fwereade | dimitern, <3, I'll just do a quick skip through the CL for anything I've missed | 09:32 |
| dimitern | fwereade: thanks | 09:32 |
| dimitern | fwereade: and also, the car really helped with moving all the stuff, thanks again! | 09:33 |
| fwereade | dimitern, cool, glad it came in handy :) | 09:33 |
| fwereade | dimitern, oh, just a thought, when will you be back again? | 09:33 |
| dimitern | fwereade: on the 30th | 09:34 |
| noodles775 | jam: 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 |
| dimitern | fwereade: updated the team calendar | 09:34 |
| fwereade | dimitern, sweet, cath will need the keys again the following day sometime ) | 09:34 |
| jam | noodles775: second "private" which is actually the public one. | 09:34 |
| jam | I see BUILD(scheduling) right away | 09:34 |
| jam | and then BUILD(networking), etc. | 09:34 |
| jam | mgz: ^^ would it make sense to included re-querying HP at a logical time during 'first status' ? | 09:35 |
| dimitern | fwereade: 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 |
| noodles775 | jam: yep, the full set are listed here: http://docs.hpcloud.com/api/compute#ServerStates | 09:35 |
| fwereade | dimitern, sounds good, ping me when you're back and I'll come round | 09:36 |
| dimitern | fwereade: sure thing | 09:36 |
| noodles775 | jam: just in case, but pls don't update the status of that MP yet, I'm still adding a test. | 09:36 |
| jam | noodles775: 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 |
| noodles775 | yep. | 09:36 |
| mgz | jam: yes, hp does have its own little world of statuses | 09:37 |
| jam | mgz: so we can handle treating BUILD* as BUILD. but the question is how will the addressing changes poke at stuff like this. | 09:37 |
| jam | noodles775: I've even seen BUILD(networking) that for 1s had only private address, and then in another second had a public address. | 09:38 |
| mgz | well, it's good to know that it doesn't go from having no addresses to having all in one step | 09:38 |
| jam | Presumably it would have to have the public address at the point we get to spawning. | 09:38 |
| mgz | as the obvious poll logic is to stop when a macine has anything | 09:38 |
| jam | mgz: BUILD(scheduling) no addresses, BUILD(networking) 10.* address, BUILD(networking) 10.* + 15.*, BUILD(spawning) 10.*+15.* | 09:39 |
| jam | that is from doing "watch -n1 nova list" as I do a bootstrap. | 09:39 |
| noodles775 | Similar here with a log.Infof: http://paste.ubuntu.com/6002242/ | 09:40 |
| jam | mgz: well we know that on HP we must end up with 2? Could we hack that in? | 09:40 |
| mgz | well, 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 in | 09:40 |
| dimitern | jam, noodles775: I believe an update to goose on the bot is in order due to that change? | 09:41 |
| jam | maybe something in DNSName that knows to wait until we have a public address? | 09:41 |
| jam | dimitern: goose is updated on the bot from noodles landing the patch. | 09:41 |
| dimitern | jam: perhaps even a juju-dev email | 09:41 |
| mgz | we're not guarenteed to get a public address on boot, is one thing there | 09:41 |
| jam | dimitern: well I don't think noodles patch depending on the goose change has landed. | 09:41 |
| noodles775 | dimitern: we can email if/when the juju-core branch lands right? | 09:42 |
| jam | mgz: not guaranteed by who? | 09:42 |
| jam | openstack? | 09:42 |
| jam | or by HP | 09:42 |
| jam | ? | 09:42 |
| dimitern | noodles775: right | 09:42 |
| fwereade | dimitern, reviewed -- but, one thing, you shouldn't send the settings up in EnterScope | 09:42 |
| mgz | clouds in general. hp and aws do give you a public address | 09:42 |
| fwereade | dimitern, we can keep that behind the api | 09:42 |
| dimitern | fwereade: you mean always call EnterScope with nil? | 09:43 |
| fwereade | dimitern, I mean get the private address inside the API version of EnterScope | 09:43 |
| fwereade | dimitern, we still need to put it in, but the uniter doesn't need to worry about it any more I think | 09:43 |
| dimitern | fwereade: not sure I get you | 09:44 |
| fwereade | dimitern, inside the API EnterScope method, you have the unit available | 09:44 |
| fwereade | dimitern, construct the settings map there | 09:44 |
| fwereade | dimitern, don't require that the uniter send it up | 09:44 |
| dimitern | fwereade: and drop the settings field from the args? | 09:44 |
| fwereade | dimitern, yeah, please | 09:44 |
| dimitern | fwereade: how should the map look like when constructed? | 09:45 |
| jam | mgz: "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 nicely | 09:45 |
| dimitern | fwereade: "private-address": unit.PrivateAddress() ? | 09:45 |
| jam | mgz: note that elmo specifically feels that we should be using floating ips by default on canonistack now. | 09:45 |
| fwereade | dimitern, {"private-address": <unit's private address>} | 09:45 |
| jam | as they got (2?) /24 blocks for it. | 09:45 |
| dimitern | fwereade: ok | 09:45 |
| fwereade | jam, mgz: isn't that a matter of using an existing config setting? | 09:46 |
| dimitern | the use-floating-ips is false by default | 09:46 |
| jam | fwereade: 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 |
| jam | fwereade: and the root discussion there | 09:46 |
| jam | fwereade: is that HP will show us the machine before it has finished building | 09:46 |
| mgz | I guess my point is it's simple enough to do the right thing for hp without stopping juju from working on more basic setups | 09:46 |
| fwereade | jam, got you, just confiirming I remembered use-floating-ips accurately :) | 09:46 |
| jam | and will give it a private IP address that we don't want to treat as canonical location | 09:46 |
| jam | until we get the public address. | 09:46 |
| jam | mgz: which is don't treat a machine as alive until it gets to BUILD(spawning) ? | 09:47 |
| mgz | jam: for addresses? it'd just be check again later as well. | 09:48 |
| jam | noodles775: 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 |
| jam | mgz: when ? | 09:48 |
| mgz | at some point after BUILD | 09:49 |
| jam | mgz: 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 |
| jam | SelectPublicAddress 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 |
| mgz | jam: yup, it's a cute hp-influenced hack | 09:52 |
| mgz | there's not a slightly fancier way of doing that, which I've not yet committed | 09:52 |
| jam | mgz: sort with 10.* and 127.* treated as more local? | 09:53 |
| jam | (less public) | 09:53 |
| mgz | auto-detect private addresses as private, yeah | 09:53 |
| jam | noodles775: 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 |
| noodles775 | jam: k - I'll finish adding my test and re-propose. Thanks. | 09:58 |
| * fwereade coffee, bbiab | 10:17 | |
| * TheMue => lunchtime | 10:40 | |
| noodles775 | dimitern, 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 -> lunch | 11:03 | |
| rogpeppe | fwereade, dimitern, TheMue, mgz: huge but trivial: https://codereview.appspot.com/12940044 | 11:25 |
| dimitern | rogpeppe: great! will have a look after the standup | 11:26 |
| fwereade | rogpeppe, if it's really just the gc fix, LGTM sight unseen | 11:26 |
| rogpeppe | fwereade: it is, yeah | 11:26 |
| rogpeppe | fwereade: i hacked up some code to make the change automatically | 11:27 |
| fwereade | rogpeppe, nice | 11:27 |
| TheMue | fwereade: trust as LGTM, nce :D | 11:31 |
| TheMue | rogpeppe: automated change? | 11:32 |
| rogpeppe | TheMue: yeah | 11:32 |
| TheMue | rogpeppe: ok | 11:33 |
| jam | TheMue: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 standup? | 11:33 |
| mgz | rog: try the lowest bandwidth mode if you've not yet | 11:35 |
| rogpeppe | mgz: i am using that | 11:35 |
| rogpeppe | mgz: (audio only) | 11:35 |
| rogpeppe | mgz: it all *started* quite well! | 11:35 |
| TheMue | jam: oh, shit, yes | 11:35 |
| rogpeppe | jam, fwereade: apologies. it looks like i can't do this. | 11:36 |
| jam | rogpeppe: np | 11:36 |
| fwereade | rogpeppe, np | 11:36 |
| jam | you can just text what you'reup to on IRC | 11:36 |
| jam | if there's anything | 11:36 |
| rogpeppe | jam: i'm getting 10-of-a-second bursts of audio | 11:36 |
| rogpeppe | 10th-of-a-second | 11:36 |
| rogpeppe | ah, i hear dimitern! | 11:37 |
| rogpeppe | mgz: was there some problem with me submitting that enormous branch? | 11:39 |
| mgz | rogpeppe: no, I was just joking that I wanted to land my branches first, rather than have to deal with conflicts :) | 11:40 |
| rogpeppe | mgz: too late, sorry! | 11:40 |
| mgz | gah, and I get kicked | 11:45 |
| dimitern | jam, 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 on | 11:49 |
| mgz | :) | 11:49 |
| rogpeppe1 | gah! my laptop just crashed | 11:49 |
| dimitern | it's a bad case of mondays | 11:50 |
| rogpeppe1 | dimitern, mgz: more conflict fuel: https://codereview.appspot.com/13105043 | 12:03 |
| natefinch | man.. 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 |
| rogpeppe1 | natefinch: that's as good as i ever get! :-) | 12:03 |
| natefinch | rogpeppe1: wow, I'm sorry :) | 12:04 |
| dimitern | rogpeppe1: LGTMed | 12:04 |
| rogpeppe1 | dimitern: ta | 12:04 |
| dimitern | rogpeppe1: how is the last batch coming along? | 12:28 |
| rogpeppe1 | dimitern: i was just waiting for 2nd batch to merge :-) | 12:29 |
| rogpeppe1 | dimitern: will propose last batch now | 12:29 |
| dimitern | rogpeppe1: great! I wanted to wait for all of them to land before I branch off | 12:29 |
| dimitern | rogpeppe1: probably the last bit of massive automatic changes like that is to make sure all imports everywhere are grouped | 12:31 |
| rogpeppe1 | dimitern: just resolving conflicts in relationunit_test.go | 12:32 |
| dimitern | rogpeppe1: yep, sorry about that - they are mostly just additions | 12:32 |
| rogpeppe1 | dimitern: 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 |
| dimitern | rogpeppe1: you're running all the tests before proposing, right? saves a bit of time from having to go back and fix stuff the bot bounced | 12:36 |
| rogpeppe1 | dimitern: tbh i just made sure everything compiled | 12:38 |
| rogpeppe1 | dimitern: although i'm running the tests where i've manually fixed conflicts | 12:38 |
| dimitern | rogpeppe1: ok | 12:38 |
| rogpeppe1 | dimitern: last one: https://codereview.appspot.com/13105044 | 12:43 |
| dimitern | rogpeppe1: LGTM | 12:44 |
| rogpeppe1 | dimitern: ta | 12:45 |
| rogpeppe1 | lunch | 12:48 |
| noodles775 | This 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/179899 | 13:16 |
| dimitern | noodles775: please always include a link to the CL on rietveld when setting the commit message | 13:19 |
| dimitern | noodles775: also in this specific case I think a bit more is needed in the message, although surely not the full CL description | 13:20 |
| noodles775 | dimitern: 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 |
| dimitern | noodles775: instead of lbox submit, you can just use lbox propose to do all the work and the change the commit message on the MP | 13:24 |
| noodles775 | dimitern: k, will do. Updated - let me know if you still want further changes (or you can probably update the commit msg yourself?). | 13:25 |
| dimitern | noodles775: thanks, i'll just quickly go through it | 13:26 |
| dimitern | noodles775: a couple of comments | 13:29 |
| rogpeppe1 | noodles775: in general, i really like having the whole codereview description in the commit msg | 13:31 |
| rogpeppe1 | noodles775: it means you can look at the commit log and see all the relevant trunk changes and links to their code review | 13:31 |
| noodles775 | rogpeppe1: oh - OK, I'll do that then (makes it easier - I just thought people would think it noise). | 13:31 |
| dimitern | noodles775: otherwise lgtm, but you already have one, so it's ok | 13:32 |
| sidnei | rogpeppe1: dimitern: any clues on this one: https://pastebin.canonical.com/96004/ | 13:32 |
| noodles775 | heh, thanks dimitern. I'll update after the call and ping you for the status update. | 13:32 |
| noodles775 | s/the/a/ | 13:32 |
| rogpeppe1 | sidnei: looking | 13:32 |
| rogpeppe1 | sidnei: hmm, is that happening repeatedly? | 13:34 |
| sidnei | rogpeppe1: as in every x secs? let me ask pedronis. it happened with local provider after rebooting the machine. | 13:35 |
| rogpeppe1 | sidnei: ah, that makes sense perhaps | 13:35 |
| rogpeppe1 | sidnei: i guess the socket has survived the machine rebooting (do unix domain sockets do that?) | 13:35 |
| sidnei | maaaybe? | 13:36 |
| sidnei | which would explain a different issue im having with a charmed service that uses unix sockets (supervisord) | 13:36 |
| rogpeppe1 | sidnei: i'm slightly surprised actually, if that's what's happening | 13:37 |
| sidnei | rogpeppe1: confirmed with pedronis it's printed repeatedly | 13:37 |
| rogpeppe1 | sidnei: hmm, he could try removing it | 13:38 |
| rogpeppe1 | sidnei: that's perhaps what the code should be doing, becasue EADDRINUSE should never happen in normal circumstances for a uniter | 13:38 |
| rogpeppe1 | fwereade: what do you think? | 13:39 |
| * fwereade reads back a mo | 13:39 | |
| fwereade | rogpeppe1, sidnei: I think davecheney hit that the other day, there's a bug, proposed fix looks sane... just a mo... | 13:40 |
| fwereade | rogpeppe1, sidnei: https://bugs.launchpad.net/juju-core/+bug/1212916 | 13:42 |
| _mup_ | Bug #1212916: uniter/worker: unit agent MUST remove stale unix socket <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1212916> | 13:42 |
| rogpeppe1 | more bikeshed colour suggestions anyone? https://codereview.appspot.com/13053043/ | 13:42 |
| fwereade | rogpeppe1, it should obviously be puce | 13:42 |
| rogpeppe1 | fwereade: 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 | |
| rogpeppe1 | fwereade: it is now indeed a delicate shade of puce | 13:44 |
| noodles775 | dimitern: Updated with your changes. Pls approve when you've time. Thanks! | 13:49 |
| noodles775 | dimitern: btw, do you or someone from juju-core want to send out the email re updating goose, otherwise I can send it. | 13:49 |
| dimitern | noodles775: thanks; approved | 13:51 |
| dimitern | noodles775: I'd appreciate if you send the mail please | 13:51 |
| dimitern | noodles775: i'm elbow-deep in the API now :) | 13:51 |
| === tasdomas is now known as tasdomas_afk | ||
| noodles775 | dimitern: sure thing. | 13:56 |
| noodles775 | dimitern: 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 |
| dimitern | noodles775: I did! sorry, will do | 13:58 |
| dimitern | noodles775: approved | 13:59 |
| mgz | noodles775: 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 needed | 14:03 |
| mgz | (or are you not in ~juju yet?) | 14:03 |
| noodles775 | mgz: I'm not - hence the ping :) | 14:04 |
| mgz | well, we should fix that :) | 14:05 |
| * noodles775 hears dimitern breathing a sigh of relief. | 14:05 | |
| dimitern | noodles775: uh? sorry missed that | 14:06 |
| dimitern | noodles775: :) | 14:06 |
| noodles775 | dimitern: heh, I just meant I won't need to ping you to update the status :) | 14:06 |
| dimitern | noodles775: ah, ok :) no trouble at all | 14:07 |
| mgz | niemeyer: can you add ~michael.nelson to ~juju please? :) | 14:08 |
| fwereade | dammit, my mgo-munging mental structures have atrophied | 14:10 |
| fwereade | or possibly they've matured, and have allowed me to realise something's harder than I thought | 14:11 |
| fwereade | grar | 14:11 |
| mgz | you have not taken your medicine enough recently | 14:11 |
| * fwereade ponders the wisom of afternoon caffeine | 14:11 | |
| niemeyer | mgz: Sure | 14:13 |
| rogpeppe1 | my network connectivity is likely to be dodgy for the next couple of hours | 14: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 |
| noodles775 | Do 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/179899 | 14:49 |
| mgz | geme_: seems the charm doesn't call open-port at all | 14:50 |
| mgz | geme_: 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 |
| mgz | that actually calls open-port | 14:52 |
| noodles775 | mgz: care to re-Approve my MP ^^ (seems I'm not yet part of ~juju) | 14:55 |
| mgz | noodles775: done | 14:55 |
| mgz | niemeyer: ^ poke? thanks. | 14:56 |
| geme_ | mgz: ok | 15:03 |
| geme_ | mgz: do you have a deploy url for that ? The link reporting page not found | 15:05 |
| mgz | geme_: ? `bzr branch` the url listed in the bug report, and deploy from local | 15:08 |
| dimitern | rogpeppe1, fwereade, jam: for consideration https://codereview.appspot.com/13107043 | 15:13 |
| rogpeppe1 | dimitern: looking | 15:13 |
| dimitern | rogpeppe1: 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 this | 15:15 |
| rogpeppe1 | dimitern: erm, *would* look, if i had more than itty bitty connectivity | 15:15 |
| rogpeppe1 | dimitern: i think i know what the CL is likely to be, and i approve :-) | 15:16 |
| dimitern | rogpeppe1: cheers :) | 15:17 |
| dimitern | rogpeppe1: it's mostly stuf like this http://paste.ubuntu.com/6003214/ | 15:18 |
| dimitern | rogpeppe1: does that open? | 15:18 |
| rogpeppe1 | dimitern: yup, i can see that, thanks | 15:18 |
| rogpeppe1 | dimitern: i thought as much | 15:18 |
| geme_ | mgz: Could you repeat the tomcat6 bug report again pls. Chat session drop out | 15:19 |
| dimitern | rogpeppe1: can you at least send the LGTM? or rietveld is not opening for you | 15:20 |
| mgz | geme_: bug 1015202 | 15:20 |
| _mup_ | Bug #1015202: new-charm Tomcat <Juju Charms Collection:New for negronjl> <https://launchpad.net/bugs/1015202> | 15:20 |
| rogpeppe1 | dimitern: i'd like to review the API proposal properly before LGTMing | 15:20 |
| dimitern | rogpeppe1: sure | 15:21 |
| dimitern | rogpeppe1: no rush | 15:21 |
| === mthaddon is now known as mthaddon` | ||
| * dimitern gtg, back here in a couple of hours | 15:21 | |
| rogpeppe1 | dimitern: i'll do that when i get back home in a couple of hours | 15:21 |
| niemeyer | mgz: Done | 15:27 |
| niemeyer | mgz: Btw, William is an admin as well | 15:27 |
| fwereade | dimitern, LGTM, just a few extra notes that'd be worth adding | 15:28 |
| natefinch | I 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 |
| mgz | niemeyer: thanks! | 15:31 |
| mgz | natefinch: 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 |
| natefinch | mgz: this is just some pretty boring equals stuff, like length of two slices... | 15:32 |
| natefinch | mgz: 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 function | 15:34 |
| mgz | natefinch: my guess is then that your checker is borked somehow :) | 15:35 |
| natefinch | but... regardless of the code in the function.... it always returns true or false.... and gc.not should flip that, and it's not somehow | 15:36 |
| mgz | geme_: are you having any luck? | 15:37 |
| natefinch | mgz: 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 is | 15:52 |
| natefinch | tested by just putting return false, "something" at the top of the check function | 15:52 |
| mgz | hm. | 15:53 |
| natefinch | (same thing with return true, "something" | 15:53 |
| natefinch | mgz: 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 failed | 15:57 |
| natefinch | mgz: yeah, the code in c.Check is clear, it treats any non-empty error string as a failure | 15:58 |
| natefinch | and gc.Not() just passes up the error string from the thing it wraps | 15:58 |
| mgz | that sounds somewhat sensible | 15:58 |
| natefinch | mgz: docmentation would make it clearer. I still wish I could control the error msg | 16:00 |
| geme_ | mgz: I've been using robert ayres tomcat charm previously with the python version. Just setting up these charms. | 16:07 |
| fwereade | natefinch, 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 added | 16:28 |
| mgz | geme_: ace. maybe you could comment on that bug as well? | 16:30 |
| natefinch | fwereade: that looks like something you write at the test site, not inside the test function. | 16:31 |
| fwereade | natefinch, ah, sorry, I misunderstood what you were saying | 16:32 |
| natefinch | fwereade: 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 failed | 16:32 |
| * rogpeppe1 is back in the world of wi-fi | 16:42 | |
| geme_ | mgz: sure | 16:45 |
| === mthaddon` is now known as mthaddon | ||
| rogpeppe1 | done for the day. | 18:10 |
| rogpeppe1 | g'night all | 18:10 |
| === tasdomas_afk is now known as tasdomas | ||
| === marcoceppi__ is now known as marcoceppi | ||
| thumper | morning folks | 21:12 |
| thumper | hi fwereade | 21:12 |
| thumper | fwereade: are you perhaps around? | 21:12 |
| === tasdomas is now known as tasdomas_afk | ||
| fwereade | thumper, heyhey | 22:02 |
| thumper | hi fwereade | 22:03 |
| thumper | fwereade: got time for a quick hangout? | 22:04 |
| fwereade | thumper, sure | 22:04 |
| * thumper getting pinged all over | 22:05 | |
| fwereade | thumper, I think I'll be around for a bit if you'd prefer | 22:06 |
| thumper | that's fine, I'll start one | 22:06 |
| arosales | is there a juju command to create juju tools locally? | 22:11 |
| arosales | http://juju-dist.s3.amazonaws.com/ | 22:27 |
| thumper | arosales: not really | 22:30 |
| thumper | arosales: although the local provider does it | 22:30 |
| arosales | thumper, ok so I assume your core guys do some magjc to generate tools for aws and hp? | 22:31 |
| thumper | if by magic you mean run a script, then yes | 22:31 |
| thumper | arosales: although dave probably knows most about that | 22:31 |
| arosales | thumper, ok | 22:32 |
| arosales | bigjools, around? | 23:05 |
| wallyworld_ | thumper: z'up | 23:19 |
| thumper | hi wallyworld_ | 23:19 |
| thumper | wallyworld_: how are you doing today? | 23:19 |
| thumper | I half thought you wouldn't be around | 23:20 |
| wallyworld_ | ok. not too sore. a nice scar on the side of my head | 23:20 |
| wallyworld_ | nah, stuff to do | 23:20 |
| wallyworld_ | you working on addressability stuff? | 23:21 |
| thumper | no, working of refactoring agent.Conf | 23:23 |
| thumper | although wondering how deep to hit this | 23:23 |
| thumper | several things depend on it | 23:23 |
| wallyworld_ | i'm not too familiar with that bit of the code base | 23:23 |
| wallyworld_ | if the change driving towards HA? | 23:24 |
| thumper | diving towards a consistent manner of handling "pseudo environment variables", and a more readable and less duplicated agent config file | 23:26 |
| thumper | with parts that will be writable | 23:26 |
| thumper | like addresses of endpoints | 23:26 |
| thumper | and other parts that shouldn't be changed | 23:27 |
| thumper | like agent tag | 23:27 |
| wallyworld_ | sounds nice | 23:27 |
| thumper | so will be used for HA bits too | 23:27 |
| thumper | and some of the pending work I have | 23:27 |
| thumper | with logging | 23:27 |
| wallyworld_ | +1 for logging :-) | 23:28 |
| arosales | bigjools, ping me when you return on juju provider tools | 23:28 |
| arosales | https://bugs.launchpad.net/juju-core/+bug/1214181 | 23: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!