[00:35] <Teranet> do we have anyone online who knows about : nova-cloud-controller     I do have an error which I do need help with
[06:43] <Andrew_jedi> hello, how can i install juju 1 ?
[06:43] <Andrew_jedi> juju/stable now points to juju 2
[11:35] <angelinux> hello everybody
[11:35] <angelinux> I have a question: is it possible to bootstrap juju in a vm that is contained in a private openstack cloud
[11:36] <angelinux> and let it manage that private openstack cloud?
[12:34] <themagicaltrout> pfft
[12:36] <marcoceppi> angelinux: it should be. Do you have credentials for that openstack cloud?
[12:58] <angelinux> @marcoceppi Yes I have
[12:59] <angelinux> but I get an error when I try to boostrap
[13:30] <marcoceppi> angelinux: what is the error?
[13:36] <angelinux> @marcoceppi: http://askubuntu.com/questions/859862/juju-bootstrap-on-a-private-openstack-cloud-fails here you can find details
[13:37] <angelinux> @marcoceppi: the error is "json: cannot unmarshal string into Go value of type nova.jsonEntity"
[13:37] <angelinux> @marcoceppi could you please help me?
[13:42] <marcoceppi> angelinux: what's your region name in OpenStack? Is it indeed RegionOne?
[13:44] <angelinux> @marcoceppi: yes my igestack cloud has RegionOne
[13:44] <angelinux> as region
[19:17] <bdx> lazyPower: ping
[19:18] <bdx> interesting issue here
[19:19] <bdx> if I `lxc launch:16.04 es-test`, and add the elastic.co gpg key and source repo, update apt, and `sudo apt install elasticsearch`, I get a successfull installation
[19:20] <bdx> `lxc launch ubuntu:16.04 es-test`*
[19:20] <bdx> whats interesting, is when I mimic these ops with juju -> https://github.com/jamesbeedy/juju-layer-elasticsearch-base
[19:21] <bdx> I hit this error http://paste.ubuntu.com/23665305/
[19:22] <bdx> or, even more, if I `juju deploy ubuntu`, and run the same ops to install elasticsearch that I run in the lxd container, I get a failure
[19:22] <bdx> with http://paste.ubuntu.com/23665305/
[19:23] <jrwren> bdx: how different is your default lxd profile from your juju lxd profile?
[19:24] <bdx> jrwren: http://paste.ubuntu.com/23665326/
[19:24] <jrwren> bdx: now that IS interesting ;)
[19:25] <bdx> jrwren: yeah, I'm on the line with others who are experiencing the same thing right now
[19:25] <bdx> I'm thinking I should write the list
[19:26] <bdx> jrwren: right
[19:27] <bdx> jrwren: I'm honestly over trying to troubleshoot this ... over my head at this point
[19:27] <jrwren> bdx: i thought mabye you had set security.privileged=true in your default profile or something.
[19:28] <bdx> jrwren: yea, that was my initial thought too
[19:28] <bdx> jrwren: even if I remove the extra profile, such that my juju container is only left with the default profile applied
[19:29] <bdx> I still get the error
[19:29] <bdx> so strange
[19:29] <jrwren> right, it doesn't seem to be a profile thing.
[19:32] <jrwren> bdx: can you pastebin output of `lxc config show <container>` for the two containers?
[19:34] <bdx> jrwren: here's the juju deployed container -> http://paste.ubuntu.com/23665355/
[19:35] <bdx> jrwren: here's the straight lxd -> http://paste.ubuntu.com/23665359/
[19:35] <bdx> jrwren: good call
[19:36] <bdx> jrwren: how does the juju container end up with all that extra jazz in there?
[19:36] <bdx> crazy
[19:36] <jrwren> bdx: the lxd provider in juju does it.
[19:36] <bdx> ahhh
[19:36] <bdx> wow, talk about opinionated
[19:37] <jrwren> juju is very opinionated. :)
[19:38] <bdx> jrwren: what do you feel is the best approach to resolving the issue I'm experiencing?
[19:38] <jrwren> bdx: email the list.
[19:38] <bdx> the issue being that elasticsearch won't install to juju deployed lxd containers
[19:38] <bdx> right
[19:38] <bdx> will do
[19:38] <bdx> jrwren: thx
[19:40] <jrwren> bdx: i'm going to try to repro. is it possible its 2 diff elastic search packages?
[19:44] <bdx> no
[19:44] <jrwren> bdx: if it helps at all, I get the couldn't write errors on package installation on my lxc.
[19:45] <bdx> jrwren: juju deploy lxc?
[19:45] <jrwren> so, I don't think this is a juju issue.
[19:45] <bdx> oh really
[19:45] <jrwren> no, no juju at all.
[19:45] <bdx> I don't get them on straight lxd
[19:45] <jrwren> bdx: I'll paste a repro, see if it works for you.
[19:45] <bdx> ok
[19:45] <jrwren> or rather, see if you do get the error :)
[19:47] <jrwren> bdx: https://gist.github.com/jrwren/8b648cc2736e68e82d96334d32b131b9   one file and 2 commands to run.
[19:47] <bdx> jrwren: I just got the error on straight lx43
[19:47] <bdx> lxd*
[19:47] <jrwren> oops, and I pasted the wrong command.
[19:47] <jrwren> bdx: oh, well, ok, that is great!
[19:49] <jrwren> bdx: maybe file a bug with elastic.co?
[19:54] <bdx> jrwren: I just ran these commands on an fresh xenial aws instance -> http://paste.ubuntu.com/23665448/
[19:54] <bdx> success
[19:55] <bdx> jrwren: ^ makes me think its more or less a lxd thing...
[19:55] <jrwren> bdx: nice... but still, not working on LXD is bad.
[19:55] <jrwren> bdx: I can't imagine it would work in docker, for the same reasons.
[20:06] <jrwren> bdx: https://github.com/elastic/elasticsearch/commit/32df032c5944326e351a7910a877d1992563f791  looks like ES fixed it by enabling a parameter, a ES_SKIP_SET_KERNEL_PARAMETERS in the environment.
[20:08] <bdx> jrwren: nice find!
[20:08] <jrwren> bdx: well, it NEEDS to work in lxd, or else its not a great juju charm :)
[20:08] <bdx> right
[20:09] <bdx> jrwren: so, is this a use case for a tactic you think?
[20:09] <bdx> jrwren: to set ES_SKIP_SET_KERNEL_PARAMETERS prior to the apt install phase
[20:10] <bdx> or should I just add the few lines to the reactive file and set the param and then run the install cmds from the layer-apt api
[20:12] <jrwren> bdx: I don't know anything about tactics or layers, sorry.
[20:13] <bdx> jrwren: now my question is this, we don't want to always skip the kernel params on install, right? so should I detect whether or not the install is happening on a container, and only apply the ES_SKIP_SET_KERNEL_PARAMETERSES_SKIP_SET_KERNEL_PARAMETERS to container installs?
[20:13] <bdx> errg .. sorry, that pasted 2ce for some reason
[20:14] <jrwren> bdx: yes, that is probably best.
[20:14] <bdx> sebastienp:^
[20:14] <bdx> jrwren: thanks for your insight here
[20:21] <jrwren> bdx: oh my... have you used that es package?
[20:22] <bdx> jrwren: not yet ... I'm trying to though
[20:22] <bdx> jrwren: why, whats up with it?
[20:22] <jrwren> bdx: well, don't forget to specify openjdk-8-jre-headless package manually. they don't use dependencies.
[20:22] <jrwren> bdx: and then, don't be shocked like I was as it allocated 2+GB of ram immediately on starting. NOT virtual. 2.241g of RSS
[20:23] <jrwren> i guess that is java magic.
[20:23] <bdx> jrwren: openjdk-8-jre-headless installs as a dep of es when you install it from their repo
[20:23] <jrwren> bdx: that was not my experience.
[20:23] <jrwren> Depends: libc6, adduser, bash
[20:24] <jrwren> and on first run, the service fails asking to install a java.
[20:32] <bdx> jrwren: yeah ... I'm getting the same thing .... don't know how or why I had success previously (possilby I forgot to add my sources and installed 2.x or something)
[20:33] <jrwren> bdx: i see the package in ubuntu archives does have Depends: with a jre. *shrug* no biggie.
[20:34] <jrwren> bdx: I was just shocked at the 2.2G memory alloc on start.
[20:38] <bdx> jrwren: yeah, thats nuts
[20:39] <jrwren> bdx: i wonder what it does on a tiny instance :)
[20:39] <bdx> jrwren: whats even worse -> https://docs.mongodb.com/manual/core/wiredtiger/#memory-use
[20:39] <jrwren> lol, it had to be mongo
[20:40] <bdx> jrwren: I was wondering why my juju controllers were consuming so much ram ... even when barely anything was deployed ... it was driving me crazy, then I found that
[20:40] <bdx> lol
[20:40] <jrwren> bdx: :(
[20:40] <bdx> jrwren: ^ 50%-1G really borks lxd local deploys
[20:40] <jrwren> bdx: agreed. I don't leave lxd controllers up for that reason.
[20:41] <bdx> if you have a massive lxd-visor, the juju controller will automatically steal all your goods
[20:41] <jrwren> bdx: it has gotten MUCH better in jujud itself since some of the 2.0 betas
[20:41] <bdx> jrwren: yeah, but the underlying mongo tiger eats up 50%-1G though .... cry cry cry
[20:42] <bdx> thats w/o juju memory consumption taken into account of course
[20:43] <bdx> something needs to happen about the 50% mem on lxd controllers ... possibly we can apply some mem limit to the juju-controller profile or something
[20:43] <jrwren> bdx: painful :(
[20:48] <jrwren> bdx: may be as simple as mongoCmd = mongoCmd + "--wiredTigerCacheSizeGB"  here: https://github.com/juju/juju/blob/master/mongo/service.go#L185
[20:49] <jrwren> bdx: its wednesday before the holidays and if you are feeling brave, propose that :)
[21:40] <petevg> cory_fu, bcsaller: PR for the dump of the logs here: https://github.com/juju-solutions/matrix/pull/56 (It's non ideal for a lot of reasons, but I believe suitable for our basic needs. I'm going to work through some of the TODOs, and prioritize partially based on feedback.)
[21:41] <bdx> whats the best way to check if you are in a container or not?
[21:41] <bdx> I found this -> https://code.launchpad.net/~zulcss/charm-helpers/is_container
[21:41] <bdx> but it isn't in charmhelpers 0.10.0 ...
[21:42] <bdx> even more, systemd-virt-check
[21:42] <bdx> doesn't seem to even be a thing ...
[21:43] <bdx> ahhh, possibly I should be checking the output of 'systemd-detect-virt'