[00:12] rick_h_: Might hassle you about some selenium stuff quickly if you're still around once I've finished with Gary. [00:13] gary_poster: https://github.com/huwshimi/juju-gui/compare/small-screen-notification [00:44] rick_h_: If you're around, I guess knowing how we run our selenium tests would be a good start :) [01:08] huwshimi: sorry, afk for the most part at the moment. If you send me a branch/email I can try to take a peek [01:11] rick_h_: It's ok, I'll have a poke around. === gary_poster is now known as gary_poster|away [09:42] morning fwereade: I was prototyping a way to add the env name to the hooks context, if you have time, could you please take a quick look at http://pastebin.ubuntu.com/6848457/ ? [09:42] that seems to work, not sure if it's worth of making two api requests for the uuid and the env name [09:44] frankban, roughly sane [09:44] frankban, the tricky bit is during an upgrade [09:44] frankban, upgraded units might want to call that method on a server that hasn't finished its upgrade yet [09:53] fwereade: uhm... does it affect the current impl? [09:54] frankban, sorry, can I kick you sideways to jam please? [09:54] fwereade: sure [09:54] frankban, wait no I can't he doesn't work fridays [09:54] dimitern, do you have a moment to discuss uniter api changes with frankban? [09:55] fwereade, frankban, sure [09:56] dimitern: thanks [09:57] thank you fwereade [09:57] frankban, I've seen the paste - I have some suggestions re the api [09:57] cool [09:58] frankban, I think we should add a CurrentEnvironment api call, that returns both the UUID and Name and deprecate the CurrentEnvironmentUUID call [09:58] dimitern: +1 [09:59] fwereade, do you concur? [09:59] dimitern: that's what I was thinking as well [09:59] dimitern, frankban: yep, that definitely sgtm [10:00] dimitern, frankban: I'm mostly concerned about managing the changeover at upgrade time [10:00] frankban, and re backward compatibility, we need to make sure the client-side api handles gracefully the case when CurrentEnvironment is not available in an older apiserver [10:00] frankban, which means the code should work without a name or get the name in some other way [10:01] I see [10:02] dimitern: is it possible to have newer server and older units? [10:04] frankban, yes - until the upgrade is complete [10:04] fwereade, right? [10:05] dimitern, frankban: yes, during an upgrade there's currently no guarantee which will finish first [10:05] dimitern: in that case also, old units would still call CurrentEnvironmentUUID [10:07] frankban, yes [10:07] dimitern: so, if server > unit: we keep CurrentEnvironmentUUID, reimplementing it so that it uses CurrentEnvironment and return just uuid, error [10:07] frankban, just a sec [10:08] frankban, we implement CurrentEnvironment -> name, uuid in the apiserver; we keep CurrentEnvironmentUUID; the client-side tries to use CurrentEnvironment first for st.Environment(), and if it fails with CodeNotImplemented, uses CurrentEnvironmentUUID instead and keeps the name empty [10:10] dimitern: sounds good [10:12] frankban, and the compatibility code should be in its own function (e.g. environ1dot16 or something - look for 1dot16 in state/api for examples) [10:13] dimitern: do you want that check to be made at client call level? e.g. in state/api/uniter/environ? and how to call the new client method? NameAndUUID? Info? [10:19] frankban, I think the best way is to change st.Environment() method in state/api/uniter/uniter.go to call CurrentEnvironment directly, and if params.IsCodeNotImplemented(err), call func (st *State) environ1dot16() (string, error) and call CurrentEnvironmentUUID inside, returning an *Environment with just a UUID [10:21] dimitern: ok will take a look [10:21] frankban, if err is nil, just return a *Environment with both name and uuid. Then, in state/api/uniter/environ.go we don't need st *State inside, but name and uuid strings as fields, and two methods Name() and UUID() which both return just strings (no errors - update the doc string of UUID() please), e.g. e.name and e.uuid [11:00] dimitern: so, just o know I understand the direction, something like this? http://pastebin.ubuntu.com/6848807/ [11:09] frankban, looks great, apart from a few minor suggestions: 1) doc comments on all exports (lines 7, 83, 103, 124), 2) tests for the IsCodeNotImplemented fallback - look in TestAddLocalCharm in state/apiserver/client/client_test [11:10] frankban, sorry, re 2) - not easy to test actually, but at least manually testing it should suffice [11:10] dimitern: yeah, that just a prototype [11:11] dimitern: I'll add comments and tests and also docs if required (to ducument the new env var in the hooks context) [11:11] (i.e. just change line 71 to call CurrentEnvironment1 or something and add some debug logging to environment1dot16 to ensure it gets called) [11:11] frankban, great, thanks [11:11] cool [11:30] * frankban bbiab [12:20] hi frankban, when you have some free time could you try to reproduce https://bugs.launchpad.net/bugs/1274692 [12:20] <_mup_> Bug #1274692: Mongo error when deploying charm === gary_poster|away is now known as gary_poster [13:17] hi bac: do I need to switch to revno 2282? what's the exact quickstart command you run? [13:18] frankban: yes, i was testing with the latest juju-core. unfortunately it requires modifying quickstart/app.py to remove the 'cmd.insert('sudo')' if you're running locally. [13:19] frankban: i was just starting with: .venv/bin/python ./juju-quickstart [13:19] frankban: i have seen the failure on lxc and ec2 [13:19] frankban: and trying again, manually bootstrapping with --upload-tools [13:19] s/and/am [13:20] frankban, bac, make sure you've rebuilt the binaries before doing bootstrap --upload-tools [13:21] dimitern: i have. i'm surprised it has to be done manually, though. [13:21] frankban: hi. have we already changed quickstart to not create ssh keys for 1.17.x and higher (per "Juju Docs - SSH key requirements" thread [13:21] dimitern: i'm seeing http://paste.ubuntu.com/6849358/ [13:21] bac, when deploying from source it's needed, otherwise you might end up bootstrapping with some older binaries and there's no way to tell [13:22] bac: quickstart never uses --upload-tools: that can be the cause of the issue [13:22] bac, try with --show-log and --debug ? [13:22] frankban: yes, that's why i'm doing the bootstrap manually. [13:22] frankban, ah! that's the issue most likely [13:22] frankban: but this issue was seen using the ppa version [13:23] of juju [13:23] 1.17.1 [13:23] bac, the ppa version doesn't include the fix, which i committed yesterday [13:24] bac, dimitern: so it seems it should be fixed now, is it valuable for me to try to dupe? [13:25] dimitern: i get this from 'juju bootstrap' http://paste.ubuntu.com/6849369/ [13:25] frankban, bac, well, I claim i've fixed it, but if you can repro it after the fix, i'll be most interested [13:25] frankban: not now, i guess [13:25] frankban: let me get a successful run using --upload-tools and see [13:26] gary_poster: as per discussion with fwereade, since juju reuses keys if they are set up, we decided to keep that functionality in quickstart: it should continue to work with newer juju versions [13:26] frankban: cool thx [13:26] bac: ok [13:26] bac, something might be odd with the control bucket from a previous test perhaps? destroy/bootstrap should fix it [13:28] frankban: i'll add a note to HACKING making it clear you cannot use a hand-built juju with quickstart unless you bootstrap manually. is that accurate? [13:31] bac: even if you have $GOPATH/bin in the path, quickstart invokes /usr/bin/juju, so you are not actually using the trunk binaries. I think the confusing part pf this story is that you were using a broken ppa package [13:32] bac, frankban, so can we consider bug 1274692 for invalid then? [13:32] <_mup_> Bug #1274692: Mongo error when deploying charm

[13:34] dimitern: if you confirm the 1.17.1 from PPA was broken, then I am inclined to say yes, but I'd wait for bac to confirm this in trunk [13:35] frankban, I can definitely confirm 1.17.1 from the ppa is broken, but trunk should be ok [13:36] dimitern: i'm testing now and will mark it invalid if trunk is ok. [13:36] bac, cheers [13:36] dimitern: but i still cannot get a clean bootstrap with upload tools, after changing control buckets [13:36] bac: to do that, in addition to removing the sudo call in quickstart, you might want to change "/usr/bin/juju" to just "juju" everywhere in app.py [13:37] frankban: i have linked /usr/bin/juju and jujud to be the trunk version [13:37] bac: try to destroy the environment using both the PPA version and the trunk version of juju [13:37] bac: cool [13:38] frankban: neither show an environment started [13:38] nothing to destroy [13:41] bac, you could manually delete your control bucket from the ec2 console, remove any .jenv files and try anew [14:36] bac is distUtils already included in quickstart? [14:37] hatch: it is a core library [14:37] so, it'll always be there [14:39] lol no docs http://docs.python.org/2/distutils/apiref.html#module-distutils.version [14:39] oh that's weird [14:40] It works now I think I'll just wait for frankban 's review haha [14:41] hatch: if you are curious you can do help(distutils.version) [14:42] >>> help(distutils.version) [14:42] Traceback (most recent call last): [14:42] File "", line 1, in [14:42] NameError: name 'distutils' is not defined [14:42] even the cli doesn't want me to use it [14:42] haha [14:42] hatch: "import distutils" before that [14:43] AttributeError: 'module' object has no attribute 'version' [14:43] it don't exist yo! [14:44] hatch: are you running trusty? [14:44] import distutils.version [14:44] help(distutils.version) [14:44] profit [14:44] 12.04 [14:44] rick_h_: you saw spencer got you the images? [14:44] python 2.7.3 [14:45] frankban: are .jenv files supposed to be left around after an env is destroyed? [14:45] hatch: >>> from distutils import version [14:45] >>> help(version) [14:45] there we go [14:45] bac: no AFAIK, but their removal is not always guaranteed [14:46] gary_poster: yep, offline'd them into dropbox [14:46] hatch: from __future__ import braces [14:46] gary_poster: thanks for the poke [14:46] rick_h_: cool, np [14:46] ""Version numbering for anal retentives and software idealists."" lol! [14:46] bac: hatch we should be off of distutils. It's going away. setuptools or bust [14:46] yeah ok I'm leaving my branch as is lol [14:46] bac: hatch https://mail.python.org/pipermail/distutils-sig/2013-March/020126.html [14:46] frankban: not guaranteed to be removed and it looks like they are not regenerated if environments.yaml changes [14:47] hatch: I'd prefer "Version numbering for anarchists and software realists." [14:47] sorry, distribute, nvm [14:47] rick_h_: really. is there another package that provide versioning? [14:47] ignore me [14:47] bac: for versioning pkg_resources provides it [14:47] hatch: didn't know your branch is ready for review [14:48] frankban oh, I guess LP doesn't send emails when the branch is updated :/ [14:48] sorry bout that [14:48] bac: https://github.com/juju/jenkins-github-lander/blob/develop/src/jenkinsgithublander/__init__.py [14:48] rick_h_: sorry, i meant parsing and comparison [14:49] bac: sorry, jumped into the middle of a conversation and missing context. Ignore me. Carry on. [14:50] hatch: np, I'll look at it asap, so, is distutils not worth of bothering? [14:51] reading the docs I don't really see what it gets us [14:51] maybe some parsing [14:51] save a couple lines....maybe? [14:51] it doesn't look like I can do comparisons [14:53] bac: yeah, if something goes wrong and the jenv is not deleted the only solution I know is to remove the files manually. I hope that happens only when you do unexpected things, like using different version of juju or removing instances manually (e.g. from the ec2 console) [14:54] hatch: In [8]: from distutils.version import LooseVersion [14:54] In [9]: LooseVersion('1.18') < LooseVersion('1.17.2wtf') [14:54] Out[9]: False [14:55] frankban: doesn't StrictVersion work for our needs? [14:56] hatch: implementer choice IMHO, but if you decide for distutils that's how it is used. And in our case StrictVersion should work as well, as bac suggests [14:58] hatch: if you use ipython (which I strongly suggest) you can also do things like "object?" to see docs and "object??" to also see the definition [14:59] hatch: and it also has inspect/autocompletion and other cool features [15:00] dimitern: I have a juju test intermittently failing in trunk: http://pastebin.ubuntu.com/6849689/ I am on saucy revno 2285 [15:02] frankban, that's a known issue, but it's very hard to reproduce [15:02] frankban, do you get it consistently? [15:06] dimitern: it is intermittent, it fails once every 3/4 runs [15:06] hatch: I have an event handler that is being called multiple times even though the event is only fired once. Any idea why that might be? [15:06] benji that means it was attached multiple times [15:07] if you put a debugger in front of the attach point then you can see when it gets called [15:07] oooh, that makes sense [15:07] :) [15:07] hatch: while I have you; what does "addEvent" do? I can't find it in the YUI docs anywhere. [15:08] it's an extension rick_h_ wrote which allows you to hold onto the event handler to detach later without having to manually manage them [15:09] benji grep for Y.Event.EventTracker [15:09] frankban: can i trouble you to verify you can do a 'juju bootstrap --upload-tools' with juju-core trunk? [15:10] thanks [15:10] bac: trying [15:10] thx [15:10] app/assets/javascripts/event-tracker.js is the source :) [15:10] this is one of those things in "assets"; that's such a silly place for code we wrote ourselves and isn't managed as an external project [15:11] bac: it worked, what errors are you encountering? [15:11] frankban: unable to upload tools to the bucket [15:12] bac: local env? [15:12] ec2 [15:12] bac: trying ec2 [15:13] benji haha yeah, I use `git grep -n foo` all the time :) [15:50] jujgui call in 10 [15:58] jujugui call in 2 [15:59] safe travels rick_h_ [16:00] gary_poster, hatch, the fix for bug 1273464 just landed [16:00] <_mup_> Bug #1273464: putcharm api fails for compressed charm contents wrapped in a folder

[16:00] awesome thanks dimitern! [16:00] awesome thanks [16:01] please test it with zip created on windows as well - it should work just the same [16:04] hey luca_ could you please get us the relationship circle assets before you get on the plane? [16:05] gary_poster: I'll see, Spencer will have to deliver that [16:05] ok thanks luca_ [16:15] darn, now I have to merge in all those conflicts [16:17] hatch: your mp has conflicts [16:17] *sigh* [16:17] haha [16:18] * gary_poster stepping out for lunch [16:18] booting up vm [16:20] frankban what's the best way to merge these? it doesn't appear to want to let me [16:23] hatch: who is blocking you? ;-) [16:24] frankban it says they have diverged then just dumps out [16:25] hatch: pull trunk, then merge trunk, you should see conflicts, fix them and then "bzr resolve" + commit [16:26] yeah I didn't create a shared repo for this branch so is there any way I can merge trunk into my current branch without pulling it down into a separate folder? [16:28] I really need to figure out a way to link the gui source directory in the charm to my local directory so it would be easier to work with [16:31] hatch: bzr merge lp:juju-quickstart ? but I suggest you to setup a shared repo. I also use lightweight checkouts, and the work flow is similar to the one you are used to with git. the charm solves deploy issues with "make deploy" so basically the charm does not need to be in a local charm repository [16:31] yeah I will set up a shared repo, I wasn't expecting this branch to take this long :D [16:33] * Makyo dogwalk [16:36] bac did you handle the frankban ok conflict fixed [16:36] woah [16:36] lol [16:36] lets try that again [16:37] frankban conflict has been fixed and pushed [16:37] :) [16:37] cool [16:37] on it [16:37] thanks /me crosses fingers [17:23] hatch: done [17:23] frankban lol, alphabetical fail [17:23] :-) [17:24] hatch: I know you think this branch is taking forever, but, given this is your first Python code, I am instead surprised about how quickly you got fluency on the language [17:34] jujugui: my branch is up for review at https://github.com/juju/juju-gui/pull/96 [17:34] benji on it [17:34] benji oh you'll need to rebase [17:34] somehow... [17:34] benji: looking [17:34] oh rick_h_ you're still here? [17:34] heh [17:34] hatch: I... though I had done that. [17:34] lol [17:35] git is confusing sometimes [17:35] frankban well thanks! I'm on the fixes right now [17:43] hatch: fixed my comments, I think the correct comparison is just: return (major, minor, patch) < (1, 17, 2) [17:44] oh cool [17:44] benji: build failed due to make lint [17:45] darn, I ran lint... oh that was before all the git calistenics I did to get things merged [17:45] benji: but LGTM with a couple of comments and places to make sure we clean up things [17:46] rick_h_: thanks; I'm going to take lunch now (with a side of wishing for death -- bad head cold). Afterward I'll address the review issues and attemp a rebase. [17:46] benji: rgr, good luck [17:47] (Didn't Richard Pryor have problems with rebasing too?) [17:48] launchpad reviews are sure horrible [17:48] sheesh [17:51] anyone tried 1.17.2? /me is sticking with 1.17.0 atm since it was working ok locally [17:51] rick_h_: trunk works well with local envs, so I presum 1.17.2 is ok too [17:52] frankban: cool [18:10] frankban ok the fixes have been pushed [18:11] I think I finally got the deps in the proper order haha [18:13] hatch: :-) they looks good, but I am past EOD and don't have time now to QA, could you please ask someone else? [18:14] sure [18:14] bac benji [18:14] thanks! [18:14] thank you, have a nice we! [18:14] you too :) [18:14] hatch: sure [18:14] thanks [18:14] hatch: i need that change now anyway! [18:14] haha aww yeah! [18:29] oo boy that's a lot of functional refactoring [18:29] should make it da-bomb to test though [18:29] hatch: huh? [18:29] rick_h_ I just refactored my local charm upload to be purely functional [18:29] hatch: oh cool [18:30] lots of functions in functional style [18:30] lol [18:36] hatch: QA looks good. i didn't let it bring the envs all the way up but it started bootstrapping without mentioning sudo. [18:37] that's good thanks for the QA! [18:37] so now how should I land this since I can't use lbox? [18:44] hatch: sorry, i didn't see your question. [18:45] hatch: create a fresh branch for lp:juju-quickstart. merge your branch into it. then check it in with a nice message of the form: [18:45] bzr ci -m '[r=frankban] Don't use sudo, blah blah' [18:45] then bzr push lp:juju-quickstart [18:46] no problem [18:46] hatch: make sure you run make lint first [18:46] heh yeah [18:46] since lbox usually does it [18:46] it's really too bad lbox doesn't work in the console and requires a browser for auth [18:47] there is a work-around for that but i can't do it off the top of my head [18:48] ugh kernel panic....go osx [18:49] hatch: wait [18:49] hatch: at the end of quickstart i get this message [18:49] Run "sudo juju destroy-environment -e local [-y]" [18:49] to destroy the environment you just bootstrapped. [18:49] the sudo is not required for destroy, right? [18:49] I'm guessing that if sudo is not required to start then it's not required for destroy [18:50] good catch [18:50] i'll confirm. but if that is true we should change that message [18:50] yeah, ok I'll do that after lunch [18:50] * hatch hunnnnngry [18:50] hatch: and for >= 1.7.2 the '-e' is deprecated [18:50] yeah, which is bonkers [18:51] no kidding! [18:51] because you need it for bootstrap [18:51] so it makes no sense [18:51] you need it for every other damned command [18:51] lol [18:51] should yell at thumper about that [18:52] I just asked in #juju-dev [18:52] ha! [18:53] here is a nice article I read during lunch about some of Chrome's nicer dev/debug tools: https://medium.com/p/f1f29cb2c5e0 [18:54] cool I'll check it out [20:04] monitorEvents is cool [20:04] I didn't know about that one [20:10] deploying local charms via the GUI is so darn cool :D [20:26] and the charms even deploy and everything :) [20:26] this is going to be a huge release next [20:33] benji - I really have no idea the proper way to rebase your branch [20:33] with all of those merges and commits from rick [20:33] hmm [20:34] maybe it'll need to be rebased into a couple commits [20:34] hatch: I'm looking at it now and I don't either. I'm going to attempt to create a new branch and use patch to get the changes into it [20:34] I wish I had time to read a book on git. [20:34] mm, maybe Makyo would know, if he's around? [20:35] when you do that... I'd like it if you could try `git rebase -i HEAD~17` then squash them into logical commits [20:35] _o/ [20:35] but I did that before and totally borked my branch and had to cherry-pick [20:35] Either patch or cherry-pick, yeah. [20:35] hey Makyo. are you up on pretending to be a git expert for benji? [20:35] lol [20:36] oh yeah cherry pick [20:36] might be easier? [20:36] under these circumstances [20:36] well not really because he needs all of them [20:36] Create a new branch off develop, then cherry-pick changes from your working branch. You can either recreate your PR, or push -f over the old one (daaangerous, though, not recommended) [20:36] hatch, But can rebase without the merge commits then. [20:37] I think... [20:37] can he though? he would have worked ontop of them [20:37] so I don't think that will work... [20:37] Well, if you cherry-pick into a branch that already has those commits? [20:37] Then they're not merges. [20:37] hmm...good point [20:37] it might work [20:37] That's what I mean. git juju-sync; git checkout -b new-feature-branch; git cherry-pick... [20:37] then rebase after the cherry-picking [20:37] Yeah. [20:38] that's probably a good technique [20:38] cherry-pick is a pain. [20:38] But it'll do it. [20:38] To be fair, patching will be easier if there's a lot of changes, though. [20:38] I am really curious if using HEAD~`7 will do it [20:38] er [20:38] git rebase -i HEAD~17 [20:38] then leave the merges [20:38] then he'll only have to cherry pick a few commits [20:39] so, how do I get a patch with just the differences between my branch and the official develop branch? [20:40] diff against develop into a file, then apply with git patch, I think. [20:40] I'm hesitant to give commands, because I know I'm going to mix it up with bzr. [20:40] the issue with patch is that it's going to include the merge diff too [20:40] isn't it? [20:41] No, because that won't differ from develop. [20:41] You'll have to juju-sync before either of these options. [20:41] ahh right right gota diff against develop not local trunk [20:41] Yeah. [20:42] hatch: have a look at https://help.launchpad.net/API/EndUserHints . the /bin/echo trick might be what you need [20:42] (Which is sort of like diffing against local trunk after syncing develop) [20:42] hatch: for your lbox woes, i mean [20:42] hmm thanks I'll take a look [20:43] hatch: you close to landing that quickstart branch? [20:43] bac sorry was working on js for a bit :) will do that stuff for the naming now [20:44] bac actually, is there a way we can store the sudo require status somewhere? [20:44] I think Rick put some changes from another one of his branches into this one. A branch that may not have landed yet, so I'm getting lots of changes that aren't native to this branch. [20:46] hatch: looking [20:46] bac actually.... [20:46] I can probably do this using format() [20:47] yep [20:47] you got alls you need [20:48] bac can you check this out to see if this is correct? I don't really want to run a whole QA cycle to test :P https://gist.github.com/hatched/8742817 [20:49] I think I used format() properly [20:49] :) [20:50] hatch: you can drop the is_local at line 11. otherwise looks great [20:50] ahh right [20:58] bac done https://code.launchpad.net/~juju-gui/juju-quickstart/trunk [20:58] thanks for the help [21:01] ooooh, hatch, you're gonna get it! you broke francesco's 100% test coverage! [21:01] shoot I didn't know we were doing that! [21:02] I can fix in a follow-up [21:02] :) [21:02] hatch: he's been obsessive about it from day one. [21:02] figures i'd be the one to break it [21:08] Makyo: i looked into it a bit more after being really annoyed by the quickstart ssh-agent problem. it looks like the fix is quite simple. would you have time to have a look? https://codereview.appspot.com/53740045 [21:11] bac, sure. [21:14] Makyo: i see that some tests are not mocking out ssh-agent calls, so 'make test' spins up five still. [21:19] Oh, boo. [21:19] Looks good otherwise. Still can't get on rv but will try again in a bit. [21:20] s/get on/login on [21:40] Makyo: i've made the changes to mock out the test calls to the actual ssh-agent. pushing changes now. [21:41] bac, cool. Will look in a few. May have to make comments here, haven't figured out rv issue. [21:41] (just get a 500 whenever I try to sign in) [21:42] Makyo: you can use the LP merge proposal if you'd like. would at least be more persistent than IRC logs. :) [21:42] bac, sure thing. [21:42] gary_poster I looked at huw's branch and suggested the fix for the test failures [21:42] cool. going to do short walk with jojo [21:42] awesome thanks hatch [21:43] Alright. [21:43]