| === mup_ is now known as mup | ||
| === frankban|afk is now known as frankban | ||
| junaidali | Guys, is it possible to deploy an application on a machine with either a tag test1 or test2? | 08:33 |
|---|---|---|
| junaidali | cloud provider is MAAS | 08:34 |
| mark-dickie | junaidali: You can use the --constraints tags=<tag> parameter. | 13:06 |
| junaidali | mark-dickie: can we specify a constraints like `--constraints tags=<test1 or test2>`? | 13:08 |
| junaidali | to deply on a machine with a tag either test1 or tes2* | 13:10 |
| === Guest99060 is now known as med_ | ||
| === med_ is now known as medberry | ||
| bdx | did something come across about being able to deploy bundles to pre-existing machines recently? | 14:07 |
| rick_h | bdx: it's something being hacked on in the side time. | 14:11 |
| === medberry is now known as med_ | ||
| bdx | rick_h: thx | 14:28 |
| === disposable3 is now known as disposable2 | ||
| === frankban is now known as frankban|afk | ||
| 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? | 16:56 |
| rick_h | andrew-ii: so for testing definitely so what makes sense | 17:05 |
| 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:06 |
| 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:08 |
| 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:09 |
| andrew-ii | Huh. Neat. That's a pretty cool design | 17:10 |
| 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:17 |
| 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:28 |
| 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:46 |
| 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:48 |
| 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:49 |
| 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 | 17:50 |
| xarses | snaps, why does it always have to be snaps... | 19:22 |
| xarses | seriously though, all of the charms tools versions where switched to snaps | 19:25 |
| xarses | and aparently snapd doesn't run on this box, and its installed and there is no service for it | 19:26 |
| pmatulis | xarses what is the nature of your box? | 19:30 |
| 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:33 |
| xarses | erm, 14.04 even | 19:35 |
| pmatulis | xarses, i know. it was changed to snaps b/c the PPA wasn't supported anymore | 19:37 |
| pmatulis | it may still work | 19:38 |
| xarses | ppa's have been removed totally? or just for charms project? | 19:39 |
| hallyn | axw: sure I can give each DC a different name. thanks i'll give that a shot. | 19:41 |
| pmatulis | xarses, just charm tools | 19:44 |
| pmatulis | and like i said, it may still work | 19:46 |
| xarses | sigh, sounds not fun | 19:47 |
| pmatulis | https://launchpad.net/charm-tools | 19:47 |
| [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:10 |
| rick_h | [Kid]: not atm, it's not supported. | 20:57 |
| [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:05 |
| [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:06 |
| [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:07 |
| [Kid] | that sounds perfect | 21:08 |
| [Kid] | but that is waiting on some work in lxd right now? | 21:08 |
| rick_h | [Kid]: right | 21:09 |
| [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:10 |
| [Kid] | brb, i would like to finish this shortly | 21:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!