[00:00] Hey bac! [00:01] I gota run for an hour or so but huwshimi when I get back I can answer any q's [00:01] sure [01:42] huwshimi hey back, so any other ideas on implementation or do you just want to land it as is? [02:13] hatch: Apologies I was eating lunch [02:13] Oh [02:28] * benji wonders how often huwshimi eats sashimi. [02:29] Mmm... sashimi [11:06] frankban: demo went off awesome. I've had several people pull me aside to say it was awesome/impressive including Mark S [11:06] rick_h_: \o/ [11:06] so big case of Gui rocks! [11:06] :) [11:07] rick_h_: very cool, so this was the local charms, right? [11:07] local charms, and then while that deployed I used quickstart -i to choose a non-default environment, and deploy the mongodb cluser bundle [11:08] so hit both together and blew them away [11:08] rick_h_: great [12:19] hey rick_h_ [12:41] rick_h_, awesome! so no issues with local charm uploads? [12:42] dimitern: nope was awesome. we've got some polish to do, but great demo. [12:44] rick_h_, perfect! is there a deployed gui with local charms support? staging or something? [12:48] he benji you around? [12:48] rick_h_: ping [12:49] bac: yep; what's up? [12:49] benji: i've got a bundle inheritance question. you up on that? [12:49] benji: looky here: http://bazaar.launchpad.net/~bac/charms/bundles/charmworld-demo/bundle/view/head:/bundles.yaml [12:51] I haven't done anything with bundle inheritance, but I'm looking at it :) [12:52] benji: ok, i thought you had. quickstart hates it. i'll figure it out [12:53] bac: I don't know for sure, but I think the charmworld-production is missing the "services" key. [12:53] elasticsearch and mongodb should be under a "services" key [12:54] ah, right [12:54] bac: pong [12:55] rick_h_: hey i got a modified version of that charmworld bundle deployed in lxc. the only tweak required was to change charmworld_import_limit to -1 [12:56] charm ships with 110, so you were seeing 110 bundles + back versions [12:56] bac: oh! [12:56] doh [12:56] * rick_h_ is so tired, but should have seen that [13:07] hey rick_h_, glad the demo went so well. :-) [13:10] gary_poster woot [13:38] jujugui: anyone ever use 'juju destroy-environment --force'? does it clear out stale 'provider-state' and other files that make juju think it is bootstrapped when it isn't? (i just did i manually before discovering --force) [13:39] * gary_poster has never used [13:48] jujugui: the lcy02 maintenance a few days ago knocked the charmworld CI off-line and it went unnoticed. it is alive again. [13:50] I wonder if there is a simple and effective dead man's switch we could implement for that. [13:59] jujugui added a customer bug to the kanban in urgent. It's an odd one. Customer has a workaround but if anyone gets a chance to poke at it appreciate it [14:00] I've told them we'd not have a fix until next week, so no one ruin their friday/weekend on it, but want to make sure we're responsive to them. [14:01] rick_h_: that may well be something specific to that charm. Do you know the OpenStack charm guy? He's probably there. [14:01] * gary_poster tries to remember name [14:02] * gary_poster has face... [14:02] gary_poster: ah, james? [14:02] no [14:02] he might know anyway [14:03] k, everyone is running for the hills so will see what I can find out [14:03] rick_h_: adam gandelman [14:04] though, yeah, james has more commits than I expected https://code.launchpad.net/~charmers/charms/precise/nova-compute/trunk [14:07] lol has face [14:07] :-P [14:08] ok, going afk until probably sunday when I get back to the US. have fun all! [14:08] * rick_h_ ran out of mifi data 2gb in one week :/ [14:08] bye rick_h_, safe travels [14:09] frankban: do you know why quickstart/deployer would reject root-disk as an invalid constraint? [14:10] cya rick_h_ have a safe trip [14:10] bac, don't we whitelist constraints? [14:11] and I don't recall root-disk as a standard one [14:11] gary_poster: is this wrong: https://juju.ubuntu.com/docs/reference-constraints.html [14:11] bac, unlikely, but it may well be *new* [14:11] ah [14:12] gary_poster: perhaps, but it has been part of the manual charmworld deploy, presumably for a while [14:12] bac: the first whitelist I see in the stack is ALLOWED_CONSTRAINTS in guiserver/bundles/utils.py [14:12] ALLOWED_CONSTRAINTS = ('arch', 'cpu-cores', 'cpu-power', 'mem') [14:13] bac: we should update that list if core introduces new constraints [14:13] and I am not sure about deployer's own validation, but it's worth looking there too [14:14] frankban: agreed. and proof should match too. annoying to get a false positive from the cheap test of proof only to have it fail later. [14:18] frankban: as shown here https://juju.ubuntu.com/docs/charms-constraints.html, the constraints list is space-separated for the command-line. guiserver forces comma-separated. [14:18] frankban: should we support both? [14:19] bac: we need to support what is supported by the deployer [14:19] (and only that) [14:19] bac: which can be different by how things are spelled in the juju-core cli [14:20] bac: what we ideally need is a shared/simple/complete/tested bundle validation Python library that can be used by proof/quickstart/guiserver/deployer... [14:21] preach! [14:21] :-) [14:21] :-) [14:21] frankban: and when we do, it would be nice if it matched what the juju-core CLI and documentation expects [14:26] crazy talk\ [14:26] we part ways there [14:32] gary_poster: you being funny, no? [14:32] bac, I am hilarity incarnate [14:32] which is proven by folks having to ask. :) [14:33] exactly :-) [14:33] i understand. my humor goes unappreciated here. [14:33] here = my house [14:33] heh [14:37] abentley: the charmworld ci process seems to be partially dead. could you give me some pointers? chat? [14:37] bac: sure, but opt right now. [14:37] OTP [14:37] abentley: np. eta? [14:38] 10 [14:38] thanks [14:50] bac: Okay, how can I help? [14:51] abentley: let me invite you to a hangout [15:03] guihelp: what do I need to do in the GUI to add an external js lib (except for adding that in the assets and loading it in index)? [15:04] * gary_poster seems to recall docs in this direction. looking [15:04] frankban see merge-files [15:05] it's in bin/ [15:05] (and lib) [15:06] the one in lib is just the script, the one in bin is the one which has the 'extras' list [15:06] which I've kind of always found odd [15:06] heh [15:06] hatch: so I have to push new libs in that filesToLoad.js, correct? anything else in the Makefile? [15:07] hatch are you looking at huw's branch to make it landable per your qa, or should I or someone else? https://github.com/juju/juju-gui/pull/113 [15:07] frankban: other thing: add a section to hacking doc describing what you did :-) [15:07] frankban that's it, nothing else required in the makefile [15:07] gary_poster: yeah I was thinking about that :-) [15:08] gary_poster yeah I think I'm going to pull it down and make some small changes and then re-push [15:13] ok thanks [15:14] gary_poster I'm also going to be working on adding view support to the viewlet manager [15:14] did you have anything else in the pipe you would like ahead of that? [15:17] in other news I was finally able to get my afp:// mount working [15:23] making notes, will be with you in a sec [15:25] *barf* this new coffee is horrid [15:26] benji any updates on the investigation? Boards still have it in starting [15:26] hatch: I need to update the board. I'll do that now. The current situation is that I'm fighting with the testing infrastructure. [15:27] want to pair on it? Or is it just something you need to slog through? [15:27] hatch, viewlet -> view is good. [15:28] sounds good [15:28] I'm not interested in pairing just yet. [15:28] benji ok np lemme know if you do [15:29] itunes is stuck playing a single song.....oh boy stable 14.04 can't come soon enough [15:34] bac: Oh, and since I didn't spell it out in voice chat, a swift or s3 container that's configured for public access is just an http URL, so it works with most tools. [15:35] abentley: right [15:43] bac: I don't think you successfully installed tarmac into /usr/local/lib. https://pastebin.canonical.com/104462/ [15:44] abentley: just did. had to clean out /usr/local/lib.../tarmac. the new version wasn't getting written [15:46] bac: Woot! It worked. [15:46] cool [15:49] gary_poster huw's branch is landing with trivials from his code [15:49] odly enough I rebased my fix into his and it showed as him doing the work [15:49] so it must take the first commit as the 'owner' ? [15:51] dunno, but good all around [15:52] jujugui call in 8 [15:52] yupyup [15:55] hatch, if rick is not back Monday and you are looking for something to do, maybe investigate DnD charm upgrade? first cut UX would be to drag a charm on an existing service to trigger upgrade dialog, maybe? [15:55] and the viewlet -> view thing is not done [15:55] does core support it yet? [15:55] viewlet -> view more important [15:56] sure, same story: upload charm then can simply tell service to switch to new charm id that juju tells you [15:56] ahh right [15:56] I'll create a card in Project 1 [15:57] gary_poster do we want to allow the drop on the inspector as well? [15:57] hatch. I considered it. If you like it, try it. :-) [15:58] ok I made a card which will be split out into a few I think [15:58] cool [15:58] jujugui call in 2 [16:01] Makyo ping [16:01] Keep getting "this party is over but you can start a new one" [16:01] Trying other comp. [16:01] weird [16:52] gary_poster: two leave requests added to canonicaladmin for your reviewing pleasure [16:52] btw, another remote collaborative tool worth following: http://screenhero.com/ . Current killer for us is no Linux support, but supposedly in process/coming: http://feedback.screenhero.com/forums/192060-feature-requests/suggestions/3941833-make-screenhero-for-linux [16:52] ack bac, I eagerly await clicking buttons...will report back in a amoment [16:53] gary_poster: and 1 day is rollover, so i just need to email sarah when approved, correct? [16:53] bac, yes, and cc me [16:55] bac, all approved . Would you like me to write email to Sarah about using 2013 day? I've done so in the past and am happy to. [16:55] will cc you [16:56] bac, actually you did it already. following up. [17:00] another thought on stateless components: instead of the top level dealing with a mutable bag of user state I wonder if we would be better served by passing in immutable state and getting back a sequence of changes to be enacted, that way we wouldn't have to infer changes from a state delta [17:01] e.g.: pass in {sidebar: {minimized: false}} and if the user clicked on the sidebar show button we would get back actions = {sidebar: "un-minimize"} [17:02] benji, fwiw, that's my pattern for rendering actually: the factories return instructions on what to draw, rather than drawing themselves. I was more direct for the event handlers, since I didn't want to have to come up with a vocabulary for the much larger (and yet-to-be-discovered) possible set of actions [17:02] benji you're basically taking the event system and bringing it down to the functional level with that [17:03] which is fine, it removes the async nature of it, (which might be a good thing) [17:03] could be; hopefully with the benefits of events plus the benefits of a functional approach [17:04] I considered having generic data mutation actions, but I was using immutable data that had a _replace method on it to generate a new version, so it kind of felt like that already, for cheaper cost [18:44] Boo My solution doesn't work for some relations. [18:45] :( [18:46] Was blithely checking relation hook failures, but some relations have multiple endpoints that connect to the same interface, like db and db-slave [18:46] guihelp: I need two reviews for https://github.com/juju/juju-gui/pull/115 . Anyone available? thanks! I'll try to make the changes and eventually land it in the we. [18:47] frankban: on it [18:47] sure I'll take it [18:48] benji: ^^^ I already have two reviewers, so, just FYI, that branch introduces the zip library and also adds a zip-utils module where to store helper functions for working with zip archives [18:48] gary_poster, hatch: thank you! [18:49] frankban: thanks np. have a great weekend! should we try to land it for you if we can? [18:50] frankban: sounds good [18:50] gary_poster: sure! hopefully I will be able to do that in the we, but if not, please anyone feel free to take it [18:51] cool frankban. ttyl [18:51] have a great weekend! [18:52] thanks :-) [18:53] hatch are you going to comment on modules-debug/modules-prod instead of the script tag, or shall I? [18:54] :-) [18:54] haha, I'm on lunch [18:54] go ahead [18:54] ok cool [18:55] I kind of wish we used the loader of some sort so that we didn't have to ship all of that js to the client all the time [18:57] but...we are building an app that needs all of it? [18:57] maybe I'm missing something [18:57] well it's just that you don't need it at all unless you're doing the local charm stuff [18:57] so. quickstart kind of went a little wonky during the charm school today [18:57] so it has to be shipped for the 90% of the time that's unused [18:58] tell us more marcoceppi? [18:58] gary_poster: oh, it's been recorded to youtube for prosperity, but basically it wasn't able to connect to the juju-gui websocket [18:59] posterity, even [18:59] let me find you the link where I start to panic [19:00] oh! weird, and I'm sorry. was there anything unusual about the circumstances? A bug report--or anything written--giving details would be fantastic [19:00] juju quickstart -i ~/production.yaml was what I ran [19:00] we'll make one if you don't, of course, but it would be better to have you give us the details (and easier :-P) [19:00] marcoceppi, local env? ec2? [19:00] gary_poster: I didn't really take time to debug, just kind of swept under the run and moved on [19:00] hpcloud [19:00] sure of course [19:01] I'll attempt it again now to see if I can repro [19:01] is there a verbose flag or someting I can use? [19:01] I bet we haven't done much hpcloud ourselves. Thank you! [19:01] marcoceppi: --debug [19:02] cool, will give that a go now [19:02] thank you much [19:14] gary_poster I don't get an email from linked-in for over a year, I log in thanks to you and now I get about 1 a day lol [19:14] hatch, heh, sorry ;-) [19:15] gary_poster: looking at the deployer code i see that it parses the constraints only as space-separated key=value pairs. looks like guiserver using comma-separated is an outlier. [19:48] jujugui: if you attempt to apploy a bundle via quickstart or the juju-gui, juju-core api requires that referenced charm urls have revisions in them. if you don't you get an error message back like "Error": "charm url must include revision" [19:49] the juju-deployer doesn't use the api and juju-core CLI doesn't have that restriction [19:49] anyone know the rational? [19:49] s/apploy/deploy/ [19:51] marcoceppi: ^^^ that's what led to the bug i filed yesterday [19:52] bac: I don't know of any reason we would include that constraint. frankban would be a good person to ask. [19:52] bac: thanks for the clarification [19:52] benji: it isn't us. it is juju-core [19:52] couldn't you just do revision expansion? [19:53] so charm: "mysql" would expand to cs:precise/mysql-33 [19:53] or are we of the idea that charms should be explicit? and if so that's something the remote proof will have to include, charm-tools proof only does a few things [19:53] charm url validation occurs on the API side [19:54] ahh, in that case I would suspect it is an accident of implementation (and an organizational anti-pattern: all clients should use the same API) [19:54] in the case of proofing, the API I'm referring to is the charmworld api [19:56] bac: https://manage.jujucharms.com/api/3/bundle/proof is where that should be fixed, not charm-tools [19:57] marcoceppi: it would be better to find out if it is a false restriction and realign the juju-core api with the cli. [19:57] true [19:57] fwiw, the cli exapnds it prior to sending the charm url over [19:58] so either we replicate that within juju-gui or just expose the more strict nature of the api and say you must have a version [19:58] juju-gui server/quickstart [20:00] i think from the perspective of a bundle specifying a particular revision is desirable, which guarantees this collection of charms works together. with no revision you get the latest and that group of charms may have incompatabilities. [20:01] i think i just argued with myself, again. [20:04] yes that's a definite requirement else you get issues like we have with npm dependencies [20:21] jorge wants the loose approach too [20:21] He thinks he does, anyway :-) [20:28] well I could see that it would be ok [20:29] but that's kind of the cowboy approach and not for 'approved' charms [20:29] er bundles [20:29] at least IN MY MOST HUMBLE OF OPPINIONS [20:29] IMMHOO [20:31] hatch is calling out to the Canadian moose in Saskatoon [20:32] (and I agree) [20:38] gary_poster: bac hatch I think jorge and I are in the same boat [20:38] Give you enough rope to hang yourself [20:38] :-) k [20:38] marcoceppi: can you clarify that boat [20:38] he wants to be able to have bundles that do not specify versions [20:38] with regards to specifying versions in charms. I think we can talk about promulgated bundles being locked [20:38] cool [20:39] but I should be able to strap on spurs and a 10 Gal hat with my own bundle namespace [20:39] I'd agree with that, and I think that's what we had intended for some time now [20:39] heh, sure [20:39] so are we advocating for a change to guiserver to accept revision-less charm urls, look up the latest, and hand it to the juju-core API? [20:39] it's a deployer thing [20:39] IMMHOO, yes [20:39] and I think it already does it there [20:39] heh [20:39] NO [20:39] well, deployer uses the CLI [20:39] marcoceppi so, approved bundles would require versions? [20:39] and the CLI does it [20:39] ah right [20:40] well promulgated bundles, if that ever exists, yes [20:40] though the deployer should be able to change for 1.18 [20:40] so, as marcoceppi said earlier, we'd have to have guiserver do the lookup before calling the api [20:40] * gary_poster suggests we wait for 1.18 [20:40] and then have the deployer do the righth thing with the API [20:40] i'm confused [20:40] and then use that [20:40] the deployer does what jorge wants [20:40] the POWAA! [20:41] ugh who chose promulgated to be the word.....SERIOUSLY [20:41] was 'promoted' too easy? [20:41] :P [20:41] bac what do you mean? [20:41] haha, you would get along with jorge swimingly [20:41] lol [20:41] the deployer uses the CLI and does what jorge wants, revisionless charm urls [20:41] currently [20:42] juju-quickstart and juju-gui use the API and must have revisions [20:42] so.... [20:42] bac, in 1.18 the CLI uses the API [20:42] gary_poster: for juju deploy? I thought it already did since 1.16 [20:43] gary_poster: ok, then in 1.18 jorge will be sad in all cases [20:43] marcoceppi: mebbe so. I know that the API work is still ongoing [20:43] who would like to have a quick hangout? [20:43] bac, no, my hope is that the API does the looking up on the server side now [20:43] gary_poster: the CLI does the charm url conversion for by doing a look up against store.juju.ubuntu.com [20:43] [20:43] or shall we continue this whoseonfirst routine? [20:43] marcoceppi: and then talks to the API? [20:44] when I run juju deploy mysql in 1.17.X it resolves the charm url then, I believe, uses api to do the deploy [20:44] * marcoceppi runs --debug [20:44] seems a shame that the charm url conversion is not done on the server side [20:44] gary_poster: networking concerns [20:44] marcoceppi, gary_poster: please to be joining me. https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso [20:44] though, the same exists for the desktop I guess [21:08] gary_poster, hatch Current impl of relation is in error. Appears to work, but may be worth a second set of eyes, if either of you have time. http://pastebin.ubuntu.com/6893602/ [21:08] gary_poster: bug 1277696 [21:08] <_mup_> Bug #1277696: Bundles with revision-less charm URLs should deploy [21:09] hatch finished https://github.com/juju/juju-gui/pull/115 ; ready for you [21:09] thank you bac [21:09] will mess with it in a sec [21:09] looking Makyo [21:09] gary_poster: feel free to correct the description if muddy or wrong [21:09] cool thanks [21:11] Makyo: trivial but maybe worth clarification: "...side of the relation are in a relation error state..." -> "...side of the relation are in an error state for this relation..." or something like that? awkward. do what you will. still reading [21:11] Oh, right, didn't get to the comment yet. Will do. [21:13] gary_poster ok thanks I'll get to it once I get out of viewlet manager mode [21:13] ack thanks hatch [21:13] * bac -> dog walk [21:15] Makyo looks good just maybe some inline comments explaining what the code does so future us doesn't have to actually read the code :D and just FYI arrays have a native some() in all of our supported browsers [21:15] hatch, cool, thanks. Will ensure 'some', but yeah, comments on the way. [21:16] this viewlets and views code is a headache [21:16] from now on, I want the final app spec before I start any code :P [21:17] enterprise baby!!! [21:17] Makyo, looks good to me. I have a couple of minor niggles for you to take or leave. (1) the `indexOf(sourceEndpoint[1].name + ...) !== -1 seems potentially problematic (if I have a name "bar" and another name "foobar", for instance). Can't we use `...=== 0` instead? [21:17] hatch :-P good luck :-) [21:17] lol [21:17] gary_poster, oh, okay, yeah. Will take a look. [21:19] Makyo: thanks, cool. (2) I love me some functional programming, but I wonder if the sourceEndpoint & targetEndpoint assignment would be clearer (and as short or shorter) with conditionals [21:20] gary_poster, oh, so sourceEndpoint = endpoints[0][0] === source.id ? endpoints[0] : endpoints[1] or something? [21:20] if (this.endpoints[0][0] === self.source.id) { sourceEndpoint, targetEndpoint = this.endpoints } else {targetEndpoint, sourceEndpoint = this.endpoints} [21:20] or whatever [21:20] yeah what you said is good direction too [21:21] Can you expand arrays like that? [21:21] That'd be neat. [21:21] no [21:21] Boo! >:/ [21:21] too much language exploration [21:21] sorry :-) [21:21] Haha, I wish [21:22] apparently some iteration of ES6 has the multi assignment stuff added [21:22] yay [21:23] bac, moved "[suggestion] quickstart cmdline option for which juju to use" card to slack. putting your new bug in its place. AOK? [21:24] bac, uh, confused. So we should close bug 1277188, replaced by bug 1277696; and open a new bug about the comma/space difference in constraints parsing? [21:24] <_mup_> Bug #1277188: charm-proof should warn on revision-less charm URLs [21:24] <_mup_> Bug #1277696: Bundles with revision-less charm URLs should deploy [21:25] OIC [21:25] no, we want all three. :-/ k [21:44] gary_poster, hatch http://pastebin.ubuntu.com/6893754/ ? [21:44] looking [21:44] oo pretty green [21:45] Makyo: looking good. Only additional thought, that hatch can probably answer, is whether this is the right logic for peer relations [21:45] Is it? Or is that not even pertinent? [21:46] gary_poster, hatch not pertinent; peer relations are filtered out in the drawing process. Logic will have to change if it goes down into handler level code. [21:46] Maybe not pertinent because it would not participate in a relation menu [21:46] cool [21:46] Makyo isn't this.source.units is not already an array? Isn't it a LML? Or is toArray() just a passthrough in that case? [21:47] hatch, passthrough, I think. source.units is definitely not an array. [21:47] gotchaz [21:47] +1 [21:47] looks good here [21:47] Makyo: cool, looks good. For future: https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7#Destructuring_assignment_(Merge_into_own_page.2Fsection) :-) [21:48] Whew, okay. Glad I caught the weird dual relations case. Good test is mediawiki with two mysqls. The interfaces are different on mediawiki, but the same on each mysql. [21:49] Bonus :D [21:49] :) yay [21:50] yay go future javascript [21:50] which we can't use if we ever don't support the latest browsers [21:50] heh, open the inspector when you go to that page and look at console. Maybe this is only new to me [21:51] * hatch hands gary a fancy hat and whistle.... "Welcome to the internet!!!" [21:51] :-P [21:51] lol [22:01] * Makyo dogwalk, then tests. [22:01] the viewlet manager now accepts viewlets AND views [22:01] unfortunately all the css is broken with views [22:01] yay [22:02] probably a rather simple specificity fix though so that's good [22:05] OO 168 test failures [22:06] there are so many test failures that the scrollback in my terminal doesn't go that far [22:06] haha oops [22:17] heh [22:18] * gary_poster running [22:18] have a great weekend and next week! === gary_poster is now known as gary_poster|away