| hatch | huwshimi you had some questions you sent in the email yesterday | 00:43 |
|---|---|---|
| hatch | have you got those solved or do you still need a hand there? | 00:43 |
| huwshimi | hatch: Not solved (no replies). I'm trying to figure out, in a machine/container token how I can tell if the machine/token has been deleted | 00:45 |
| hatch | you can't, I'm not sure you can tell if anything has been deleted | 00:45 |
| hatch | units, services etc | 00:45 |
| huwshimi | hatch: Yeah... | 00:45 |
| hatch | so when something gets deleted do we want to remove it form the db? probably not because then what if they change their minds | 00:46 |
| huwshimi | yeah | 00:46 |
| hatch | but with that said, that's how the units are done now | 00:47 |
| hatch | see environmnt-change-set.js line 691 | 00:47 |
| hatch | relations are done the same way | 00:47 |
| hatch | oh wait | 00:48 |
| hatch | no that's only removing the ghost stuff | 00:48 |
| hatch | hmm | 00:48 |
| hatch | I have to finish cooking supper | 00:50 |
| hatch | leave this with me and I'll get back to you when I'm done | 00:50 |
| huwshimi | hatch: OK, thanks! | 00:51 |
| Makyo | Supper or dinner? | 00:52 |
| hatch | Makyo haha, supper | 01:07 |
| hatch | :P | 01:07 |
| hatch | huwshimi so unfortunately we have been pretty destry | 01:07 |
| hatch | destructive when dealing with removing of relations | 01:07 |
| hatch | and units so far | 01:07 |
| hatch | so we'll have to go back and fix that | 01:07 |
| huwshimi | hatch: Oh, so not going through ecs? | 01:07 |
| hatch | but the only reasonable way I can think of is to have an 'ecs-destroyed' attr of some sort which we check when we decide to render things | 01:08 |
| hatch | because what happens if we remove a service then the user decides to 'cancel' the ecs changes | 01:08 |
| hatch | it needs to revert back as if nothing happened | 01:08 |
| hatch | we can't do that if the service is gone | 01:08 |
| hatch | but we need to signify it being gone in the canvas | 01:08 |
| hatch | huwshimi so basically when a user destroys a deployed machine, it needs to mark on the model that it's in the queue to be destroyed | 01:10 |
| hatch | but then if that ever gets canceled it needs to go in and set it back | 01:10 |
| huwshimi | hatch: So maybe I should land this branch with the correct states on the token and then once we have those flags we can hook it all up? | 01:11 |
| hatch | yeah that's a good idea | 01:11 |
| hatch | hmm | 01:11 |
| hatch | huwshimi atm if you destroy a machine that's queued we just remove it from the db and it's gone | 01:12 |
| hatch | so there will be no UI for that, but for real machines we have nothing to signify it's destruction | 01:13 |
| hatch | huwshimi with that said you could pretty easily hack it into the ecs | 01:13 |
| hatch | if you wanted to just play with it | 01:14 |
| hatch | not sure if you want to tackle that task or if you want to push it off | 01:14 |
| huwshimi | hatch: I'm a bit scared of that area. I might add the card to track the deleted state and then if no one gets to it I can take a look | 01:16 |
| hatch | heh yeah there definitely be dragons there | 01:17 |
| hatch | I have some ideas to clean it up but we aren't done adding features yet to know what we really need :) | 01:17 |
| hatch | agile-yo | 01:17 |
| hatch | huwshimi if you'd like to create a card and assign it to me I can do/start it tomorrow | 01:18 |
| huwshimi | hatch: Great, will do! | 01:19 |
| hatch | and if you have some downtime today you could review my latest PR :) https://github.com/juju/juju-gui/pull/463 | 01:19 |
| hatch | tradezies | 01:19 |
| huwshimi | hatch: I'll take a look | 01:20 |
| hatch | thanks | 02:03 |
| === uru_ is now known as urulama | ||
| urulama | morning all | 06:16 |
| rogpeppe1 | urulama: hiya | 07:42 |
| urulama | rogpeppe1: morning | 07:42 |
| rogpeppe1 | urulama: here's a fairly trivial follow up to yesterday's PR, addressing frankban's comments: https://github.com/juju/charmstore/pull/43/files | 07:43 |
| urulama | commenting the fieldinclude code? | 07:43 |
| rogpeppe1 | urulama: i didn't do very well there, in fact. | 07:44 |
| urulama | rogpeppe1: those todo's about "return nil, err" ... did you find any conclusion yesterday? | 07:48 |
| rogpeppe1 | urulama: i'm just working on the spec about that actually | 07:48 |
| urulama | rogpeppe1: excellent | 07:48 |
| rogpeppe1 | urulama: my current thoughts are these: | 07:48 |
| rogpeppe1 | urulama: any metadata that's not found will be defined to return null. In a single request, if null would be returned, a 404 "data not found" error is returned instead. | 07:49 |
| rogpeppe1 | urulama: in a bulk request, null entries are omitted from the returned map. | 07:50 |
| urulama | rogpeppe1: without indication about error? | 07:50 |
| urulama | rogpeppe1: what about these: return nil, fmt.Errorf("unrecognized metadata name %q", include) | 07:50 |
| urulama | when handlers are not found | 07:50 |
| rogpeppe1 | urulama: that's considered a genuine error | 07:50 |
| rogpeppe1 | urulama: and will return an actual error accordingly | 07:51 |
| rogpeppe1 | urulama: the most significant change that implies to the current semantics is that if you ask for charm-actions and the charm has none, you'll get a 404 rather than null. | 07:51 |
| rogpeppe1 | urulama: i think that's kinda reasonable though | 07:52 |
| rogpeppe1 | urulama: what do you think? | 07:52 |
| urulama | rogpeppe1: what if in that case {} is returned? | 07:52 |
| urulama | rogpeppe1: what happens if you want charm-actions on bundle? | 07:54 |
| rogpeppe1 | urulama: if you want charm-actions on bundle, you'd get null too | 07:54 |
| rogpeppe1 | urulama: i *think* i'd prefer null rather than the empty object | 07:55 |
| rogpeppe1 | urulama: that way it's totally trivial for people to decide whether there's some data or not | 07:55 |
| rogpeppe1 | urulama: and in a way, there *are* no charm actions, so 404 is actually appropriate | 07:56 |
| urulama | ok, so new semantics would be: return object if exists, return 404 if request is correct but object has no data and return nil if error occurs? | 07:59 |
| rogpeppe1 | urulama: the last isn't quite right - we'd return an error if an error occurs | 08:01 |
| rogpeppe1 | urulama: but otherwise that's right | 08:01 |
| urulama | rogpeppe1: ? return nil, fmt.Errorf("unrecognized metadata name %q", include) | 08:02 |
| rogpeppe1 | urulama: that's returning an error | 08:02 |
| rogpeppe1 | urulama: (the nil is ignored if the error is set) | 08:02 |
| urulama | and in bulk, they are just left out from the results, no messages | 08:06 |
| rogpeppe1 | urulama: yes | 08:15 |
| urulama | ok, just that we add this to the Charmstore api doc | 08:16 |
| rogpeppe1 | urulama: i've added a paragraph to the doc. how does that look to you? | 08:22 |
| urulama | rogpeppe1: i was just typing that i'm adding Entity struct to the Charm store API doc and i can add errors as well ... will look | 08:23 |
| rogpeppe1 | urulama: what's the Entity struct? | 08:23 |
| urulama | doc.go | 08:23 |
| rogpeppe1 | urulama: you mean mongodoc.Entity? | 08:23 |
| urulama | yes | 08:23 |
| rogpeppe1 | urulama: i think that's an implementation detail and as such doesn't really belong in that document | 08:24 |
| rogpeppe1 | urulama: (unless we add an "implementation" section) | 08:24 |
| urulama | rogpeppe1: exactly, implementation details | 08:24 |
| rogpeppe1 | urulama: i *think* i'd prefer an entirely separate document to talk about implementation details | 08:24 |
| rogpeppe1 | urulama: the API doc is already quite long, and it's well scoped. | 08:25 |
| urulama | rogpeppe1: ok, makes sense | 08:25 |
| rogpeppe1 | urulama: cool | 08:25 |
| rogpeppe1 | urulama: do we actually need an implementation document? i'd have thought that comments in the code might be better (and more likely to be updated when the implementation changes) | 08:26 |
| urulama | rogpeppe1: maybe not implementation details but data handling doc ... i like it when it's documented which collections have what type of data ... more of a registry | 08:28 |
| rogpeppe1 | urulama: i agree that it's great to have that stuff documented, but i think i'd prefer to document it in the code, so that anyone that reads the code will see it | 08:29 |
| rogpeppe1 | urulama: the mongodoc package seems like a potentially good place to add all those details | 08:29 |
| urulama | rogpeppe1: that'll work too | 08:30 |
| rogpeppe1 | urulama: perhaps add a package-level comment in mongodoc? | 08:30 |
| rogpeppe1 | urulama: or... | 08:30 |
| rogpeppe1 | urulama: maybe a comment on Entity itself - we will in general have a single mongodoc type for each collection | 08:31 |
| urulama | rogpeppe1: made a small task for latter, there's no hurry, just that we don't forget | 08:34 |
| rogpeppe1 | urulama: cool, thanks | 08:34 |
| urulama | rogpeppe1: i've merged your versions and recoded charm actions ... do I create new PR and close #40? | 09:12 |
| urulama | rogpeppe1: sorry, it seems as it is still #40 | 09:12 |
| rogpeppe1 | urulama: it's up to you | 09:13 |
| rogpeppe1 | urulama: that's fine | 09:13 |
| urulama | rogpeppe1: then pleas give a quick look at https://github.com/juju/charmstore/pull/40 | 09:14 |
| rogpeppe1 | urulama: looking | 09:14 |
| rogpeppe1 | urulama: LGTM | 09:15 |
| urulama | rogpeppe1: tnx, i'll wait for Jay to make a review as well (due to the 2people/review policy) | 09:15 |
| rogpeppe1 | urulama: ... or frankban, i guess | 09:16 |
| urulama | rogpeppe1: we agreed that you and frankban are the final reviewer, paired with go "n000bs", so that we learn as much as possible | 09:16 |
| urulama | s/reviewer/reviewers | 09:17 |
| rogpeppe1 | urulama: ok. i hope that won't impair velocity too much, given the time zone difference | 09:17 |
| urulama | rogpeppe1: for mornings before US people arrive, it'll be us three, right ... i'll make the merge | 09:19 |
| rogpeppe1 | urulama: sgtm | 09:19 |
| frankban | urulama: that's right. Jay or Brad, or JC I guess. anyway, you have my LGTM off the records ;-) | 09:19 |
| urulama | i'll add a comment that dummy charm has actions in the charm.v2 repo implementation, just to make clear | 09:21 |
| rogpeppe1 | urulama, frankban: this PR implements the not-found-omitted logic as recently specified in the charm API doc: https://github.com/juju/charmstore/pull/44 | 10:06 |
| urulama | rogpeppe1: need to have a lunch now ... | 10:08 |
| urulama | (as we still have "stable" electricity ... strange weather) | 10:09 |
| frankban | rogpeppe1: done | 10:25 |
| rogpeppe1 | frankban: thanks | 10:25 |
| * frankban bbiab | 10:25 | |
| rogpeppe1 | jrwren: any chance you could have a look at https://github.com/juju/charmstore/pull/44 please? | 10:27 |
| rick_h__ | morning | 10:28 |
| rick_h__ | rogpeppe1: he should be on in another 2hr | 10:29 |
| rogpeppe1 | rick_h__: ok. | 10:29 |
| rick_h__ | urulama: heads up, I added the 'changes' call to the api doc as well. | 10:31 |
| rick_h__ | urulama: but didn't yet create a card for it and it's a bit undefined. I wanted to get other's opinions on if we could provide info on 'what' changed and such | 10:32 |
| rick_h__ | since you mention doc/spec editing | 10:32 |
| urulama | rogpeppe1: looking at #44 | 10:54 |
| rogpeppe1 | urulama: thanks | 10:54 |
| urulama | rogpeppe1, rick_h__ ... if interested, yesterday i was playing around with the idea of "juju for home automation" and made a quick demo with smart lights. video here http://goo.gl/fh5rb2 | 10:58 |
| * rogpeppe1 downloads | 10:58 | |
| rogpeppe1 | urulama: it's upsidedown for me | 10:59 |
| urulama | argh | 10:59 |
| rogpeppe1 | urulama: cool though | 11:00 |
| rogpeppe1 | urulama: is that deployed locally? | 11:00 |
| urulama | rogpeppe1: yes, it works on local net only | 11:01 |
| rick_h__ | urulama: cool, yea saw you and hatch talking about it last night. Juju fun time :) | 11:02 |
| urulama | rick_h__: yes. had to get it out of my system :D | 11:03 |
| urulama | rick_h__: there are some storms here and if i just disappear it's either net or electricity problems ... i moved to a house with a generator, however, better to let you know | 11:04 |
| rick_h__ | urulama: understood | 11:05 |
| rick_h__ | thanks for the heads up | 11:05 |
| urulama | rogpeppe1: i like it how you've linked it to the doc | 11:07 |
| rogpeppe1 | urulama: cool | 11:07 |
| urulama | rogpeppe1: the error handling that is | 11:07 |
| urulama | rick_h__: thanks for changes call ... it looks like a general call, what about if we add bulk id handling to it as well? maybe people will be interested only in changes of few charms and bundles | 11:09 |
| urulama | rogpeppe1: maybe a comment about nilHandler how it is used to simulate returned nil values by "real" handlers? | 11:21 |
| urulama | rogpeppe1: or is it too obvious? | 11:21 |
| rogpeppe1 | urulama: i think it should be obvious enough | 11:21 |
| rogpeppe1 | urulama: in a subsequent branch i have actually deleted it | 11:21 |
| rogpeppe1 | urulama: and replaced it with constMetaHandler | 11:21 |
| urulama | :) | 11:22 |
| rick_h__ | urulama: yep, open for debate/discussion there | 11:29 |
| rogpeppe1 | urulama, frankban: next up, the API test refactoring: https://github.com/juju/charmstore/pull/45 | 12:07 |
| urulama | rogpeppe1: in a sec, writing /changes api proposal | 12:07 |
| rogpeppe1 | urulama: np | 12:07 |
| rogpeppe1 | urulama: /changes ? | 12:08 |
| rick_h__ | rogpeppe1: do we have cards for each of these? I know there's a few reviews going on but nothing in review/kanban | 12:08 |
| urulama | api test refactoring is on kandban | 12:09 |
| urulama | rogpeppe1: https://docs.google.com/a/canonical.com/document/d/1TgRA7jW_mmXoKH3JiwBbtPvQu7WiM6XMrz1wSrhTMXw/edit#bookmark=id.i81dlcr3spp9 | 12:09 |
| rogpeppe1 | rick_h__: i added one card after the fact | 12:09 |
| rogpeppe1 | rick_h__: the most recent one has a card already | 12:09 |
| rick_h__ | rogpeppe1: the one you're waiting for jrwren to review? | 12:09 |
| rogpeppe1 | rick_h__: we made a unilateral decision that delaying all branches for hours because of the time zone difference was not really a good thing | 12:11 |
| rogpeppe1 | rick_h__: so merged after just +1s from frankban and urulama | 12:11 |
| urulama | rick_h__: #44 is already merged, frankban and i reviewed it ... the card is in landing | 12:11 |
| rick_h__ | rogpeppe1: urulama ok, we should chat then on methods to help bootstrap the less experienced devs without that then | 12:11 |
| rick_h__ | as I fear it'll leave a lot of code just landing before they get a chance to learn form it and be gone | 12:11 |
| rogpeppe1 | rick_h__: it's fine when everyone is online | 12:12 |
| urulama | hangouts? | 12:12 |
| rick_h__ | the whole goal of spec'ing out a one month trial is to accept some pain for a limited time for the greater good | 12:12 |
| rick_h__ | urulama: I'm open for discussion, however monday we agreed to do this. Changing it up on the fly one day without discussion is disappointing from my POV | 12:12 |
| rogpeppe1 | rick_h__: but because github doesn't do prereq branches, it will really affect velocity badly if we can only merge when everyone's online | 12:12 |
| rogpeppe1 | rick_h__: i thought it was ok with two reviews in fact | 12:13 |
| rogpeppe1 | rick_h__: do we need reviews from all the new guys? | 12:13 |
| rick_h__ | rogpeppe1: right, I understand the pain point. | 12:13 |
| rick_h__ | rogpeppe1: we've got matt, brad, jay all need to get up to speed from more senior go folks. They're all in US TZ and I know tha sucks, but if the branches are going up for review and landing before they see them it's not going to help them much. | 12:14 |
| rogpeppe1 | rick_h__: so what's the actual policy here on when i can land a branch? | 12:14 |
| rick_h__ | rogpeppe1: the policy is 2 reviews with a goal of trying to get a less experienced dev into one of those review | 12:15 |
| rogpeppe1 | rick_h__: does urulama count as less experienced? | 12:15 |
| rick_h__ | rogpeppe1: I understand not all will be possible, however I want to make sure it's the goal we're working towards and not only doing when 100% convienent | 12:15 |
| rogpeppe1 | rick_h__: i thought he did, hence i thought it was ok | 12:15 |
| rick_h__ | rogpeppe1: yes, sure. | 12:15 |
| rogpeppe1 | rick_h__: ok, so all's good then, right? | 12:15 |
| rick_h__ | rogpeppe1: but your statement "we made a unilateral decision that delaying all branches for hours because of the time zone difference was not really a good thing" is what I'm speaking to | 12:16 |
| rogpeppe1 | rick_h__: ah, ok. that's actually not been the case. | 12:16 |
| rick_h__ | because 'unilateral' and 'not really a good thing' I'm not excited about here | 12:16 |
| rogpeppe1 | rick_h__: i would have liked to have roped jrwren in on the reviews too | 12:16 |
| rick_h__ | understand, you had a branch and got two reviews. That specific case is fine | 12:16 |
| rogpeppe1 | rick_h__: the "decided not to delay" remark was about that | 12:17 |
| rick_h__ | rogpeppe1: ok, as long as we're speaking to the single branch and not in general | 12:17 |
| rick_h__ | rogpeppe1: your comment seemed to imply a more broad policy shift | 12:17 |
| rogpeppe1 | rick_h__: i would have an issue if there were no new folks in roughly my time zone. i think it's important that we can land some branches before early afternoon. | 12:19 |
| rick_h__ | rogpeppe1: I agree and why it's nice having serveral folks in your timezone. However, if your next chunk of work is not immediately dependent on the previous branch, waiting a few hours on those to aid new devs would be ideal | 12:20 |
| rogpeppe1 | rick_h__: sure. | 12:20 |
| urulama | rick_h__: i think that if it's early in the morning here for us, we should handle it, however, point it out to others, that these PRs have been reviewed (so that everyone is up to date - that's what i do first thing in the morning for example) and for our afternoon PRs, the policy from Monday holds as agreed. there might be some exceptions to the rule if two branches are really dependant on each other as one break the other | 12:20 |
| urulama | (as rogers API change and mine charms actions) | 12:20 |
| rick_h__ | rogpeppe1: and in that statement I'm ack'ing that if the next chunk of work is immediatly dependent that getting frankban and urulama as 2 reviews is peachy | 12:20 |
| rick_h__ | urulama: agreed | 12:21 |
| rick_h__ | I just want to all agree that " we made a unilateral decision that delaying all branches for hours because of the time zone difference was not really a good thing" is not in the spirit of our goal this month | 12:21 |
| rogpeppe1 | rick_h__: i agree with that | 12:21 |
| rick_h__ | ok, aplogies for the confusion | 12:22 |
| rick_h__ | bah, apologies | 12:22 |
| rogpeppe1 | rick_h__: although perhaps all new devs should try to look through (and comment on) all recent PRs, even if they have been merged before they looked. | 12:22 |
| rick_h__ | rogpeppe1: +1, and we'll do that. There's always a bit of a blocker on commenting on landing code as we chatted about in London. | 12:23 |
| rick_h__ | but completely valid | 12:23 |
| rogpeppe1 | rick_h__: i'm not sure i remember that chat. is there an issue with commenting on code that's landing? | 12:23 |
| rick_h__ | rogpeppe1: ah sorry, other way around. I had that chat with someone else around your post-landed reviews. :) | 12:24 |
| rogpeppe1 | rick_h__: if i comment on something that's already landed, i'd hope that the remarks were taken into account in a subsequent PR (or replied to in place) | 12:25 |
| rick_h__ | rogpeppe1: yes, I defended the practice | 12:25 |
| rogpeppe1 | rick_h__: thanks :-) | 12:25 |
| rick_h__ | rogpeppe1: just ack'ing that for some folks it's more difficult as there's a feel of 'this is already ok'd and in the codebase' | 12:25 |
| rick_h__ | rogpeppe1: so making that the primary source of getting newer devs involved is less than ideal | 12:26 |
| rick_h__ | there's less 'communication' around those ime | 12:26 |
| rogpeppe1 | rick_h__: sure, review before landing is definitely better | 12:27 |
| rick_h__ | ok, <3 we're all happy agree'rs carry on kind sir. | 12:27 |
| rick_h__ | and thanks for clarifying my mis-understanding of the board by noting the stuff I was looking for is landed. | 12:28 |
| BradCrittenden | rick_h__: you merged frankban's test-test branch on purpose, right? caused me a little panic when i saw it had landed. | 12:32 |
| rick_h__ | BradCrittenden: yes, it seemed legit enough to add a year and harmless | 12:32 |
| BradCrittenden | rick_h__: ok, great | 12:33 |
| urulama | rogpeppe1: and we do not return strings (as another nil type)? | 12:33 |
| rogpeppe1 | urulama: strings cannot be nil | 12:33 |
| BradCrittenden | dang, someone has stolen my nick. must figure out how to get it back. | 12:34 |
| === rogpeppe1 is now known as rogpeppe | ||
| urulama | rogpeppe: indeed. that's nice :) | 12:34 |
| urulama | removing the comment | 12:34 |
| === BradCrittenden is now known as bac_ | ||
| === bac_ is now known as bac | ||
| * bac \o/. take that ben a carson | 12:39 | |
| rick_h__ | lol | 12:39 |
| rogpeppe | bac: how did you get it back? | 12:40 |
| jrwren | rick_h__: i took a look at https://github.com/juju/charmstore/pull/44 even though it landed. consider this less experienced go dev bootstrapped anyway :) | 12:40 |
| rick_h__ | jrwren: woot woot | 12:40 |
| bac | rogpeppe: /msg NickServ RELEASE yournick yourpassword | 12:40 |
| bac | rogpeppe: but you must have it registered | 12:41 |
| rogpeppe | bac: ah, so he hadn't hacked your password, just taken the username when you weren't logged in | 12:41 |
| bac | rogpeppe: yeah | 12:41 |
| bac | my client dropped last night | 12:41 |
| jrwren | I also tend to git/bzr log -p pretty much every checkout I checkout with git, as to see where the most recent activity is. | 12:42 |
| rick_h__ | jrwren: cool, yea just trying to look out for the new folks. The more effort put in the better for sure. | 12:43 |
| rick_h__ | and we want to make it as easy as we can | 12:43 |
| bac | rogpeppe: i'm looking at your pull request to see if i can get jenkins to kick off. (again). don't be alarmed. | 12:44 |
| rogpeppe | bac: ok. jenkins seemed to work ok earlier, FWIW | 12:45 |
| rogpeppe | q | 12:45 |
| bac | rogpeppe: yeah, but when it adds the 'please test this' message it indicates it is unhappy | 12:45 |
| bac | rogpeppe: so far i don't understand why it does that | 12:46 |
| rogpeppe | bac: ah. i wondered what the significance of that was. | 12:46 |
| urulama | rogpeppe: aaa, i see now what happened to nilMetaHandler :D | 12:46 |
| rogpeppe | urulama: :-) | 12:46 |
| rogpeppe | rick_h__: what column should i put branches that i've completed the coding on, but can't submit for review because of other outstanding unlanded prereqs? | 12:59 |
| urulama | rogpeppe: probably in review | 12:59 |
| rick_h__ | rogpeppe: hmm, I'd put them in review and mark them blocked | 13:00 |
| rogpeppe | rick_h__: ok, cool, will do | 13:00 |
| rick_h__ | rogpeppe: is there something we did to get into that pickle we need to address? | 13:00 |
| rogpeppe | rick_h__: not really - just that since github doesn't do prereqs, it's not possible to have two reviews outstanding if one is branched from another | 13:01 |
| rick_h__ | rogpeppe: ok, yea then review/blocked I'd suggest. It notes the coding is done and we're trying to get it reviewed | 13:01 |
| rogpeppe | rick_h__: sgtm. done. | 13:01 |
| bac | rogpeppe: as an experiment would you add the comment "ok to test" to your PR please? | 13:05 |
| rogpeppe | bac: which PR? | 13:05 |
| bac | https://github.com/juju/charmstore/pull/45 | 13:05 |
| urulama | rogpeppe: i like how new api tests show which charms (bundles in future) we are using for tests and which calls are being made. actual testing code gets a bit more hidden than before, but still clear enough. like it | 13:07 |
| rogpeppe | urulama: cool | 13:07 |
| rogpeppe | urulama: it should make it trivial to add new metadata tests too without trying to remember all the contexts that the metadata can be returned in | 13:08 |
| rogpeppe | bac: done | 13:09 |
| bac | ty | 13:09 |
| rogpeppe | jrwren: would you be able to take a look at the above branch, please? | 13:09 |
| rogpeppe | frankban: too | 13:09 |
| frankban | rogpeppe: on it | 13:10 |
| rogpeppe | frankban: ta! | 13:10 |
| urulama | rogpeppe: hope you don't have any plans to refactore these in near future :D | 13:11 |
| rogpeppe | urulama: not currently :) | 13:12 |
| jrwren | rogpeppe: looking at it now | 13:14 |
| rogpeppe | jrwren: thanks | 13:14 |
| urulama | rogpeppe: this errgo? https://github.com/jsimnz/errgo | 13:14 |
| rogpeppe | urulama: no, github.com/juju/errgo | 13:15 |
| urulama | rogpeppe: uu, nice | 13:15 |
| urulama | rogpeppe: we should always use it probably | 13:16 |
| rogpeppe | urulama: yeah. | 13:16 |
| rogpeppe | urulama: my branch changes the whole code base to use it | 13:17 |
| urulama | rogpeppe: whole charmstore? | 13:17 |
| rogpeppe | urulama: yeah | 13:17 |
| urulama | rogpeppe: that'll be fun to review :) | 13:17 |
| rogpeppe | urulama: i have a tool to make the changes automatically | 13:17 |
| rogpeppe | urulama: so it only took a few minutes to do it | 13:18 |
| === alexpilotti_ is now known as alexpilotti | ||
| frankban | rogpeppe: done | 13:31 |
| rogpeppe | frankban: ta | 13:32 |
| frankban | guihelp are those cards in landing effectively landing? I just shipit before looking at the board and then I realized there is no space available | 13:39 |
| rick_h__ | rogpeppe: urulama your branches have landed correct? | 13:40 |
| rogpeppe | rick_h__: not yet | 13:40 |
| rick_h__ | frankban: upping the total by one due to team size increase for the moment | 13:40 |
| rick_h__ | frankban: and looking into the cards. | 13:40 |
| frankban | rick_h__: thanks | 13:40 |
| rogpeppe | rick_h__: i need to add some more tests after frankban's review | 13:41 |
| rick_h__ | rogpeppe: ok, so the card should be back in review vs landing | 13:41 |
| rogpeppe | rick_h__: oh, those branches | 13:41 |
| rogpeppe | rick_h__: yes, those have landed | 13:41 |
| rick_h__ | ok, yea I thought they had | 13:42 |
| frankban | rogpeppe: store: isn't efficient getter for router landed? | 13:42 |
| rogpeppe | rick_h__: i moved the card | 13:42 |
| rogpeppe | s | 13:42 |
| rick_h__ | ty | 13:42 |
| frankban | oh ok | 13:42 |
| frankban | rick_h__: any suggestion for my next card? | 13:42 |
| rick_h__ | frankban: looking | 13:42 |
| rick_h__ | frankban: I'd love to have you and hatch looking at the deleted/removed work | 13:43 |
| rick_h__ | frankban: huw sent an email to the list about it on Monday night around trying to do the UI for it, but we don't keep the removed 'ghosts' around | 13:43 |
| rick_h__ | frankban: hatch should be in soon and maybe we should do a quick call to sync up on it, but you can start to peek at the issue? | 13:44 |
| frankban | rick_h__: sure, looking at the email | 13:44 |
| rick_h__ | frankban: and https://pastebin.canonical.com/114475/ is the irc convo from last night | 13:44 |
| frankban | rick_h__: so, UI needs to knwo when a real machine/container has been marked for removal, right? | 13:49 |
| frankban | know even | 13:49 |
| rick_h__ | frankban: rgr, so that we can show the user that it's an uncommitted change | 13:50 |
| rick_h__ | we have a UX for remove unit, but not container/machine/relation | 13:50 |
| rick_h__ | so this is to help enable that work | 13:50 |
| frankban | rick_h__: uhm, so a model attribute? Or am I missing something? | 13:55 |
| rick_h__ | frankban: that's what I want to figure out. What people think is the best path forward. If we go a model route, then we need to make sure we don't remove the models from the db | 13:55 |
| rick_h__ | and update any code reading 'number of machines/etc' to be aware of the attribute | 13:55 |
| rick_h__ | or that we store them in another collection? Or something else? | 13:56 |
| rick_h__ | I just want to get more than hatch's brain on it and it might be interesting to implement given your other ECS work. | 13:56 |
| frankban | rick_h__: the more I think about the ecs stuff, the more I suspect a db based architecture (like the one we already have to maintain in parallel to the ecs records) is sufficient most of the times. In theory, we could resolve all the changes only inspecting the db. For the time being we also have the ecs machinery, but for new features most of the time it seems easy to me to just use the db to represent a state. config/constraints are different, and n | 14:00 |
| frankban | eed more love, but for something like a "toBeRemoved" attribute I guess we can just mutate the existing db records | 14:00 |
| frankban | rick_h__: but I also want to know what you/Jeff think | 14:01 |
| urulama | rick_h__: what to do with misc card which is in tracking and is done? Just delete it? | 14:09 |
| rick_h__ | urulama: put it in daily call | 14:11 |
| rick_h__ | urulama: and we'll note that it's done/etc to the team and no longer tracking | 14:11 |
| rick_h__ | urulama: and then it'll just go to releaseable/archive like normal | 14:11 |
| rick_h__ | frankban: +1 on the db myself, but yea want to have a chat. | 14:12 |
| rick_h__ | frankban: make sure we're not missing something better, and then we'll add the work to keep the db entries around, even in a remove where the models might normally be removed | 14:12 |
| frankban | rick_h__: cool | 14:13 |
| bac | rick_h__: did my email about expenses jibe with your understanding? if so, could you approve it? | 14:14 |
| rick_h__ | bac: yes, will definitely go through folks expenses today | 14:15 |
| rick_h__ | bac: sorry I missed the date on the original email. | 14:15 |
| rick_h__ | there's hatch | 14:21 |
| hatch | wasssuuuuuuuup | 14:21 |
| rick_h__ | hatch: when you get settled call on the ghost-removing items with ecs stuff? | 14:21 |
| hatch | yeah sure, just got breakfast on the stove.....say, 10mins? | 14:21 |
| rick_h__ | hatch: rgr | 14:22 |
| frankban | rick_h__: filed expenses and swap day | 14:28 |
| rick_h__ | frankban: ty for the heads up | 14:29 |
| rick_h__ | jujugui I've approved all expenses filed to date, jcsackett got your ec2 one as well I didn't know was there. | 14:29 |
| rick_h__ | oh and jcsackett is out today now that I look at HR heh | 14:31 |
| jcsackett | i am? | 14:31 |
| jcsackett | i shouldn't be. | 14:31 |
| rick_h__ | oh nvm | 14:31 |
| jcsackett | i just filed for a half day on friday. | 14:32 |
| rick_h__ | well it says 8/30 | 14:32 |
| rick_h__ | I have two things here | 14:32 |
| jcsackett | ... | 14:32 |
| * jcsackett opens hr connect, grumbling all the while. | 14:32 | |
| rick_h__ | ok, so half day on friday? | 14:32 |
| jcsackett | i have the one i just filed for friday, 8/1 | 14:32 |
| rick_h__ | bah, I ok'd two things but I can't find them now that I hit approve | 14:32 |
| jcsackett | and a swap day for 8/18 | 14:33 |
| jcsackett | (this being american dates, so it's probably the other way round in hr canonica) | 14:33 |
| jcsackett | mind you, i totally believe it's saying the wrong thing, as there are myriad things it's telling me that aren't true at the moment. :p | 14:34 |
| rick_h__ | I've got the 15th of aug | 14:34 |
| rick_h__ | and the 18th of aug | 14:34 |
| hatch | jcastro hey, I saw you upvoted a question on AU. I went to read the docs for his question and found them missing information on how to execute hook commands - is the hook commands api somewhere in these docs that I'm missing? | 14:35 |
| rick_h__ | are those both true? | 14:35 |
| jcsackett | rick_h__: those are both true--the 15th was filed a while ago. i was just listing the recent ones. | 14:35 |
| rick_h__ | jcsackett: ok, think we're all good then | 14:35 |
| jcsackett | hm. "awhile ago" might mean last week. my sense of time is a bit off. :p | 14:35 |
| jcsackett | rick_h__: cool. | 14:35 |
| rick_h__ | I think I've approved everything everyone ever ... ran out of ever's ... wanted approved :) | 14:36 |
| urulama | rick_h__: do expenses for "per diem" need to be added for each day? and if so, can lunch + dinner be just added as one entry? | 14:37 |
| jcastro | hatch, https://juju.ubuntu.com/docs/authors-relations-in-depth.html and the next page I think | 14:37 |
| rick_h__ | urulama: so since not every day has each I prefer split, but people do add them for each day. They do need to be listed | 14:38 |
| rick_h__ | for instance, team dinner night you need to not claim dinner | 14:38 |
| jcastro | hatch, I don't know if we have a list of things like getting the private and public address, I could have sworn we had one though | 14:38 |
| hatch | jcastro right but neither of those says 'run this in your hook script to access relation data' | 14:38 |
| jcastro | marcoceppi, ^^^ | 14:38 |
| jcastro | yeah | 14:38 |
| urulama | sure, but for other days, sould i write lunch+dinner or put two rows in? | 14:38 |
| urulama | rick_h__: ^ | 14:39 |
| marcoceppi | jcastro: I'll use the answer I make to the AU question to update the docs | 14:39 |
| jcastro | hah | 14:39 |
| rick_h__ | urulama: up to you. I prefer split, this goes to Mark so maybe he'll take the one row without issue. Do what you please. | 14:39 |
| hatch | marcoceppi :) thanks | 14:39 |
| jcastro | hatch, real time docs | 14:39 |
| hatch | marcoceppi maybe we need an 'api' section for these docs? | 14:39 |
| bac | rick_h__: i've updated some of the git plugins on jenkins. it requires a restart but the restart attempt is failing. you ever restart jenkins and is there a trick? | 14:39 |
| marcoceppi | hatch: we have that | 14:39 |
| rick_h__ | bac: no, not had issues restarting it. Just sudo service jenkins restart | 14:39 |
| bac | rick_h__: fails | 14:40 |
| rick_h__ | bac: or using the restart button in the UI | 14:40 |
| hatch | marcoceppi yeah? for hook commands? | 14:40 |
| marcoceppi | after you sacrifice the chicken, you'll be enlightened with it's location hatch | 14:40 |
| rick_h__ | bac: will have to check the jenkins logs and see what's up then | 14:40 |
| hatch | lol!! | 14:40 |
| jcastro | marcoceppi, didn't we write up the mysql charm like this? | 14:41 |
| jcastro | I could have sworn we had a page where we documented the mysql charm and then were like "for the other ones, just derive what you've learned here." | 14:41 |
| marcoceppi | when I have to run a grep on the md files, we're probably doing sometihng wrong | 14:41 |
| marcoceppi | jcastro: vanilla | 14:42 |
| marcoceppi | https://juju.ubuntu.com/docs/authors-charm-writing.html | 14:42 |
| marcoceppi | oh | 14:42 |
| marcoceppi | and the mysql interface | 14:42 |
| hatch | marcoceppi haha | 14:42 |
| hatch | rick_h__ so did you want to have a chat? | 14:42 |
| marcoceppi | https://juju.ubuntu.com/docs/interface-mysql.html | 14:42 |
| rick_h__ | hatch: yes please | 14:42 |
| rick_h__ | hatch: standup? | 14:43 |
| jcastro | https://juju.ubuntu.com/docs/authors-charm-writing.html#writing-hooks | 14:43 |
| rick_h__ | frankban: ^ | 14:43 |
| hatch | yep joining | 14:43 |
| jcastro | hatch, scroll down on that page | 14:43 |
| hatch | jcastro I don't see a hook api? | 14:43 |
| frankban | rick_h__: joining | 14:43 |
| jcastro | I think we only have the one | 14:44 |
| marcoceppi | jcastro hatch it was documented sometime | 14:46 |
| marcoceppi | somewhere | 14:46 |
| rogpeppe | frankban, urulama, jrwren, bac: trivial PR for review: https://github.com/juju/charm/pull/29 | 14:48 |
| jrwren | trivial ones are EASY | 14:49 |
| urulama | rogpeppe: i liked this one :D | 14:54 |
| rogpeppe | urulama, jrwren: :-) | 14:54 |
| hatch | jujugui call in 1 | 14:59 |
| rick_h__ | jcsackett: antdillon kadams & | 15:01 |
| rick_h__ | jrwren: ^ | 15:01 |
| hatch | great answer marcoceppi | 15:08 |
| frankban | hatch: PR url? | 15:17 |
| hatch | https://github.com/juju/juju-gui/pull/463 | 15:17 |
| rick_h__ | frankban: so you're ok creating a card for the flag/helpers on models as the first step from here? | 15:18 |
| urulama | jrwren: sorry for putting such a card on, it was just a reminder not to forget this ... | 15:18 |
| frankban | rick_h__: +1 | 15:18 |
| jrwren | urulama: no no, its a good card. | 15:18 |
| rick_h__ | cool, thanks | 15:18 |
| bac | rick_h__: on jenkins are we actualy using GitHub Pull Request Builder Plugin | 15:18 |
| rick_h__ | bac: it does the initial test run | 15:18 |
| bac | rick_h__: i don't see it in the UI under plugins | 15:19 |
| rick_h__ | bac: so the non -merge jobs are that plugin I thought | 15:19 |
| rick_h__ | oh...then...huh? | 15:19 |
| bac | but there is an error message that is coming from it. so i'm confused | 15:19 |
| jrwren | urulama: it should be trivial, but then its not once we look at certain features. | 15:19 |
| rick_h__ | bac: so maybe it's not in the UI because it's not loading properly? | 15:19 |
| urulama | jrwren: need help splitting it in smaller tasks? otherwise feel free to do as rick_h__ suggested. | 15:19 |
| urulama | jrwren: which ones? | 15:20 |
| urulama | jrwren: i meant which features? | 15:20 |
| bac | rick_h__: there are several different github plugins and i'm not sure which are active | 15:20 |
| jrwren | urulama: version config and mojo. | 15:20 |
| rick_h__ | so some require others to work if I recall | 15:20 |
| rick_h__ | bac: ^ | 15:20 |
| rick_h__ | bac: can compare to the other insteance if that helps | 15:21 |
| rick_h__ | bac: can at least compare what it thinks is running and version check the two | 15:21 |
| jrwren | urulama: its deceptive because version config doesn't make sense at the moment IMO. Because v4 doesn't have a server. It probably will in a day or so. | 15:21 |
| rick_h__ | maybe see if we can downgrade it to match what's working there bac | 15:21 |
| jrwren | urulama: so really only v2 makes sense IMO. | 15:21 |
| bac | rick_h__: which other instance are you referring to? curtis'? | 15:21 |
| rick_h__ | jrwren: feel free to add the server as a pre-req to a chunk of your card | 15:21 |
| rick_h__ | bac: moving to other channel | 15:21 |
| jrwren | urulama: and mojo i'm still trying to grok its impact on the charm. | 15:22 |
| jrwren | urulama: seems like what rick_h__ said makes good sense - do it in increments, just charm it up, then add these features. | 15:22 |
| rick_h__ | jrwren: urulama so how about we start with basic framing, repo, initial files/readme/etc | 15:22 |
| rick_h__ | jrwren: urulama and then start to look at any pre-implementation chats for each, etc | 15:23 |
| urulama | rick_h__: yes. repo, skeleton, hooks, ... | 15:23 |
| rick_h__ | jrwren: urulama yep | 15:23 |
| rick_h__ | and we can work on iterating vs defining it all up front | 15:23 |
| rick_h__ | we know the big 'watch outs' as we go | 15:23 |
| jrwren | ok | 15:23 |
| rick_h__ | jrwren: so feel free to add cards or if you're not sure let me know and we can create them together | 15:24 |
| jrwren | rick_h__: i'll add some. | 15:24 |
| rick_h__ | jrwren: realizing that at any time, if your chunk of work spins off new threads/pre-req's it's always ok to put one card back in the todo lane and build new ones as things because clear | 15:24 |
| jrwren | rick_h__: urulama: is the focus here on the old version or new version or both? | 15:24 |
| rick_h__ | jrwren: new version only is the focus | 15:24 |
| urulama | jrwren: charmstor branch v4 | 15:25 |
| jrwren | urulama: rick_h__:in that case, I need a server :) | 15:25 |
| jrwren | urulama: rick_h__: i'll skeleton without for now. | 15:26 |
| urulama | jrwren: what about if you play with local for a start? | 15:26 |
| rick_h__ | jrwren: urulama the server is in the 'old' code and a branch to add it to v4 would be ok as a first pre-req? | 15:26 |
| jrwren | urulama: appserver. equivalent of charmstored, I think it is. | 15:26 |
| jrwren | err, charmd | 15:28 |
| rick_h__ | jrwren: the card for the server is at the top of the lane. | 15:28 |
| rick_h__ | jrwren: feel free to move the charm card back, take the start command card, and move that foward. | 15:28 |
| frankban | hatch: why you changed envSeries to be a callable? | 15:28 |
| rick_h__ | jrwren: we'll break down the charm work and then be all set | 15:28 |
| hatch | frankban because the envSeries isn't actually set until after the application is well-since loaded and operational | 15:28 |
| frankban | hatch: good, I suspected that, I'd suggest to add a comment explaining that | 15:29 |
| hatch | so it would then need to be set again everywhere in the app when that changes | 15:29 |
| hatch | ok can do | 15:29 |
| jrwren | rick_h__: ok | 15:29 |
| urulama | rick_h__, jujugui - I have to leave this plave as they are locking it down, hope internet at home is working already | 15:30 |
| urulama | s/plave/place | 15:30 |
| rogpeppe | urulama: ok | 15:30 |
| rick_h__ | urulama: best of luck | 15:30 |
| urulama | there's always mobile data :D | 15:31 |
| jrwren | rick_h__: alright, I made a few cards. You mentioned there was a specific place the charm repo should live? | 15:37 |
| jrwren | rick_h: https://github.com/CanonicalLtd ? | 15:38 |
| rick_h__ | jrwren: yes, taking to the other channel | 15:38 |
| hatch | rick_h__ if we are going to moveo to trusty being the default it should be done in a follow-up as it should be done whole hog throughout the app imho and there are a-lot of places where precise is being used :) | 15:39 |
| rick_h__ | hatch: understood | 15:39 |
| hatch | sounds like a plan? | 15:40 |
| rick_h__ | hatch: and yea, I'm smitted with my idea of making the charm set the default. If I install the gui precise charm, it'd default to precise, etc | 15:40 |
| rick_h__ | hatch: but yea, that's outside of this current work scope, so carry on | 15:40 |
| hatch | :) sounds good | 15:40 |
| rogpeppe | cfrankban: i've updated https://github.com/juju/charmstore/pull/45 to add some sanity checking for the metaEndpoint.get functions | 15:58 |
| rogpeppe | frankban: ^ | 15:58 |
| rogpeppe | and also updated the branch to use the gopkg.in/mgo.v2 (it was a hassle switching back and forth all the time) | 15:58 |
| rogpeppe | frankban: PTAL | 15:58 |
| frankban | rogpeppe: cool, I'll look in a minute | 15:59 |
| rick_h__ | what is PTAL? I keep seeing it but don't process it | 15:59 |
| frankban | rick_h__: I suppose it is "please take a look" | 16:02 |
| rick_h__ | ah! that makes sense | 16:03 |
| rogpeppe | rick_h__: actually, it's usually "please take another look" | 16:03 |
| rogpeppe | rick_h__: at least, that's the way i use it | 16:03 |
| frankban | heh | 16:03 |
| rick_h__ | gotcha | 16:04 |
| rick_h__ | that also makes sense | 16:04 |
| hatch | it's also a guys name | 16:06 |
| hatch | except there is an accent on the a | 16:07 |
| hatch | :) | 16:07 |
| frankban | hatch: review done | 16:08 |
| hatch | frankban thanks for the qa, I'll have to look into that issue | 16:08 |
| hatch | it's very puzzling | 16:08 |
| hatch | frankban ahh I see the issue | 16:10 |
| hatch | bundles get returned in the autocomplete as well | 16:10 |
| hatch | rick_h__ are we to show bundles in the autocomplete result set or just charms? | 16:11 |
| hatch | they are shown atm | 16:11 |
| bac | jenkins is now properly testing new pull requests for charmstore, e.g. http://ci.jujugui.org:8080/job/charmstore/33/ | 16:12 |
| frankban | bac: \o/ | 16:13 |
| rogpeppe | rick_h__: nothing can land on juju-core because it's blocked by critical bugs | 16:13 |
| frankban | rogpeppe: lgtm | 16:14 |
| rogpeppe | frankban: thanks | 16:14 |
| rogpeppe | rick_h__: so despite having go ahead to merge that branch, i cannot... | 16:14 |
| hatch | frankban branch has been updated with a fix - mind qa'ing again? | 16:14 |
| frankban | hatch: sure | 16:14 |
| rick_h__ | rogpeppe: yea, their new policy. mark the card as blocked please | 16:15 |
| hatch | thanks | 16:15 |
| frankban | hatch: where can I see the code change? | 16:15 |
| hatch | in the PR there is a commits tab | 16:15 |
| hatch | it's the last commit | 16:15 |
| frankban | hatch: ok | 16:17 |
| hatch | frankban with our new review rules we have decided to not squash the commits until after the reviews are done and the branch is ready to land | 16:17 |
| hatch | should help with reviewing and whatnot | 16:17 |
| rick_h__ | hatch: yes, bundles and charms | 16:17 |
| rick_h__ | bac: woot | 16:18 |
| frankban | hatch: yes, I really appreciate the ability to just see what's changed after a review | 16:18 |
| rick_h__ | and rogpeppe :( sad but they needed to do that as core needs to get some unbroken love time. | 16:18 |
| rogpeppe | rick_h__: yeah, i think it's probably a good thing too | 16:18 |
| bac | rick_h__: after lunch i'd like to fix the issue i opened against jenkins-github-lander. it is a timebomb waiting for anyone using that tool. | 16:18 |
| rogpeppe | rick_h__: but will probably cost another hour or two of bitrottedness updating | 16:19 |
| rick_h__ | bac: sounds like a plan. | 16:19 |
| bac | ty | 16:19 |
| * bac lunches | 16:19 | |
| rick_h__ | rogpeppe: understood, can't be helped. Thanks for the heads up | 16:19 |
| rick_h__ | urulama: ^ | 16:19 |
| * rick_h__ goes to get food | 16:20 | |
| hatch | frankban when a relation gets created in topology/relation.js it sets a 'pending' attribute to true just FYI https://github.com/juju/juju-gui/blob/develop/app%2Fviews%2Ftopology%2Frelation.js#L967 | 16:25 |
| frankban | hatch: so a ghost relation is called pending. I'd propose to use the isGhost attribute everywhere. Pending is a different concept, already in use in juju with a different meaning. | 16:28 |
| frankban | hatch: isGhost and isRemoved | 16:29 |
| hatch | frankban that's fine - I just wanted to point that out to you as it'll need to be renamed and the corresponding stuff which checks for it renamed as well | 16:29 |
| frankban | hatch: yeah, ack | 16:29 |
| rogpeppe | frankban, urulama, bac, jrwren: here's a branch to make us create more informative errors in the charm store: https://github.com/juju/charmstore/pull/47 | 16:32 |
| rogpeppe | it's also a prereq for generating sensible HTTP status codes | 16:32 |
| frankban | rogpeppe: oh, the errgogeddon, on it | 16:33 |
| rogpeppe | frankban: lol | 16:33 |
| rogpeppe | frankban: thanks | 16:33 |
| jrwren | why is this better? | 16:33 |
| jrwren | ah, location updates by Mask. That is nice. | 16:36 |
| frankban | hatch: local env is keeping ages to switch the gui to your branch :-/ It used to be faster... | 16:42 |
| hatch | :( | 16:42 |
| frankban | hatch: it seems blocked on "Retrieving Juju GUI source checkout from https://github.com/hatched/juju-gui.git (ac-result-sort-1348290)" | 16:43 |
| hatch | that's odd, did you try switching it back to 'local' then to my branch again? | 16:44 |
| urulama | now this was an hour well spent ... on the line with ISP and persuading the tech support that their routers have reveresed on factory settings during short electrical blackout ... he then realised he was checking my neighbour's router and not mine ... sheesh :D | 16:45 |
| frankban | hatch: in the local LXC I see this: http://pastebin.ubuntu.com/7906321/ | 16:46 |
| frankban | git, go home, you're drunk | 16:46 |
| hatch | heh weird | 16:47 |
| frankban | hatch: it made progress \o/ it just took half an hour to check out a branch :-/ | 16:50 |
| hatch | frankban that ocean is vast.....maybe it was using the message-in-a-bottle protocol :) | 16:51 |
| frankban | heh | 16:52 |
| rick_h__ | frankban: it takes a long long time | 16:54 |
| rick_h__ | frankban: when I did some QA stuff in london it took a good 10-20min | 16:54 |
| frankban | hatch: QA ok, even if maybe we should do that in four groups: 1) recommended + series, 2) just recommended, 3) just series, 4) all the others. E.g. now when I type wordpress I get the oneiric non-recommended one as first result, the precise recommended as second | 16:55 |
| hatch | hmm that is a good point | 16:56 |
| hatch | I'm working on my other card right now, can you add that to the PR and I'll do it as soon as I get this one up | 16:56 |
| frankban | hatch: done | 16:57 |
| hatch | thanks! and thanks for putting up with the grueling qa procedure :) | 16:57 |
| frankban | rick_h__: yeah, thanks for confirming | 16:57 |
| jrwren | urulama: glad to hear that service there is the same as here. | 16:57 |
| frankban | hatch: np | 16:58 |
| hatch | ooo charmworld just changed which charms are popular | 16:58 |
| hatch | now I have to search for mysql/wordpress lol | 16:58 |
| rick_h__ | hatch: huh? | 16:59 |
| rick_h__ | charmworld hasn't had a deploy in a couple of weeks, and that change was fixing ngram results in search | 16:59 |
| hatch | rick_h__ https://www.evernote.com/shard/s219/sh/8d9cbeaf-6d5d-45da-9216-2e77f1feec86/ede9a6fe24b279b7dda4c712bdebbc3b | 17:00 |
| hatch | it's no longer mysql and wordpress | 17:00 |
| rick_h__ | hatch: ah, you might be watching during an ingest | 17:00 |
| hatch | oh it's changing again | 17:00 |
| hatch | wth | 17:00 |
| rick_h__ | hatch: yea, ingest and such the index rebuilds | 17:01 |
| rick_h__ | hatch: it'll settle in a sec | 17:01 |
| hatch | wait, so it blows out the old one, rebuilds it live? | 17:01 |
| rick_h__ | hatch: and something we'll fix/make better in charmstore search | 17:01 |
| rick_h__ | :) | 17:01 |
| hatch | shouldn't it rebuild on the side then swap? | 17:01 |
| hatch | ohh ok :) | 17:01 |
| frankban | done for the day, rick_h__ see you later at the call, have a good night all | 17:01 |
| rick_h__ | frankban: thanks for attending | 17:01 |
| rick_h__ | have a good night | 17:01 |
| hatch | rick_h__ I guess as long as it's a known issue :) | 17:02 |
| rick_h__ | hatch: yep | 17:02 |
| hatch | well it can't even find mysql | 17:02 |
| hatch | I guess I'll wait | 17:02 |
| hatch | lol | 17:02 |
| hatch | https://github.com/facebook/immutable-js | 17:03 |
| hatch | in the mean time.... | 17:03 |
| marcoceppi | hello gui and friends | 17:14 |
| marcoceppi | charmworld issue | 17:14 |
| marcoceppi | http://manage.jujucharms.com/api/3/charm//trusty/ceilometer | 17:14 |
| marcoceppi | https://store.juju.ubuntu.com/charm-info?charms=ceilometer | 17:14 |
| marcoceppi | one of these things is not like the other | 17:14 |
| lazyPower | https://bugs.launchpad.net/charmworld/+bug/1350451 | 17:15 |
| _mup_ | Bug #1350451: Missing charm in charmworld-api - ceilometer <charmworld:New> <https://launchpad.net/bugs/1350451> | 17:15 |
| urulama | jrwren: there is a promise land far far away, where ISP do what they suppose to :D | 17:16 |
| * rogpeppe is done for the day | 17:20 | |
| rogpeppe | g'night all | 17:20 |
| urulama | rogpeppe: g'night, see you tomorrow | 17:31 |
| rick_h__ | Makyo: call or were you afk this afternoon? | 18:32 |
| rick_h__ | someone had a dr apt and now can't recall | 18:32 |
| Makyo | rick_h__, sorry, lost track of time, 1 sec | 18:32 |
| rick_h__ | np | 18:33 |
| * rick_h__ runs away for a little bit until my next meeting afk | 18:39 | |
| bac | jujugui: i want to 'git stash' a single file but that doesn't seem possible. is there another command to do it? equivalent of 'bzr shelve fn'? | 18:51 |
| hatch | bac git add the files | 18:52 |
| hatch | then git stash | 18:52 |
| hatch | file(s) | 18:52 |
| hatch | should work | 18:52 |
| hatch | sec lemme google | 18:52 |
| bac | hatch: oh, add the files i want to keep... | 18:52 |
| hatch | yeah http://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed | 18:53 |
| hatch | there ya go | 18:53 |
| hatch | it outlines it in more detail | 18:53 |
| bac | hatch: somewhat easier: git stash -p | 18:56 |
| bac | though it makes you pick each hunk | 18:56 |
| hatch | oh cool | 18:56 |
| hatch | thanks I didn't know abou that one | 18:56 |
| bac | hey hatch in github when using 'issues' is there a way to associate a branch with the issue? | 19:22 |
| bac | like in LP where you link the branch to the bug/s it fix/es | 19:22 |
| hatch | in a commit message you can | 19:22 |
| hatch | not sure about a branch though | 19:22 |
| hatch | would a commit message be good enough? the issue would then have a link to the commit in the branch | 19:23 |
| bac | hatch: i guess that is good enough. do i just say -m "Fixes issue 16"? | 19:23 |
| bac | i assume there is some special token it looks for | 19:23 |
| hatch | yeah there is a bunch of them | 19:23 |
| hatch | one sec | 19:23 |
| hatch | here is closing issues via commit messages https://help.github.com/articles/closing-issues-via-commit-messages | 19:24 |
| bac | cool, just found it | 19:24 |
| hatch | https://help.github.com/articles/writing-on-github#references | 19:24 |
| hatch | also ^ might be helpful | 19:24 |
| hatch | to link to branches | 19:24 |
| hatch | er repositories | 19:24 |
| bac | rick_h__: when you have a second to review : https://github.com/juju/jenkins-github-lander/pull/17 | 19:28 |
| Makyo | jujugui #1350505 | 19:32 |
| _mup_ | Bug #1350505: Relation inspector does not have actions attached properly <juju-gui:New> <https://launchpad.net/bugs/1350505> | 19:32 |
| hatch | Makyo thx - my branch does some stuff around there so I'll make sure it lands before work on that one start | 19:33 |
| hatch | s | 19:33 |
| Makyo | hatch, cheers, thanks | 19:33 |
| hatch | if I ever finish these tests | 19:58 |
| hatch | that is.... | 19:58 |
| hatch | guys r working on our power again I may drop offline in a bit | 20:14 |
| rick_h__ | bac: looking | 20:22 |
| === sebas53__ is now known as sebas5384_ | ||
| hatch | jujugui lf two reviews and a qa for https://github.com/juju/juju-gui/pull/465 | 21:01 |
| hatch | don't everyone jump on it at once :) | 21:09 |
| jrwren | if I knew anything about UI dev, I'd be all over it. | 21:17 |
| rick_h__ | BradCrittenden: got that crumpler bag, will be much nicer for the next trip me thinks. Though it's definitely not easy to get at. | 21:58 |
| rick_h__ | BradCrittenden: thanks for pointing that out in london | 21:59 |
| === BradCrittenden is now known as bac | ||
| bac | rick_h__: yes, i love mine | 22:14 |
| Makyo | jujugui #1350592 | 22:42 |
| _mup_ | Bug #1350592: Destroy machine/container has HTML in deployer bar summary <juju-gui:New> <https://launchpad.net/bugs/1350592> | 22:42 |
| hatch | jrwren it's like back-end dev but without all the nice tooling :P | 22:43 |
| hatch | Makyo https://bugs.launchpad.net/juju-gui/+bug/1337404 did you ever get any input from UX about what is supposed to happen here? And are you working on it any longer? | 22:47 |
| _mup_ | Bug #1337404: Long service names go under ghost indicator and break out of service icon <juju-gui:Triaged by makyo> <https://launchpad.net/bugs/1337404> | 22:47 |
| Makyo | hatch, never started. worked on Go vis instead. Guidelines from UX were truncate names with ellipses, have the indicator at the end whether or not truncated. | 22:49 |
| hatch | ok Ill update the bug thx | 22:49 |
| huwshimi | Morning | 23:02 |
| hatch | morning huwshimi | 23:19 |
| hatch | huwshimi did you see that your branches were reviewed ? | 23:19 |
| rick_h__ | morning huwshimi | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!