[12:15] bac or benji, either of you able to help me cover calls at 10am today? [12:15] rick_h_: sure. What does that mean? :) [12:16] (and what time zone?) [12:21] benji: 10am edt [12:22] thanks [13:09] benji: nvm, meeting got moved to thurs [13:11] rick_h_: ok [13:37] rick_h_, I noticed the promulgated bundle isn't showing up still [13:37] jcastro: on jujucharms? [13:38] jcastro: or on comingsoon? [13:38] jcastro: jujucharms has to wait for a deploy. The link I gave you was comingsoon which it should show ok for [13:38] ah, it's on comingsoon [13:39] yea, we'll do a deploy this week before charm school [13:39] rick_h_, prod deploys before friday though right? [13:39] and the marketing thing [13:39] perfect, thanks [13:44] rick_h_, hey so [13:44] how does the GUI react/show colocated services these days? [13:44] like if I wanted to do some all-in-one bundles? [13:44] jcastro: it doesn't. It's the current project. To add a machine view [13:44] I'll mention it on the uds session [13:45] ok so what happens if we have a bundle with coloe'd services, will they still work or does the whole thing fall apart? [13:45] the bundle should work, but there's no indication in the gui that they're colocated. [13:45] though I'll be honest, we've not tried it out yet [13:45] ok I think I will wait for the machine view [13:45] k [13:45] what's the TLDR on that, 14.04, past 14.04, or 14.10? [13:46] 14.05 ish [13:46] ta [13:54] morning [13:54] morning [13:55] guihelp: anyone available for a quickstart review? https://codereview.appspot.com/72520044 no qa and thanks [13:56] sure [13:56] frankban: just one? [13:57] bac: technically I need two. But it's mostly code moves. Anyway, if you want to take a look it would be appreciated [13:57] ok [13:57] thank you both [14:09] frankban all done [14:10] luca___ rick_h_ in a design of the inspector there was a button for removing the relations - the code is there but the UI is not.... (re the comments on the bug #1289469) [14:10] <_mup_> Bug #1289469: Remove relation button missing from relations tab in inspector [14:11] thanks hatch! I'd still be inclined to have two separate functions, the current logic seems explicit and intuitive [14:12] bac: are you doing the review? [14:12] frankban: yes [14:12] frankban sure no problem, I was thinking of abstracting that out of the app and into the ssh utils class but thats just personal preference :) [14:13] bac: cool [14:13] hatch: ack [14:13] ugh I hate DST changes...all of my meetings are an hour earlier [14:13] :P [14:14] rick_h_ can we move the 1:1 either an hour later or earlier on wednesday? [14:14] hatch: otp, can look in a min [14:14] ack [14:20] frankban: done [14:23] anyone know how this happens? https://jujucharms.com/sidebar/search/~bwtiffin/raring/gnucobol-sample-0/?text=cobol#readme [14:23] the readme looks like proper markdown [14:25] jcastro the file doesn't end in md [14:26] .md that is [14:34] bac: thanks [14:51] jujugui: are we meeting in 10 or 70? [14:51] 10 [14:51] :( [14:51] i'll :( that too [14:51] us non DST people have to pay for the DST peoples sins [14:52] i think the people with the wildly fluctuating time should suffer, not use rational people [14:52] s/use/us/ [14:52] lol [14:54] rick_h_ so do I get a +1 on my inspector base branch after the missing render test gets added? [14:55] bac: yea have it for 6 min from now [14:55] bac: but will bring up if moving it makes sense [14:55] hatch: hmm, I forget, looking [14:55] rick_h_: i'm ok with it. [14:55] tbh I'm ok with the new time - only because google keeps track of the DST changes for me :) [14:56] odly enough tomorrows standup is at 10 [14:56] hatch: yea, I moved tomorrow due to vuds [14:56] ohh [15:00] jujugui call now [15:01] benji: able to standup? [15:02] rick_h_ oh, I thought it was an hour later; coming [15:27] rick_h_, ugh, the GUI is still spitting out bundles that don't pass proof, the "if the relations were reversed" thing again [15:28] http://pastebin.ubuntu.com/7068198/ [15:28] why is this not valid? [15:30] does a bundle need to pass proof to be listed in the search results? [15:32] ohh sorry now I get it [15:32] the exports are exporting backwards [15:32] jcastro does it deploy? [15:33] yes [15:33] so that seems to me like proof is wrong then [15:33] hey bac [15:33] I am having a hard time pushing a bundle [15:33] jorge@jilldactyl:~/src/bundles/rails-simple$ bzr push lp:~jorge/charms/precise/bundle/rails-simple/bundle [15:33] bzr: ERROR: Permission denied: "~jorge/charms/precise/bundle/rails-simple/bundle/": : Cannot create branch at '/~jorge/charms/precise/bundle/rails-simple/bundle' [15:33] shouldn't that work? [15:34] rebooting [15:37] jcastro: was otp, looking] [15:39] jcastro: bundle replaces the series name. so try lp:~jorge/charms/bundles/rails-simple/bundle [15:39] jcastro: here is the URL for one of mine: bzr+ssh://bazaar.launchpad.net/~bac/charms/bundles/muletrain/bundle/ [15:39] aha! so the instructions are wrong [15:39] fixing [15:39] yay [15:40] rick_h_ ok I'm pretty confident that my wifi issues are caused by putting osx to sleep [15:40] hatch: ugh [15:41] apple quality [15:41] jcastro: where's this bundle so I can check it out? [15:41] who do I have to pay to get someone to fix the linux kernel bug? [15:41] :) [15:42] hatch: no, proof cares about direction [15:42] hatch: if we're exporting them wrong we need to file a bug and fix them [15:42] hatch: the deployer doesn't care about order though and will get things deployed [15:42] rick_h_ right - but if the bundle is valid (deploys) then proof is wrong [15:43] but the deployer isn't the final say of truth. Deployer deploys bundles with local charms [15:43] but we don't ingest them :) [15:43] rick_h_, order should not matter [15:43] It's a bug that the deployer deploys them [15:43] hazmat: we talked with core about it and were told order mattered [15:43] no I'm pretty sure that order is not important [15:43] rick_h_, that's so short-sited. [15:43] rick_h_, pushed it here: https://code.launchpad.net/~jorge/charms/bundles/rails-simple/bundle [15:43] blarg, so confusing heh [15:43] rick_h_, deploying local charms is a huge point to deployer.. its doesn't fit with the sharing use case [15:43] hazmat: k, we're going off what we were told from core. That's what we implemented [15:44] rick_h_, but it would if deployer did a bundle/zip format [15:44] hazmat: understood. Just saying that proof isn't all about 'will it blend' [15:44] true [15:44] rick_h_, just saying deployer wouldn't exist without the local charm use case [15:45] * rick_h_ looks for the notes and bug that lead to us making relations directional [15:51] rick_h_ I think CI is down..... [15:52] https://saucelabs.com/jobs/3515492a81b640c8a0ecf8dfa210e3cd [15:54] hatch: looking, wonder if the port isn't updated up any more :/ [15:55] how could that happen? [15:56] rick_h_, yeah so we need to fix this by friday if at all possible [15:57] jcastro: k, benji can you find the old communication around that order of relations stuff [15:57] this didn't show up in my "are bundles ready to be shipped" tests because directional-ness (is that a word?) wasn't an issue before [15:57] jcastro: right, if order doesn't matter we can go back on it [15:57] * benji looks [15:58] jcastro: but we hit a bug originally that started all this and now I'm not able to find the original bug [15:58] well that depends if order really matters right? [15:58] jcastro: so we'll get our notes together and figure out what to do [15:58] jcastro: well the order error came out of a bug that we were pulling in bad bundles to start with [15:58] jcastro: so I want to make sure we don't just pull the change and put a new bug back in place [15:58] yeah [15:59] I personally don't care if order matters or not, just that something the GUI exports can work, heh. [15:59] jcastro: rgr, so this is a gui export? [15:59] jcastro: like I told hatch, if we're exporting them out of order then we should fix that [15:59] yes, they are all GUI exports, all I do is mangle envExport to be a name [15:59] the GUI export does not take order into consideration when exporting [16:00] because when it was written order didn't matter [16:00] rick_h_: my IRC logs were a victim of my lost partition, but I recall Kapil saying that the deployer respects and enforces relation directionality [16:01] hatch: ci port got closed up. re-opening. It's a victim of server maint. I think [16:01] rick_h_ so who's fault is this? I just want to make sure that this doesn't get broken in the future [16:01] hatch: give it another go and when it's running you should be able to hit that url now (ci.jujugui.org:8888) [16:02] hatch: it's the fault that MS does maint which takes down/up machinse every so often and the port isn't a port setup by the charm. It's manually done and it must have gotten lost in the maint from MS. [16:02] rick_h_, if you can tell me how to mangle the existing order relation that would unblock me [16:02] hatch: it probably will, but it's a pretty obvious failure. The saucelabs says it can't hit the url. If you can't either, then it's not there to hit [16:02] benji, directionality is a bit of a misnomer that's not specified on the cli, deployer does respect relation creation ordering [16:02] lines 25 and 26: http://bazaar.launchpad.net/~jorge/charms/bundles/rails-simple/bundle/view/head:/bundles.yaml [16:03] rick_h_ We are hosting this on Azure? [16:03] jcastro: sorry, multi-tasking here as our CI is down atm. I've got it pull down and tesing it out [16:03] hatch: yes [16:03] ohh, maybe we should look into switching to someone else [16:03] benji: no can do [16:04] I'd just hate for you to be on vacation and the CI goes down until you get back :) [16:04] hatch: it's the first time since CI went up and the azuire credentials are in the wiki for everyone else to use ;) [16:04] rick_h_: ?? [16:04] benji: bah sorry [16:04] hatch: no can do [16:04] :) [16:04] benji: looking through your old branches to see if I can find a branch that rings to the bug [16:04] any gmail fu for 'relation ordering' is apprecited benji (not sure if it'll find the pull request/etc) [16:05] * benji looks [16:05] rick_h_ ok so the ci docs need to be updated then? I didn't see any reference to the host or where to find information on it in there [16:05] hatch: because the ci docs are public. I emailed ~peeps I thought. If not sorry. It's in the CI page in the private wiki [16:05] rick_h_, relations are a list.. the list order is respected.. not sure which bug triggered it.. but imo if ordering matters to relations its a bug in the underlying charm [16:06] rick_h_ right, I'm just saying we should probably have a line which says 'see the wiki for azure details' or something [16:06] deployer respects the order due to playing in the real world... [16:06] hazmat: yea, I want to find the original bug. This all started for some legit reason and it's long enough I can't recall [16:06] hatch: patches welcome :) thanks [16:06] rick_h_, any chance of uistage/comingsoon moving to canonistack ? [16:06] hazmat: so it'll be a new staging and yes. RT is filed and been in the list for a month or two now [16:06] rick_h_, low priority.. just wanting to be able to shut down that instance.. thanks [16:06] hazmat: oh hmm, well the charmworld one, due to dns mangling it's first on the list for comingsoon [16:07] hazmat: yep, we've got rts in to work on getting that moved around [16:07] rick_h_: this is the branch that adds a hint about bundle errors due to incorrect relation order: https://code.launchpad.net/~benji/charmworld/1263120-allow-self-referential-relations-in-bundles/+merge/202373 [16:08] benji: awesome thanks [16:09] hazmat: so can you +1 then that per that branch and bug order matters? ^ [16:12] hazmat: so the requires end of a relation must be specified before the provider of that relation? Or am I just confused? [16:20] jcastro: did http://paste.ubuntu.com/7068467/ testing it in an lxc right now to make sure it comes up right [16:20] jcastro: filing a bug on the gui to get the order righgt [16:21] what do the - - and - mean btw? [16:21] if you're busy you can explain that to me later actually [16:22] jcastro: the first - means "here be a relation" [16:22] rick_h_, no.. within a relation pair order doesn't matter, between pairs the order is respected [16:22] and the second - means "here's the first point, next one is below" [16:22] rick_h_, ie add-relation x y vs add-relation y x doesn't matter [16:22] http://pastebin.ubuntu.com/7068476/ [16:22] rick_h_, but add-relation x y, add-relation a b will always happen in that order [16:22] the complex one gets way more complicated [16:22] hazmat: ok then. Confusion in that [16:23] hazmat: I suppose the 'order was respected' got confused between the "list of all relatoins in the bundle" and the "order of a single relation" [16:23] thanks hazmat, jcastro filing bugs to get sorted out [16:24] benji, rick_h_ so -1 on that branch, cause order within a relation doesn't matter to juju [16:24] link or CC me on the bug, I'll need to keep track so I can get in as many bundles as I can when it's fixed [16:24] jcastro: rgr [16:25] jcastro, re the syntax its a list of lists re - - [16:25] if we need to change proof's behavior, that's fine, but the branch in question didn't introduce the behavior in question (it only reported it to the user better) [16:26] benji: right. So right now there's no behavior issue other than proof is sending an error and so won't ingest [16:26] jcastro, i sometimes find it helpful to do, cause yaml is subset of json.. i typically do - [x, y] to avoid the - - nesting [16:26] benji: and these are bundles that come straight out of the Gui [16:29] has anyone run into an issue when the loader wouldn't find a file defined in modules-debug? [16:29] hatch: no, it's doing a full make clean-all and build so should be fine [16:30] yeah the file is clearly in the list '/vagrant/app/views/inspector-base.js', but then I get Error: ENOENT, no such file or directory 'node_modules/yui/inspector-base/inspector-base.js' [16:30] somehow it's being added to the YUI modules list as well [16:30] './node_modules/yui/inspector-base/inspector-base.js', [16:31] benji: I've added a bug/card. Can you look at that next after your current branch is up? [16:32] rick_h_: sure (it may take a little longer than expected, this moring has been interruptful) [16:32] benji: rgr, thanks. [16:32] jcastro: you're subscribed. Will get it next in line and work on getting it into the deploy by EOW [16:32] cool, I have enough bundles in the queue so it hopefully won't hold up the line [16:33] jcastro: I can verify that swap of order works [16:33] jcastro: deployed that bundle with that change to lxc with quickstart [16:33] ok I can get that one in then [16:33] rick_h_ so the issue is proof or the GUI? [16:33] jcastro: rgr [16:33] hatch: proof, the gui's not helping by not caring about order either [16:34] hatch: but the fix can just be letting proof let it through [16:34] ok cool, so order does matter or doesn't? [16:35] hatch: ok, sorry catching up. have a diff to look at for your loader issue? [16:35] figured it out.....pebkac error [16:35] YUI().add() vs YUI.add() [16:35] ah, yay [16:35] that should really throw instead of working in a cryptic manner [16:35] but oh well [16:35] rick_h_, ugh you're going to hate me, found another problem [16:36] lol [16:36] the GUI exports the GUI in the bundle [16:36] but if you try to quickstart the bundle [16:36] it bails because the bundle has the GUI defined [16:36] ^ hehe [16:36] so much discussion around that one [16:36] yeah [16:36] I think we should give you the option to export the GUI [16:36] jcastro: yes, known bug. It's on the todo list but won't be there by EOW [16:36] so I take it, you want me to just remove the GUI from all the bundles? [16:36] manually yes :) [16:37] ok I'll just do that [16:40] rick_h_: I've cleaned up https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1V3B3dDNvYXJGRE0 [16:40] luca___: awesome thanks [16:41] rick_h_: no worries, I've asked spencer to update the visuals to make sure they are all the latest, so it should be up to date by the end of our day [16:41] luca___: ok that sounds great. Appreciate it. [16:43] rick_h_: to highlight to the user which environment they are deploying to in the deployment summary what can we say? something like " Deployment summary – Prodstack" or would it better as a affirmation like "These changes will be deployed to Prodstack"? [16:43] luca___: I'm not sure we have a name atm so I'd start with "Deployment summary" to start with [16:44] rick_h_: I see, thanks [16:44] luca___: but I like the first as it's shorter and easier to see a word I recognize (my env name) [16:44] rick_h_, do you have the bug handy for quickstart/juju-gui? [16:44] but it's just personal preference [16:44] jcastro: yep, sec [16:44] https://bugs.launchpad.net/juju-gui/+bug/1249039 [16:44] <_mup_> Bug #1249039: Exporting from real environment exports juju-gui as well

[16:44] jcastro: & [16:45] err ^ [16:45] ack, filed this too: https://bugs.launchpad.net/charm-tools/+bug/1290444 [16:45] <_mup_> Bug #1290444: Bundle proof should check for juju gui [16:45] that should cover us [16:45] jcastro: k, will note that one as well. [17:35] rick_h_ I just got an email from MS saying that there was a maintenance restart on all the single instance machines :) [17:36] hatch: yea [17:36] they've been warning me of that for a while [17:36] it's been rescheduled twice [17:36] but I didn't know it would kill the open port [17:36] I wonder if ec2 kills the open ports when rebooted [17:36] no [17:36] seems like a bug to me [17:38] rick_h_ does the merge system use a different machine? [17:38] merging my branch had the same issue [17:41] hatch: no, I'm looking. oh it uses 8889 doh [17:41] :) [17:42] applying change [17:46] hatch: ok, restarted it from the github side [17:47] thanks [17:53] bac: any luck getting a query plan? [17:54] rick_h_: not yet [18:00] rick_h_ I think I am going to convert the inspector base class into an extension and have the viewlet manager create new instances of the views now that it doesn't need to support viewlets [18:00] care to have a hangout to pre-imp? [18:00] hatch: sure [18:00] https://plus.google.com/hangouts/_/76cpi6bn708kprean3vnlq1vas?hl=en [18:18] rick_h_ http://ci.jujugui.org:8080/job/juju-gui-merge/178/console lol wth [18:18] CI is going boom! [18:19] hatch: grrr [18:20] hatch: crap, looks like we hit that new connect update. [18:21] hmm, is it versioned? can we switch to back to the old version [18:22] hatch: not sure, it seems strange. [18:22] hatch: this is the good part http://paste.ubuntu.com/7069098/ [18:23] hatch: got a phone call in a couple of min. Will have to look at it in a bit [18:24] this might have been a bug caused by the npm update and re-shrinkwrap [18:24] we should still be using connect 2 :( [18:25] hatch: yea, not sure [18:25] hatch: can you see what version we list in trunk? [18:27] rick_h_ various versions of 2.x [18:28] hatch: so that's still listed in the deps file? [18:28] the 2? [18:28] "various versions" ? [18:29] there are a few deps which have connect as their deps [18:29] so we are running multiple versions of it depending on the dep [18:29] dep dep dep depppppp [18:29] :) [18:42] * hatch lunching [18:48] rick_h_: i'm continuing to poke at elasticsearch running on staging. i'm having a hard time getting the interactive queries using curl to work the way i expect. i suspect i'm doing something silly. [18:50] bac: otp, can look in a sec [19:10] bac: how goes? [19:11] hey rick_h_. chatting with curtis to pick his brain [19:11] rick_h_: you want to hangout real quick like? [19:11] bac: cool sure thing [19:11] shoot me a linky and I'll join up [19:12] rick_h_: https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso [19:34] rick_h_ did you have a chance to get the merging ci back up? [19:35] hatch: no, on calls [19:36] ok np, I've finished the changes I'd make so I was going to push them up, but they include the currently-pending branch as well [19:37] hatch: k [19:39] rick_h_ here is the wip https://github.com/juju/juju-gui/pull/172/files just keep in mind that it includes that other branch in the diff as well [19:46] rick_h_: fwiw, here is a working query against staging using httpie http://paste.ubuntu.com/7069565/ [19:46] no explain, just a query [19:46] bac: right cool [19:46] yes, much nicer than curl [19:47] :) [19:47] but elsec ftw [19:47] very cool [19:59] rick_h_ would you like me to take a look at the ci failures? [19:59] hatch: looking now. The npm versions are the same for the test run vs the merge rnu [19:59] ok cool [20:00] the error is coming out of the node js http server in the test-server.js [20:00] which is odd, why would it fail here and not in the test rnu [20:00] but merge does a make clean-all [20:01] sorry I can't offer any input, I haven't looked at how the CI runs since ben and I set it up the first time :) [20:01] hatch: it's there in the make file :) [20:01] and the jenkins config [20:01] well...any knowledgable input :D [20:01] everything you have access to [20:01] right, I meant from memory :) [20:15] https://github.com/joyent/node/blob/master/lib/net.js#L342 so apparently no handle is being created for whatever reason [20:15] ^ rick_h_ [20:16] hatch: think I've got it [20:16] running a merge right now on my branch to verify [20:16] hatch: I think the reason is that the address was already in use [20:17] hmm [20:17] http://ci.jujugui.org:8080/job/juju-gui-merge/182/console [20:17] to follow along at home [20:17] lol ok [20:18] I'm wondering why the address being in use would cause address to return null and not an error [20:18] address() [20:18] because the way it was written. server was not defined [20:18] server.address() died as it had no handle I'd imagine [20:18] well, we'll see I guess. maybe I'mwrong [20:19] no, it's running tests now [20:19] cool [20:19] I've updated how it starts the server so the new error is: [20:19] events.js:72 [20:19] throw er; // Unhandled 'error' event [20:19] ^ [20:19] Error: listen EADDRINUSE [20:19] per http://ci.jujugui.org:8080/job/juju-gui-merge/181/console [20:19] which is a LOT more obvious [20:19] cool - that must have been a 'recent' change to the Server class returned from createServer [20:20] haha yes this is a much better way [20:20] once this branch of mine lands you should be safe to :shipit: yours [20:20] and then you can redo your pull request for review [20:21] yeah I'll wait for this one to land first :) [20:22] ok queueing up 171 again [20:34] ugh these http json requests are killing this CI [20:34] I bet if we fixed that it would cut the CI time in half lol [20:37] geeze, it's 4:30?! /me missed where today went [20:38] oh yeah you guys are now 2h away from me [20:38] guess I'll be lonely for more of the day now :'( [20:38] some days just don't feel like you moved the needle forward at all ugh [20:38] truth! [20:40] yay, landed [20:40] yay [20:43] rick_h_: results from staging. still looking at it. http://paste.ubuntu.com/7069840/plain/ [20:46] bac: is it just me or is this just a few results? [20:46] I find score 11 times on there? [20:46] hmm, total says "384" ? /me is confused [20:47] paste was probably like '5MB? fogetaboutit!!!' [20:47] no, it looks complete, but 11 results let to 384 in our results? [20:59] rick_h_, bbcsupermicro is having a hard time deploying a bundle [20:59] what's the URL structure again? [20:59] juju quickstart bundle:http://launchpad.net/~jorge/charms/bundles/mediawiki-simple/bundle [21:00] bac: so in looking at this it seems like there's something missing. It shows 384 total but only lists 10 here. These 10 are good results though. Scores go from 20 down to 1. I like these results you pasted and wonder if we can ignore the rest like they seemed to [21:00] juju quickstart bundle:~jorge/charms/bundles/mediawiki-simple/bundle [21:00] also doesn't work [21:00] jcastro: checking [21:01] rick_h_: still looking. trying to read that file in as json so i can play with it. not parsing. [21:01] jcastro: sec, the deploy stuff gives you the specific revision. Looking for a revisionless url. [21:01] juju-quickstart bundle:~jorge/mediawiki-simple/5/mediawiki-simple [21:02] ugh [21:02] is meant to work for yours from the deploy tab [21:02] bac right, it's invalid [21:02] that's not what the help says [21:02] oh ok [21:02] thanks hatch [21:02] bbcmicrocomputer, ok so for each bundle [21:02] bac json needs the key and value to be quoted with " [21:02] hatch: yep [21:03] bbcmicrocomputer, the GUI has deploy instructions [21:03]