| 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:08 | |
| 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:10 |
| bac | yes | 13:11 |
| bac | frankban: is charm-tools not in trusty distro? | 13:11 |
| 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:12 |
| 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:24 |
| 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:26 |
| marcoceppi | frankban: no | 13:27 |
| marcoceppi | I dont' think you can have two aliases for one branch | 13:27 |
| marcoceppi | in launchpad | 13:27 |
| 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:28 |
| marcoceppi | frankban: yes, ping me when you need a promulgation | 13:29 |
| frankban | marcoceppi: will do, thanks | 13:29 |
| rick_h_ | frankban: thanks, exactly | 13:38 |
| bac | frankban: unshallow the checkout. such godawful gitspeak. not your fault, of course. | 13:47 |
| bac | frankban: code looks great, with some wording changes. will QA now. | 13:50 |
| 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:51 |
| 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:52 |
| 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:54 |
| frankban | bac: you can run `make deploy SERIES=trusty` from any location. I usually develop the charm from a sandbox directory. | 13:55 |
| bac | frankban: well, i have a lightweight checkout that lives in ~/charms/precise/juju-gui | 13:56 |
| 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:57 |
| bac | frankban: sorry to nitpick but could you also s/ DVCSes/version control/ | 13:59 |
| frankban | bac: sure | 14:01 |
| frankban | bac: I see only two VLL in HACKING (lines 17 and 33), and those are links, not sure you can wrap them | 14:04 |
| bac | frankban: ok, i didn't know the url had to abut the other. nm then | 14:05 |
| 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:17 |
| frankban | bac: yes, exactly | 14:18 |
| bac | frankban: maybe that can be made more clear in the testing section of HACKING | 14:18 |
| 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:20 |
| frankban | bac: never tried to bootstrap two ec2 environments simultaneously | 14:21 |
| bac | frankban: i didn't mean simultaneously | 14:21 |
| 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:22 |
| Makyo | jujugui call in 10 | 14:50 |
| bac | frankban: this is going slow. ftests just finished for trusty. all passed | 14:50 |
| frankban | bac: cool, yeah charm tests are slow | 14:51 |
| hatch | jujugui call now | 15:00 |
| 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 | 15:13 |
| hatch | frankban it'll be safe to use a Model and listen on the ModelList for '*:change' events on the children | 16:07 |
| 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:08 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:15 |
| 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:28 |
| 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:29 |
| 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:30 |
| frankban | marcoceppi: ack, thanks | 16:31 |
| hatch | Makyo looks like the new version of your branch is smaller once you moved the fn's out :) | 17:11 |
| Makyo | Woo! | 17:11 |
| hatch | S&**$&@*#&@*@$&*@$&%&@*% | 17:14 |
| hatch | I just did a ton of work on the wrong branch | 17:14 |
| hatch | ugh!!!! | 17:14 |
| * hatch hopes cherry pick works | 17:15 | |
| hatch | phew* that was a lot less worse than I was thinking | 17:18 |
| hatch | umm a whole ton of my emails were just deleted.... | 18:05 |
| === BradCrittenden is now known as bac | ||
| * Makyo steps out to appointment | 18:47 | |
| bac | rick_h_: you around? | 19:01 |
| 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:02 |
| 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:03 |
| rick_h_ | bac: let's see if we can get some info then and work on setting it up sometime. | 19:04 |
| 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:05 |
| 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:06 |
| rick_h_ | bac: but if they're not ready there yet, then it's important to have a QA env to land. | 19:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| bac | oi, not so perfect. doing a search causes it to fall over. perhaps ES is not up. | 19:11 |
| 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:12 |
| kadams54 | guihelp https://github.com/juju/juju-gui/pull/239 is ready for review | 19:29 |
| hatch | kadams54 on it | 19:32 |
| kadams54 | hatch thanks | 19:34 |
| 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:39 |
| hatch | I see the test failure but I'm not sure what it has to do with the utils | 19:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:48 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| hatch | I have a diff for you to try if I can paste it somewhere.... | 19:58 |
| hatch | darn gist is broken | 19:58 |
| hatch | kadams54 try this diff http://paste.ubuntu.com/7257293/ | 19:59 |
| hatch | thats using your branch merged into develop as a base | 19:59 |
| kadams54 | Thanks, will do | 20:00 |
| hatch | kadams54 done and done | 20:13 |
| hatch | kadams54 any luck with that diff? | 20:16 |
| hatch | you should be able to apply it using patch | 20:16 |
| hatch | marcoceppi you're having issues :) | 20:17 |
| 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:19 |
| hatch | Makyo u back yet? | 20:26 |
| hatch | Makyo it's ok I got it | 21:03 |
| hatch | 322 test failures - here's hoping that they are cascading failures | 21:08 |
| hatch | Makyo since you're into timelapse you might find this cool https://plus.google.com/117025856686519461862/posts/Z5UEae2zNfb | 21:20 |
| hatch | Script error. (:0) | 21:38 |
| hatch | best test failure error....ever | 21:38 |
| Makyo | hatch, I saw that, hah. Better than my attempt, which was just mistake after mistake. | 22:25 |
| hatch | Makyo, the timelapse? :) | 22:28 |
| Makyo | hatch, yeah | 22:28 |
| Makyo | Here's the unedited one I made: https://www.youtube.com/watch?v=QshXrhBFOBU | 22:29 |
| hatch | :) looks pretty cool | 22:51 |
| huwshimi | Morning | 23:00 |
| hatch | hey huwshimi hows it going? | 23:49 |
| huwshimi | hatch: | 23:50 |
| huwshimi | erm | 23:50 |
| huwshimi | hatch: Hey, good thanks :) | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!