=== mup_ is now known as mup
=== frankban|afk is now known as frankban
[08:33] <junaidali> Guys, is it possible to deploy an application on a machine with either a tag test1 or test2?
[08:34] <junaidali> cloud provider is MAAS
[13:06] <mark-dickie> junaidali: You can use the --constraints tags=<tag> parameter.
[13:08] <junaidali> mark-dickie: can we specify a constraints like `--constraints tags=<test1 or test2>`?
[13:10] <junaidali> to deply on a machine with a tag either test1 or tes2*
=== Guest99060 is now known as med_
=== med_ is now known as medberry
[14:07] <bdx> did something come across about being able to deploy bundles to pre-existing machines recently?
[14:11] <rick_h> bdx: it's something being hacked on in the side time.
=== medberry is now known as med_
[14:28] <bdx> rick_h: thx
=== disposable3 is now known as disposable2
=== frankban is now known as frankban|afk
[16:56] <andrew-ii> A best practice question of MAAS and Juju: does my Juju controller need to run on its own MAAS node, or would it be reasonable to run on the MAAS controller?
[17:05] <rick_h> andrew-ii: so for testing definitely so what makes sense
[17:06] <rick_h> andrew-ii: but for production, with an HA controller setup we recommend own nodes so that you can migrate and have full safety of those controllers
[17:08] <andrew-ii> rick_h: does that impact bringing Juju charms on the internet, when MAAS is the proxy for everything (any challenges I should watch for?)
[17:08] <andrew-ii> (I am planning to use Openstack)
[17:09] <rick_h> andrew-ii: so if maas is proxying for the nodes that come up it should be ok. One thing folks have done is to manually create a VM and register that in maas
[17:09] <rick_h> so you bootstrap to MAAS, but use constraints (--to=xxx) to target the VM node in maas for the controller
[17:10] <andrew-ii> Huh. Neat. That's a pretty cool design
[17:17] <rick_h> andrew-ii: yea, it helps isolate the controller in case you need to blow stuff away later and keeps everything behaving as normal maas setup
[17:28] <andrew-ii> Thanks rick_h. I have the hardware to make that work, I just wanted to make sure I didn't shoot myself in the foot at the start
[17:46] <jamesbenson> Hi all, so I've moved my maas controller to a hyper-v server and I'm trying to move my juju controller there, but having issues.  I'd rather have a VM host this than a full node.  Has anyone else done this?
[17:48] <rick_h> jamesbenson: moving an already running controller?
[17:48] <jamesbenson> fresh is fine with me :-)
[17:48] <jamesbenson> I was having issues deploying the controller in a VM because I didnt' get the reboot typing right...
[17:48] <jamesbenson> since maas can't do hyper-v
[17:49] <rick_h> jamesbenson: hmm, k. so I don't know about maas and hyper-v tbh. If you can get it registered in maas just tag the node with a special tag and bootstrap --constraints to target it during bootstrap
[17:50] <jamesbenson> yeah, I got the VM registered on Maas, but the power types don't exist for hyper-v... tagging was the way to go though for making sure it got the right one
[19:22] <xarses> snaps, why does it always have to be snaps...
[19:25] <xarses> seriously though, all of the charms tools versions where switched to snaps
[19:26] <xarses> and aparently snapd doesn't run on this box, and its installed and there is no service for it
[19:30] <pmatulis>  xarses what is the nature of your box?
[19:33] <xarses> wsl, 12.04
[19:33] <xarses> all of the docs for all the juju versions had non-snap directions a few months ago
[19:35] <xarses> erm, 14.04 even
[19:37] <pmatulis> xarses, i know. it was changed to snaps b/c the PPA wasn't supported anymore
[19:38] <pmatulis> it may still work
[19:39] <xarses> ppa's have been removed totally? or just for charms project?
[19:41] <hallyn> axw: sure I can give each DC a different name.  thanks i'll give that a shot.
[19:44] <pmatulis> xarses, just charm tools
[19:46] <pmatulis> and like i said, it may still work
[19:47] <xarses> sigh, sounds not fun
[19:47] <pmatulis> https://launchpad.net/charm-tools
[20:10] <[Kid]> is there a way to run the juju controller in a lxc container on a remote node?
[20:10] <[Kid]> instead of localhost
[20:10] <[Kid]> i tried juju bootstrap maas maas-controller --to lxd:containername but it didn't like that
[20:57] <rick_h> [Kid]: not atm, it's not supported.
[21:05] <[Kid]> ok, then how about HA between two localhost controllers?
[21:05] <[Kid]> on different physical hosts
[21:05] <[Kid]> provided they can talk to each other?
[21:06] <[Kid]> i.e. lxd network bridge on each host
[21:06] <rick_h> [Kid]: so at the moment that's waiting on some work taking place in lxd to enable building a lxd cluster.
[21:06] <rick_h> [Kid]: then it'll allow juju to treat it as a cloud and lxd will provision containers and load balance and such
[21:07] <[Kid]> so it will basically be an lxd cloud?
[21:07] <[Kid]> lxd cloud provider
[21:07] <rick_h> [Kid]: the best thing at the moment is to build a lxd environment on each machine and use the cross model relations feature in the upcoming 2.3 release (in beta now) to have things speak across the machines
[21:07] <rick_h> [Kid]: exactly
[21:07] <rick_h> [Kid]: take 5 machines, build a lxd cluster on them, and point juju at them to manage multiple models of running applications
[21:08] <[Kid]> that sounds perfect
[21:08] <[Kid]> but that is waiting on some work in lxd right now?
[21:09] <rick_h> [Kid]: right
[21:10] <[Kid]> could i not just build a controller on each physical machine right now under the same model and do a juju enable-ha?
[21:11] <[Kid]> brb, i would like to finish this shortly