[08:05] <kjackal> Good morning Juju world!
[08:06] <SaMnCo> dgonzo hi. Sorry the MWC swamped all my time this week, but today is the day I actually spin that g2. Upcoming news soon
[09:52] <cnf> aaand good morning
[09:52] <cnf> lets try bootstrapping my controller, day 3 :P
[10:15] <Mmike> Hello, lads. What's the best way to get bundletester? If I pip-install it, it breaks stuff on my system - for instance, pull-lp-source from ubuntu-dev-tools doesn't work anymore
[10:45] <cnf> Mmike: virtualenvwrapper ftw?
[10:46] <Mmike> cnf, can we pretend I never asked this question? :)
[10:46] <cnf> done!
[10:46] <cnf> :P
[10:46] <Mmike> :D
[10:47] <magicaltrout> i'm afraid it will shortly end up here: https://irclogs.ubuntu.com/2017/03/03/%23juju.html ;)
[13:14] <Zic> magicaltrout: these are not the logs you are seeking!
[13:14] <Zic> s/seeking/looking for/ :>
[13:15] <Zic> I missed the VO version :p
[15:29] <cnf> hmm
[15:29] <cnf> juju really doesn't want to connect to the bootstrapped controller on ssh
[15:29] <cnf> and no debug logging on it, it seems :(
[15:30] <cnf> Attempting to connect to 172.20.20.16:22
[15:30] <cnf> aaaand stuck
[15:34] <cnf> hmz :/
[15:35] <cnf> how do i get more info than --debug --show-log
[15:42] <cnf> hmm, i guess it's friday afternoon
[15:56] <cnf> still stuck at Attempting to connect to 172.20.20.16:22
[16:05] <lazyPower> cnf: and this is still attempting over the sshuttle tunnel?
[16:05] <cnf> lazyPower: yes
[16:05] <cnf> it's as close as I can get to a direct connection
[16:05] <cnf> manual ssh works over it
[16:06] <lazyPower> I see you've tuned it for verbosity as well
[16:06] <cnf> yeah, but the ssh bit isn't being very verbose
[16:06] <cnf> so i don't know what is going on
[16:09] <cnf> lazyPower: tbh, it seem --show-log doesn't do much beyond what --debug does
[16:11] <lazyPower> yeah i think thats max verbosity, what you have listed there
[16:11] <cnf> yeah, sadly it doesn't give any debug messages for the underlying ssh
[16:13] <Budgie^Smore> My very first juju controller was managed over a sshuttle connection and it worked just fine
[16:14] <Budgie^Smore> but that was about a year ago
[16:14] <cnf> yeah, 2.0 seems to have changed some things?
[16:14] <cnf> idno, i'm new to juju
[16:14] <cnf> Budgie^Smore: did you have to do anything specific?
[16:15] <Budgie^Smore> I was using 2.0... not that I remember... whats your sshuttle command look like?
[16:15] <cnf> sshuttle -r tele-maas --ssh-cmd='assh wrapper ssh' 172.20.20.0/24 195.130.158.250
[16:16] <Budgie^Smore> hmmm, I wonder if it is your ssh-cmd that is causing it, I didn't use that flag
[16:17] <cnf> well, without it, it won't work well
[16:17] <cnf> it needs a few hops to get anywhere
[16:17] <cnf> Budgie^Smore: but i can manually do "ssh 172.20.20.16" and it works
[16:17] <cnf> but juju won't connect to it, it seems
[16:17] <Budgie^Smore> if you can ssh to it then you shouldn't need that flag
[16:18] <cnf> no, i can't ssh to the target
[16:18] <cnf> 172.20.20.16 needs to go over the sshuttle
[16:19] <cnf> it's me ---- machine  ---- MAAS controller --- machine booting to be the juju controller
[16:19] <Budgie^Smore> oh yeah, sorry barely woke up yet
[16:19] <Budgie^Smore> however just cause you can manually ssh doesn't mean that wrapper doesn't change things so that juju can't
[16:19] <cnf> the wrapper is for sshuttle, though
[16:20] <cory_fu> petevg: Can you make any sense of this error I'm getting from Model.deploy()?  http://pastebin.ubuntu.com/24102747/
[16:20] <Budgie^Smore> cnf yes but any wrapper can change something in it's stream so that it is no longer sending expected packets
[16:20] <rick_h> cory_fu: usually I get that with bad yaml
[16:21] <cnf> well, the wrapper is just calling the ssh binary
[16:21] <rick_h> cory_fu: or an invalid value, a string for a tag or something
[16:21] <cnf> i don't see how it would affect anything
[16:21] <Budgie^Smore> or doing something stupid like merging stdout and stderr
[16:21] <cory_fu> rick_h: But there's no yaml in that request?
[16:21] <rick_h> cory_fu: e.g. is it a user tag vs a string username/etc
[16:21] <Budgie^Smore> calling it with what flags?
[16:21] <petevg> cory_fu: Yes. You're giving it an int or something when it expects a string.
[16:21] <cnf> Budgie^Smore: all it does is generate ssh parameters like ProxyCommand etc
[16:21] <cory_fu> petevg: ...  thanks
[16:21] <cnf> so i can chain hops
[16:21] <rick_h> cory_fu: "None"
[16:22] <rick_h> cory_fu: that in there isn't a string or valid value for json
[16:22] <cory_fu> rick_h: That's a Python None, which would be converted to a null
[16:22] <Budgie^Smore> cnf I would reckon there is a conflicting flag between what juju is providing and the wrapper
[16:22] <cory_fu> petevg: Does the "to" field not accept None?
[16:22] <cnf> Budgie^Smore: but the wrapper is for shhuttle only
[16:23] <petevg> cory_fu: I don't remember. The code around the "to" field is really annoying and hard to keep in one's head.
[16:23] <cory_fu> petevg: Docstring says, "If None, a new machine is provisioned." so that seems pretty explicit
[16:23] <cnf> Budgie^Smore: juju just needs to do /usr/bin/ssh 172.20.20.16
[16:24] <petevg> cory_fu: interesting. The Python code in python-libjuju/juju/placement.py represents my best understanding of what Go wants for that field.
[16:24] <petevg> cory_fu: note that it always seems to want things to be packed into an array/list
[16:24] <cory_fu> petevg: Looks like None gets converted to an empty list
[16:24] <cory_fu> petevg: I wonder if it's the Constraints param?
[16:25] <petevg> cory_fu: could be. The version of placement that I'm looking at will just return "None" when it gets passed None, no list involved.
[16:25] <petevg> ... so maybe that is the error -- maybe it should return [] rather than None in that first check.
[16:26] <cory_fu> petevg: Well, it won't ever actually get passed None, at least not from Model.deploy, because there's an outer None check that converts it to []
[16:26] <petevg> cory_fu: Got it.
[16:27] <cory_fu> petevg: I think it's the constraints.  It's getting passed {} which it thinks is a valid parsed value, but it should probably be None instead
[16:28] <petevg> cory_fu: interesting. The constraints.py thing that I wrote will pass back None. I'm assuming that it's getting converted into the empty dict in the facade  object ...
[16:28] <cory_fu> Well, that got me past the ghost failure, but mysql failed
[16:28] <cory_fu> petevg: http://pastebin.ubuntu.com/24102792/
[16:28] <petevg> cory_fu: ah. Unless you give it a dict, then it will pass a dict back, without checking to see if it has stuff in it.
[16:28] <cory_fu> petevg: Yeah.  I was giving it a dict, like a... chump
[16:29] <petevg> cory_fu: eh. I was passing back an empty dict like a chump :-)
[16:29] <cory_fu> petevg: Probably worth replacing the 'if None' and 'if == ""' with a single "if not"
[16:29] <petevg> agreed.
[16:29] <cory_fu> I'll do that in my conjure-up branch
[16:30] <petevg> That error still says "number" to me, though. I wonder if you need to stringify everythign -- "num_units" is an int rather than a string.
[16:30] <cory_fu> Not according to the docstring nor default arg
[16:31] <cory_fu> petevg: mysql is the only one that has config values.  Could the 20000 value be the issue?
[16:32] <cory_fu> petevg: Should we switch regular deploy to use configYAML as well?
[16:32] <cnf> hmz, this is frustrating
[16:33] <petevg> cory_fu: interesting. That could be it, too.
[16:33] <Budgie^Smore> cnf, it probably doesn't just do a clear ssh command, probably adds some control options but the devs would have to say for sure
[16:33] <cory_fu> petevg: +        # stringify all config values for API, and convert to YAML
[16:33] <cnf> it is doing something weird, that's for sure
[16:33] <petevg> cory_fu: yeah. That is supposed to fix things. :-/
[16:34] <Budgie^Smore> and if it isn't that, then it is might be key related
[16:34] <petevg> cory_fu: and I've successfully deployed stuff with configs that look like mysql.
[16:34] <cory_fu> petevg: Actually, I don't like that we have duplication between Model.deploy and BundleHandler.deploy.  Do you think we could combine those?
[16:35] <petevg> cory_fu: probably. I think that I only switched to using config_yaml in BundleHandler.
[16:35] <petevg> ... so if your code is passing through Model.deploy, it might not be stringifying things.
[16:35] <cory_fu> Right
[16:37] <Budgie^Smore> silly question probably but did you add your ssh pubkey to maas so it can add it to juju?
[16:41] <Budgie^Smore> OK I am going to shut up now, that question doesn't make sense :-/ going to go find coffee, bbiab
[16:41] <cnf> Budgie^Smore: yeah, and i can ssh manually
[16:41] <cnf> Budgie^Smore: enjoy :P
[16:42] <Budgie^Smore> something in me still things there might be a key issue, i.e. juju not talking to ssh-agent, etc.
[16:43] <Budgie^Smore> but I am more inclined to thing that it is an overlapping ssh flag issue
[16:43] <cnf> i wish i'd get ssh debug info :/
[16:50] <cnf> hmm
[16:50] <cnf> maybe got something closer
[16:50] <cnf> maybe
[16:51] <lazyPower> cnf: while i wouldn't normally advocate this... you can try something
[16:51] <cnf> no, nm
[16:51] <lazyPower> cnf: you can temporarily rename the ssh bin to something like ssh.orig, and put a wrapper in place that invokes that .orig ssh bin with -vvv
[16:51] <cnf> hmm
[16:51] <lazyPower> but i feel like this means we shoudl file a bug to request a flag to dump ssh debug info
[16:51] <cnf> indeed
[16:51] <lazyPower> i'm not seeing anything anywhere that indicates we have a flag already to provide that detail
[16:52] <cnf> --debug should put ssh in -vvv mode
[16:52] <lazyPower> so, hacky work-around solutions seem to be the path forward for now
[16:52] <lazyPower> cnf: since you filed the other bug i'll file this one ;)
[16:52] <cnf> haha, thanks :P
[16:52] <cnf> it is, once again, almost time to go home for me...
[16:52] <cnf> almost WE
[16:55] <lazyPower> cnf: https://bugs.launchpad.net/juju/+bug/1669848
[16:55] <mup> Bug #1669848: When bootstrapping with the --debug flag, ssh should also pass -vvv for debugging ssh issues <juju:New> <https://launchpad.net/bugs/1669848>
[16:56] <cnf> lazyPower: thanks!
[16:56] <lazyPower> if you dont mind hitting the top left "This bug affects you" to add some bug heat. You may also want to subscribe for updates so you can follow up with any discussion there.
[16:57] <lazyPower> SimonKLB: You're next after i get caio some feedback on a PR submit this morning.
[16:57] <lazyPower> i look forward to this :)
[16:58] <cnf> ah, i was looking for that!
[17:02] <SimonKLB> lazyPower: nice!
[17:09] <cnf> lazyPower: your trick doesn't work! it isn;t showing the output :P
[17:09] <lazyPower> cnf: well it was worth a shot
[17:10] <cnf> yep
[17:10] <cnf> well, i'm out of ideas
[17:10] <cnf> not the way i wanted to start the WE ^^;
[17:13] <cnf> k, i'm going home
[17:13] <cnf> thanks for the help lazyPower, Budgie^Smore
[17:14] <lazyPower> np cnf
[18:23] <bdx> stub: https://bugs.launchpad.net/postgresql-charm/+bug/1669872
[18:23] <mup> Bug #1669872: charm install fails installing snapd on trusty  <PostgreSQL Charm:New> <https://launchpad.net/bugs/1669872>
[18:27] <bdx> from what I can find, snap should install via apt on trusty
[18:27] <bdx> not sure why I'm not getting it
[18:28] <bdx> http://paste.ubuntu.com/24103535/
[18:35] <bdx> stub: in what revision was layer snap introduced to the postgresql charm?
[18:42] <bdx> stub: ahh, rev 117
[18:54] <stormmore> ok I am back and in the office
[22:58] <lazyPower> cory_fu: so i didn't get to it this morning but i just deployed the autoscaler. Did you use this outside of bundletesting?
[22:58] <cory_fu> lazyPower: Nope
[22:58] <lazyPower> cory_fu: do you want to see whats up with it? :D
[22:58] <lazyPower> i'm in a hangout running the paces rn
[22:59] <cory_fu> Uh, sure
[23:01] <lazyPower> lol its cool man :) you're busy and its after 5 on a friday
[23:01] <lazyPower> just making the offer
[23:01] <lazyPower> but i'm in the batcave