[01:09] vds: Last time I talked to my legal, I was told I can't bypass the clickthroughs in any way (including things like the Juju licence acceptance feature). However, if you look at the Oracle JRE distribution licence IIRC you can bundle it with software where it is required to make it work or make features work. [01:10] vds: My interpretation being you would be able to embed the tarball in your charm or snap, but not in a charm layer. But I didn't put that interpretation to our legal. [01:13] vds: If you want to use the Oracle JDK, the Cassandra charm requires the user to download (accepting the licence) and make the tarball available at a configurable URL. This was before Juju resources existed. It is a terrible user experience. [03:01] Ubuntu 16.04 Installed LXD and conjure-up snap packages. [03:01] ran conjure-up kubernetes [03:01] made it all the way to the end and received following error: [03:01] "could not fetch IP addresses and link layer devices: cannot get all ip addreses [03:01] Anyone know how to resolve this? [07:37] https://www.irccloud.com/pastebin/3nNyg5ZI [07:37] Need help [07:45] Charm deployment fails as not able it add repository "cloud-archive:pike" [07:45] Please see the pastebin for exact error [08:14] Hi, I just started to play around with Juju and I'm impressed of the simplicity and how easy it is to bootstrap an entire Kubernetes cluster in the cloud. I do however have a question around the entire concept. If you need to customize the entire kubernetes setup for example. Is this possible or should it only be used "as is". Will settings be ove [08:14] rwritten during upgrades. I know it's a hard question to answer but should charms be "fire and forget" or used as a base for further modifications? === frankban|afk is now known as frankban === wpk_ is now known as wpk [12:29] Hello Everyone! I'm writing a charm which encapsultes a jar with some spark program. Does anyone knows how can I run action from hadoop-spark charm submit-spark during the deployment of my charm [12:29] I need your help charm masters! [12:37] hi elmaciej, not sure about the masters but I can try to help [12:37] how do you write your charm? python+reactive? [12:38] yes, that was my intention, I'm doing it based on vanilla charm [12:38] and to be honest it's first charm I have to write [12:39] ok, no worries [12:40] I would suggest you start by building the bigtop spark charm so you get familiar with the toolchain [12:40] let me grab some links [12:40] elmaciej: here is the bigtop project that has a number of charm layers. https://github.com/apache/bigtop [12:41] the spark layers is here: https://github.com/apache/bigtop/tree/master/bigtop-packages/src/charm/spark/layer-spark [12:42] so you should try building that one first. (git clone bigtop; charm build ) [12:42] great, will do it now. Thank you very much. [12:43] now you said you want to run a submit-spark during the deployment. I think you should first have to wait the deployment to finish and then submit a job. [12:45] elmaciej: there is this action you ca take a look at to see how you can do a spark submit: https://github.com/apache/bigtop/blob/master/bigtop-packages/src/charm/spark/layer-spark/actions/spark-submit [12:47] your jar can be inside your version of the charm or have it served from a remote location or make use of juju resources https://jujucharms.com/docs/2.1/developer-resources [12:54] kjackal : Thanks a lot! [12:54] gl hf [16:50] kwmonroe: mind if I continue to hassle you about Greylog stuff? [16:50] hassle away bdx! [16:50] I'll just start rattling off in that case [16:50] :) [16:50] 1) SSL [16:51] graylog has instructions for generating a key/cert and setting up ssl at the application/graylog level [16:51] http://docs.graylog.org/en/2.3/pages/configuration/https.html [16:51] its a bit cumbersome, and not really what I would want to go with anyway [16:52] I would rather just deploy an ssl terminating proxy infront of graylog [16:52] with the legit trusted key/cert from my CA [16:55] I'm thinking I should just be able to go ahead and setup the ssl terminating proxy in front of graylog, and forward to the web/api ports - bypassing the graylog ssl setup because terminating 1 hop in front of it [16:55] bdx: agreed that an ssl proxy feels easiest. GL needs the apache vhost proxy anyway, so just make the apache unit ssl-aware. [16:55] right [16:56] the other thing I was thinking about [16:56] I've used this https://gist.github.com/jamesbeedy/d587cbf048038fb274ef4cd55c4ee3dd [16:56] for quite some time [16:57] in front of apps that I want to terminate ssl infront of [16:57] I was thinking [16:58] it might be easier to just make the reverseproxy relation for haproxy do the right things to setup the extra frontend/backend for both 9000 on / and 9001 on /api [16:59] then we could kill the apache2 middle man [16:59] I gave the haproxy bits a try === frankban is now known as frankban|afk [17:02] kwmonroe: https://gist.github.com/jamesbeedy/b784bfd8779fca668b536332a10be5c1 [17:02] my thinking behind ^ [17:02] was such that it would just be easier to create the dict in python and just dump it to yaml [17:03] rather then trying to concat a bunch of templated strings inline [17:03] lol [17:03] but what I realized [17:03] bdx: not to dissuade you from haproxy, but did you look at https://jujucharms.com/u/tengu-team/ssl-termination-proxy/? [17:03] it's built with layer-nginx, so might handle the revproxy stuff ootb [17:03] (plus letsencrypt support) [17:04] oh sick [17:05] sweet [17:05] ok, so lets use that as an example instead of haproxy [17:06] well [17:06] kwmonroe: the reason I went with haproxy, is because we have two ports that need forwarding based on the route right? [17:06] i haven't actually used it myself, but i am encouraged that it calls the ngingx.congure_site bits, which i think will auto handle 9000 and 9001/api bits: https://github.com/tengu-team/layer-ssl-termination-proxy/blob/master/reactive/ssl_termination_proxy.py#L121 [17:06] kwmonroe: so this https://gist.github.com/jamesbeedy/b784bfd8779fca668b536332a10be5c1#file-haproxy_reverseproxy_test-py-L13 [17:06] was my little bit of secret sauce [17:07] to accommodate the url route based routing [17:07] default / -> :9000, if /api, -> :9001 [17:09] yeah bdx, i *think* graylog is doing the right thing with the http interface: https://git.launchpad.net/graylog-charm/tree/reactive/graylog.py#n322 [17:09] that is setting a "services" string for both 9000 / and 9001 /api [17:10] and i *think* the revproxy config_site bits of the nginx layer will do the right thing with those to make them vhost templates for nginx [17:10] https://jujucharms.com/haproxy/ [17:10] it so contrived what type the relation data is lol [17:10] look at the last example for multiple backends [17:10] which is what I was trying to follow [17:11] but yeah [17:11] oof, yeah, that example is hard to follow [17:11] the graylog charm is setting the correct type of data .... yaml strings [17:11] yeah [17:12] so you see how my example gist would work if we were just setting a yaml string, or even python types (just pass the dict to the relation) [17:13] it expresses the correct key:val in the data structure [17:13] it just has to get transformed into this crazy thing before it will make any sense to the haproxy / reverseproxy relation [17:13] lo [17:13] 9l [17:14] lo9l fo real [17:15] I feel like building into this "crazy thing" any more then already has been done is just perpetuating the issue here [17:16] issue being the contrived data that the reverseproxy relation is accepting [17:16] it will never be something people will look at and be like "oh ok, I get it" [17:17] even after many hours now [17:17] :) [17:17] but I do get it, it just totally seems like the worst thing in the world [17:18] anyway [17:18] I don't even know where I was going with this [17:19] oh yeah, so I feel we are presented with a few not so great options here [17:21] given this isn't the most common use case, but its a pretty simple reverseproxy configuration that we should be able to support via charms w/o taking a round trip on the event horizon [17:21] heh [17:22] possibly just "making it work" with the reverseproxy is the cheapest way to short term victory with Graylog [17:23] and looking at possibly doing something about the reverseproxy relation in the future [17:23] idk [17:23] possibly other people like it [17:23] I'm really forcing my view here [17:23] ha [17:23] sorry [17:24] but I feel my reasoning is justified [17:24] i think one problem is the complex example in the haproxy charm. i don't know what those options actually do, but the http interface example for rev proxy seems much simpler: https://github.com/juju-solutions/interface-http#requires [17:25] got it [17:25] ok [17:26] what they do [17:26] is allow you to configure more complex proxying [17:26] https://gist.github.com/jamesbeedy/b784bfd8779fca668b536332a10be5c1#file-haproxy_reverseproxy_test-py-L13 [17:26] ^ takes care of proxying both of the routes [17:27] / -> 9000 and /api -> 9001 [17:27] by using the extra relation data context to configure extended routing/backend [17:29] its only complex because the data type/content isn't understandable [17:29] if was written out like this [17:29] http://paste.ubuntu.com/26090348/ [17:29] and it said, "set the yaml string as relation data" [17:30] lol [17:30] but that (set the yaml string as relation data) isn't even whats going on [17:30] its not even a yaml string [17:30] I still don't know what it is [21:07] hey [21:07] exist a way to put a custom config [21:07] on juju config file [21:07] example i want to add something on the configuration of a charm [21:07] cinder that is not supported on the yaml [21:08] jose-phillips: https://jujucharms.com/cinder/#charm-config-config-flags [21:08] and if i want to add it on a different stanza [21:10] jose-phillips: make a bug report for the cinder charm about that [21:11] jose-phillips: https://bugs.launchpad.net/charm-cinder [21:13] is exactly for this setting [21:13] # A list of backend names to use. These backend names should be backed by a [21:13] # unique [CONFIG] group with its options (list value) [21:13] enable_backends [21:19] also support enable_backends [21:23] jose-phillips: put that in a bug please [21:24] and post the bug back here after you have filed it [21:47] ok bdx thanks [21:47] another question did you know where juju store the containers configuration for openstack [21:47] i need to create glance and cinder interface with 2 interfaces [21:48] jose-phillips: if you are deploying openstack to the lxd provider, you do that through lxd profile modification [21:48] no is kvm [21:48] novakvm [21:48] jose-phillips: so you have maas setup? [21:48] yep [21:48] and you checked a bunch of kvm nodes into your maas? [21:49] yep the deployment is completed on 3 nodes [21:49] for example i dont need ceph [21:49] because im using a netapp storage [21:49] so i take 1 node for controller and 2 for compute [21:50] on the controller node have 2 interfaces , data and storage [21:50] when juju create the containters inside of controller node [21:50] openstack controller node [21:50] jose-phillips: you need to create a feature request tp support netapp storge [21:51] ok [21:51] another question if i modify manually cinder.conf [21:51] when will be overwritted? [21:51] during upgrades only [21:51] or restarting the container may overwrite the configuration [22:50] jose-phillips: modifying the config by hand is not supported in any way [22:51] jose-phillips: the openstack charms will keep persistence of the config files [22:51] modifying it by hand will only cause you grief