=== bdx_ is now known as bdx [00:43] I'm wondering how python3 can be used as the default python for trusty based *legacy* charms ... [00:43] it seems it would have to be installed prior to the running of hooks.py [00:45] so, if you can't use the 'install' hook to install python3 (because python3 needed for hooks.py to run) [00:45] then how is it done? [00:45] there must be a way [00:45] I'm thinking execd preinstall? [00:46] install hook wrapper where the install hook is a shell script that installs python3 [00:46] and then calls hooks.py's install hook [00:46] Right, install doesn't have to be a symlink. [00:46] bdx: ^ [00:46] All the others usually are, but install can be a script which checks the environment and then calls hooks.py [00:47] hloeung: thats great! thank you! [00:49] hloeung, wgrant: this is probably why I see 'install.real' files laying around then I'm thinking [00:50] ahh like this https://github.com/openstack/charm-glance/blob/master/hooks/install [00:51] bdx: yeah, just like that === mup_ is now known as mup [06:57] Good morning Juju world! === frankban|afk is now known as frankban [09:55] Hello! I'm writing tutorial in how to create a new "layer" in juju. Is the proper start for that by using charm-create or how would you recommend that a beginner starts developing layers? [09:56] The tutorial will build on the last one I wrote and are now updating also to accomodate for a series of tutorials. === fnordahl_ is now known as fnordahl === tinwood is now known as tinwood_lunch [12:03] erik_lonroth: yeah, `charm create` is correct [12:09] OK. Thanx. Its not clear from the documentation that a layer is the same thing in essence as a charm. [12:11] I also would need some help to understand when to place configuration options in the "layers.yaml" vs. config.yaml [12:12] config.yaml is for user editable configuration options mostly erik_lonroth3_ [12:12] like "i want to make this port configurable" [12:13] So, the layer.yaml is for ? [12:13] ... when do I place configuration in there? [12:13] dunno [12:13] it's mainly for configuring the layers below yours, if you need to [12:13] layer.yaml is for the stacking of other layers your charm depends on [12:13] mostly [12:14] According to the documentation in the base-layer, it seems like those configuration options in the layer.yaml is intended for being over-ridden by layers above. [12:15] So, if I create a charm on top of base-layer, I can use those options from within my own charm. Is that right? [12:16] you can set those options at build time, in your layer.yaml [12:17] they're not meant to be use at run time like config options from config.yaml [12:17] Ah. [12:18] So, its build-time configuration. [12:18] yep [12:19] erik_lonroth3_: concrete example from the 'apt' layer: https://git.launchpad.net/layer-apt/tree/README.md#n158 [12:19] (line 158) [12:20] in the example yaml on line 169, options are being set for layer basic and layer apt [12:22] tvansteenburgh: Thats a great example! === tinwood_lunch is now known as tinwood === freyes__ is now known as freyes === Guest24728 is now known as zeus [13:37] Is it nessecary at all to write 'hooks' (start,stop,install,etc.) if you do charms the 'reactive' way instead ? [13:38] erik_lonroth3_: no, I think `charm build` creates them for you. [13:49] jrwren: I dont follow exactly. What I don't get, is if I need to create files in the "hooks/" dirctory aswell as create the code in the "reactive/" directory. [13:50] erik_lonroth3_: you don't need to create anything in hooks/ [13:50] `charm build` will do that for you [13:50] Thats weird since the build-process complain if I don't create them... [13:51] erik_lonroth3_: pastebin a directory listing of your charm, and the error you're seeing [13:52] erik_lonroth3_: did you create an empty hooks/ dir? [13:53] erik_lonroth3_: if so, delete it and rebuild [13:55] Hmm, I think your kind of right. https://pastebin.com/uaSvn9c1 [13:55] However, if I follow the 'recommendations' in the "Information" - I end up in a bad situation. [13:56] erik_lonroth3_: are you running `charm proof` before `charm build`? [13:56] yeah [13:56] ok yeah, that won't work [13:57] right now you have a layer. you have to `charm build` to turn it into a valid charm [13:57] erik_lonroth3_: would you be willing to submit a PR to fix the docs that tripped you up? [13:57] because that would be great [14:11] I can do that. [14:12] Do I also have to do "charm-build" for layers? [14:12] ... as well as for charms and interfaces ? [14:14] erik_lonroth3_: you only do `charm build` if you are making a charm [14:15] layers are the building blocks of charms [14:15] `charm build` combines them together to make a functional charm [14:16] not if I'm making a layer? This is confusing [14:18] I understand what you are saying, but I fund the documentation quite difficult to follow and digest... Thanx for answering my questions... [14:19] ... So, if I understand you right. Layers are not charms? [14:19] erik_lonroth3_: for example, the apt layer is a layer, but it is not built into a charm - it's meant to be used by other charms [14:19] erik_lonroth3_: layers are not charms [14:20] I got that. But how about when I build and intend to distribute my "charm" that builds on a "layer". Wouldn't I have to distribute that "layer" also ? [14:20] layers are like the source code. when you build them (with `charm build`), you get a charm [14:21] Ah, good description. [14:21] you don't have to distribute the layer. the built charm is what juju deploys. [14:21] I'm going to "rip" that explanation in my tutorials [14:22] but, most people do make their layers available on github or something [14:22] and if your layer is meant to be reused, you can register it here http://interfaces.juju.solutions/ [14:22] Yeah, I guess its kind of key to have those layers accessible if you intend to build on them. [14:25] But at what point do I then create a "charm" as opposed to "layer" if there is nothing that in the process of creating them is different? [14:27] erik_lonroth3_: the charm is the "compiled" output of one or more layers [14:27] you can `charm build` as often as you want [14:27] So I decide for my self if a layer should become a charm or not ? [14:28] for every change you make to your layer source, you could charm build and push the built charm to the charm store [14:28] yes [14:28] OK, that also explains more to me. [14:29] are you building something that you're unsure should be a charm or not? [14:32] No not really. I'm creating tutorials to help my collegues to get started with this also. I've written a "hello-world" tutorial that produces a very simple charm. I started today working on doing a "layer" tutorial. That has come to a point where I realize that the reactive framework is a "must" and that I need to re-write the tutorial now =D [14:33] https://github.com/erik78se/hello-world/wiki [15:37] good morning [15:37] is anyone monitoring their juju openstack with elk [15:37] ? [15:49] bildz: not yet, thinking about it - why do you ask? [15:53] erik_lonroth3_: (y) === frankban is now known as frankban|afk [17:14] hey marcoceppi - bdx needs a charm-kibana in https://github.com/charms. will you make that happen (with elastic-ops as an admin)? [17:14] kwmonroe: thx [17:15] marcoceppi: thx [17:15] bdx: just to make sure, you want to commit an old-style charm there, right? the convention is layer-foo for layered source and charm-foo for the older style (like the elasticsearch charm) [17:15] ooh [17:15] I did not know [17:15] that makes sense [17:16] yeah so bdx, do you want charm-kibana or layer-kibana? [17:16] both [17:16] ha! for why? [17:17] https://github.com/jamesbeedy/juju-charm-kibana [17:18] ok - that's a good looking candidate for layer-kibana. what would you be committing to charm-kibana (remember we don't need to commit the built charm artifact anymore) [17:18] yeah ... I need to fix all my repo names now [17:18] lol [17:19] yeah, so in that case only a layer-kibana I guess [17:19] meh - whatever works for you is cool. just noting the convention for ./charms and ./juju-solutions github orgs. [17:19] totally [17:19] ok - so marcoceppi, s/charm-kibana/layer-kibana in the charms org please. [19:29] I'm trying to remove a charm stuck in en error state... I'm trying 'juju remove-application hello-world-reactive' but it wont go away. I'm probably doing something wrong... Can you tell me how you guys debug and remove charms stuck in error state? [19:31] erik_lonroth: have you tried removing the unit? [19:31] erik_lonroth: sometimes it’s hard to catch the hooks in a good state to do something with the removal request [19:32] not yet... would "the unit" also destroy my host vm ? I don't want to destroy the vm [19:33] i’m not sure what your host vm refers to [19:34] the controller? the juju machine the unit is installed on? [19:34] Yeah, the "machine" = "host vm" [19:35] I tried "juju remove-unit" now also... no luck [19:35] yes, remove-unit also destroys the juju machine that the unit is installed on. a juju machine can be a lot of different things [19:35] erik_lonroth: use `juju debug-log` to debug [19:35] Ah, ok [19:35] you want to find out what's broken before destroying it [19:36] then you can fix your charm, rebuild it locally, and then use the `juju upgrade-charm` command to upload your new (fixed) charm over the top of the broken one [19:38] see `juju debug-log -h` for helpful options, especially --replay and -i [19:39] thanx!!! [19:39] there is also a juju debug-hooks command if the error is in a hook [19:39] also, with `juju upgrade-charm` you'll want to use the --path arg to upgrade to the freshly built charm on your local filesytem [19:48] I did: "erik@snowflake:~/git/juju/charms$ juju upgrade-charm hello-world-reactive --path ~/charms/trusty/hello-world-reactive" but its still there. [19:50] the debug-log contains some hint perhaps: "juju.worker.uniter awaiting error resolution for "install" hook" [19:55] Now it seems its just adding to the model... Added charm "local:xenial/hello-world-reactive-4" to the model. [19:59] "juju resolved --no-retry hello-world-reactive/0" seemed to remove it. [20:38] bdx: kwmonroe done [20:41] thx marcoceppi [20:48] admcleod: setting it up now