[13:08] guihelp: I need two reviews + QA for https://codereview.appspot.com/88100044 (GUI charm/python). It requires running the tests on an ec2 Juju env. Anyone available? [13:08] frankban: on it [13:08] bac: thank you! [13:08] * bac is curious as to what is required to move to trusty [13:10] bac: do you know if it's possible in launchpad to have an branch (e.g. lp:~juju-gui/charms/precise/juju-gui/trunk) point to another one (e.g. p:~juju-gui/charms/TRUSTY/juju-gui/trunk)? So that when you push to a branch also the other is updated. [13:10] frankban: no, there is no concept of aliases like that [13:10] bac: ack. So this means we'll have to push on both branches when releasing a new charm, right? [13:11] yes [13:11] frankban: is charm-tools not in trusty distro? [13:12] bac: yes it is, but it's also on the PPA, and I expect that sourc eto be the most updated one [13:12] ack [13:24] rick_h_: FYI http://bazaar.launchpad.net/~frankban/charms/precise/juju-gui/trusty-charm/view/head:/README.md#L163 (from my branch under review) includes some useful info for the sprint discussion [13:26] marcoceppi: I am looking at "charm promulgate". I see that it accepts a --series argument. Does it mean that I can promulgate the same branch to two different series? [13:27] frankban: no [13:27] I dont' think you can have two aliases for one branch [13:27] in launchpad [13:28] marcoceppi: ok, so we'll need soon to have the GUI promulgated for both precise (as it currently is) and trusty. So I guess the way to do that is to push the charm also to a trusty branch and then promulgate it, correct? [13:29] frankban: yes, ping me when you need a promulgation [13:29] marcoceppi: will do, thanks [13:38] frankban: thanks, exactly [13:47] frankban: unshallow the checkout. such godawful gitspeak. not your fault, of course. [13:50] frankban: code looks great, with some wording changes. will QA now. [13:51] bac: yeah, I am not sure that's a real English word... anyway, I am not even sure the git help is written in English, but I am not qualified to judge that [13:51] bac: thanks [13:52] oh, frankban, your English is 1000x better than linus' -- at least you give a damn [13:52] it isn't really English, though. [13:52] heh [13:52] its just making shit up [13:54] frankban: can i do 'make deploy' out of my ~/charms/precise/juju-gui directory for *trusty* or do i need to check it out a second time (or ln -s) to ~charms/trusty? [13:55] bac: you can run `make deploy SERIES=trusty` from any location. I usually develop the charm from a sandbox directory. [13:56] frankban: well, i have a lightweight checkout that lives in ~/charms/precise/juju-gui [13:57] bac: that's good, make deploy creates a juju repo under /tmp/. Its goal is to allow for developing the charm without having to manually create a local repo and place the branch in it [13:57] frankban: i notice HACKING.md has some Very Long Lines. could you wrap those please? [13:57] bac: sure [13:57] ty [13:59] frankban: sorry to nitpick but could you also s/ DVCSes/version control/ [14:01] bac: sure [14:04] bac: I see only two VLL in HACKING (lines 17 and 33), and those are links, not sure you can wrap them [14:05] frankban: ok, i didn't know the url had to abut the other. nm then [14:17] frankban: do i need to run 'make ftest' twice, once for precise and once for trusty? and the only way to do so is to use environments that have the default-series set to one or the other? [14:18] bac: yes, exactly [14:18] frankban: maybe that can be made more clear in the testing section of HACKING [14:20] frankban: if both are on ec2, will the environments need separate control-buckets? it seems reasonable that they might so that tools don't clash. but perhaps it isn't required. [14:21] bac: never tried to bootstrap two ec2 environments simultaneously [14:21] frankban: i didn't mean simultaneously [14:22] maybe i'm overthinking it [14:22] bac: I tested the charm two times just changing the default-series [14:22] ok, never mind then [14:50] jujugui call in 10 [14:50] frankban: this is going slow. ftests just finished for trusty. all passed [14:51] bac: cool, yeah charm tests are slow [15:00] jujugui call now [15:13] hatch: did you say you're out all next week too? [15:13] bac yeah, I took monday/tuesday off then I'm at gophercon [15:13] cool [15:13] I will still be around monday/tuesday but doing house type work [16:07] frankban it'll be safe to use a Model and listen on the ModelList for '*:change' events on the children [16:08] the set() call fired a single event which bubbles up so as long as we only create a single listener for *:change it won't cause memory creep [16:10] hatch: this sounds good [16:10] the model instance has a bunch of overhead over a LML but if we run into any issues it'll be easy to switch over using the technique above [16:10] we'll just have to keep an eye on it on large envs [16:10] hatch: so the change event includes the information about the modified field, right? [16:10] yeah - the only thing I'm not sure about is multiple updates [16:11] so if 10 machines get updated [16:11] that will be 10 events [16:11] we might want to throttle those [16:11] again - can be done later [16:12] hatch: using the sandbox mode we can easily check overhead, and I agree this can be done later. [16:12] bac: any progress on precise tests? [16:12] yeah good call - there was also a card I created yesterday about adding containers to the sandbox [16:13] it's in 'on deck' in project one....just fyi [16:13] frankban: yes, i went to look for your rietveld link and then got distracted. qa ok for trusty and precise. thanks! [16:15] hatch: the simulator card? cool. FWIW containers can be easily created also using the JS console, app.env.addMachines IIRC [16:15] bac: cool thanks, so do you still have the output of the trusty test? [16:15] yeah [16:28] marcoceppi: the precise release of the GUI charm is at https://code.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk . And it is referenced as lp:charms/juju-gui. Any ideas about where to push the trusty release? https://code.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk ? [16:28] frankban: that's where you should push it [16:29] lmk when it's up there and I'll promulgate that branch [16:29] marcoceppi: cool, so lp:charms/juju-gui will still be the precise one and lp:~juju-gui-charmers/charms/trusty/juju-gui will be the trusty one, right? [16:30] frankban: well, when it's promulgated lp:charms/trusty/juju-gui will be to that new branch [16:30] and juju deploy cs:trusty/juju-gui will map properly [16:30] otherwise, without promulgation, you'll have to cs:~juju-gui-charmers/trusty/juju-gui [16:31] marcoceppi: ack, thanks [17:11] Makyo looks like the new version of your branch is smaller once you moved the fn's out :) [17:11] Woo! [17:14] S&**$&@*#&@*@$&*@$&%&@*% [17:14] I just did a ton of work on the wrong branch [17:14] ugh!!!! [17:15] * hatch hopes cherry pick works [17:18] phew* that was a lot less worse than I was thinking [18:05] umm a whole ton of my emails were just deleted.... === BradCrittenden is now known as bac [18:47] * Makyo steps out to appointment [19:01] rick_h_: you around? [19:02] bac: yes [19:02] rick_h_: cool. hey i just chatted with curtis re our resources on canonistack. he thinks moving to a different provider is a good idea but suggested hp instead. [19:03] apparently antonio manages a group account so there is no billing and better uptime [19:03] bac: k, that works for me [19:04] bac: let's see if we can get some info then and work on setting it up sometime. [19:05] rick_h_: well, from the conversation i had with curtis, everything is all charmed up and should deploy over there with minimal hassle. do you want me to proceed or hold off? [19:05] bac: well, how broke are we? can we limp until vegas? [19:05] I know we have to have it but we've got a big crunch to get things ready for vegas. [19:06] rick_h_: no, staging is up but cannot be updated. right now it is on tip - 1 so it is doing us no good as a QA resource [19:06] bac: ok, can you check on the status of our inernal prodstack CI? If it's up then we've got something to catch deploy breaks I'd hold off [19:06] rick_h_: i've got landed branches that i'd like to deploy to production but have held off since they haven't been qa'ed anywhere but my local machine [19:07] bac: but if they're not ready there yet, then it's important to have a QA env to land. [19:08] rick_h_: are you referring to the tracking card to get staging up on prodstack? [19:08] i'm not sure what the status of that is. the last work i was aware of was when the ES cluster got entangled. [19:08] bac: yes, they had it up at some point as it broke our production [19:09] bac: and I didn't get to talk to them as our IS sync call was while I was traveling [19:09] bac: so if that's up/close to up then it'd be shorter to use that as a QA/safety check [19:09] before a release [19:09] rick_h_: https://rt.admin.canonical.com/Ticket/Display.html?id=67257 [19:10] the latest message makes it sound available [19:10] bac: bingo [19:10] bac: yea, so if this works out then I'd say hold off on a new qa environment until post vegas [19:10] perfect [19:11] oi, not so perfect. doing a search causes it to fall over. perhaps ES is not up. [19:12] rick_h_: ^ [19:12] i'll work with webops to see what's going on. have a good afternoon. [19:12] bac: thanks [19:29] guihelp https://github.com/juju/juju-gui/pull/239 is ready for review [19:32] kadams54 on it [19:34] hatch thanks [19:39] kadams54 I dont' understand what needs to be straightened out with the view utils? [19:39] Talk to Rick… he was the one who looked into it [19:39] ^ rick_h_ [19:41] I see the test failure but I'm not sure what it has to do with the utils [19:42] hatch: it's a YUI dep thing. The test utils use stuff like viewlets but doesn't depend on any view stuff [19:42] hatch: we've got a borked dep chain from what I can see, and the alias 'include all of this' stuff is poor form imo [19:43] hatch: it makes it hard to trace down these issues when something doesn't line up right as most things aren't explicit in their includes/etc [19:43] the goups you mean? Yeah I've never liked that [19:44] hatch: right, and the test utils clearly should require some view stuff but don't [19:44] but because they're pulled in with other things that do pull in all the view it 'works' [19:44] We tried to get the tests working without depending on the juju-views group (just depending on juju-serviceunit-token directly) but that's when rick_h_ ran into problems with test-utils [19:45] kind of by accident and that was part of the failure for kadams54. If he didn't use() juju-views then there would be dep issues [19:45] even though he's adding a simple widget that doesn't need that space at all [19:45] * rick_h_ grumbles about these small things getting put into views just because they're an instance of Y.View vs widgets or components or something else [19:45] So it sucks but going this route (a comment) lets me at least get the code reviewed so we can keep the card moving forward. [19:48] oh juju-tests-utils is the module that needed juju-views? [19:48] hatch: right [19:48] hatch: at least i think so [19:48] ohh ok that's not what the comment says [19:48] heh [19:48] after a point I gave up [19:52] when I remove the change from modules-prod and change the module in test_serviceunit to 'juju-serviceunit-token' it works fine locally [19:53] that's the only change that happened between the test failure and passing? [19:53] Are you running test-prod? [19:53] Yeah [19:53] test-prod failed without (even locally) and worked with [19:54] The only change was adding that line to modules-prod [19:54] yeah it's working here no problem [19:54] even if I remove every other test suite [19:55] Honestly though, I don't really care about that… it's sorta secondary to the main purpose [19:55] Which is implementing unit tokens :-) [19:58] I have a diff for you to try if I can paste it somewhere.... [19:58] darn gist is broken [19:59] kadams54 try this diff http://paste.ubuntu.com/7257293/ [19:59] thats using your branch merged into develop as a base [20:00] Thanks, will do [20:13] kadams54 done and done [20:16] kadams54 any luck with that diff? [20:16] you should be able to apply it using patch [20:17] marcoceppi you're having issues :) [20:19] hatch: no you're having issues [20:19] I AM NOT THE PROBLEMMMM [20:19] * marcoceppi goes to check server connectivity [20:19] lol [20:26] Makyo u back yet? [21:03] Makyo it's ok I got it [21:08] 322 test failures - here's hoping that they are cascading failures [21:20] Makyo since you're into timelapse you might find this cool https://plus.google.com/117025856686519461862/posts/Z5UEae2zNfb [21:38] Script error. (:0) [21:38] best test failure error....ever [22:25] hatch, I saw that, hah. Better than my attempt, which was just mistake after mistake. [22:28] Makyo, the timelapse? :) [22:28] hatch, yeah [22:29] Here's the unedited one I made: https://www.youtube.com/watch?v=QshXrhBFOBU [22:51] :) looks pretty cool [23:00] Morning [23:49] hey huwshimi hows it going? [23:50] hatch: [23:50] erm [23:50] hatch: Hey, good thanks :)