| huwshimi | gary_poster: Are you around? | 00:37 |
|---|---|---|
| gary_poster | huwshimi, unfortunately :-P | 00:37 |
| gary_poster | not for your sake, for the sake of staring at my branch :-) | 00:37 |
| huwshimi | :) | 00:38 |
| gary_poster | hey hatch, if you are around could you give https://codereview.appspot.com/12306043 a once over? I'm going to ask Francesco to review, land, qa and release the gui his tomorrow morning. then I'll ask benji and curtis to coordinate testing the charm upgrade and the GUI upgrade. | 01:17 |
| gary_poster | email sent | 01:42 |
| gary_poster | I'm outta here. Bye all. I'll check email occasionally | 01:43 |
| === gary_poster is now known as gary_poster|away | ||
| hatch | gary_poster|away: sorry I was out - I'll give it a review now. cya! | 05:31 |
| rick_h | frankban: seen the emails. If there's anything I can help with please let me know. | 10:57 |
| frankban | rick_h: thank you. I just landed a branch that should fix the service menu bug. I am going to QA now for the release, more QA eyes can help | 10:59 |
| rick_h | frankban: rgr, will pull it down. | 10:59 |
| frankban | rick_h: everything seems to work here, except for a bug also present in the current release: destroying a service from the service detail view does not work | 11:20 |
| rick_h | frankban: hmm, works here. That's the popup menu when you click on a service? | 11:21 |
| rick_h | frankban: ah, I see, when you click on it in details. My bad | 11:22 |
| frankban | rick_h: no, double click a service, and then click the destroy button, yes | 11:22 |
| rick_h | yea, the "are you sure" dialog pops up and the immediately closes | 11:22 |
| frankban | rick_h: exactly, I don't think this is a release blocker | 11:23 |
| rick_h | ok, I'll file a bug for the moment on that then. Looking into the reason right now | 11:24 |
| frankban | rick_h: cool, please ping me if you think there is a really quick solution for the problem | 11:24 |
| rick_h | frankban: yea, it's showing as -hidden so something in the code is running a .hide(). I'm not familiar with the detail view. Will go with a bug for now if it's not a blocker. | 11:25 |
| frankban | rick_h: I assume it's not a blocker b/c it's not a new bug | 11:25 |
| rick_h | ah, interesting. I'd agree then. And there's a workaround to destroy from the service icon | 11:26 |
| rick_h | frankban: one line fix | 11:33 |
| frankban | rick_h: great! | 11:34 |
| rick_h | frankban: http://paste.mitechie.com/show/986/ | 11:34 |
| rick_h | frankban: can you apply please? My trunk is a little messed up due to an accidental commit to trunk and I need to clean it up | 11:34 |
| frankban | rick_h: sure, thank you | 11:35 |
| frankban | rick_h: charmbrowser QA seems great to me, could you please confirm? | 11:38 |
| rick_h | frankban: yes, I've not been able to break it. +1 | 11:39 |
| frankban | rick_h: do you have time to write a quick changelog for this release, so that I can put that in the changes.yaml file? if not, no worries. | 11:40 |
| rick_h | frankban: sec. /me looks | 11:41 |
| rick_h | frankban: should just be able to go through the releasable cards right? | 11:41 |
| frankban | rick_h: yes, or here: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/changes | 11:42 |
| rick_h | frankban: k, working on it | 11:42 |
| frankban | rick_h: thanks | 11:42 |
| rick_h | frankban: http://paste.mitechie.com/show/987/ I think works going at it a little quickly. Rest of the cards are charmworld or not really 'changelog' items | 11:45 |
| frankban | rick_h: nice, thanks! | 11:47 |
| benji | frankban: how goes the release? | 11:57 |
| frankban | benji: QA is done. Now starting the release process. I am also running the CI tests, just in case. | 11:58 |
| benji | cool | 11:58 |
| bac | benji: are you going to work on the iom demo today? i've created cards and reference the google doc. | 12:16 |
| benji | bac: I have some availability, but my main priority is upgrading the charm. I should have some time but I don't know for how long. | 12:17 |
| benji | I'll help any way I can. | 12:17 |
| bac | benji: ok, i didn't know how far you'd gotten on the charm | 12:18 |
| benji | it is ready to go; I'm waiting on the release now | 12:18 |
| benji | well, my changes are ready to merge, that's what I'm doing now | 12:19 |
| * bac loves the yaml. deployer example config had one line missing an indentation space and it went nuts. | 12:37 | |
| benji | yeah, significant whitespace will never catch on | 12:39 |
| bac | hey, that's different! :) | 12:39 |
| bac | benji: and the py interpreter gives a better error message than 'expected key missing' | 12:40 |
| benji | there is that; I guess every good idea can be done badly | 12:40 |
| frankban | guihelp: CI tests fail during the charm installation :-/ (make distfile): http://pastebin.ubuntu.com/5939960/ | 12:55 |
| frankban | guihelp: I assume there is an error in deploying the charm using a branch as juju-gui-source? Should we consider this a release blocker? | 13:04 |
| teknico | frankban: uhm, no idea | 13:05 |
| benji | frankban: I am not aware of that bug (but I haven't tried it recently either) | 13:06 |
| adeuring | abentley: could you have a look at this mp? https://code.launchpad.net/~adeuring/charmworld/1206158-dl-count-by-week-half-year/+merge/178265 | 13:11 |
| abentley | adeuring: sure. | 13:11 |
| abentley | adeuring: r=me. | 13:15 |
| frankban | benji: I am trying to dupe using juju-core. I'll also check if this is a regression introduced after the last stable release. If so, I don't think we should go on, otherwise, I'll proceed with the release. Sounds good? | 13:16 |
| rick_h | frankban: hmm, I just did a fresh checkout/build and didn't hit that. | 13:16 |
| frankban | rick_h: yeah. Build works locally here too. What nodejs version are you using? | 13:16 |
| rick_h | frankban: 0.10.8 | 13:16 |
| benji | frankban: sounds good; note that I merged my changes to juju-gui-charmers trunk within the last hour so it is possible that I caused any problems with those changes (but I don't see how) | 13:17 |
| rick_h | benji: gary_poster's branch yesterday updated a npm file with a bunch of 'mechanical' looking changes | 13:17 |
| rick_h | I wonder if anything in there wasn't good | 13:17 |
| adeuring | abentley: thanks | 13:17 |
| frankban | benji: CI uses cs:~juju-gui/precise/juju-gui . That's a different charm, right? | 13:18 |
| abentley | bac, benji: Can we do a hangout on bundles? | 13:19 |
| benji | frankban: I don't know exactly how it works, but my understanding is that the juju-gui-charmers trunk is the source for the official gui charm. My understanding is that within 15-20 minutes of landing to trunk the new charm should be in force | 13:19 |
| rick_h | frankban: looking at https://codereview.appspot.com/12306043/patch/1/1004 some of the grunt items were version updated? contextify was updated from 0.1.5 to 0.1.6 | 13:20 |
| bac | abentley: sure | 13:20 |
| benji | abentley: I'm consumed with release things at the moment | 13:20 |
| frankban | rick_h: I have v0.10.5 locally. The charm (precise) installs v0.8.23. Perhaps this is relevant? | 13:20 |
| rick_h | frankban: ouch! | 13:20 |
| rick_h | frankban: yea, that's not good if it's that far behind. | 13:20 |
| frankban | yeah, I guessed so :-/ | 13:20 |
| rick_h | doesn't hacking still require going through a nodejs ppa? | 13:21 |
| rick_h | I would have expected the charm to also pull the sudo add-apt-repository ppa:chris-lea/node.js ppa | 13:21 |
| rick_h | ? | 13:21 |
| rick_h | as it's what we dev against | 13:22 |
| rick_h | sinzui: around? did IS change/frown on this? | 13:22 |
| sinzui | rick_h, that wont work | 13:23 |
| abentley | rick_h: IS generally want to use only things in the main archive or the precise-cat archive (or whatever series is appropriate). | 13:23 |
| rick_h | frankban: I'm going to guess we've got bigger issues then. I'm not sure how we released before tbh with a 0.8 nodejs | 13:24 |
| sinzui | rick_h, frankban. I think all packages need to be installed in "cat" which is mad available via the exec.d hack | 13:24 |
| frankban | rick_h: this can be a very old regression | 13:24 |
| sinzui | we need an rt to place a package in cat. | 13:24 |
| sinzui | PS there is 1 webops today. He has 2.5h before EOD. I hope to monopolise him to move charmworld's mongodb | 13:25 |
| frankban | rick_h: I believe the charm takes npm from https://launchpad.net/~juju-gui-charmers/+archive/stable | 13:26 |
| rick_h | ugh, friday release fail | 13:26 |
| frankban | s/npm/nodejs/ | 13:27 |
| rick_h | frankban: oh hmm, and that's an old release from that ppa it appears. | 13:27 |
| rick_h | frankban: so yea, I've no idea how this works I guess :/ We're running 2 large versions ahead in dev, just updated the revisions of some deps, and things went boom on production. | 13:27 |
| sinzui | frankban, rick_h, webops make fat charms. they don't deploy the ones we give them. The can update their scripts to pull a branch of need dep, then add it to the charm. | 13:27 |
| rick_h | sinzui: well at this point I'm confused. If we've been running an old version for a known reason for a while then I don't want to suggest updating it | 13:28 |
| rick_h | I'm guessing we're on 0.8 for a reason then? However, it seems devs are all on 0.10 | 13:28 |
| hatch | yes | 13:28 |
| rick_h | I know hatch has tinkered with nodejs versions so we'll bug him | 13:28 |
| rick_h | ...starting now | 13:28 |
| hatch | lol | 13:29 |
| frankban | sinzui, rick_h: I also believe webops deploy from releases. This bug only affects deployment using branches (e.g. juju-gui-source=lp:..). node/npm are only required to create releases from branches. | 13:29 |
| sinzui | frankban, correct | 13:29 |
| rick_h | frankban: ah, that's what you mean by 'old regression' then? Maybe deployment from branches has had issues for a while but only now seeing? | 13:29 |
| hatch | reading backlog | 13:30 |
| antdillon | rick_h, My branch is lp:~ya-bo-ng/juju-gui/typography-charm-details | 13:30 |
| frankban | rick_h: exactly, especially considering the functional test in the charm uses a fake branch | 13:30 |
| hatch | frankban: is g++ installed? | 13:30 |
| sinzui | rick_h, the webops script retrieves the tarball from lp and places it in the charm, | 13:30 |
| rick_h | frankban: k, then I guess it sounds like it's a non-blocker if we can get a release build? | 13:30 |
| rick_h | antdillon: thanks, I'll create a card on the board for it and try to get some eyeballs on it after we get teh release issues worked through . | 13:31 |
| frankban | rick_h: yes, that's what I am checking with juju-core. Even like that, I am nervous making a release without being able to run the CI tests (and they are broken in canonistack for quite a while) | 13:32 |
| antdillon | rick_h, Awesome thank you! | 13:32 |
| rick_h | frankban: yes, agreed there | 13:32 |
| frankban | rick_h: g++? is that a new requirement for the charm? | 13:32 |
| frankban | sorry, hatch ^^^ | 13:32 |
| hatch | frankban: yes | 13:32 |
| hatch | I'm not sure why though | 13:33 |
| hatch | I just know that gary had an issue attempting to deploy when it wasn't installed | 13:33 |
| frankban | http://nooooooooooooooo.com/ | 13:33 |
| rick_h | lol | 13:33 |
| rick_h | npm dep requiring c-speedups? w..t..f | 13:34 |
| frankban | there is no mention of g++ in the charm sources, nor in our ppa (https://launchpad.net/~juju-gui-charmers/+archive/stable) | 13:34 |
| hatch | can't we just add apt-get install g++ ? | 13:35 |
| hatch | to see if that fixes it? | 13:35 |
| frankban | I suppose we can | 13:36 |
| * rick_h runs and gets more coffee... | 13:36 | |
| rick_h | I can't look | 13:36 |
| hatch | hmm I think this shrinkwrap is busted | 13:38 |
| hatch | it's changed a ton of versions | 13:38 |
| hatch | on trunk I can no longer run make | 13:42 |
| hatch | make: *** No rule to make target `app/assets/javascripts/d3.v2.js', needed by `build-shared/juju-ui/assets/modules.js'. Stop. | 13:42 |
| hatch | d3.v2 was removed.... | 13:43 |
| bac | hatch: make clean | 13:45 |
| frankban | hatch: we switched to d3 v3 | 13:45 |
| hatch | yeah... I did a fresh checkout | 13:45 |
| hatch | hoping that fixes it | 13:45 |
| hatch | yeah must have had something hanging around | 13:45 |
| hatch | frankban: is it attempting to build now with g++? | 13:46 |
| * benji reboots | 13:47 | |
| bac | sinzui: staging.jujucharms.com is broken when trying to view a specific charm | 13:48 |
| bac | sinzui: can i get login access to staging? | 13:48 |
| frankban | hatch: right now I am trying to understand what revision introduced this regression. rick_h: this is not an old bug, juju set -e go juju-gui juju-gui-source=lp:juju-gui:897 worked well | 13:48 |
| sinzui | bac, sure. It is just a special nova file to source | 13:49 |
| rick_h | frankban: I'd assume it was gary's branch that changed the shinkwrap.json? | 13:49 |
| bac | sinzui: i noticed staging was dead after i pushed my bundle branch. sadly i didn't check it before so i don't know if that is the culprit | 13:49 |
| sinzui | bac. mongo is angry | 13:50 |
| sinzui | OperationFailure: !loc.isNull() | 13:50 |
| frankban | rick_h: I am testing revision 917. then I will go with 918, which is Gary's branches I merged this morning. | 13:50 |
| adeuring | abentley: seems that the mongodb on staging is badly broken. Try to access any charm deital page... | 13:50 |
| adeuring | File "/home/webops_deploy/charmworld/local/lib/python2.7/site-packages/pymongo/mongo_client.py", line 789, in __check_response_to_last_error | 13:50 |
| adeuring | raise OperationFailure(details["err"]) | 13:50 |
| adeuring | OperationFailure: !loc.isNull() | 13:50 |
| rick_h | frankban: rgr | 13:50 |
| frankban | "Friday, never hesitate..." | 13:51 |
| abentley | adeuring: looking. | 13:51 |
| rick_h | frankban: I thought it was "Friday, never again"? | 13:52 |
| rick_h | oh well | 13:52 |
| abentley | sinzui: adeuring says staging mongodb is badly broken. I am investigating. | 13:52 |
| sinzui | abentley, well that is bad, because I switched it last night | 13:53 |
| abentley | sinzui: Right. | 13:53 |
| sinzui | and production switched 10 minutes ago | 13:53 |
| abentley | sinzui: it has a relation error. | 13:53 |
| frankban | rick_h: 917 fails with the same error. That's not Gary's branch | 13:53 |
| * sinzui not see that | 13:53 | |
| sinzui | ah, yes I do see that | 13:54 |
| * rick_h goes to look at 917 | 13:54 | |
| * rick_h looks at hatch | 13:54 | |
| bac | abentley: not sure if you saw my message, but this seems to have happened after i pushed a bundle branch to launchpad. | 13:54 |
| bac | abentley: trying to ingest locally i get http://paste.ubuntu.com/5940134/ | 13:55 |
| teknico | ha-ha, hatch broke the world ;-) | 13:55 |
| rick_h | frankban: ok, so something between 897 and 917? | 13:55 |
| frankban | rick_h: yes, trying to re-run the config-changed hook after installing g++ | 13:55 |
| abentley | bac: Weren't we going to test locally before pushing? | 13:55 |
| rick_h | frankban: can you try 915? I wonder if the scss stuff which broke some things is still there | 13:55 |
| teknico | (sorry hatch, just teasing you :-) ) | 13:56 |
| rick_h | frankban: I wonder if there's more deps than just the scss package still in the npm file that won't work. | 13:56 |
| adeuring | sinzui: well, managae.jujucharms.com does not seem to be affected: http://manage.jujucharms.com/charms/precise/apache2 works,m while http://staging.jujucharms.com/charms/precise/apache2 fails | 13:56 |
| bac | abentley: we talked about testing the deployer file against the deployer locally, which i did, but not about ingesting a local file. once it was pushed on LP staging found it. | 13:56 |
| sinzui | adeuring, agreed. the staging errors do not appear until 5 hours ago. We have seen this happen 3 weeks ago | 13:57 |
| * sinzui off to present | 13:57 | |
| abentley | bac: I thought getting a working deployer file was my responsibility. | 13:57 |
| bac | abentley: if the staging errors happened 5 hours ago then it isn't related | 13:57 |
| hatch | frankban: let me know if adding g++ fixes | 13:58 |
| abentley | sinzui: I believe the error is due to a stale charm-- it's running scripts/worker, which was supplanted by ingest-queued. | 13:58 |
| bac | abentley: afaik, we never assigned tasks until this morning when i made kanban cards. i sent a message here about it. | 13:58 |
| sinzui | abentley, oh dear. | 13:58 |
| sinzui | orangesquad: per https://docs.google.com/a/canonical.com/document/d/1AoMhTdrominYLBS8iHbZLW_Ji2OH3mNhUzoHjetnD9w/edit , you can see I ran /srv/deploymgr/charmworld restart | 13:59 |
| sinzui | ^ I left a copy of all the commands run | 14:00 |
| frankban | hatch: sure. rick_h: I'll try 915 later. Anyway, the real bug here is that our devenvs and our production env are really different | 14:01 |
| rick_h | frankban: +1, I'll add a discuss card I guess. | 14:01 |
| hatch | rick_h: the reason for the shrinkwrap updates is because those modules specify loose deps so when shrinkwrap was re-run it updated those loose versioned deps | 14:01 |
| frankban | rick_h: yes, please, thanks | 14:01 |
| rick_h | hatch: yea, gotcha. just trying to find something that 'changed' recenly and that's hitting close to home | 14:02 |
| rick_h | only other recent npm change I can think of is the scss work | 14:02 |
| hatch | well node-gyp requires gcc and g++ on OSX so I'm going to assume that it's also missing on 12.04 | 14:03 |
| hatch | and for some reason it's exposed itself now... | 14:03 |
| rick_h | so what needs node-gyp | 14:04 |
| rick_h | yea, node-gyp is a native build tool, so something wants to build a native package compiling on the target. Why do we need that now all of a sudden? | 14:04 |
| hatch | one theory is that it included a bin in contextify@0.1.5 but removed in 0.1.6 | 14:05 |
| hatch | but that's all I got | 14:05 |
| hatch | :) | 14:05 |
| abentley | bac: I have concerns that we may not be adequately filtering out bundles for API 2 that I wanted to discuss before pushing a bundle. | 14:05 |
| bac | abentley: shall i delete the branch? | 14:06 |
| hatch | rick_h: also the reason we are using node sass and not pysass is because the node stuff is automatically hooked up to our watch system | 14:06 |
| hatch | where the python stuff isn't | 14:06 |
| abentley | bac: if it's older than 15 minutes, it doesn't matter. | 14:06 |
| bac | abentley: let's talk when you get a chance | 14:07 |
| rick_h | grrr, I can't find anything that 'deps' on node-gyp. Just that it's installed globally and deps on npm | 14:09 |
| abentley | bac: sure. | 14:09 |
| rick_h | hatch: ok, yuea. It's in the contextify build | 14:10 |
| hatch | cool I was right | 14:11 |
| hatch | lol | 14:11 |
| hatch | my hypothesis has now been confirmed | 14:11 |
| frankban | benji, hatch, rick_h : installing g++ seems to fix the problem, I'll add the dependency in the charmers charm, then I'll merge the charmers charm into our juju-gui charm, and then I'll try CI again... | 14:11 |
| * hatch waits for his interviews | 14:11 | |
| hatch | frankban: sorry about my timezone, I could have told you that sooner ;) | 14:11 |
| benji | frankban: I'm glad you figured it out. Do be careful with the merge. It is my understanding that the charmers charm is old an disused. | 14:12 |
| abentley | sinzui: The charm is not stale; the "scripts/ingest" script is broken. | 14:12 |
| abentley | sinzui: Other methods of ingesting should work. | 14:12 |
| frankban | hatch: we encountered this problem right before you arrived. We spent the Friday morning fixing other things, so do not excuse yourself for being in Canada | 14:13 |
| hatch | lol | 14:13 |
| rick_h | hatch: ok, so that's the d3 update | 14:13 |
| rick_h | hatch: d3 requires jsom which requires contextify | 14:13 |
| rick_h | frankban: so it all comes down to our d3 upgrade which was recent and probably broke it | 14:14 |
| frankban | rick_h: yes, it seems so, double checking with CI | 14:15 |
| hatch | this is my biggest gripe with node/npm | 14:15 |
| rick_h | hatch: so that would explain why gary ran into the issue | 14:15 |
| hatch | packages are like the wild friggen west | 14:15 |
| hatch | where we're going - we don't NEEED stability | 14:15 |
| rick_h | hatch: well, you'd expect that to be in giant letters in a changelog or something for going from 2-3. That's a big req change | 14:16 |
| hatch | that's what I mean | 14:16 |
| hatch | authors update deps with no testing | 14:16 |
| hatch | then claim it works with every version of node by using the > | 14:16 |
| hatch | npm is awesome - but I think it needs less features to restrict people to do the right thing | 14:17 |
| hatch | sooooo many packages broke when 0.10 came out simply because they said they worked in >=0.8.x | 14:17 |
| rick_h | everyone fights it though. Even python/pypi just recently stopped serving beta/alpha packages out as the most recent package by default. | 14:18 |
| rick_h | hah, yea when you know that anything > 0.8 would be an api break. It's the point of using big version numbers | 14:18 |
| hatch | right | 14:19 |
| hatch | so many people in the community release things using 0.x forever | 14:20 |
| hatch | things never hit 1.0 release | 14:20 |
| hatch | I think it's so they don't have to provide a stable product lol | 14:20 |
| rick_h | meh, just ignore the 0. 0.7 to 0.8 to 0.10 == breaks | 14:21 |
| frankban | benji: charms updated (fix added to charmers, and then merged charmers into juju-gui) | 14:21 |
| hatch | awesome | 14:21 |
| hatch | rick_h: rumor has it 0.12 will be 1.0 so we can hope :) | 14:21 |
| rick_h | hatch: fine, then 1.0 to 1.1 will break :P | 14:22 |
| benji | frankban: great! let me know when the GUI release is done | 14:22 |
| frankban | benji: I'll let you know IF the release will be done | 14:22 |
| hatch | rick_h: nope it's a 1.0 release, no api breaking changes allowed! | 14:22 |
| hatch | frankban: lol | 14:22 |
| hatch | be optomistic :) | 14:23 |
| benji | heh, I guess that will work too | 14:23 |
| hatch | optimistic even | 14:23 |
| hatch | I really need to get an irc client with spell check | 14:23 |
| rick_h | jujugui looking for a second person to help review/qa antdillon's changes https://codereview.appspot.com/12343044 | 14:24 |
| benji | rick_h: I'll take a look | 14:25 |
| rick_h | thanks benji | 14:25 |
| antdillon | benji, rick_h Thank you | 14:25 |
| abentley | sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/ingest-uses-ingest-queued/+merge/178310 ? | 14:25 |
| hatch | what's going on with the typography.less file? | 14:26 |
| hatch | the type class name has no relation to the contents within it | 14:26 |
| benji | rick_h, antdillon: I don't see a diff, only "error: old chunk mismatch" | 14:26 |
| abentley | bac: Let's chat. | 14:26 |
| rick_h | benji: hmm, working for me :/ | 14:26 |
| antdillon | benji, Working for me | 14:26 |
| benji | hmm | 14:27 |
| sinzui | abentley, r=me | 14:27 |
| antdillon | benji, This not working? https://codereview.appspot.com/12343044/patch/1/1005 | 14:27 |
| benji | rick_h, antdillon: apparently only the side-by-side diffs are broken; the stright-up diffs are fine; I'll look at those | 14:28 |
| rick_h | benji: ah, reitveld fail | 14:29 |
| benji | apparently | 14:29 |
| hatch | rick_h: frankban on my tasklist is to attempt to update our packages and node to be up to date next week (re your card in discuss) | 14:30 |
| rick_h | hatch: yea, but the larger issue is more the diff in dev vs production | 14:30 |
| rick_h | we should have hit this issue when d3 was upgraded, not a week later during a deploy attempt | 14:30 |
| hatch | oh well prod will then need to be updated as it'll fall over hard :) | 14:31 |
| rick_h | hatch: and it sounds like this g++ issue was hit, but not brought up. | 14:31 |
| frankban | hatch: cool, thanks | 14:32 |
| hatch | somehow I ended up working on two branches at once | 14:33 |
| bac | abentley: ok, can you set up a hangout? i need to move rooms. | 14:34 |
| abentley | bac: https://plus.google.com/hangouts/_/b3e9170262ba4b41f761dee440dcbb9ac111cf3d?hl=en-GB | 14:36 |
| rick_h | antdillon: landing your branch. It won't be in the release today, but will be on comingsoon later today. | 14:48 |
| frankban | guihelp: http://pastebin.ubuntu.com/5940316/ I presume this only means that the unit tests in ie are particularly slow... Please confirm my impression | 14:51 |
| frankban | rick_h: please don't land GUI branches | 14:52 |
| rick_h | frankban: :/ sorry. Figured it was -r locked. It just completed | 14:53 |
| frankban | rick_h: no worries. Does antdillon change need to be QA'd? | 14:53 |
| rick_h | frankban: as to the test run, yea it says they passed, there's the skipped. Not sure why it said it can't complete. | 14:53 |
| antdillon | rick_h, Cool thanks | 14:53 |
| rick_h | frankban: no, it was qa'd as part of review. Small css font changes to the browser | 14:54 |
| frankban | rick_h, antdillon: so it will be included in the release. guihelp: please don't land GUI branches | 14:54 |
| hatch | frankban: yes we have a number of unit tests which are skipped - they shouldn't be causing it to be incomplete though | 14:55 |
| abentley | bac: The URL structure is http://manage.jujucharms.com/api/3/bundle/~sinzui/mysql-5/tiny as described here: https://docs.google.com/a/canonical.com/document/d/1H1PH0q9Mr8pSvTmRnEgptrlC-OQZK7i-Le-1SzpJG5Y/edit | 14:55 |
| frankban | hatch: that can be a problem in CI tests, but it does not block the release. unit tests passed in firefox | 14:56 |
| hatch | ok great | 14:56 |
| hatch | I have huw's branch to land so let me know when it's ok :) | 14:57 |
| abentley | sinzui: r325 and later should not be deployed to production. | 14:58 |
| sinzui | abentley, understood. Since webops are off in 1h and I am away next week. I think we have little opportunity to shoot ourselves in the foot | 14:59 |
| abentley | sinzui: Tarmac is no longer setting the revno of charmworld after landing. The value is currently -1. Suspect it's related to the lcy02 changes. diogo isn't around. | 15:03 |
| benji | call today? Maybe it is at 11 since we'll not be doing a retrospective since Gary is out. | 15:03 |
| hatch | benji: I was thinking at 10 | 15:03 |
| hatch | in 1h | 15:03 |
| hatch | just the standup | 15:03 |
| hatch | the retro was yesterday | 15:04 |
| hatch | :) | 15:04 |
| benji | cool, 11 it is ;P | 15:04 |
| hatch | haha | 15:04 |
| sinzui | damn it abentley. I swear that lazy service goes on holiday every time Diogo takes off work | 15:04 |
| sinzui | abentley, surely tarmac needs it ssh config changed | 15:05 |
| abentley | sinzui: Yes, I expect that's the problem. | 15:05 |
| hatch | rick_h: do you use vim in multiple terminal panels (using tmux or the like) or use some vim pane manager? | 15:09 |
| rick_h | hatch: I use a tiling window manager + vim | 15:10 |
| rick_h | tmux and such is just gravy and kept seperate | 15:10 |
| rick_h | hatch: vim comes with 'pane managers' called splits. http://lococast.net/archives/111 | 15:10 |
| rick_h | and buffers really | 15:10 |
| jcastro | we do charm schools with both vim and tmux splits | 15:11 |
| hatch | right now I work in tmux splits but each window is it's own terminal so I always forget to add my ssh key or osmething to one | 15:12 |
| hatch | which just irritates me heh | 15:12 |
| hatch | so that's why I was wondering :) | 15:12 |
| rick_h | hatch: use an ssh-agent | 15:12 |
| rick_h | hatch: then you init your ssh key on boot and never worry about it again | 15:12 |
| hatch | there is some wakoness to osx > ubuntu sshing | 15:12 |
| hatch | I have to run `exec ssh-agent bash` every time | 15:13 |
| hatch | http://fromanegg.com/post/45733384142/nfs-between-ubuntu-vm-and-osx-host | 15:13 |
| rick_h | https://help.github.com/articles/working-with-ssh-key-passphrases says that on OSX they can be saved in the keychain | 15:13 |
| hatch | it's not the passphrase | 15:14 |
| hatch | it's that the env variables for ssh-agent don't exist | 15:14 |
| hatch | I haven't spent the time to track that down | 15:14 |
| hatch | but I'd need to run some auto commands from tmux to fix | 15:14 |
| hatch | or something | 15:14 |
| benji | bac: I've done everything I can do and am in a holding pattern at the moment; is there anything I can do for you? | 15:14 |
| hatch | jujugui lf one review of https://codereview.appspot.com/12320044/ re-propose of huws branch with minor change | 15:15 |
| benji | hatch: on it | 15:15 |
| bac | benji: quick chat? | 15:15 |
| hatch | thanks benji | 15:15 |
| benji | bac: sure | 15:15 |
| benji | guichat? | 15:15 |
| hatch | frankban: can I merge into trunk yet? | 15:21 |
| frankban | hatch: no | 15:21 |
| hatch | ccccmmmmoooooooonnnnnnn | 15:21 |
| hatch | ;) | 15:22 |
| frankban | guihelp, please do not land GUI branches, I'll ping you later | 15:22 |
| hatch | frankban: is there anything I can help with? | 15:23 |
| frankban | hatch: not at the moment, thanks | 15:24 |
| hatch | alright well let me know if you run into something that needs another set of hands | 15:25 |
| frankban | guihelp: juju-gui 0.8.2 released \o/ Please feel free to restart landing branches. I'll live test it with juju-core. | 15:33 |
| hatch | yay | 15:34 |
| hatch | thanks a lot frankban you rock! | 15:34 |
| frankban | benji: release work done | 15:34 |
| hatch | jujugui - submitting branch | 15:34 |
| rick_h | frankban: yay! thanks for bearing through all that | 15:34 |
| rick_h | sinzui: so is there a chance of a jujucharms deploy or it sounds like nadda IS help available? | 15:35 |
| frankban | thank you for the help | 15:35 |
| benji | frankban: great! I'll proceed with my work now. | 15:35 |
| sinzui | rick_h, slim chance. .5 hours left | 15:35 |
| rick_h | benji: ^ | 15:36 |
| rick_h | in case that effects your work on the next step | 15:36 |
| benji | sinzui: .5 hours left until what? | 15:36 |
| sinzui | No webops | 15:36 |
| benji | arg! | 15:37 |
| benji | I'll see what I can do quickly | 15:37 |
| benji | (without making things worse) | 15:37 |
| benji | frankban: what is the release's version number? | 15:37 |
| rick_h | I did 0.8.2 in the changelog | 15:37 |
| hatch | awesome, I was hoping it wasn't 0.9.0 :) | 15:38 |
| frankban | benji: 0.8.2 | 15:38 |
| benji | that doesn't sound right, but we can argue about that when we have more time ;) | 15:38 |
| benji | thanks | 15:38 |
| rick_h | hatch: inspector should be 0.9 imo :) | 15:38 |
| hatch | yeah! | 15:40 |
| frankban | reliable CI should be 0.9 imho ;-) | 15:40 |
| hatch | lol!! | 15:40 |
| hatch | rick_h: I was also thinking a double bump to 0.10 ;) | 15:40 |
| hatch | haha | 15:40 |
| rick_h | frankban: hah! what is that? | 15:40 |
| frankban | heh | 15:40 |
| benji | sinzui: we are go for upgrade | 15:41 |
| sinzui | benji, 0.8.2? | 15:42 |
| benji | sinzui: yep | 15:42 |
| hatch | jujugui branch landed - anyone else is free to submit | 15:42 |
| hatch | jujugui guichat in 10 | 15:51 |
| hatch | kanban it up! | 15:51 |
| bcsaller | the anticipation grows | 15:51 |
| hatch | just wait | 15:51 |
| hatch | it'll be huge! | 15:51 |
| hatch | jujugui guichat in 2 | 15:58 |
| sinzui | jujugui 0.8.2 is deployed | 16:09 |
| benji | yay! | 16:09 |
| rick_h | sinzui: rock on! | 16:09 |
| rick_h | benji: http://hg.python.org/peps/rev/82e24ac40255 | 16:13 |
| * benji looks | 16:13 | |
| hatch | rick_h: you can probably hold off on reviewing bcsaller's branch | 16:13 |
| rick_h | hatch: ok | 16:13 |
| hatch | there is a QA failure | 16:13 |
| bcsaller | ha, great :( | 16:13 |
| rick_h | hatch: ok, will ignore then. bcsaller ping when you're ready | 16:13 |
| * rick_h is just happy he finds the qa stuff in other people's branches too :P | 16:14 | |
| hatch | haha | 16:14 |
| hatch | bcsaller: review and qa done - I'm guessing there is a merge issue from trunk or something | 16:16 |
| bcsaller | hatch: I can merge trunk and test it local | 16:16 |
| hatch | bcsaller: were you able to reproduce? | 16:26 |
| bcsaller | hatch: no, I have settings, thats working fine. The new branch throws the styles off though so the placement of the indicators is wrong now, cleaning that up | 16:26 |
| hatch | hmm | 16:27 |
| bcsaller | hatch: I did have to take trunks version of viewlet-manager.handlebars in the merge though | 16:27 |
| bcsaller | does bzr status show a conflict for you? | 16:27 |
| hatch | cleaned it out and trying again | 16:28 |
| benji | rick_h: I'm still not happy with docstrings being 72 characters, but those changes dull most of the pain :) | 16:32 |
| rick_h | benji: yea, I've not done that one myself. I don't think the pep8 tool complains | 16:33 |
| rick_h | benji: but yea, I like that it's less of "pep8 encourages longer lines" and more "pep8 lets you be stupid if you want to be, but don't expect us to use it that way" | 16:33 |
| hatch | bcsaller: ok it all qa's fine now....sorry I must have broken something somehow | 16:34 |
| hatch | although the styling on the settings panel is a little broken for some reason | 16:34 |
| bcsaller | hatch: yeah, thats what I'm fixing now, thats a merge conflict | 16:34 |
| benji | it really makes no sense to me, especially for the first line of a docstring which often has to be carefully constructed to convey what a funciton/method/class is about and still be less than 80 chars, now having to be even shorter will be highly irritating | 16:34 |
| benji | plus, line wrapping tools have to be smarter because different chunks of the files have different rules | 16:35 |
| rick_h | benji: yea | 16:35 |
| frankban | hatch, rick_h: latest jenkins failures seem different: now the tests are started, and there is the ie failure in unittests (added a card). so, it seems the charm fix (g++) has been relevant for CI. | 16:36 |
| rick_h | frankban: looking, I honestly hit delete assuming it was more of the same | 16:37 |
| hatch | lol so did I | 16:37 |
| hatch | :D | 16:38 |
| hatch | oops | 16:38 |
| hatch | we are horrible | 16:38 |
| frankban | haha | 16:38 |
| frankban | hatch, rick_h: I believe CI was right and we ignored it pretending it was a canonistack failure. That confirms we are horrible people and that maybe we really need to switch to ec2 or hp... | 16:41 |
| hatch | haha | 16:42 |
| rick_h | frankban: yea, I thought we were getting permission to go to ec2 for it | 16:42 |
| rick_h | frankban: not sure where that dropped off | 16:42 |
| hatch | rick_h: frankban yeah EC2 is in the pipe but we need to figure out account details | 16:42 |
| hatch | whos gota pay yo! | 16:42 |
| hatch | for friday funnyness http://yuireactions.tumblr.com/post/55786097549/watching-yeti-run-unit-tests-chrome-safari | 17:07 |
| hatch | bcsaller: have a minute to guichat about these retry/replace/resolve buttons? | 17:17 |
| bcsaller | yes | 17:17 |
| hatch | ok heading to guichat | 17:17 |
| === schwuk is now known as schwuk_away | ||
| hatch | bcsaller: I'm still curious about the setTimeout in inspector.js | 17:30 |
| hatch | rick_h: you can review now....everything looks merged in properly | 17:37 |
| rick_h | hatch: bcsaller's branch? /me goes to look | 17:37 |
| hatch | yup | 17:37 |
| hatch | bcsaller: lgtm'd | 17:38 |
| rick_h | hatch: bcsaller what was with the timeout? | 17:47 |
| rick_h | bcsaller: no tests for this? | 17:48 |
| hatch | not sure | 17:51 |
| hatch | grabbing lunch | 17:56 |
| bcsaller | rick_h: hatch, sorry was out for a minute, the idea with the timeout was to remove the style after the transition has run, its supposed to display a background and then fade it out, after its gone I didn't want the style to remain on the node | 18:04 |
| bcsaller | I think properly a transition helper that binds the transitioned event as noted is proper | 18:05 |
| bcsaller | but I know other work is being thought about wrt animations | 18:05 |
| rick_h | bcsaller: yea, I'm looking at the Y module for it to help catch the event. | 18:05 |
| rick_h | bcsaller: but not gotten it all setup right atm. | 18:05 |
| bcsaller | rick_h: no, me either, I'm happy to look into a transition helper though | 18:06 |
| rick_h | bcsaller: in that case can the animation be set with the style change? /me didn't qa since hatch was. Are the two classes incompatible? | 18:07 |
| sinzui | jujugui, does anyone have time to review https://code.launchpad.net/~sinzui/charms/precise/juju-gui/nagios/+merge/177588 | 18:07 |
| bcsaller | rick_h: you add the class to trigger the transition, but I wanted the class off the node at the end, not sure I really understand the question though | 18:08 |
| rick_h | bcsaller: so instead of using the class resolved, can the animation be between .conflict and without? | 18:09 |
| rick_h | so that removing the .conflicted triggers the animation, I'm looking at the css closer trying ot see | 18:09 |
| rick_h | bcsaller: is there any qa instructions to generate a conflict to look at this? | 18:17 |
| bcsaller | rick_h: on the CR/MP | 18:17 |
| bcsaller | console tricks | 18:17 |
| rick_h | ah sorry got it | 18:18 |
| rick_h | bcsaller: the instructions aren't working for me. I'm getting an error on line 324: Simulate a conflict from the console: | 18:22 |
| rick_h | bah | 18:22 |
| rick_h | Simulate a conflict from the console: | 18:23 |
| rick_h | error is that the object has no method 'get' for getting the 'model' | 18:23 |
| bcsaller | rick_h: you deployed glance? | 18:23 |
| bcsaller | hmm | 18:23 |
| rick_h | bcsaller: yea, trying again. I originally deployed ceph and then went back and added glance | 18:24 |
| bcsaller | rick_h: I think you hit the 'expose' bug, thats long standing | 18:24 |
| rick_h | bcsaller: ah, yea I did touch that | 18:24 |
| rick_h | ok, will start clean and go again | 18:24 |
| bcsaller | rick_h: yeah, those instructions modify service[0] with a key in glances config | 18:25 |
| bcsaller | I could change item(0) to getById('glance') but... | 18:25 |
| rick_h | bcsaller: all good. working on it | 18:26 |
| rick_h | bcsaller: I can't get the animation to go. It's when I select one value over the other right? | 18:28 |
| rick_h | then the checkbox goes away and there's a background color animation? | 18:29 |
| bcsaller | rick_h: no, its not working properly :( | 18:29 |
| bcsaller | I tried a few things, but I didn't get it to work | 18:29 |
| rick_h | bcsaller: ok, so should we pull that out then? | 18:30 |
| rick_h | or did you want to give it a go to fix it before landing? | 18:30 |
| bcsaller | I could take one more pass at it. I sort of figured we'll get a better general answer to doing that type of thing in the near term | 18:31 |
| rick_h | bcsaller: well, everything I've got going is specific per location of use | 18:32 |
| rick_h | there's not really an "import animation...go" module coming from what I've gotten to work | 18:32 |
| bcsaller | maybe I'll take a stab at it then. node.transition('class', transitioned_cb) | 18:33 |
| bcsaller | the cb could be used to do chaining if needed | 18:34 |
| rick_h | bcsaller: well I note using single classes and duping them up | 18:34 |
| rick_h | what I had hoped to test was that if we could add the transition to the .xxx.conflict | 18:34 |
| rick_h | and then when .conflict was removed it would animate the background change | 18:34 |
| rick_h | but having a hard time setting it up/getting that tested. | 18:34 |
| bcsaller | yeah, I'll poke at it again and write some tests since the general UX seems ok to people at this point | 18:35 |
| rick_h | basically use .conflict as a base css and then add a .pending .resolved or something to help with the tweaks. | 18:36 |
| bcsaller | you got me thinking, I think I have something that might work | 18:37 |
| rick_h | bcsaller: cool, does this work for all field types as well? checkbox and such? | 18:40 |
| bcsaller | rick_h: input/text area are tested currently, haven't checked with checkboxes, I don't think we use them for config/constraints which is what this is for | 18:47 |
| rick_h | bcsaller: ok, I know hatch had some stuff that dealt with boolean types and wanted to check if boolean config would come into play as a checkbox vs an input box for resolution UX | 18:48 |
| bcsaller | rick_h: I think that was the 'use defaults or not' toggle and isn't part of the databinding | 18:49 |
| rick_h | bcsaller: so in mediawiki for example, there's a 'debug' setting that's a checkbox in the config | 18:49 |
| bcsaller | exposed is realtime, when you flip it, it sends the rpc and the delta will update it in place | 18:49 |
| * bcsaller checks | 18:49 | |
| bcsaller | for me it says boolean -> false in the box, not a checkbox | 18:50 |
| rick_h | bcsaller: ok, yea in the old UI it was a checkbox. | 18:50 |
| bcsaller | good line of questioning though | 18:51 |
| rick_h | bcsaller: just checked it with the inspector and correct, there are only input boxes now. Hmm, so does that cast/work well? I'm wondering if that's a rabbit hole of 'FALSE' 'F', etc? | 18:51 |
| rick_h | ugh, seems like a downgrade, but doesn't effect this then if everything's a text box. | 18:52 |
| bcsaller | looks like the template tries to do it properly with type=checkbox | 18:52 |
| bcsaller | so some untested regression maybe | 18:52 |
| bcsaller | and then I have to add support for this somehow | 18:53 |
| bcsaller | the other issue is that a textarea with tons of content will give a bad UX with this design | 18:53 |
| rick_h | bcsaller: yea, was going to ask about a textarea next. :/ | 18:54 |
| rick_h | I know we had some with the expanding textarea that were large config bits | 18:54 |
| rick_h | bac: can you think of a good demo charm for a large bit of data in the config file? | 18:55 |
| bcsaller | yeah, and it should work as it does now, but no max height it set or overflow: scroll-y or anything like that | 18:55 |
| rick_h | bcsaller: right | 18:55 |
| rick_h | is it 'usable' I guess. | 18:55 |
| rick_h | at least to start | 18:55 |
| bcsaller | the whole use case is pretty rare, so as a starting point I'm not that worried | 18:56 |
| rick_h | right | 18:56 |
| rick_h | ok, well I'm going to run away. Have a good weekend everyone. | 18:57 |
| hatch | bcsaller: mediawiki was a checkbox yesterday | 18:58 |
| hatch | heh | 18:58 |
| hatch | had* | 18:58 |
| hatch | yeah on comingsoon | 18:58 |
| hatch | too | 18:58 |
| hatch | areyou guys saying that's a text input now? | 18:59 |
| bcsaller | hatch: looks that way currently | 18:59 |
| hatch | BUG WARNING | 18:59 |
| hatch | :P | 19:00 |
| bcsaller | hatch: ahh I see | 19:00 |
| bcsaller | the ghost has it, the main doesn't | 19:00 |
| bcsaller | isBool handling or whatever isn't common | 19:00 |
| bac | rick_h: haproxy was the charm that initially had the problem with multi-line settings input | 19:01 |
| hatch | bcsaller: ahh - they are using the same template so there is definitely a bug there somewhere | 19:02 |
| hatch | I see that it's not your branch though | 19:02 |
| hatch | filing bug | 19:02 |
| hatch | https://bugs.launchpad.net/juju-gui/+bug/1207870 | 19:03 |
| _mup_ | Bug #1207870: Boolean values aren't checkboxes on deployed services <juju-gui:New> <https://launchpad.net/bugs/1207870> | 19:04 |
| hatch | bcsaller: I also noticed that the 'scale units' input value does not change as the simulator runs, known issue? (not caused by your branch) | 19:04 |
| bcsaller | that used to work, for a long time | 19:18 |
| jcastro | sinzui: thanks for that list | 19:19 |
| bcsaller | hatch: I didn't know that no. sometimes I feel like our testing misses the mark | 19:19 |
| jcastro | everything owned by charmers in precise is now README.md, I converted some from RST | 19:19 |
| jcastro | I ignored personal branches and oneiric | 19:19 |
| hatch | bcsaller: sometimes? ;) | 19:19 |
| bcsaller | I was being nice | 19:20 |
| hatch | bcsaller: https://gist.github.com/hatched/0ef6c3898dab4e3e1626 - don't shate the DOM tree ;) | 19:24 |
| hatch | shake* | 19:24 |
| hatch | no I'm not going to leave it like that :D | 19:24 |
| bcsaller | hatch: no, thats bad, even an _nodes in there, ha | 19:26 |
| hatch | yeah I do what I can lol | 19:30 |
| hatch | bcsaller: so should the simulator be able to react to these env commands? | 20:07 |
| bcsaller | hatch: the simulator randomly sets unit agent states, it has nothing to do with resolving errors as hooks don't actually run in the sandbox | 20:08 |
| hatch | oh right - so should we hook it up to react to them? | 20:09 |
| bcsaller | its not the simulator that would matter. The result of resolved is just that the agent state should clear out of pending on core. So for example after the hook is retried the agent will update its state if it works | 20:10 |
| bcsaller | resolve, means I resolved this async to the UI (gui or cli) and I'm telling the agent to try to continue with new hooks | 20:11 |
| bcsaller | retry mean basically the same thing + run the hook that failed putting the unit into error | 20:11 |
| bcsaller | the states coming from the simulator don't mean anything and there are no transitions happening relative to a given unit | 20:12 |
| hatch | so the way to test this is to make sure that if I click on the button it ends up being sent to fakebackend | 20:13 |
| hatch | for testing purposes | 20:13 |
| abentley | orangesquad or benji or bac: Could you please review https://code.launchpad.net/~abentley/charmworld/polish-ingest-bundle/+merge/178376 ? | 20:15 |
| benji | abentley: I'll take a look | 20:16 |
| abentley | benji: How's the review going? | 20:33 |
| benji | abentley: sorry, I was talking to Brad about his branch. I'm looking though. | 20:33 |
| benji | abentley: it looks good to me | 20:34 |
| abentley | benji: thanks. | 20:35 |
| abentley | bac, benji: I think bundle ingest might now be working. I'm pushing a bundle branch to find out. | 20:43 |
| benji | cool | 20:43 |
| bac | benji: this one? | 20:49 |
| benji | this one works :) | 20:49 |
| bac | abentley: turns out since the URL we're serving up on was /api/ we already had support from the work we did in raleigh | 20:49 |
| bac | if you look in views/api.py there is a bundle() method. it isn't listed in routes | 20:50 |
| abentley | bac: Oh, and that gives the bundle text, not metadata? | 20:51 |
| bac | abentley: it does now. :) | 20:52 |
| benji | bac: the output is missing the outer mapping | 20:58 |
| benji | bac: see http://paste.ubuntu.com/5941515/ | 20:58 |
| benji | the first is the output from the app, the second was the input | 20:58 |
| bac | benji: yeah i saw that | 20:59 |
| benji | oh, and _id shouldn't be in the output | 20:59 |
| bac | benji: trying the deployer on http://paste.ubuntu.com/5941555/ | 21:10 |
| bac | benji: it seems happy. :) | 21:11 |
| benji | yay! | 21:11 |
| benji | do all the relations get added and everything? | 21:12 |
| bac | benji: don't know yet. it ate the config without burping and is doing it's business now | 21:13 |
| bac | benji: i think it parses it at the beginning so if it were going to be unhappy it would've complained early | 21:13 |
| bac | may take about 30 minutes since i have to fetch the charms locally and then push to ec2 | 21:14 |
| benji | yeah, I would think so | 21:14 |
| bac | benji, abentley: i've updated my branch at lp:~bac/charmworld/jam-bundle | 21:14 |
| bac | i suggest replicating what i've done with the canonistack instance | 21:14 |
| bac | benji: we also need to get gary to run it beforehand so charm fetching will not be necessary | 21:15 |
| benji | that's a good point | 21:15 |
| benji | so if this all works out the next thing we should do is write up a script for Gary to follow | 21:15 |
| abentley | bac: I'm not sure what you mean, but the canonistack instance is already fetching charms. | 21:15 |
| benji | and include prep notes like that one | 21:15 |
| bac | abentley: when you run juju-deployer it has to fetch all of the necessary charms | 21:16 |
| bac | it may not be a big deal for him but it is for me since my ISP is so slow | 21:16 |
| benji | we might also include usage instructions so he can build his own, I'm thinking he might want to make a more impressive bundle to deploy | 21:16 |
| bac | benji: well, perhaps one with the gui in it | 21:17 |
| abentley | benji: I think that's gravy. | 21:17 |
| benji | If I were demoing it I would have the gui-pre-deployed so the audience can watch the bundle deploy | 21:17 |
| abentley | bac: So are you saying you'd like me to install your branch on the canonistack instance? | 21:17 |
| benji | abentley: tasty, tasty gravy | 21:18 |
| bac | abentley: yes and then run 'jam' on whatever bundle y'all decide upon | 21:18 |
| bac | benji: yes, good point about having the gui up first | 21:18 |
| bac | remember the bundle filename will be the basket name in the URL so make it meaningful | 21:18 |
| abentley | bac: Your branch is in place. | 21:21 |
| bac | abentley: great. can you grab the bundle, rename it, and then run 'jam'? | 21:22 |
| abentley | bac: I've already run jam on that instance. | 21:22 |
| bac | oh, so what is the basket and bundle name? | 21:22 |
| bac | abentley: can you see the json at /api/2/bundle/<basket>/<bundle> ? | 21:23 |
| abentley | bac: Yes. http://162.213.34.16/api/2/bundle/mediawiki/intranet | 21:25 |
| bac | so, we should be able to run 'juju-deployer -e ENV -c http://162.213.34.16/api/2/bundle/mediawiki/intranet' | 21:26 |
| abentley | bac: Yes, I think so. | 21:26 |
| bac | i've just done it locally and it seems to have worked. would like to see someone else try | 21:27 |
| bac | make sure you have lp:juju-deployer/darwin | 21:27 |
| abentley | bac: I can't because that would dump it into the same env as 162.213.34.1 | 21:27 |
| benji | bac: I'll run it | 21:27 |
| bac | benji: to ec2? | 21:28 |
| benji | yep | 21:28 |
| benji | is that ok? | 21:28 |
| bac | yeah, great | 21:28 |
| bac | that's what i did | 21:28 |
| abentley | bac, benji: We've successfully ingested a bundle on staging: http://staging.jujucharms.com/api/2/bundle/~abentley/wiki-bundle-1/wiki | 21:28 |
| benji | first I'll deploy the GUI so I can watch it work | 21:29 |
| benji | abentley: cool! | 21:29 |
| bac | abentley: from launchpad? | 21:29 |
| abentley | bac: Yes. | 21:29 |
| bac | cool | 21:29 |
| bac | abentley: is that my latest branch running? i see _id in the output but it should be stripped | 21:29 |
| bac | oh, that's on staging | 21:30 |
| bac | oi | 21:30 |
| bac | man, i'm surprised it works at all | 21:30 |
| abentley | bac: revno 336 | 21:31 |
| abentley | bac: 336 is what's on 162.213.34.16 | 21:33 |
| bac | abentley: ok, that makes more sense. thanks | 21:33 |
| bac | abentley: i'm confused by that data representation. it doesn't match the code in r336 and won't work with the deployer | 21:37 |
| bac | abentley: i see a problem. i didn't properly delete '_id'. i just pushed r337 which does | 21:39 |
| bac | having it in there doesn't seem to hurt anything | 21:39 |
| abentley | bac: Updated. | 21:40 |
| bac | but the json shown on staging does not have the bundle name as the outer key | 21:40 |
| bac | and it is showing the bundle representation not just the ['data'] portion | 21:41 |
| abentley | bac: AFAIK you have not landed your code on trunk, so it is not running your code. | 21:42 |
| bac | abentley: ok, that makes sense. i thought you said staging had been manually updated to 336 | 21:42 |
| abentley | bac: No, I meant the other instance. | 21:43 |
| bac | gotcha | 21:43 |
| bac | benji: any progress? | 21:43 |
| bac | benji: i need to step out for 30-40 minutes. that ok? | 21:43 |
| benji | I have the GUI up and am running deployer now | 21:43 |
| benji | bac: yep, I have to go get the smallest York right now anyway | 21:43 |
| bac | benji: url for the gui? | 21:44 |
| benji | bac: https://ec2-54-227-91-238.compute-1.amazonaws.com/ | 21:44 |
| bac | thanks. bbiab | 21:44 |
| abentley | bac: In theory, I could force your code onto staging. I was actually surprised you weren't targetting trunk. | 21:44 |
| bac | abentley: it hasn't been reviewed | 21:45 |
| bac | it is a bit hacky | 21:45 |
| benji | bac: I'm running "deployer/bin/juju-deployer -e ENV -c http://162.213.34.16/api/2/bundle/mediawiki/intranet" now | 21:47 |
| benji | (I had to put the path on the command to get it to work.) | 21:47 |
| benji | bac: 2013-08-02 16:47:01 Deployment name must be specified. available: ('intranet',) | 21:47 |
| benji | now running "deployer/bin/juju-deployer -e ENV -c http://162.213.34.16/api/2/bundle/mediawiki/intranet intranet" | 21:47 |
| benji | bac: error 2013-08-02 16:48:02 Error getting status, is it bootstrapped? | 21:49 |
| benji | I have ot go now, back in 30 or so minutes | 21:49 |
| hatch | does the GUI know about the landscape URL? | 21:52 |
| hatch | hmm the env commands are getting to rapi but the updates aren't updating the UI | 21:59 |
| benji | heh, I trusted the copy-paste too much "-e ENV" bit me. Trying again with no -e option | 22:29 |
| hatch | benji: do you know if rapi is supposed to react to resolve commands? | 22:31 |
| hatch | it receives them and says it responds | 22:31 |
| hatch | but the resulting dataset never changes | 22:31 |
| benji | I'm afraid I don't know. | 22:31 |
| hatch | alright - I'm just trying to figure out if my code is broken or rapi :) | 22:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!