[13:08] <frankban> 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] <bac> frankban: on it
[13:08] <frankban> bac: thank you!
[13:08]  * bac is curious as to what is required to move to trusty
[13:10] <frankban> 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] <bac> frankban: no, there is no concept of aliases like that
[13:10] <frankban> bac: ack. So this means we'll have to push on both branches when releasing a new charm, right?
[13:11] <bac> yes
[13:11] <bac> frankban: is charm-tools not in trusty distro?
[13:12] <frankban> bac: yes it is, but it's also on the PPA, and I expect that sourc eto be the most updated one
[13:12] <bac> ack
[13:24] <frankban> 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] <frankban> 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] <marcoceppi> frankban: no
[13:27] <marcoceppi> I dont' think you can have two aliases for one branch
[13:27] <marcoceppi> in launchpad
[13:28] <frankban> 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] <marcoceppi> frankban: yes, ping me when you need a promulgation
[13:29] <frankban> marcoceppi: will do, thanks
[13:38] <rick_h_> frankban: thanks, exactly
[13:47] <bac> frankban: unshallow the checkout.  such godawful gitspeak.  not your fault, of course.
[13:50] <bac> frankban: code looks great, with some wording changes.  will QA now.
[13:51] <frankban> 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] <frankban> bac: thanks
[13:52] <bac> oh, frankban, your English is 1000x better than linus' -- at least you give a damn
[13:52] <bac> it isn't really English, though.
[13:52] <frankban> heh
[13:52] <bac> its just making shit up
[13:54] <bac> 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] <frankban> bac: you can run `make deploy SERIES=trusty` from any location. I usually develop the charm from a sandbox directory.
[13:56] <bac> frankban: well, i have a lightweight checkout that lives in ~/charms/precise/juju-gui
[13:57] <frankban> 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] <bac> frankban: i notice HACKING.md has some Very Long Lines.  could you wrap those please?
[13:57] <frankban> bac: sure
[13:57] <bac> ty
[13:59] <bac> frankban: sorry to nitpick but could you also s/ DVCSes/version control/
[14:01] <frankban> bac: sure
[14:04] <frankban> bac: I see only two VLL in HACKING (lines 17 and 33), and those are links, not sure you can wrap them
[14:05] <bac> frankban: ok, i didn't know the url had to abut the other.  nm then
[14:17] <bac> 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] <frankban> bac: yes, exactly
[14:18] <bac> frankban: maybe that can be made more clear in the testing section of HACKING
[14:20] <bac> 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] <frankban> bac: never tried to bootstrap two ec2 environments simultaneously
[14:21] <bac> frankban: i didn't mean simultaneously
[14:22] <bac> maybe i'm overthinking it
[14:22] <frankban> bac: I tested the charm two times just changing the default-series
[14:22] <bac> ok, never mind then
[14:50] <Makyo> jujugui call in 10
[14:50] <bac> frankban: this is going slow.  ftests just finished for trusty.  all passed
[14:51] <frankban> bac: cool, yeah charm tests are slow
[15:00] <hatch> jujugui call now
[15:13] <bac> hatch: did you say you're out all next week too?
[15:13] <hatch> bac yeah, I took monday/tuesday off then I'm at gophercon
[15:13] <bac> cool
[15:13] <hatch> I will still be around monday/tuesday but doing house type work
[16:07] <hatch> frankban it'll be safe to use a Model and listen on the ModelList for '*:change' events on the children
[16:08] <hatch> 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] <frankban> hatch: this sounds good
[16:10] <hatch> 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] <hatch> we'll just have to keep an eye on it on large envs
[16:10] <frankban> hatch: so the change event includes the information about the modified field, right?
[16:10] <hatch> yeah - the only thing I'm not sure about is multiple updates
[16:11] <hatch> so if 10 machines get updated
[16:11] <hatch> that will be 10 events
[16:11] <hatch> we might want to throttle those
[16:11] <hatch> again - can be done later
[16:12] <frankban> hatch: using the sandbox mode we can easily check overhead, and I agree this can be done later. 
[16:12] <frankban> bac: any progress on precise tests?
[16:12] <hatch> yeah good call - there was also a card I created yesterday about adding containers to the sandbox
[16:13] <hatch> it's in 'on deck' in project one....just fyi
[16:13] <bac> frankban: yes, i went to look for your rietveld link and then got distracted.  qa ok for trusty and precise.  thanks!
[16:15] <frankban> hatch: the simulator card? cool. FWIW containers can be easily created also using the JS console, app.env.addMachines IIRC
[16:15] <frankban> bac: cool thanks, so do you still have the output of the trusty test?
[16:15] <hatch> yeah
[16:28] <frankban> 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] <marcoceppi> frankban: that's where you should push it
[16:29] <marcoceppi> lmk when it's up there and I'll promulgate that branch
[16:29] <frankban> 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] <marcoceppi> frankban: well, when it's promulgated lp:charms/trusty/juju-gui will be to that new branch
[16:30] <marcoceppi> and juju deploy cs:trusty/juju-gui will map properly
[16:30] <marcoceppi> otherwise, without promulgation, you'll have to cs:~juju-gui-charmers/trusty/juju-gui
[16:31] <frankban> marcoceppi: ack, thanks
[17:11] <hatch> Makyo looks like the new version of your branch is smaller once you moved the fn's out :)
[17:11] <Makyo> Woo!
[17:14] <hatch> S&**$&@*#&@*@$&*@$&%&@*%
[17:14] <hatch> I just did a ton of work on the wrong branch
[17:14] <hatch> ugh!!!!
[17:15]  * hatch hopes cherry pick works
[17:18] <hatch> phew* that was a lot less worse than I was thinking
[18:05] <hatch> umm a whole ton of my emails were just deleted....
[18:47]  * Makyo steps out to appointment
[19:01] <bac> rick_h_: you around?
[19:02] <rick_h_> bac: yes
[19:02] <bac> 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] <bac> apparently antonio manages a group account so there is no billing and better uptime
[19:03] <rick_h_> bac: k, that works for me
[19:04] <rick_h_> bac: let's see if we can get some info then and work on setting it up sometime.
[19:05] <bac> 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] <rick_h_> bac: well, how broke are we? can we limp until vegas? 
[19:05] <rick_h_> I know we have to have it but we've got a big crunch to get things ready for vegas. 
[19:06] <bac> 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] <rick_h_> 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] <bac> 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] <rick_h_> bac: but if they're not ready there yet, then it's important to have a QA env to land. 
[19:08] <bac> rick_h_: are you referring to the tracking card to get staging up on prodstack?
[19:08] <bac> 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] <rick_h_> bac: yes, they had it up at some point as it broke our production
[19:09] <rick_h_> bac: and I didn't get to talk to them as our IS sync call was while I was traveling
[19:09] <rick_h_> bac: so if that's up/close to up then it'd be shorter to use that as a QA/safety check 
[19:09] <rick_h_> before a release
[19:09] <bac> rick_h_: https://rt.admin.canonical.com/Ticket/Display.html?id=67257
[19:10] <bac> the latest message makes it sound available
[19:10] <rick_h_> bac: bingo
[19:10] <rick_h_> bac: yea, so if this works out then I'd say hold off on a new qa environment until post vegas
[19:10] <bac> perfect
[19:11] <bac> oi, not so perfect.  doing a search causes it to fall over.  perhaps ES is not up.
[19:12] <bac> rick_h_: ^
[19:12] <bac> i'll work with webops to see what's going on.  have a good afternoon.
[19:12] <rick_h_> bac: thanks
[19:29] <kadams54> guihelp https://github.com/juju/juju-gui/pull/239 is ready for review
[19:32] <hatch> kadams54 on it
[19:34] <kadams54> hatch thanks
[19:39] <hatch> kadams54 I dont' understand what needs to be straightened out with the view utils?
[19:39] <kadams54> Talk to Rick… he was the one who looked into it
[19:39] <hatch> ^ rick_h_ 
[19:41] <hatch> I see the test failure but I'm not sure what it has to do with the utils 
[19:42] <rick_h_> hatch: it's a YUI dep thing. The test utils use stuff like viewlets but doesn't depend on any view stuff
[19:42] <rick_h_> 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] <rick_h_> 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] <hatch> the goups you mean? Yeah I've never liked that
[19:44] <rick_h_> hatch: right, and the test utils clearly should require some view stuff but don't
[19:44] <rick_h_> but because they're pulled in with other things that do pull in all the view it 'works'
[19:44] <kadams54> 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] <rick_h_> 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] <rick_h_> 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] <kadams54> 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] <hatch> oh juju-tests-utils is the module that needed juju-views?
[19:48] <rick_h_> hatch: right
[19:48] <rick_h_> hatch: at least i think so
[19:48] <hatch> ohh ok that's not what the comment says
[19:48] <hatch> heh
[19:48] <rick_h_> after a point I gave up
[19:52] <hatch> 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] <hatch> that's the only change that happened between the test failure and passing?
[19:53] <kadams54> Are you running test-prod?
[19:53] <kadams54> Yeah
[19:53] <kadams54> test-prod failed without (even locally) and worked with
[19:54] <kadams54> The only change was adding that line to modules-prod
[19:54] <hatch> yeah it's working here no problem
[19:54] <hatch> even if I remove every other test suite
[19:55] <kadams54> Honestly though, I don't really care about that… it's sorta secondary to the main purpose
[19:55] <kadams54> Which is implementing unit tokens :-)
[19:58] <hatch> I have a diff for you to try if I can paste it somewhere....
[19:58] <hatch> darn gist is broken
[19:59] <hatch> kadams54 try this diff http://paste.ubuntu.com/7257293/
[19:59] <hatch> thats using your branch merged into develop as a base
[20:00] <kadams54> Thanks, will do
[20:13] <hatch> kadams54 done and done
[20:16] <hatch> kadams54 any luck with that diff?
[20:16] <hatch> you should be able to apply it using patch
[20:17] <hatch> marcoceppi you're having issues :)
[20:19] <marcoceppi> hatch: no you're having issues
[20:19] <marcoceppi> I AM NOT THE PROBLEMMMM
[20:19]  * marcoceppi goes to check server connectivity
[20:19] <hatch> lol
[20:26] <hatch> Makyo u back yet?
[21:03] <hatch> Makyo it's ok I got it
[21:08] <hatch> 322 test failures - here's hoping that they are cascading failures
[21:20] <hatch> Makyo since you're into timelapse you might find this cool https://plus.google.com/117025856686519461862/posts/Z5UEae2zNfb
[21:38] <hatch> Script error. (:0)
[21:38] <hatch> best test failure error....ever
[22:25] <Makyo> hatch, I saw that, hah.  Better than my attempt, which was just mistake after mistake.
[22:28] <hatch> Makyo, the timelapse? :)
[22:28] <Makyo> hatch, yeah
[22:29] <Makyo> Here's the unedited one I made: https://www.youtube.com/watch?v=QshXrhBFOBU
[22:51] <hatch> :) looks pretty cool
[23:00] <huwshimi> Morning
[23:49] <hatch> hey huwshimi  hows it going?
[23:50] <huwshimi> hatch: 
[23:50] <huwshimi> erm
[23:50] <huwshimi> hatch: Hey, good thanks :)