[00:40] Bug #1600061 opened: Expect multi-region MAAS clouds [00:40] Bug #1600063 opened: Remove the local: from cloud listing [07:41] Bug #1587739 changed: rackspace,vsphere: firewalling in HA setup is broken [07:44] Bug #1587739 opened: rackspace,vsphere: firewalling in HA setup is broken [07:50] Bug #1587739 changed: rackspace,vsphere: firewalling in HA setup is broken === urulama|__ is now known as urulama [08:44] hey dimitern, could you take another look at http://reviews.vapour.ws/r/5161/ please? [08:44] babbageclunk, dooferlad: a tiny review fixing bug 1598164 - http://reviews.vapour.ws/r/5215/) please, take a look [08:44] Bug #1598164: [aws] adding a machine post-bootstrap on the controller model closes of api port in controller security group [08:45] babbageclunk: *click* [08:45] dimitern: ha ha, swap you - looking now [08:45] babbageclunk: have you seen such an elaborate explanation for a 2 line fix? :D [08:48] babbageclunk: ha, that looks familiar ;) I'll give it a manual test now [08:48] dimitern: quite a twisty tale! [08:49] babbageclunk: yeah, one of those you tell over campfire at night LOL [08:52] * babbageclunk waves. :( [08:52] babbageclunk: I meant mine :) [08:52] dimitern: Yeah, that's what I was talking about too! [08:52] babbageclunk: however reading fwereade's comments it seems we don't need the hook tool at all? [08:53] dimitern: yours LGTM [08:53] babbageclunk: ta! [08:53] dimitern: Only the get one - we still need the set. [08:53] babbageclunk: ah, now it makes more sense, yeah [08:54] babbageclunk: got a link to that modified postgresql charm? [08:55] dimitern: Hmm, no - I could push it somewhere. [08:56] dimitern: But would you be happy enough with `juju run --unit blah/0 "application-version-set yay"`? [08:57] dimitern, babbageclunk: http://reviews.vapour.ws/r/5213/ and http://reviews.vapour.ws/r/5214/ are both small and high impact if you could take a look [08:57] dooferlad: certainly, adding them to my list [08:58] dooferlad: Think I can do them both in 2 mins? [08:58] babbageclunk: ok, so should work with an unmodified ubuntu charm then? [08:58] babbageclunk: probably [08:58] dimitern: yup [08:58] dooferlad: oh alright :) [08:59] dooferlad: I'll swap those 2 for my tiny one [08:59] dimitern: you are on [08:59] dimitern: I can quickly fork and push the charm anyway - it's nicer to see it working properly. [08:59] dooferlad: http://reviews.vapour.ws/r/5215/ [08:59] dimitern's one is small but perfectly formed [08:59] babbageclunk: that's better - it makes it reusable for CI as well [09:00] dimitern: ok [09:00] anyway, lets talk about this in video! [09:00] *let's [09:01] babbageclunk: beware though, if you haven't used the charm tools before to publish a charm, you'll need to both push it on LP and then grant everyone read access, otherwise only you'll see it on jujucharms.com/u/babbageclunk [09:01] omw [10:41] babbageclunk: ping [10:42] dimitern: hi [10:46] dimitern: ? [10:49] babbageclunk: I'm trying to live test your branch [10:50] babbageclunk: on lxd I deployed 3 ubuntu units and tried juju run --unit ubuntu/X -- 'application-version-set Y' [10:50] dimitern: ok [10:50] babbageclunk: should I be seeing what I set somewhere? I can't.. [10:51] dimitern: There's another change to add version to the tabular status, but it's not landed. Can you see it on juju status --format yaml? [10:51] babbageclunk: ah, yeah - I can see it now, sorry [10:52] dimitern: awesome [10:53] dimitern: Just working out how to create (the equivalent of) a pull request on bzr+launchpad. [10:55] babbageclunk: you can just push a local bzr branch to lp:~user/+junk/name IIRC [10:56] http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ [11:09] dimitern: thanks [12:50] Bug #1600221 opened: "juju ssh" et al. should recommend add-ssh-key on auth failure [13:48] Bug #1598358 opened: [juju beta10] With MAAS, node allocated but never told to deploy. [14:18] Bug #1600237 opened: ErroredUnit: 0 is in state cannot complete machine configuration: model configuration has no authorized-keys [14:24] Bug #1600237 changed: ErroredUnit: 0 is in state cannot complete machine configuration: model configuration has no authorized-keys [14:27] Bug #1600237 opened: ErroredUnit: 0 is in state cannot complete machine configuration: model configuration has no authorized-keys [14:57] Bug #1600257 opened: The tab completion on juju yeilds KeyError: 'services' [16:20] Hello balloons can I bother you for a minute? [16:20] balloons: Do you know where the tab completion code is for Juju? Regarding: https://bugs.launchpad.net/juju-core/+bug/1600257 [16:20] Bug #1600257: The tab completion on juju yeilds KeyError: 'services' [16:34] mbruzek, yes I know where the code is [16:35] balloons: I found it in etc/bash_completion.d/ [16:35] mbruzek, that's an interesting bug. Right, that's the installed location [16:36] mbruzek, it stems from https://github.com/juju/juju/tree/41eb73708fa1f86c337cf60d10c2c9f3b2b004f7/etc/bash_completion.d [16:37] you should be able to propose any fixes against one of those files [16:37] balloons: This is strange. I see the bash_completion file in juju-core (master) does not contain the word "services" but the one on my system does. [16:38] balloons: Perhaps it is resolved and just not released in beta11 yet? [16:38] mbruzek: I think I was talking to you in the wrong channel :) [16:39] mbruzek: or is your problem that installing the newer beta doesn't update the completions? [16:40] babbageclunk: I just wanted to help fix this problem, but it looks OK in master [16:41] mbruzek: Yeah, I tried the same thing a little while ago and realised it was already fixed. :) [16:41] great [16:41] I will stand down. [16:42] I'm curious why you aren't seeing the fix in beta11 [16:42] babbageclunk: I see 3 files in /etc/bash_completion.d/ juju2, juju-core, and juju-core2. I don't see the corresponding files in the code tree in github. There must be some rule to copy those? [16:43] my expectation was it would be there [16:43] mbruzek, yes the packaging code lives in a bzr brnach [16:43] http://pastebin.ubuntu.com/18798379/ [16:45] mbruzek: Hmm - maybe the wrong one is being found? Possibly one of them was renamed at some point, and so the old file has been orphaned in bash_completion.d? [16:46] babbageclunk: I just compared the three files, the only difference is juju-core2 has #!/bin/bash on line 1 [16:47] mbruzek: but they all still refer to services? [16:48] mbruzek: This is in /etc/bash_completion.d? [16:48] babbageclunk: Yes, and I see the file in master does not have any references to "services" [16:48] babbageclunk: Correct on my system, xenial 16.04 [16:48] mbruzek: Do you install juju from ppa, or are you building it yourself? [16:49] ppa [16:50] Ok, in that case it sounds like there is still a bug with how the installer sets up completions. [16:52] When you got beta11 it should have included updating the bash_completion.d files. [16:52] http://bazaar.launchpad.net/~juju-qa/juju-release-tools/packaging-juju2-default/view/head:/debian/rules [16:52] I still don't have working completion [16:53] I touched those rules last :-) [16:53] babbageclunk: ballooons: Could you point me to the packaging branch on bzr so I could have a look? [16:54] Bug # opened: 1600296, 1600300, 1600301, 1600302 [16:54] ahh I see the link above [16:55] fyi I just reinstalled juju-2.0 from the ppa in xenial and I don't have anything juju related in /etc/bash_completion.d [16:56] Line 52 installs the file to /usr/share/bash-completion/completions/ but I was checking /etc/bash_completion.d/ directory. [16:57] I checked my system, I have juju-2.0 and juju-version in /usr/share/bash-completion/completions/ [17:01] Weird. I've got working completion, but mine's built from source and is installed from the makefile target (install-etc) whicn puts the files in /etc/bash_completion.d [17:09] mbruzek, if you have the files in the right place, sourcing the directory should make tab completion work [17:27] balloons: is it possible this file used to install in /etc/bash_completion.d/ directory ? I may have old ones left over, but it seems to be favoring the /etc/bash_completion.d/ directory rather than the one in /usr/share/bash-completion/completions/ [17:31] mbruzek, it has changed a bit -- both the location and file name -- and the fact there are 2 files now [17:31] http://bazaar.launchpad.net/~juju-qa/juju-release-tools/packaging-juju2-default/revision/127 [17:33] balloons: What should be done about the old files? I have juju2 and juju-core and juju-core2 which all appear to be the same file. Should the packaging clean up the old ones? Or is that an exercise left to the user? [17:54] Bug #1600311 opened: Juju 2.0 Bootstrap Fails on Ubuntu Trusty Power machine. [17:57] mgz, opinions on old files ^^? [17:57] ...dpkg should handle it [17:57] mbruzek, for the ppa stuff, I would generally say it's just life. However for the archive, we shouldn't be leaving a mess. And since we depend on the ppa so heavily an argument could be made there as well to hold oneself to a higher standard. [17:58] mbruzek: which packages own which files? [17:58] mgz how can I tell that? [17:58] I just updated the bug: https://bugs.launchpad.net/juju-core/+bug/1600257 [17:58] Bug #1600257: The tab completion on juju yeilds KeyError: 'services' [17:59] It seems like my system favors the files in /etc/bash_completion.d/ [17:59] mbruzek, you can use apt-file to check [18:00] mbruzek: `dpkg -S completions/juju` or similar [18:00] whatver the new dir we put it in is called [18:01] mbruzek: `dpkg -S bash_completion.d/juju` for the old location as you seem to have those [18:01] mgz: http://pastebin.ubuntu.com/18804873/ [18:02] balloons: did we not make a conflicts/replaces on juju-core2? [18:03] we want juju2 and juju-core2 deaded if any new packages are installed [18:03] mgz, my concern above came from the fact we have the ppa packaging and the archive packaging [18:03] http://pastebin.ubuntu.com/18805007/ [18:03] juju-core2 is superdead though right? [18:03] That now includes the new files. [18:03] mbruzek: yeah, so it's a bad mix of ppa and archive [18:04] mbruzek: we should do a better job of sanity [18:04] mbruzek: I'd appreciate a bug against juju ini ubuntu for this [18:04] -ini+in [18:04] mgz: OK. I am happy to help, is my juju-core bug not sufficient? You want me to open this on ubuntu? [18:05] mbruzek: oh, you had one? [18:05] https://launchpad.net/bugs/1600257 [18:05] Bug #1600257: The tab completion on juju yeilds KeyError: 'services' [18:05] that's fine, I shall just also affects distro/package to it [18:06] and you misspelt yields :P [18:06] and yea juju-core2 is super dead [18:06] but clearly still lives! [18:07] ack [18:08] balloons: I think all three files in /etc/bash_completion.d/ are "dead" from what I read in the current packaging [18:09] mbruzek: that should be correct [18:09] mbruzek: if you purge juju2 and juju-core2 do you still see the symptom? [18:11] mbruzek: thanks for poking this [18:11] Glad to help and if there is some code that needs to change I can sling some bash [18:11] mgz: I will delete the files after my standup. [18:11] eta 10 mins [18:11] mbruzek: aha, now that's an offer [18:12] mgz: I was digging into this because I thought it was something I could fix [18:12] mgz: It *is* but I don't know if you or balloons will let me fix it [18:13] trust is earned, not sure if I have achieved it yet. [18:13] I would happily let someone unleash magic on bash completion. I've got it working on my box, but it hasn't translated to others. [18:25] mgz: balloons: I am done with meeting. I can purge the files in /etc/bash_completion.d/ now. Any objections? Is there anything else you want to see before I do that? [18:28] mbruzek: nope, go for it [18:28] Done. mgz: I have new information. My old terminals still get the Traceback, and a new terminal does not tab complete. [18:29] I understand why on the old terminals, but thew new on does not seem to be getting the new /usr/share/bash_completion/completions directory [18:29] okay, so we're back to the mystery of why some systems don't do anything with the file we add to the completions dir [18:30] mbruzek: hack-copy it to the old /etc location and see if that then completes in a new term? my guess is it will [18:31] mgz: Correct that works in my system. [18:32] okay, well I wish this stuff was documented like... anywhere [18:32] mgz: My system was 15.04 and was upgraded to xenial 16.04 . Would that have anything to do with this? [18:33] I tried to trace this from .bashrc to /usr/share/bash-completion/bash_completion let me inspect bash_completion more closely [18:34] mbruzek: it may, but really the upgrade should be transparent [18:35] mgz: I only mentioned that because the configuration files may have been from the old system, I think 15.04 was systemd also [18:36] yeah, and the defaulting to the old location makes more sense for a post-upgrade system [18:36] mgz: /usr/share/bash-completion/bash_completion [18:36] mgz: http://paste.ubuntu.com/18808058/ [18:37] Can you compare that against your file? I see on line 43 it sets the backwards compat completion dir. [18:40] mbruzek: yeah, same on a fresh xenial system (and in fact on trusty), all claim RELEASE: 2.1 [18:41] just having the concept of a compat dir is no problem provided it does actually look in the new place [18:44] mgz: I was not able to get tab completion when only juju-2.0 was in the new location... [18:45] mbruzek: on either juju or juju-2.0 right? that's what's we've had reported before [18:46] mgz: Actually it was "juju ssh kuber" [18:46] I'm not sure how we're meant to register completions under the new scheme, what we're doing (sticking in dir) doesn't seem enough [18:46] so it is using the ssh completion, [18:46] I can try juju-2.0 ssh kuber if you like [18:47] yeah, I expect it's the same as would be juju s but... [18:56] mgz: I am seeing a very strange behavior. I can do "juju-2.0 ssh kuber" and THEN "juju ssh kuber". HOWEVER, if I start a new terminal "juju ssh kuber" that does not work until I try juju-2.0 [18:57] okay, well that seems like fun [18:57] mgz: My current theory is "juju" does not alias to "juju-2.0" (which is the name of the completions file) until I use juju-2.0 first. [18:57] that does seem likely [18:58] let me symlink juju -> juju-2.0 and see if that helps [18:58] mbruzek: new thing to try, move the file in completions/ dir to 'juju' and see if new terminal then lets you juju s immediately [19:00] bingo! [19:01] mgz: The symbolic link worked? [19:02] okay, so the fancy mechanism does only load files based on the root path, then once it's loaded everything works [19:02] so... humph [19:02] ! I meant the punctuation ! [19:02] interrobang [19:29] mgz: Do you agree with the symbolic link fix? Or would the name "juju" collide with the 1.25 version in packaging? [19:45] mgz: and or balloons: Here is my solution for your consideration: https://code.launchpad.net/~mbruzek/juju-release-tools/packaging-juju2-default/+merge/299600 [19:51] mbruzek: well, I guess the issue is are we okay with the script being executed twice [19:51] under different names [20:00] mbruzek, whoa that MP is insane.. target is off :-) [20:00] so mbruzek, the file needs to be named juju right? And it works with 1.x and 2.x? [20:01] if yes, we should change the upstream sourcew [20:06] balloons: I didn't test this with juju 1.x [20:07] balloons: what should the target be? [20:07] it needs to work with both [20:07] or perhaps better said; we need tab completion for both, and any change cannot break either [20:07] balloons: agreed... [20:08] balloons: perhaps we need to do further investigation into why juju-2.0 is not loading for "juju ssh kuber"