[07:10] <kjackal> Good morning Juju World!
[09:09] <cnf> ohai
[10:20] <cnf> is there a way to lint bundle yaml files?
[10:27] <cnf> i keep getting "invalid charm or bundle provided", and i don't know what's wrong
[10:33] <anrah_> cnf: if you deploy with --debug Juju should show the error
[10:34] <cnf> anrah_: ah, that's slightly more useful, thanks!
[10:37] <cnf> hmm, my juju version has no option to reload spaces, it seems
[10:37] <wpk> It's only in 2.2
[10:52] <roaksoax> /query/win 8
[10:53] <cnf> roaksoax: new to irssi, or just mistyping a lot lately? :P
[10:55] <roaksoax> cnf: ha! happens to me all the time
[10:59] <cnf> yeah, i noticed :P
[11:03] <roaksoax> :)
[11:03]  * roaksoax pulls yet another roaksoax
[11:36] <cnf> ugh
[11:37] <cnf> juju is doing weird shit with my network settings again :(
[11:37] <cnf> it works when MaaS brings it up, juju does stuff, and it no longer works
[11:45] <cnf> :(
[11:45] <cnf> why the hell is it adding post-up route add -net 172.20.19.248 netmask 255.255.255.248 gw 172.20.20.254 metric 0 || true ?
[11:46] <cnf> that makes no sense, and that subnet isn't even associated with that interface
[11:48] <boolman> when deploying services on lxd containers, the machines get stuck in pending sometimes
[11:48] <boolman> how do I retry these without destroying my model?
[11:49] <cnf> boolman: for containers, i have not found a way
[11:49] <boolman> =/
[11:49] <cnf> boolman: if you can, change a config value
[11:49] <cnf> and change it back
[11:49] <cnf> that tends to trigger a retry
[11:50] <cnf> ugh "no matching agent binaries available" :(
[11:50] <boolman> cnf: I will try that next time, thx
[11:57] <cnf> anyone here good with networking, especially in relation to juju?
[12:20] <cnf> how long can a controller upgrade take? o,O
[12:37] <cnf> hmm. it's been upgrading for 40 minutes now
[12:37] <cnf> 45
[12:43] <BlackDex> cnf: upgrading to juju 2.2?
[12:43] <BlackDex> That took a while for me
[12:44] <BlackDex> i think it has something to do with the logs cleaning or something like that
[12:44] <cnf> yes, and it's juju being retarded again
[12:44] <cnf> juju and networking bs, as usual
[12:44] <BlackDex> upgraded maas to 2.2 also already?
[12:44] <BlackDex> if so, dubble check your subnet/vlan spaces
[12:45] <BlackDex> since they changed it from subnets to vlan for the space definitiion
[12:45] <cnf> no, because maas 2.2 breaks shit for me
[12:45] <cnf> and it can't even access mass
[12:45] <BlackDex> ah
[12:45] <cnf> mass
[12:45] <cnf> maas
[12:45] <cnf> because it is being stupid
[12:45] <BlackDex> hmm
[12:45] <BlackDex> haven't yet played a lot with it yet. So i can't tell if it works for me
[12:46] <BlackDex> the only thing i know is that upgrading from juju 2.0 to 2.1 and then to 2.2 breaks whole networking for me
[12:46] <BlackDex> spaces are broken
[12:46] <BlackDex> can't enrole a lxd with the correct interfaces
[12:47] <BlackDex> but again, i havent looked at it that much, not debuged it or what ever
[12:47] <cnf> MaaS 2.1 > 2.2 spaces changed
[12:47] <cnf> fromn layer 3 to layer 2
[12:47] <cnf> which is why i am NOT upgrading MaaS at this time
[12:47] <BlackDex> it was broken from 2.0 > 2.1 for me already
[12:47] <BlackDex> 2.2 didn't fixed it
[12:47] <BlackDex> i think i need to start over again
[12:48] <BlackDex> but that is shitty for a production env
[12:49] <BlackDex> doubt that you can backup juju, remove the controller, install a new one with the new version and restore the backup
[12:49] <BlackDex> to be as clean as possible
[12:58] <cnf> so juju assumes that the machine you use to run the juju command has the EXACT same network connectivity as the controller?
[12:58] <cnf> wt?
[13:00] <cnf> jam: poke?
[13:00] <BlackDex> cnf: No, not that i know
[13:01] <BlackDex> i have several juju installs where the controller does not have a storage network
[13:01] <cnf> storage? i'm talking about storage
[13:02] <BlackDex> i'm just saying that it doesn't matter if the controller isn't connected to the storage network, it still works
[13:02] <cnf> o,O i'm not talking about storage networks
[13:02] <BlackDex> i know
[13:03] <BlackDex> i'm just stating that it doesn't matter!
[13:03] <cnf> of course not, because it's not relevant?
[13:03] <BlackDex> So, the answer to your question is NO, it doesn't have to be the EXACT same network
[13:04] <BlackDex> if i'm correct, they don't even need to be on the same subnet, preverably they do, but as long as they can send commands to each other it will all be fine
[13:04] <cnf> you misunderstand
[13:05] <cnf> juju assumes it has the same routing to get to stuff like the MaaS controller
[13:05] <cnf> if it doesn't, upgrades fail
[13:05] <BlackDex> ah
[13:05] <BlackDex> that wasn't clear in your statement ;)
[13:06] <cnf> hmz, how the hell am I going to fix this mess :(
[13:06] <BlackDex> i don't know
[13:06] <BlackDex> the failed juju upgrades i encountered ended up in a backup restore
[13:13] <cnf> westcoast is 6 am right now, isn't it?
[13:14] <cnf> i guess jam will get here once i get home ^^;
[13:31] <jam> cnf: /wave
[13:31] <cnf> ohai!
[13:31] <cnf> jam: i fixed my problem (with an UGLY UGLY hack)
[13:31] <cnf> jam: but do you have some time to debug it?
[13:32] <cnf> see what caused it, and if it was me doing something wrong, or if i need to submet a juju bug?
[13:32] <jam> I can at least chat about it a bit
[13:32] <cnf> cool
[13:33] <cnf> jam: so i just started a juju upgrade process
[13:33] <cnf> and my juju controller was trying to access MaaS on an ip that is valid from my laptop, but just doesn't work from the juju controller
[13:33] <cnf> and I can't find where it sets this, or where i can change it
[13:34] <cnf> (so i assigned the ip on the juju controller, and used ssh port forwarding to redirect as a temporary hack)
[13:34] <jam> cnf: so MAAS does have an address that the Juju controller can talk to it from, just not the one from your laptop?
[13:34] <cnf> jam: right
[13:34] <cnf> jam: it can talk to the maas controller on the maas network (172.20.20.1 in my case)
[13:36] <cnf> jam: as a sidenote, in my case the juju controller runs on a KVM on the MaaS controller machine
[13:42] <jam> cnf: if you're on a kvm on the MAAS controller, wouldn't you have a gateway of the maas controller's IP on the KVM bridge, and the MAAS machine itself would route the traffic to the other IP ?
[13:43] <cnf> jam: no routing for it on that bridge
[13:43] <cnf> and it would not be on a kvm in production, anyway
[13:43] <cnf> so it's internal vs external ip for the MaaS controller
[13:44] <cnf> the juju controller can only see the internal one
[13:50] <jam> cnf: so when you register the URL to talk to MAAS, I believe we only support a single URL, but that would be the place to set it
[13:51] <cnf> jam: register it where?
[13:51] <cnf> on the client?
[13:56] <jam> cnf: when you do "juju bootstrap" or "juju add-cloud", etc, we take the URL of the MAAS API
[13:56] <jam> that includes the IP/hostname of the MAAS controller
[13:56] <jam> cnf: another option is to use DNS to give the MAAS controller a name and have that resolve to multiple addresses
[13:57] <cnf> jam: so you are saying i will have an eternal problem with this?
[14:02] <jam> cnf: I'm not sure how you made it work in the first bootstrap case, as we always just take "here is the URL for MAAS"
[14:03] <jam> I don't quite understand why Upgrade would be different than Bootstrap/initial deployment
[14:03] <cnf> jam: i don't know...
[14:24] <cnf> jam: but it's not an uncommon usecase, i think
[14:59] <cnf> back
[16:58] <bdx> http://paste.ubuntu.com/24900445/
[16:58] <bdx> ghaaaar
[17:05] <lazyPower> bdx: wow, scaling for the win right?
[17:06] <bdx> right
[18:59] <Budgie^Smore> o/ juju world
[19:00] <lazyPower> \o Budgie^Smore