[00:43] huwshimi you had some questions you sent in the email yesterday [00:43] have you got those solved or do you still need a hand there? [00:45] 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] you can't, I'm not sure you can tell if anything has been deleted [00:45] units, services etc [00:45] hatch: Yeah... [00:46] 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] yeah [00:47] but with that said, that's how the units are done now [00:47] see environmnt-change-set.js line 691 [00:47] relations are done the same way [00:48] oh wait [00:48] no that's only removing the ghost stuff [00:48] hmm [00:50] I have to finish cooking supper [00:50] leave this with me and I'll get back to you when I'm done [00:51] hatch: OK, thanks! [00:52] Supper or dinner? [01:07] Makyo haha, supper [01:07] :P [01:07] huwshimi so unfortunately we have been pretty destry [01:07] destructive when dealing with removing of relations [01:07] and units so far [01:07] so we'll have to go back and fix that [01:07] hatch: Oh, so not going through ecs? [01:08] 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] because what happens if we remove a service then the user decides to 'cancel' the ecs changes [01:08] it needs to revert back as if nothing happened [01:08] we can't do that if the service is gone [01:08] but we need to signify it being gone in the canvas [01:10] 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] but then if that ever gets canceled it needs to go in and set it back [01:11] 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] yeah that's a good idea [01:11] hmm [01:12] huwshimi atm if you destroy a machine that's queued we just remove it from the db and it's gone [01:13] so there will be no UI for that, but for real machines we have nothing to signify it's destruction [01:13] huwshimi with that said you could pretty easily hack it into the ecs [01:14] if you wanted to just play with it [01:14] not sure if you want to tackle that task or if you want to push it off [01:16] 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:17] heh yeah there definitely be dragons there [01:17] I have some ideas to clean it up but we aren't done adding features yet to know what we really need :) [01:17] agile-yo [01:18] huwshimi if you'd like to create a card and assign it to me I can do/start it tomorrow [01:19] hatch: Great, will do! [01:19] and if you have some downtime today you could review my latest PR :) https://github.com/juju/juju-gui/pull/463 [01:19] tradezies [01:20] hatch: I'll take a look [02:03] thanks === uru_ is now known as urulama [06:16] morning all [07:42] urulama: hiya [07:42] rogpeppe1: morning [07:43] 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] commenting the fieldinclude code? [07:44] urulama: i didn't do very well there, in fact. [07:48] rogpeppe1: those todo's about "return nil, err" ... did you find any conclusion yesterday? [07:48] urulama: i'm just working on the spec about that actually [07:48] rogpeppe1: excellent [07:48] urulama: my current thoughts are these: [07:49] 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:50] urulama: in a bulk request, null entries are omitted from the returned map. [07:50] rogpeppe1: without indication about error? [07:50] rogpeppe1: what about these: return nil, fmt.Errorf("unrecognized metadata name %q", include) [07:50] when handlers are not found [07:50] urulama: that's considered a genuine error [07:51] urulama: and will return an actual error accordingly [07:51] 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:52] urulama: i think that's kinda reasonable though [07:52] urulama: what do you think? [07:52] rogpeppe1: what if in that case {} is returned? [07:54] rogpeppe1: what happens if you want charm-actions on bundle? [07:54] urulama: if you want charm-actions on bundle, you'd get null too [07:55] urulama: i *think* i'd prefer null rather than the empty object [07:55] urulama: that way it's totally trivial for people to decide whether there's some data or not [07:56] urulama: and in a way, there *are* no charm actions, so 404 is actually appropriate [07:59] 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? [08:01] urulama: the last isn't quite right - we'd return an error if an error occurs [08:01] urulama: but otherwise that's right [08:02] rogpeppe1: ? return nil, fmt.Errorf("unrecognized metadata name %q", include) [08:02] urulama: that's returning an error [08:02] urulama: (the nil is ignored if the error is set) [08:06] and in bulk, they are just left out from the results, no messages [08:15] urulama: yes [08:16] ok, just that we add this to the Charmstore api doc [08:22] urulama: i've added a paragraph to the doc. how does that look to you? [08:23] 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] urulama: what's the Entity struct? [08:23] doc.go [08:23] urulama: you mean mongodoc.Entity? [08:23] yes [08:24] urulama: i think that's an implementation detail and as such doesn't really belong in that document [08:24] urulama: (unless we add an "implementation" section) [08:24] rogpeppe1: exactly, implementation details [08:24] urulama: i *think* i'd prefer an entirely separate document to talk about implementation details [08:25] urulama: the API doc is already quite long, and it's well scoped. [08:25] rogpeppe1: ok, makes sense [08:25] urulama: cool [08:26] 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:28] 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:29] 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] urulama: the mongodoc package seems like a potentially good place to add all those details [08:30] rogpeppe1: that'll work too [08:30] urulama: perhaps add a package-level comment in mongodoc? [08:30] urulama: or... [08:31] urulama: maybe a comment on Entity itself - we will in general have a single mongodoc type for each collection [08:34] rogpeppe1: made a small task for latter, there's no hurry, just that we don't forget [08:34] urulama: cool, thanks [09:12] rogpeppe1: i've merged your versions and recoded charm actions ... do I create new PR and close #40? [09:12] rogpeppe1: sorry, it seems as it is still #40 [09:13] urulama: it's up to you [09:13] urulama: that's fine [09:14] rogpeppe1: then pleas give a quick look at https://github.com/juju/charmstore/pull/40 [09:14] urulama: looking [09:15] urulama: LGTM [09:15] rogpeppe1: tnx, i'll wait for Jay to make a review as well (due to the 2people/review policy) [09:16] urulama: ... or frankban, i guess [09:16] rogpeppe1: we agreed that you and frankban are the final reviewer, paired with go "n000bs", so that we learn as much as possible [09:17] s/reviewer/reviewers [09:17] urulama: ok. i hope that won't impair velocity too much, given the time zone difference [09:19] rogpeppe1: for mornings before US people arrive, it'll be us three, right ... i'll make the merge [09:19] urulama: sgtm [09:19] urulama: that's right. Jay or Brad, or JC I guess. anyway, you have my LGTM off the records ;-) [09:21] i'll add a comment that dummy charm has actions in the charm.v2 repo implementation, just to make clear [10:06] 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:08] rogpeppe1: need to have a lunch now ... [10:09] (as we still have "stable" electricity ... strange weather) [10:25] rogpeppe1: done [10:25] frankban: thanks [10:25] * frankban bbiab [10:27] jrwren: any chance you could have a look at https://github.com/juju/charmstore/pull/44 please? [10:28] morning [10:29] rogpeppe1: he should be on in another 2hr [10:29] rick_h__: ok. [10:31] urulama: heads up, I added the 'changes' call to the api doc as well. [10:32] 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] since you mention doc/spec editing [10:54] rogpeppe1: looking at #44 [10:54] urulama: thanks [10:58] 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:59] urulama: it's upsidedown for me [10:59] argh [11:00] urulama: cool though [11:00] urulama: is that deployed locally? [11:01] rogpeppe1: yes, it works on local net only [11:02] urulama: cool, yea saw you and hatch talking about it last night. Juju fun time :) [11:03] rick_h__: yes. had to get it out of my system :D [11:04] 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:05] urulama: understood [11:05] thanks for the heads up [11:07] rogpeppe1: i like it how you've linked it to the doc [11:07] urulama: cool [11:07] rogpeppe1: the error handling that is [11:09] 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:21] rogpeppe1: maybe a comment about nilHandler how it is used to simulate returned nil values by "real" handlers? [11:21] rogpeppe1: or is it too obvious? [11:21] urulama: i think it should be obvious enough [11:21] urulama: in a subsequent branch i have actually deleted it [11:21] urulama: and replaced it with constMetaHandler [11:22] :) [11:29] urulama: yep, open for debate/discussion there [12:07] urulama, frankban: next up, the API test refactoring: https://github.com/juju/charmstore/pull/45 [12:07] rogpeppe1: in a sec, writing /changes api proposal [12:07] urulama: np [12:08] urulama: /changes ? [12:08] rogpeppe1: do we have cards for each of these? I know there's a few reviews going on but nothing in review/kanban [12:09] api test refactoring is on kandban [12:09] rogpeppe1: https://docs.google.com/a/canonical.com/document/d/1TgRA7jW_mmXoKH3JiwBbtPvQu7WiM6XMrz1wSrhTMXw/edit#bookmark=id.i81dlcr3spp9 [12:09] rick_h__: i added one card after the fact [12:09] rick_h__: the most recent one has a card already [12:09] rogpeppe1: the one you're waiting for jrwren to review? [12:11] 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] rick_h__: so merged after just +1s from frankban and urulama [12:11] rick_h__: #44 is already merged, frankban and i reviewed it ... the card is in landing [12:11] rogpeppe1: urulama ok, we should chat then on methods to help bootstrap the less experienced devs without that then [12:11] 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:12] rick_h__: it's fine when everyone is online [12:12] hangouts? [12:12] 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] 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] 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:13] rick_h__: i thought it was ok with two reviews in fact [12:13] rick_h__: do we need reviews from all the new guys? [12:13] rogpeppe1: right, I understand the pain point. [12:14] 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] rick_h__: so what's the actual policy here on when i can land a branch? [12:15] rogpeppe1: the policy is 2 reviews with a goal of trying to get a less experienced dev into one of those review [12:15] rick_h__: does urulama count as less experienced? [12:15] 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] rick_h__: i thought he did, hence i thought it was ok [12:15] rogpeppe1: yes, sure. [12:15] rick_h__: ok, so all's good then, right? [12:16] 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] rick_h__: ah, ok. that's actually not been the case. [12:16] because 'unilateral' and 'not really a good thing' I'm not excited about here [12:16] rick_h__: i would have liked to have roped jrwren in on the reviews too [12:16] understand, you had a branch and got two reviews. That specific case is fine [12:17] rick_h__: the "decided not to delay" remark was about that [12:17] rogpeppe1: ok, as long as we're speaking to the single branch and not in general [12:17] rogpeppe1: your comment seemed to imply a more broad policy shift [12:19] 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:20] 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] rick_h__: sure. [12:20] 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] (as rogers API change and mine charms actions) [12:20] 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:21] urulama: agreed [12:21] 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] rick_h__: i agree with that [12:22] ok, aplogies for the confusion [12:22] bah, apologies [12:22] 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:23] 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] but completely valid [12:23] rick_h__: i'm not sure i remember that chat. is there an issue with commenting on code that's landing? [12:24] rogpeppe1: ah sorry, other way around. I had that chat with someone else around your post-landed reviews. :) [12:25] 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] rogpeppe1: yes, I defended the practice [12:25] rick_h__: thanks :-) [12:25] 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:26] rogpeppe1: so making that the primary source of getting newer devs involved is less than ideal [12:26] there's less 'communication' around those ime [12:27] rick_h__: sure, review before landing is definitely better [12:27] ok, <3 we're all happy agree'rs carry on kind sir. [12:28] and thanks for clarifying my mis-understanding of the board by noting the stuff I was looking for is landed. [12:32] 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] BradCrittenden: yes, it seemed legit enough to add a year and harmless [12:33] rick_h__: ok, great [12:33] rogpeppe1: and we do not return strings (as another nil type)? [12:33] urulama: strings cannot be nil [12:34] dang, someone has stolen my nick. must figure out how to get it back. === rogpeppe1 is now known as rogpeppe [12:34] rogpeppe: indeed. that's nice :) [12:34] removing the comment === BradCrittenden is now known as bac_ === bac_ is now known as bac [12:39] * bac \o/. take that ben a carson [12:39] lol [12:40] bac: how did you get it back? [12:40] 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] jrwren: woot woot [12:40] rogpeppe: /msg NickServ RELEASE yournick yourpassword [12:41] rogpeppe: but you must have it registered [12:41] bac: ah, so he hadn't hacked your password, just taken the username when you weren't logged in [12:41] rogpeppe: yeah [12:41] my client dropped last night [12:42] 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:43] jrwren: cool, yea just trying to look out for the new folks. The more effort put in the better for sure. [12:43] and we want to make it as easy as we can [12:44] rogpeppe: i'm looking at your pull request to see if i can get jenkins to kick off. (again). don't be alarmed. [12:45] bac: ok. jenkins seemed to work ok earlier, FWIW [12:45] q [12:45] rogpeppe: yeah, but when it adds the 'please test this' message it indicates it is unhappy [12:46] rogpeppe: so far i don't understand why it does that [12:46] bac: ah. i wondered what the significance of that was. [12:46] rogpeppe: aaa, i see now what happened to nilMetaHandler :D [12:46] urulama: :-) [12:59] 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] rogpeppe: probably in review [13:00] rogpeppe: hmm, I'd put them in review and mark them blocked [13:00] rick_h__: ok, cool, will do [13:00] rogpeppe: is there something we did to get into that pickle we need to address? [13:01] 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] 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] rick_h__: sgtm. done. [13:05] rogpeppe: as an experiment would you add the comment "ok to test" to your PR please? [13:05] bac: which PR? [13:05] https://github.com/juju/charmstore/pull/45 [13:07] 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] urulama: cool [13:08] 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:09] bac: done [13:09] ty [13:09] jrwren: would you be able to take a look at the above branch, please? [13:09] frankban: too [13:10] rogpeppe: on it [13:10] frankban: ta! [13:11] rogpeppe: hope you don't have any plans to refactore these in near future :D [13:12] urulama: not currently :) [13:14] rogpeppe: looking at it now [13:14] jrwren: thanks [13:14] rogpeppe: this errgo? https://github.com/jsimnz/errgo [13:15] urulama: no, github.com/juju/errgo [13:15] rogpeppe: uu, nice [13:16] rogpeppe: we should always use it probably [13:16] urulama: yeah. [13:17] urulama: my branch changes the whole code base to use it [13:17] rogpeppe: whole charmstore? [13:17] urulama: yeah [13:17] rogpeppe: that'll be fun to review :) [13:17] urulama: i have a tool to make the changes automatically [13:18] urulama: so it only took a few minutes to do it === alexpilotti_ is now known as alexpilotti [13:31] rogpeppe: done [13:32] frankban: ta [13:39] 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:40] rogpeppe: urulama your branches have landed correct? [13:40] rick_h__: not yet [13:40] frankban: upping the total by one due to team size increase for the moment [13:40] frankban: and looking into the cards. [13:40] rick_h__: thanks [13:41] rick_h__: i need to add some more tests after frankban's review [13:41] rogpeppe: ok, so the card should be back in review vs landing [13:41] rick_h__: oh, those branches [13:41] rick_h__: yes, those have landed [13:42] ok, yea I thought they had [13:42] rogpeppe: store: isn't efficient getter for router landed? [13:42] rick_h__: i moved the card [13:42] s [13:42] ty [13:42] oh ok [13:42] rick_h__: any suggestion for my next card? [13:42] frankban: looking [13:43] frankban: I'd love to have you and hatch looking at the deleted/removed work [13:43] 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:44] 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] rick_h__: sure, looking at the email [13:44] frankban: and https://pastebin.canonical.com/114475/ is the irc convo from last night [13:49] rick_h__: so, UI needs to knwo when a real machine/container has been marked for removal, right? [13:49] know even [13:50] frankban: rgr, so that we can show the user that it's an uncommitted change [13:50] we have a UX for remove unit, but not container/machine/relation [13:50] so this is to help enable that work [13:55] rick_h__: uhm, so a model attribute? Or am I missing something? [13:55] 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] and update any code reading 'number of machines/etc' to be aware of the attribute [13:56] or that we store them in another collection? Or something else? [13:56] I just want to get more than hatch's brain on it and it might be interesting to implement given your other ECS work. [14:00] 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] eed more love, but for something like a "toBeRemoved" attribute I guess we can just mutate the existing db records [14:01] rick_h__: but I also want to know what you/Jeff think [14:09] rick_h__: what to do with misc card which is in tracking and is done? Just delete it? [14:11] urulama: put it in daily call [14:11] urulama: and we'll note that it's done/etc to the team and no longer tracking [14:11] urulama: and then it'll just go to releaseable/archive like normal [14:12] frankban: +1 on the db myself, but yea want to have a chat. [14:12] 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:13] rick_h__: cool [14:14] rick_h__: did my email about expenses jibe with your understanding? if so, could you approve it? [14:15] bac: yes, will definitely go through folks expenses today [14:15] bac: sorry I missed the date on the original email. [14:21] there's hatch [14:21] wasssuuuuuuuup [14:21] hatch: when you get settled call on the ghost-removing items with ecs stuff? [14:21] yeah sure, just got breakfast on the stove.....say, 10mins? [14:22] hatch: rgr [14:28] rick_h__: filed expenses and swap day [14:29] frankban: ty for the heads up [14:29] jujugui I've approved all expenses filed to date, jcsackett got your ec2 one as well I didn't know was there. [14:31] oh and jcsackett is out today now that I look at HR heh [14:31] i am? [14:31] i shouldn't be. [14:31] oh nvm [14:32] i just filed for a half day on friday. [14:32] well it says 8/30 [14:32] I have two things here [14:32] ... [14:32] * jcsackett opens hr connect, grumbling all the while. [14:32] ok, so half day on friday? [14:32] i have the one i just filed for friday, 8/1 [14:32] bah, I ok'd two things but I can't find them now that I hit approve [14:33] and a swap day for 8/18 [14:33] (this being american dates, so it's probably the other way round in hr canonica) [14:34] 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] I've got the 15th of aug [14:34] and the 18th of aug [14:35] 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] are those both true? [14:35] rick_h__: those are both true--the 15th was filed a while ago. i was just listing the recent ones. [14:35] jcsackett: ok, think we're all good then [14:35] hm. "awhile ago" might mean last week. my sense of time is a bit off. :p [14:35] rick_h__: cool. [14:36] I think I've approved everything everyone ever ... ran out of ever's ... wanted approved :) [14:37] 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] hatch, https://juju.ubuntu.com/docs/authors-relations-in-depth.html and the next page I think [14:38] 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] for instance, team dinner night you need to not claim dinner [14:38] 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] jcastro right but neither of those says 'run this in your hook script to access relation data' [14:38] marcoceppi, ^^^ [14:38] yeah [14:38] sure, but for other days, sould i write lunch+dinner or put two rows in? [14:39] rick_h__: ^ [14:39] jcastro: I'll use the answer I make to the AU question to update the docs [14:39] hah [14:39] 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] marcoceppi :) thanks [14:39] hatch, real time docs [14:39] marcoceppi maybe we need an 'api' section for these docs? [14:39] 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] hatch: we have that [14:39] bac: no, not had issues restarting it. Just sudo service jenkins restart [14:40] rick_h__: fails [14:40] bac: or using the restart button in the UI [14:40] marcoceppi yeah? for hook commands? [14:40] after you sacrifice the chicken, you'll be enlightened with it's location hatch [14:40] bac: will have to check the jenkins logs and see what's up then [14:40] lol!! [14:41] marcoceppi, didn't we write up the mysql charm like this? [14:41] 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] when I have to run a grep on the md files, we're probably doing sometihng wrong [14:42] jcastro: vanilla [14:42] https://juju.ubuntu.com/docs/authors-charm-writing.html [14:42] oh [14:42] and the mysql interface [14:42] marcoceppi haha [14:42] rick_h__ so did you want to have a chat? [14:42]