=== frankban|afk is now known as frankban
[10:09] <imran_khakoo> I'm seeing "E: Unable to locate package juju-mongodb3.2" when I bootstrap a new 18.04 controller. Any news on when this package will be available?
[11:02] <parlos> Good Morning!
[15:11] <magicaltrout2> hello folks
[15:11] <magicaltrout2> amulet
[15:11] <magicaltrout2> its asking me for juju-deployer
[15:11] <magicaltrout2> what faux pas am I making?
[15:18] <magicaltrout2> rick_h_: any clue?
[15:18] <magicaltrout2> are you supposed to use juju-deployer with juju 2.x & amulet?
[15:19] <rick_h_> magicaltrout2: otp, but I think that amulet never lost the deployer dep so it's working as expected?
[15:20] <magicaltrout2> well deployer wants paths that don't exist in juju 2.0 like .juju/environments.yaml etc
[15:38] <cmars> hi, does CDK & ceph work with azure storage? i'm trying to deploy ceph and attach storage, but it never seems to detect the block devices
[15:42] <kwmonroe> magicaltrout: yeah, amulet will use juju-deployer.  get it with pip3 install juju-deployer.
[15:42] <kwmonroe> magicaltrout: when you want to run it with juju 2.x, make sure you pass the -e <controller>:<model
[15:43] <rmcd> list
[15:45] <kwmonroe> magicaltrout: if you're just running amulet tests directly, it should be smart enough to use the current model.  but if you're calling juju-deployer in your own script, make sure you stick in the -e.
[15:51] <magicaltrout> hmm thanks kwmonroe i'll give it another prod later
=== frankban is now known as frankban|afk
[17:18] <hml> zeestrat: ping
[18:07] <zeestrat> hml: pong
[18:08] <hml> zeestrat: hi - question on your email , what cloud are you bootstrapping?
[18:11] <zeestrat> hml: Localhost/lxd. Can't remember if I checked MAAS.
[18:13] <hml> zeestrat: 2.4-beta1 is almost out the door, so i’m not sure anything can be added.  i’d recommend emailing the juju mail list for discussion and geting more spotlight on it.
[18:14] <zeestrat> hml: Sounds good. Thanks for taking a look :)
[18:14] <hml> zeestrat: i’ve also been playing the lxc profiles
[18:14] <hml> see if i can get constraints working for you that way
[18:15] <hml> but that limits individual memory constraints to a single model
[18:15] <hml> not optimal
[18:15] <zeestrat> hml: Yeah, the problem is multiple different mem constraints in the same model. The workaround we have works so don't stress.
[18:16] <hml> :-)
[18:17] <zeestrat> hml: Thanks again. Have a nice weekend!
[18:17] <hml> zeestrat: you too!
[18:27] <ananke> was wondering if somebody could help me out figuring out general architecture question regarding juju and maas (very green on those subjects). say I have a dozen servers under maas management, and I want to use juju for various app deployments. I've bootstrapped juju onto maas, and it took on an entire physical node
[18:31] <ananke> now if I deploy any application stack with juju, each 'application' uses an entire physical node, which is a bit of an overkill of course. So my question is, what are some typical ways of combining maas+juju with virtualization, and would I be using juju to deploy them, or maas?
[18:32] <ananke> maas seems to have an option to manage kvm virtualization, but juju store doesn't have anything for that. there are container solutions, but maybe I'm overlooking something obvious
[18:35] <zeestrat> ananke: No, it's a bit of pain atm. Regarding the bootstrapped juju controller, folks usually create some kvm vm's on a dedicated machine or even on the MAAS controllers themselves and add them to MAAS so you have more machines to pick from. Then when you bootstrap juju, you can select those kvm vm's with a constraint or MAAS tag. Check out https://docs.maas.io/2.3/en/nodes-add#kvm-guest-nodes
[18:36] <zeestrat> ananke: I believe using kvm vm's got even easier with MAAS if you use their pod/composable hw setup: https://docs.maas.io/2.3/en/nodes-comp-hw
[18:37] <ananke> zeestrat: thank you. I may have to revisit the white board and figure out if maas+juju are still worth exploring. I was hoping maas+juju would help manage that middle layer
[18:38] <zeestrat> ananke: Regarding deploying applications with juju, you can use the same kvm trick as with the bootstrapped juju controller but what most folk use and would be most appropriate is LXD containers. They are well supported and make it easy to deploy multiple applications on the same host.
[18:41] <ananke> zeestrat: thanks, that makes sense. I haven't spent much time with lxd, but it's certainly something we'd be willing to learn
[18:41] <zeestrat> No worries. At work, we dedicate 2 boxes for a bit of redundancy (can do on 1) for MAAS controllers and juju controllers with kvm. For the rest we use LXD.
[18:42] <ananke> wonder if maas+openstack+juju combinations are common. seems there are guides on how to deploy openstack on maas, but not sure if those three can be glued together
[18:43] <ananke> zeestrat: that's what I was planning on doing too, have a couple controllers per rack. I have two racks of equipment in two discrete facilities, dedicated mostly for testing various things. maas & juju seemed like a good fit, and they appear to be well polished
[18:43] <zeestrat> ananke: That's exactly what we do. MAAS manages the hardware and juju deploys openstack on the hardware from MAAS.
[18:45] <ananke> zeestrat: and then does juju communicate with openstack for deploying apps, or how is that done? I wonder if there are any blueprints for that setup
[18:46] <zeestrat> ananke: Are you thinking of deploying openstack or deploying apps on top of openstack? Juju will do both, just good to know what you're looking for :)
[18:47] <ananke> zeestrat: frankly, either or, whatever makes more sense. being able to deploy apps on top of openstack would be ideal
[18:48] <hml> ananke: you can use juju to deploy openstack on your maas hardware, then turn around and have juju use the openstack to deploy applications.
[18:49] <ananke> I'm coming from the traditional HPC clustering world, which has a very different approach to many things. we would like to create an on-prem cloud solution, first to serve our IT needs, second to potentially have a self-service cloud for our researchers
[18:49] <zeestrat> ananke: I'd check out the openstack deployment guide if you're looking to deploy: https://docs.openstack.org/charm-deployment-guide/latest/. For more general info about the openstack juju charms (the recipes/playbooks used by juju) see: https://docs.openstack.org/charm-guide/latest/. For deploying apps on top of openstack see: https://jujucharms.com/docs/stable/help-openstack
[18:49] <ananke> zeestrat: thanks, I was looking at the first document already earlier today, I'll check out the other one too. just trying to get my head wrapped around how all of this could function
[18:49] <ananke> hml: ahh, that makes sense
[18:50] <hml> for juju maas, openstack, lxd, aws, gce, azure are all clouds… you can bootstrap with them then deploy
[18:52] <ananke> I should redo the juju setup then, and have it use lxd on the maas controller, instead of an entire physical node
[18:52] <hml> you can deploy units to lxd containers on machines already deployed
[18:52] <hml> instead of new machines for each unit
[18:53] <hml> check out the —to directive
[18:53] <ananke> hml: right, that makes sense. however, I'm not familiar with lxd at all, and was hoping there was an existing solution with either maas or juju to manage lxd on those machines
[18:54] <hml> ananke: you can try ‘juju add-unit <application> —to lxd:0’
[18:54] <hml> that would add a unit of something to a new lxd container on machine 0
[18:56] <hml> there are many permutations of specifying where a new unit will go… check out juju help add-unit
[18:56] <ananke> while I fumble through documentation, what's the relation of '0' in juju to maas? I imagine I would be able to query available systems from juju
[18:57] <ananke> forgive the naive questions, I just started with juju this morning
[18:57] <hml> not a problem  :-)
[18:57] <hml> 0 is what juju defines as machine 0
[18:57] <hml> if you run juju status 0
[18:57] <hml> you can find which machine/isntance in your maas config is being used
[18:58] <zeestrat> ananke: Just note that if you want to bootstrap juju on a MAAS controller, then your best bet is kvm as MAAS doesn't support lxd containers.
[18:58] <ananke> zeestrat: thanks
[18:59] <hml> zeestrat: you can still use lxd on a machine already deployed though yes?  just not use lxd as a maas machine?
[18:59] <zeestrat> hml: Yes, just not as a MAAS machine which you need for bootstrapping juju.
[19:00] <hml> lxd can be confusing, since we can use as a cloud, or to add containers to juju machines
[19:00] <hml> used in multiple ways
[19:00] <ananke> hmm, juju status 0 reveals nothing different than juju status <any number here>. https://paste.ofcode.org/yPdkLET3NNfTKjJwaHvRPq
[19:00] <hml> :-)
[19:00] <zeestrat> It's a bit confusing (it sure confused me in the start).
[19:00] <hml> ananke: oops.. sorry  - you have to deploy a charm first… :-)
[19:01] <hml> juju deploy ubuntu —to lxd
[19:01] <hml> will deploy a maas machine - then install ubuntu  charm on an lxd container on top of the machine
[19:01] <ananke> ERROR unrecognized args: ["lxd"]
[19:02] <hml> weird… dash dash to?
[19:02] <ananke> hmm. this is maas 2.3.0 with whatever latest stable juju was
[19:02] <hml> my irc client is autocorrecting on me
[19:02] <ananke> hml: ahh, some weird encoding took place. I retyped that, seems to be running now
[19:03] <bdx> kwmonroe: happy friday
[19:03] <ananke> looks like maas booted a system, and is installing ubuntu. yay
[19:03] <kwmonroe> bdx: o/
[19:04] <bdx> experiencing some issues with hadoop on openstack
[19:04] <bdx> juju status | http://paste.ubuntu.com/p/DNdJprKXHH/
[19:04] <bdx> kwmonroe: got a bug coming your way
[19:05] <bdx> have you seen this before https://paste.ubuntu.com/p/TMCVJJb4jv/
[19:05] <bdx> ?
[19:05] <ananke> hml: thank you so much, this is helping me figure out how I can approach this stack
[19:05] <bdx> when I look in /var/log/hadoop-hdfs/hadoop-hdfs-namenode-juju-6e95f5-hadoop-test-5.out
[19:05] <hml> :-)
[19:06] <bdx> https://paste.ubuntu.com/p/JvbskWgKSd/
[19:06] <bdx> cat /var/log/hadoop-hdfs/hadoop-hdfs-namenode-juju-6e95f5-hadoop-test-5.out ^
[19:07] <bdx> kwmonroe: is this telling me that xenial-cloud-img has different/more restrictive ulimit defaults that stop hdfs from starting?
[19:09] <kwmonroe> bdx: i don't think so.. the .out is terrible.  see if there's more info in the .log (should be in the same dir)
[19:09] <kwmonroe> bdx: if i had to guess, your NN can't resolve it's own address.  i know that is particularly painful in openstack envs
[19:10] <kwmonroe> i mean, trying to deploy hadoop in openstack envs..
[19:10] <bdx> Oh I bet
[19:10] <kwmonroe> which is https://github.com/juju-solutions/jujubigdata/issues/62
[19:10] <kwmonroe> which is ... still not fixed :/
[19:10] <bdx> cat /var/log/hadoop-hdfs/hadoop-hdfs-namenode-juju-6e95f5-hadoop-test-5.log | http://paste.ubuntu.com/p/FWgwPc2Yxr/
[19:10] <bdx> totally
[19:10] <bdx> I wonder if I can hook up the designate bits and make my way
[19:11] <bdx> ill be looking into this
[19:11] <bdx> guess I wont be filing any bugs for you:)
[19:11] <kwmonroe> oh there's plenty filed already.  dont you fret.
[19:11] <bdx> Caused by: java.net.UnknownHostException: juju-6e95f5-hadoop-test-5: Name or service not known
[19:11] <bdx> boom
[19:12] <bdx> ok
[20:28] <bdx> kwmonroe: its all about https://jujucharms.com/neutron-api/#charm-config-enable-ml2-dns
[20:28] <bdx> they made it simpel for the internal resolution
[20:28] <bdx> real nice
[20:28] <bdx> designate looks like it s for external dns
[20:29] <bdx> kwmonroe: I was able to get around it with that config
[20:37] <kwmonroe> whoa - super cool bdx!  i kept hoping it would fix itself (or at least get easier).  turns out waiting pays off!
[20:58] <bdx> +!
[20:58] <bdx> +1 same