[16:21] <jrwren> I was just reading https://insights.ubuntu.com/2018/03/20/lxd-weekly-status-39 and noticed something about cluster placement. Does anyone know when LXD got clusters and placement and where it is in the docs?
[16:23] <jrwren> Ah, https://lxd.readthedocs.io/en/latest/clustering/  there. no idea when this landed
[16:24] <rick_h_> jrwren: it's new trying to make lxd more 'cloud-like'
[16:24] <jrwren> rick_h_: its great and sensible!
[16:24] <rick_h_> jrwren: it's been in progress the last 2 cycles I think
[16:24] <rick_h_> yea
[16:27] <jrwren> configured correctly it can be a nice alternative to a simple openstack.
[16:27] <rick_h_> definitely
[16:28] <rick_h_> less overhead by a long shot, 5 machines in a lxd cluster > those 5 machines just running OS components
[16:28] <rick_h_> though when you outgrow and need SDN and storage and ...
[16:28] <jrwren> no need for complexity of glance, keystone, neutron (zomg complex!)
[16:28] <jrwren> yup, exactly.
[16:29] <jrwren> but still, if you are small enough... do everything you can to stay small and avoid needing neutron for as long as possible :p
[16:29] <jrwren> and cinder... UGH... cinder and swift are THE WORST!  :p
[16:30] <rick_h_> yea, it's a nice way to put something like guimaas to better work tbh
[16:30] <rick_h_> take the 6 nodes into a lxd cluster and then juju deploy on top of that "cloud" across machines and such
[16:30] <jrwren> mmmhmmm.
[16:30] <jrwren> or if you are very lucky, skip juju :p
[16:31] <rick_h_> :P
[16:31] <rick_h_> still have to operate the stuff so <insert something here>
[16:31] <jrwren> operate?
[16:31] <jrwren> k8s I guess. :p
[16:32] <jrwren> but juju is probably best way to deploy k8s, and then you are back to guimass being juju managed. But I guess k8s on metal is better than k8s on Openstack.
[16:32] <rick_h_> heh, back to running openstack
[16:32] <jrwren> so flexible!
[16:32] <rick_h_> yea, definitely k8s on bare metal
[16:33] <rick_h_> I don't get k8s on openstack tbh
[16:33] <jrwren> I do, but I don't like it.
[16:33] <jrwren> Its because k8s doesn't do any network security and since it is soft containers it doesn't technically do any OS security either and so you need the NOVA + Neutron for host and network security.
[16:34] <jrwren> It also lets you build many small k8s clusters in VMs instead of one large one.
[16:34] <jrwren> k8s doesn't do resource management quite as nicely as nova, again because of its container not VM nature.
[16:36] <rick_h_> yea, fair enough I guess
[16:36]  * rick_h_ just get sad face at the resources running the stacks of stuff needed to run the application container
[16:37] <jrwren> Me too.
[16:37] <rick_h_> at some point the complexity has to out weigh the 'ease of deploy' of stuff
[16:37] <jrwren> It is why I still LOVE the stackoverflow approach.
[16:38] <jrwren> It doesnt' even have to be complexity. It can be pure cost. Running this stuff in the public cloud gets expensive pretty quickly.
[16:39] <rick_h_> yea, I think the research was something like around 30 large instances it get more cost effective to run your own hardware?
[16:40]  * rick_h_ needs to look that back up, maybe it was a bit more than 30
[16:40] <jrwren> its subjective because it depends on so many things. I'm convinced you can pretty much make those number say wahtever you want them to say.
[16:41] <rick_h_> fair enough, there's definitely a crossing point for folks I think
[16:42] <jrwren> definitely.