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