=== frankban|afk is now known as frankban
[08:06] <kjackal> Good morning Juju world!
[08:27] <BlackDex> Hello there, is there still an option to force the usage of LXC instead of LXD with juju 2.0?
[08:27] <marcoceppi> BlackDex: lxd is lxc, you mean lxc 1.0 instead of 2.0?
[08:28] <BlackDex> yes.. i think i mean that...
[08:28] <BlackDex> Am i correct that LXD an KVM/QEMU can't run together
[08:29] <BlackDex> Because of the CPU VT-D usage?
[08:39] <rockstar> BlackDex: LXD and KVM can absolutely be used together. I'm doing it on my machine right now.
[08:40] <rockstar> BlackDex: I can't imagine a reason why LXD would be using VT at all. It's not a virtualized environment.
[08:46] <BlackDex> Ah oke
[08:46] <BlackDex> So, if i want to deploy openstack using juju 2.0 and run some services on a compute node that can be done withing LXD :)
[08:49] <marcoceppi> BlackDex: yeah, you should check out: https://github.com/openstack-charmers/openstack-on-lxd
[08:49] <rockstar> BlackDex: absolutely.
[08:49] <rockstar> BlackDex: in fact, I do the development of nova-lxd inside a lxd instance, so my devstack compute nodes are straight-up lxdception.
[08:51] <BlackDex> rockstar: So you have  a Host, which has an LXD container, which has nova-lxd in it?
[08:51] <rockstar> BlackDex: yes.
[08:51] <BlackDex> Wow
[08:51] <BlackDex> nice
[08:51] <rockstar> And I've also booted KVM instances inside of my nova-lxd container.
[08:51] <rockstar> BlackDex: it's changed a bit since this, but if you're interested: http://iamtherockstar.com/devstack-in-a-lxd-container.html
[08:51] <BlackDex> including VT?
[08:55] <rockstar> BlackDex: yes.
[08:56] <BlackDex> Oke, nice
[08:56] <BlackDex> thx for the info! and the website
[09:02] <rockstar> BlackDex: LXD shares the kernel with the host, so as long as the kernel has support for it, the LXD gets them too.
[09:02] <BlackDex> oke, that is good to know.
[09:03] <BlackDex> Do you also know if it is possible to have static ip's for LXD/LXC containers via JuJu/Maas?
[09:03] <BlackDex> Can't seem to find anything on this. It all seems to do DHCP
[09:10] <anrah> Hi! I upgraded my OpenStack and during the update I enabled HTTPS on my public APIs
[09:11] <anrah> now I get error: http://paste.ubuntu.com/23424696/
[09:11] <anrah> the instance gets created but apparentely the bootstrapped machine needs the ca-file to the machine if it wants to talk to openstack
[09:12] <anrah> ca-cert-path config option should do the trick, but that is not available on juju 2.0 ?
[09:14] <marcoceppi> anrah: it might be best to check in #openstack-charms
[09:16] <rockstar> BlackDex: that'd be a question for #lxcontainers
[09:16] <BlackDex> rockstar: Thx i will check over there
[09:17] <caribou> Hi, is there a way to prevent amulet from destroying the environment after tests (juju 1.25) ?
[09:18] <caribou> for some reason rsync refuses to get my tests logs; I get permission denied
[09:18] <anrah> marcoceppi: I am not deploying openstack, but rather definining openstack as a cloud which juju should use
[09:24] <kjackal> caribou: are you using bundletester to run your tests?
[09:24] <caribou> kjackal: no, just "juju test" from the charm's directory
[09:25] <kjackal> caribou: could you try the reset: false flag inside the test.yaml?
[09:26] <kjackal> caribou: I am not sure if that will be honored. Have a loog at the description of the flag here: https://github.com/juju-solutions/bundletester
[09:26] <caribou> kjackal: test.yaml ? don't have one of those, just the test scripts
[09:26] <caribou> kjackal: ok, I'll look at it
[09:31] <caribou> kjackal: thanks!
[10:15] <cory_fu> kjackal: Can you give me a review on https://github.com/juju-solutions/cloud-weather-report/pull/81
[10:15] <kjackal> cory_fu: I am on it!
[10:15] <cory_fu> Thanks!
[10:30] <kjackal> cory_fu: Looks good! Let me know if you want me to merge it. Should we wait for the 200 amulet return?
[10:31] <cory_fu> kjackal: Were you able to run it and confirm the HTML fix?
[10:33] <kjackal> Oh, you need a full use then! Ok, that will take some more time. I just run the unit test. I will ping you again
[10:33] <kjackal> cory_fu: ^
[10:33] <cory_fu> Please do.  Thank you
[10:33] <cory_fu> kjackal: Heading to lunch now.  bbiab
[10:46] <kjackal> cory_fu: run the testplan (git) exmaple on lxd. No problems in the HTML, looks fine!
[11:09] <cory_fu> kjackal: great, thanks
=== linaras is now known as deanman
[15:19] <petevg> bcsaller, cory_fu: I just pushed an update to https://github.com/juju-solutions/matrix/pull/11, which fixes the issues that I was seeing in test_glitch. You may need to rebuild your .tox environment, as it incorporates a matching fix to python-libjuju
[15:52] <BlackDex> can i mix series within a bundle file?
[15:52] <aisrael> blackboxsw: Yes
[15:52] <BlackDex> like almost everything is xenial, but some stuff is trusty, and that will be in an lxc?
[15:53] <BlackDex> the default series can be xenial, and then a charm just trusty/something, and that will work?
[15:53] <aisrael> blackboxsw: here's an example: http://pastebin.ubuntu.com/23426074/
[15:54] <aisrael> You can set a per-machine series
[15:54] <blackboxsw> BlackDex, that was for you ;)
[15:54] <aisrael> err, yes, sorry!
[15:55] <BlackDex> :)
[15:55] <aisrael> silly tab completion
[15:55] <BlackDex> hehe, but i figured :)
[15:55] <BlackDex> oke thx, ill go and try that
[17:33] <jjohnston> Happy Friday, I have a question about juju 2.0 and ipv6 if anyone here can assist?  My question is how to I prevent lxd instances from taking ipv6 addresses during a juju deploy?
[17:34] <jrwren> jjohnston: using the local lxd provider?
[17:35] <jjohnston> no, deploying to remote nodes via maas
[17:35] <jjohnston> maas managed nodes rather
[17:37] <jjohnston> i don't have any ipv6 networks in maas and the bare-metal hosts take ipv4 addresses as expected, but the lxd instances, including the api endpoint for ceph (in this case) are taking ipv6 addresses
=== frankban is now known as frankban|afk
[17:42] <marcoceppi> jjohnston: thta's really odd, I htink there's a model config to disable ipv6
[17:42]  * marcoceppi checks
[17:43] <jjohnston> that would be nice, I'm green with juju, but i've not been able to find such a parameter after extensive googling
[17:43] <marcoceppi> jjohnston: I don't have a MAAS model available to me atm, but does juju model-config yield anything exciting?
[17:43] <rock> Hi all. To push our charm to charm public store we created an charm account using https://login.ubuntu.com/xbX4GvuWSuVkirqs/+decide. I pushed charm to store using that account from JUJU CLI. Now  I deleted my charm account permanently. Bur account user name is still there.
[17:44] <rock> How can I remove that account username
[17:44] <marcoceppi> rock: which account username?
[17:45] <rock> marcoceppi: Hi. ubuntu SSO account username.
[17:46] <marcoceppi> rock: right, what is your username you want to delete? :)
[17:46] <rock> marcoceppi: "kaminario"
[17:48] <rock> When I was trying to create another account using same username "kaminario". It was showing username "kaminario" already in use.
[17:50] <marcoceppi> rock: I will take a look
[17:50] <rock> marcoceppi: Thank you.
[18:15] <jjohnston> @marcoceppi the only thing of remote interest that I can see is the ignore-machin-addresses and that's only because I can't even guess what that does
[18:16] <jjohnston> i don't see anything regarding protocol preferences as previous versions of juju apparently had
[18:55] <marcoceppi> jjohnston: this might be a better topic for juju@lists.ubuntu.com and juju-dev@lists.ubuntu.com, I don't have a good answer for you
[19:02] <pragsmike> anyone else having trouble rabbitmq charm rev 56 to run in openstack-base?
[19:03] <pragsmike> all the openstack charms, mysql, ntp started ok, just rabbitmq says error, hook failed: "config-changed"
[19:04] <pragsmike> deploying using maas 2.1
[19:12] <marcoceppi> pragsmike: are you putting rabbit in a lxd machine?
[19:14] <jjohnston> @marcoceppi: Thanks, I'm going to redploy juju ensuring there are no references to ipv6 prior to the bootstrap
[19:15] <marcoceppi> jjohnston: cool, if maas isn't configuring ipv6, it really shouldn't get addresses at the contiainer level
[19:15] <marcoceppi> fwiw, I haven't encountered that yet
[19:16] <pragsmike> marcoceppi: yes, I'm using the openstack-base bundle (except I tweaked constraints on the machines section)
[19:17] <pragsmike> marcoceppi: and that bundle does specify that rabbitmq be in lxc
[19:17] <marcoceppi> pragsmike: right, I wonder if there's a fix out
[19:19] <pragsmike> is that what the problem is?
[19:19] <marcoceppi> nope, that's the lastest
[19:20] <marcoceppi> beisner: have you come across this ^
[19:20] <marcoceppi> coreycb: ^
[19:21] <pragsmike> I did change the bundle to use rabbitmq rev 56, where it was 54
[19:22] <pragsmike> but i did that because it was failing the same way before
[19:23] <marcoceppi> pragsmike: ah, excellent. I know rabbitmq-server freaks out when things like DNS don't work
[19:23] <marcoceppi> you're on maas 2.0 or 2.1?
[19:24] <pragsmike> maas 2.1
[19:24] <marcoceppi> pragsmike: also, can you pastebin the /var/log/juju/unit-rabbitmq-server*.log file
[19:29] <pragsmike> marcoceppi: http://pastebin.com/v2XYtbzM
[19:30] <pragsmike> that just seems to be the rabbitmq client failing to connect to the server, doesn't say why the server didn't start
[19:35] <pragsmike> also I'm not sure if it's ok that it thinks the host name is "eth3".  maas has decided that address has the name eth3.juju-8566c3-0-lxd-2
[19:37] <pragsmike> I have a bunch of networks set up per Dimiter's instructions, but I haven't tried to make anything use them yet.  juju just decided to use the 10.100 network for everything, which ought to be ok to start.
[19:38] <pragsmike> rabbitmq doesn't use ceph, does it?
[19:44] <kwmonroe> petevg: would you mind taking a look? https://github.com/juju-solutions/layer-apache-bigtop-base/pull/53
[19:44] <petevg> kwmonroe: looking ...
[19:49] <petevg> kwmonroe: left some comments.
[19:55] <pragsmike> marcoceppi: also http://pastebin.com/D0NPZ4xJ is dmesg from rabbitmq container, full of segfaults in beam.smp
[20:33] <pragsmike> is remove-application suuposed to work in 2.0? juju remove-application rabbitmq-server has no effect that I can see.
=== zz_CyberJacob is now known as CyberJacob
[21:15] <kwmonroe> sorry to make you grump petevg -- thx for the review ;)
[21:16] <petevg> kwmonroe: no problem :-)
[21:17] <petevg> kwmonroe: squashed n merged.
[21:17] <kwmonroe> you da man.
[21:30] <coreycb> thedac, pragsmike had an issue with rmq earlier.  i think you had a fix queued up, i wonder if it's related.
[21:31] <thedac> My rabbit fix is related to maas 2.0 DNS and multiple interfaces
[21:31]  * thedac reads backscroll
[21:33] <thedac> pragsmike: yes, I think my change will help you cs:~thedac/rabbitmq-server-3 https://review.openstack.org/#/c/389387/ for reference
[21:48] <pragsmike> ok thanks guys, I'll try that one
[21:48] <pragsmike> but once the bundle has deployed, juju seems to ignore any attempts i make to remove applications
[21:49] <pragsmike> thedac: what's the recommended way to replace a running rabbitmq app with yours?
[21:49] <thedac> pragsmike: you could do `juju upgrade-charm rabbitmq-server --switch cs:~thedac/rabbitmq-server-3`
[21:50] <thedac> Actually probably need a --force in there too
[21:50] <thedac> Then a juju resolved rabbitmq-server to get it going again.
[21:50] <pragsmike> k thanks
[21:54] <pragsmike> thedac: hmm, same problem, on the surface
[21:54] <pragsmike> let me investigate further
[21:55] <pragsmike> maybe redeploy the whole shebang with that new charm
[21:55] <thedac> pragsmike: hmm, I wonder if /etc/rabbitmq/rabbitmq-env.conf still has NODNAME=eht3? That is the problem
[21:55] <thedac> It might take a bit of manual intervention
[21:55] <pragsmike> i will look
[21:55] <thedac> A redeploy would fix it :)
[21:56] <pragsmike> it does have RABBITMQ_NODENAME=rabbit@eth3
[21:57] <thedac> So just some backstory. rabbitmq is very sensative to DNS. It also needs a shortname for NODENAME. and eth3 is not resolvable. So a quick hack is to add eth3 to the 127.0.0.1 line in /etc/hosts
[21:58] <thedac> my change completely avoids this problem by not setting NODNAME and forceing `hostname` rather than doing DNS reverse lookup of the iP
[21:58] <pragsmike> i just commented it out and did "resolved".  Aha!  Now it's saying "(config-changed) RabbitMQ failed to start" in status, which i never saw before
[21:59] <pragsmike> ah, now it's back to "config change failed"
[21:59] <pragsmike> I'm going to just redeploy and go to dinner
[21:59] <thedac> pragsmike: I suspect rabbit is a bit hosed at this point.
[21:59] <thedac> Yes that is the quicker solution
[21:59] <pragsmike> thanks for the quick help and explanation
[21:59] <thedac> no problem
[21:59] <pragsmike> Recovery-oriented Computing
[21:59] <pragsmike> it's a thing
[21:59] <thedac> I'll be getting that change merged next week.
[22:00] <thedac> Rabbitmq is the most fragile service in the OpenStack
[22:00] <pragsmike> wow that's saying something
[22:00] <thedac> :)
[22:00] <pragsmike> i'd have voted for heat