[00:33] Hi any JuJU experts: How do I restart a JuJu service VM after reboot? [01:50] bryan_att hey there o/ still around? [01:51] lazyPower: yes - but I think I figured it out... power-on via MAAS restored it. [01:51] perfect, just making sure you werent' left hangin [01:51] best of luck :) [01:51] lazyPower: thanks [01:56] ohai, anyone hit timeout problems when using ubuntu-repository-cache? It never downloads the data, gets stuck in a timeout loop [01:56] jose: yes; check bugs.launchpad.net for details [01:58] blahdeblah: do you by chance have a bug#? on mobilr and can't seem to find jt [01:59] jose: not handy - but it shouldn't be hard to find; the list of bugs on u-r-c isn't that long [01:59] * blahdeblah checks [02:00] jose: I think https://bugs.launchpad.net/charms/+source/ubuntu-repository-cache/+bug/1564215 is the one I've seen [02:00] the thing is it doesn't even download the data. any known workarounds so it can download stuff? [02:00] * jose needs to set a local mirror for a conf [02:01] there's an rsync which runs from a cron job on the lowest-numbered u-r-c unit; make sure your juju units are all idle, then try the rsync manually and see what it says [02:02] usually it's a hung rsync from a previous try, or some other failed juju unit getting in the way [02:02] https://bugs.launchpad.net/charms/+source/ubuntu-repository-cache/+bug/1576920 has been logged asking for the design to be changed, but I haven't seen any action on that [02:02] Bug #1576920: ubuntu-repository-cache-sync should be called outside of juju hooks [02:05] I think i'll just try ubumirror [02:07] you sure it's not egress filtering or something else? [02:07] 'rsync -avz --dry-run rsync://us.archive.ubuntu.com/ubuntu' should give you a listing [02:08] jose: ^ [02:08] run that from one of the u-r-c units [02:08] if it fails, then check your secgroups or the equivalent for whatever provider you're using [02:09] I'm using manual on a local machine, but I'll double check [02:09] ooooh ports. firewalled connection [02:10] thanks for the idea, it never popped up! [02:10] heh yeah :) === frankban|afk is now known as frankban [08:50] Hi all, is there any way to resolve or recover service from blocked status ? [08:50] you can mark units resolved godleon [08:50] so they will continue starting up [08:51] of course if something broke, it will remain broke :) [08:51] juju resolved ? [08:51] yup [08:51] you normally have to run it a few times to get past the failed hooks [08:51] ok, but I got message "ERROR unit "neutron-gateway/1" is not in an error state" [08:52] sorry my bad [08:52] blocked could be waiting for a relation from something else [08:52] like if my charms need a java relation, i set them blocked until the relation is made [08:52] or awaitng an action or something [08:53] depends why its set the blocked state [08:53] magicaltrout, ok, I try to deploy openstack base bundle in xenial, but I got unit errors in neutron-gateway. After resolving it, it turned into blocked forever...... [08:53] and never recovered again. [08:54] https://api.jujucharms.com/charmstore/v5/xenial/neutron-gateway-2/archive/hooks/neutron_hooks.py [08:54] you can see where it blocks up here [08:54] if valid_plugin() returns false [08:55] it should also give you an error message? [08:55] https://api.jujucharms.com/charmstore/v5/xenial/neutron-gateway-2/archive/hooks/neutron_utils.py [08:55] yap => Services not running that should be: neutron-openvswitch-agent [08:56] i guess skipping the unit errors just skipped whatever is now blocked :) [08:56] godleon: you'd be better off looking at the juju log for the unit and figuring out why you had to juju resolved [08:57] that will probably get you running easier than hacking around in the charm [08:57] (i've never deployed openstack, but that seems like a reasonable guess) [08:57] hmm.....ok, will do. [08:58] thanks for your advices. :) [08:58] you can juju debug-log although personally i just ssh to the unit and grep through the logs looking for whatever broke it [09:04] how does this pattern work with charm relation-foo scripts? https://api.jujucharms.com/charmstore/v5/hadoop/archive/hooks/namenode-relation-joined [09:04] when i try referencing a common script in a charm, i just get script not found, e.g. it looks like a path issue [09:04] (this is with juju 1.25.6) [09:10] * magicaltrout wonders who could offer some sage advice there [09:10] babbageclunk or stub if they are around could probably help jamon [09:10] i can just write the relation scripts, but i thought that hadoop pattern looked rather clever [09:11] saves on repetition since my config-changed handles things nicely [09:12] that link doesn't work for me [09:14] Hello Juju World! [09:16] stub: does it just says 'hadoop-common'? [09:16] s/says/say [09:16] yes [09:16] ah that's expected, it is calling this script: [09:17] https://api.jujucharms.com/charmstore/v5/hadoop/archive/hooks/hadoop-common [09:18] all the relation joined or changed hooks refer to that common one [09:18] And its bash, so I'm not going to be any help ;) [09:20] but the pattern should work fine once you create the foo-relation-changed symlink (and foo-relation-joined, departed and whatever else you need) [09:21] I much prefer the reactive approach though - no need for this sort of thing any more. [09:22] i can't even write non reactive charms any more [09:22] my brain can't process the hookage [09:24] is there a good charm to show this reactive pattern? [09:24] i'm exactly new to this :) [09:25] okay if you're new chuck that stuff away :) [09:26] run [09:26] charm-create mycharmname [09:26] and it will create you a charm skeleton [09:26] in that skeleton you'll find a reactive directory [09:26] i think i did that, but i may have been looking at the 1.25 docs [09:26] you'll also find layer.yaml [09:27] which allows you to inherit layers and interfaces from that website you were perusing [09:27] the when you run charm build [09:27] it will compile all of is into a funcioning charms [09:27] -s [09:27] (make sure you have some environment variables set so stuff goes in the correct place) [09:28] JUJU_REPOSITORY INTERFACE_PATH LAYER_PATH [09:28] so for example I build my charm in ~/Projects/mycharm, JUJU_REPOSITORY is set to ~/Projects/charms [09:29] then charm build will compile my charm and put the whole thing into ~/Projects/charms/.... [09:29] at which point you can juju deploy etc [09:30] jamon: are you seem to be fiddling with hadoop stuff, I have a pretty simple drill charm that is reactive [09:30] https://github.com/buggtb/layer-drillbit [09:30] https://gitlab.com/jamonation/layer-hubot/tree/master [09:30] here's where i'm at [09:30] i was just using hadoop as a reference [09:30] ah right [09:31] so i must have run charm-create [09:31] all hazy now :) [09:31] well reactive/hybot.py is where you want to be [09:31] so i'll work on porting my bash stuff there? [09:31] using your reference? [09:31] you can write bash reactive scripts [09:31] but i've never done it [09:32] i'd rather ansible if i'm honest [09:32] kjackal likes this stuff, kjackal got any bash reactive samples? [09:32] magicaltrout: Hello, lgive me a sec to read the conversation [09:33] jamon: there is some ansible stuff kicking around [09:33] https://micknelson.wordpress.com/2013/11/08/juju-ansible-simpler-charms/ [09:33] https://docs.google.com/presentation/d/1e0jKfeQmCRLasFGePGFZb_6dg2IDgaY_gW6O2iICHJM/edit#slide=id.p [09:33] I don't know what the state is [09:33] i've seen references to something possibly being integrated into juju core? [09:33] but I've seen some demo stuff [09:34] so you write a juju charm that calls your ansible stuff [09:34] the new hadoop stuff does similar using puppet [09:34] kjackal knows about that stuff i'm just an observer [09:35] but you could use python to install and run the ansible stuff on a node [09:35] aweomse, thanks for the pointers, there should be lots to get me going here [09:35] awesome [09:35] Hey jamon! [09:35] in which case you could just dump it into that hubot.py install hook thats already in the template you see [09:35] * magicaltrout passes the baton over [09:36] NASA project go live day and i'm discussing ansible [09:36] should probably get my priorities sorted out ;) [09:36] magicaltrout: :) [09:36] juju deploy spaceshuttle :D [09:36] if only [09:36] more like docker-compose up huge-genomics-project.yaml [09:37] so jamon, did you go through the documentation we have for the reactive things? [09:38] It is a good place to start [09:38] let me find some good starting point [09:39] i wasn't sure about using 2.0 docs [09:40] jamon: what version of juju do you have deployed? 2.0 or 1.25? [09:40] 1.25.6 [09:40] Cool, 1.25 is the stable one [09:40] 2.0 is almost stable [09:41] so we are on 1.25, great [09:41] here is the starting point https://jujucharms.com/docs/1.25/authors-intro [09:41] right that's where i did the walkthrough [09:42] https://jujucharms.com/docs/1.25/authors-charm-writing [09:42] that got me my running hubot [09:42] jamon: awesome! [09:42] and what are your next steps? [09:42] where i'm at now might be useful information [09:43] hubot likes to talk to redis to persist information [09:43] so i'm trying to get that linked up via relations [09:43] e.g. i expect it is as easy as relation-get private-address in a relation changed/joined hook [09:44] jamon: yes it should be as easy as that [09:44] but if i should be trying with reactive, i'm happy to port it over [09:44] so first you need the interface layer [09:44] that will give me experience with both types of charms [09:45] where is your charm right now? Is is availuable for me to see how it looks like? [09:45] kjackal: not sure you saw this, but here's my charm now [09:45] https://gitlab.com/jamonation/layer-hubot/tree/master [09:45] hah nice timing [09:46] Cool! [09:46] So I see you created the charm by providing the install etc scripts under hooks and now you want to do the same thing with layers [09:47] layers + reactive [09:47] nice [09:49] This example shows how to use layers: https://jujucharms.com/docs/1.25/authors-charm-building [09:50] So, here is how we are going to do this [09:50] ah ok [09:50] Strongly suggest you create a branch, because you will have to remove the hooks directory [09:50] right easy enough [09:51] Then lets pick up some layers to form our charm so that we reuse code [09:52] i was wondering what a good base charm would be [09:52] Lets use the "basic" layer: https://github.com/juju-solutions/layer-basic [09:52] and you also said we will need to interface with reddis. So we will need the reddis interface [09:53] https://github.com/jamesbeedy/interface-redis [09:53] right ok, so my layer.yaml has includes: ['layer:basic'] already [09:53] now i just need to add the redis interface [09:54] I am not making all this up. In this url: http://interfaces.juju.solutions/ you can find all the layers and interfaces registered with juju [09:54] you can also register your own layers for others to use [09:55] ah terrific [09:56] i do not know anything about hubot, so I need to ask you, is the relation to redis optional or is it required to have hubot running? [09:56] is redis a had dependency or is it good to have ? [09:56] it is optional but highly recommended for production [09:57] i'd make a config.yaml option to disable redis [09:58] you can handle all of that in the relation jamon :) [09:58] ok, do you want to have hubot up and running without redis and when redis becomes available (related to hubot) then hubot gets reconfigured to use redis? [09:58] options are for wimps ;) [09:58] kjackal: yeah that sounds right [10:01] cool, I am trying to find the state the basic layer sets to signal "all-is_ready" [10:05] ok, we do not need to care much about the states of the basic layer [10:05] for now at least [10:06] jamon: looking at the install script https://gitlab.com/jamonation/layer-hubot/blob/master/hooks/install [10:07] I see we first add a repository then we apt-get install nodejs things [10:08] I wonder if there is any nodejs specific layer we could reuse [10:09] https://jujucharms.com/ghost/0 was the only one i found when searching for nodejs on the store [10:09] jamon: Hey it seems we have this layer: https://github.com/battlemidget/juju-layer-node [10:10] I was looking at the http://interfaces.juju.solutions/ [10:10] hmm i'll have to start looking there it sounds like [10:11] the stuff you see there jamon is all the stuff you can inherit [10:11] and get free code ;) [10:11] similarly, you could deploy layer-hubot there and I could pick it up and customise it to fit my needs [10:11] for example [10:12] right, reusability [10:12] jamon: so, looking at the readme of nodejs layer we can easily get npm installed! [10:12] absolutely. The hadoop example is a good one, I don't care how hadoop is installed, and I don't know how to install it, but I do need haddop and the hadoop client [10:12] looks like that layer will let me specify the nodejs versions too, which is important [10:12] so I can just pickup a layer that allows me to reuse all of that [10:12] https://github.com/battlemidget/juju-layer-node/blob/master/config.yaml [10:13] jamon: awesome, lets do this! [10:15] you can provide these options at deployment time [10:15] jamon: like so: https://jujucharms.com/docs/1.24/charms-config [10:16] right yes i've been using a hubot.yaml with api tokens in it for config [10:21] there is always the option to use the apt-layer and add your repository in the same way nodejs layer is doing here: https://github.com/battlemidget/juju-layer-node/blob/master/reactive/node.py#L30 [10:22] this looks like a great example layer to use [10:32] jamon: Do you have enough material to go on by yourself? [10:33] Do you want to ping me when/if you get stuck again? [10:34] jamon: I would be very happy look at how you are handling this [10:34] absolutely, it's lots to go on [10:34] just have to do a bit of $dayjob work here for a bit [10:35] then back to this charm and provisioning a new laptop with 16.04 so i can hack on charms more easily [10:39] jamon: we have this program that might interest you: https://developer.juju.solutions/ Basicaly resources for work on charms [10:40] ah cool [10:40] i'm hoping i can just use my laptop with lxc [10:41] lots of resources [10:41] i've been using my aws account in the meantime [10:41] you can certainly use lxc [10:41] you can also get aws credits for juju developers [10:41] nice and lightweight [10:42] yes, lxc is also my first option [10:42] not sure what the aws application link is any more, but marcoceppi deals with that stuff [11:57] Hi, someone knows how to add new parameters in juju to be added to my config files? [11:58] test = test for example in /etc/test.conf [11:58] config.json I suspect D4RKS1D3 [12:00] you mean config.yaml ? [12:00] yeah sorry [12:00] brains not in gear [12:01] hahaha, do not worry, i have the same "problem" hahaha thanks for your help [12:10] o/ morning charmers, bug filers, and fellow community constituents [12:11] good morning lazyPower [12:14] Ejat: having trouble with conjure? === redelmann is now known as rudi|wfh === rudi|wfh is now known as rudi_wfh === rudi_wfh is now known as rudi|wfh [13:01] his problem is running on ppc64 [13:02] ah, makes sense === cory_fu-vac is now known as cory_fu [13:51] Its possible to debug a value in a charm? [13:51] {% if metadata_shared_secret -%} [13:54] wait up petevg I havent yet created a PR for the part we consider ugly. That one is on the namenode. [13:54] :) [13:54] kjackal: I look forward to being grumpy about it in the comments :-) [13:54] lol petevg [13:56] D4RKS1D3 - that looks like a jinja template, and you sure can. but we'll need to know where its getting context from [13:57] I am trying to enable metadata_shared_secret in the nova-compute charm [13:57] in the config.yaml does not exist this parameter [13:58] I do not know how to enable [14:02] you have enough details lazyPower ? [14:04] D4RKS1D3 - looks like its either coming from neutron or keystone [14:04] just based on its location in the nova.conf [14:05] D4RKS1D3 - so you will need to do one of two things. Inspect the relationship data coming from keystone/neutron, or dump the context object before it renders that configuration to see whats in there. [14:05] Okey I will do that thanks lazyPower === zz_CyberJacob is now known as CyberJacob [15:46] evilnickveitch: I was looking for how to set the default region for juju and I found it in the docs [15:46] evilnickveitch: Thanks! [15:46] evilnickveitch: that was a surprisingly excellent experience and I wanted to thank you [15:48] mbruzek, I knew those thousands of words would come in handy some day :) [15:48] * lazyPower +1's this conversation thread [15:48] * lazyPower has reacted with :cake: [15:48] heh [15:48] evilnickveitch: Some people always complain when something goes wrong, I am letting you know it went well. [15:49] I could open an issue against the docs to thank you if you wish! === CyberJacob is now known as zz_CyberJacob === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob === zz_CyberJacob is now known as CyberJacob === frankban is now known as frankban|afk [17:14] cory_fu: I am done with the review queue for today [17:14] kjackal_: Thanks. I'll send it out in a bit. [17:14] kjackal_: Have a good evening! [17:14] cory_fu: Just a sec [17:16] I gave a +1 to pubphoto. So, if it is fine with everyone I could try to promulgate it tomorrow, but I would appreciate if you could look over my shoulder this time [17:17] cory_fu: also, the card with Hadoop HA has links to branches that I was working on. [17:17] It would be great if i could give you a tour, any feedback would be much appreciated [17:18] kjackal_: Sure. Did you want to do that tomorrow, since it's late for you, or spin through it now? [17:18] I have some time now but, whatever is more convenient for you [17:19] I do not want to pull you from whatever you were doing [17:19] kjackal_: Now is fine [17:19] ok cool, daily sync then? [17:19] Yep [17:49] someone can explain me this variable "relation_ids('neutron-plugin')" where is filled this var is in a method and this method is called when @hooks.hook('neutron-plugin-relation-changed') [17:49] Thanks [17:49] D4RKS1D3 - sure, each unit participating in a relationship gets a numeric id [17:50] the relation_ids('neutron-plugin') returns the numeric identifier for the relationships attached to that relation. it should return an array of those id's [17:52] And then with related_units(id) I can extract the information about the units? [17:53] lazyPower, I am lost here, I do not understand where the charms change information among them [17:53] are you trying to get at the relation data D4RKS1D3? [17:54] Could you explain me? === CyberJacob is now known as zz_CyberJacob [17:54] so, normally how this is done is you attach to the unit in debug-hooks, and when you hit the context of *-relation-changed you invoke on the shell directly "relation-get" [17:54] its already got context setup for you [17:54] if you have that relation-id, you can inspect the relation data out of band [17:54] relation-get -r # [17:54] lazyPower, I am trying to know in which part of code this "if enable_nova_metadata:" [17:54] is true [17:55] beisner - do you have a short answer for D4RKS1D3 here which relation provides the shared_metadata_secret key? [17:55] cc thedac [17:56] * thedac reads backscroll [17:56] I saw all the neutron charms, ovs charm and I do not know how to enable [17:56] thanks for your help lazyPower [17:57] D4RKS1D3 np, i'm not terribly familiar with the intricacies of the openstack charms, but i can certainly lend a hand with generic info. I try not to ping the openstack charmers until we're out of my depth [18:00] * beisner may need to defer to thedac on this one [18:01] thanks beisner for your time too [18:01] D4RKS1D3: ok, so you can see that the neutron-ovs sets metadata-shared-secret and passes it to nova-compute. I an see that it is not clear. But this only happens when using DVR and we want the compute node to run metadata itself rather than the neutron-gateway charm which does by default. [18:01] s/an/can [18:02] I check it [18:02] So if you are writing an SDN charm you only set that to a value if you need the compute node to run nova-api-metadata rather than have it centralized on neutron-gateway [18:03] I am not writing a charm, i am trying to enable metadata in my computes nodes [18:03] I see [18:04] I am thinking if there is a way to do that without turning on DVR. Give me a sec [18:04] thedac, you mean this value "enable-local-dhcp-and-metadata" [18:04] put a true this value? [18:05] D4RKS1D3: yes that will do it [18:05] That means the dhcp agents and the metadata agents will run on the compute nodes [18:07] I want to configure in /etc/neutron/metadata_agent.ini in the defaultconfig nova_metadata_ip = controllerIP [18:07] and metadata_secret= METADATA_SECRET_PASSWORD [18:08] and in the computes service metadata proxy = true [18:08] and the same password in this file [18:09] After saw all the python scripts i am not sure if this boolean flag you talk me enable this option, you know it thedac ? [18:09] D4RKS1D3: it will enable the metadata service on the compute nodes [18:10] D4RKS1D3: which openstack version are you deploying? mitaka liberty etc? [18:10] liberty [18:12] thedac, http://docs.openstack.org/liberty/install-guide-ubuntu/neutron-controller-install.html#configure-the-metadata-agent [18:14] We are setting the metadata_proxy_shared_secret https://github.com/openstack/charm-neutron-openvswitch/blob/master/templates/juno/metadata_agent.ini [18:14] I am double checking to make sure we don't need a template refresh for liberty+ [18:15] I will enable this option [18:15] Thanks for your help thedac [18:15] no problem [18:16] lazyPower, thanks for your help and explanations too [18:16] np D4RKS1D3 [18:16] thedac - thanks for picking that up. i tried :) [18:17] no worries. That was a bit in the weeds [18:19] for completeness for anyone following allong the other side of the relation, nova-compute, adds the metadata info to nova.conf: https://github.com/openstack/charm-nova-compute/blob/master/templates/liberty/nova.conf#L143 [18:25] thanks thedac, lazyPower :) [19:15] cory_fu: in the interest of working on the open more better, I am going to merge https://github.com/juju-solutions/bigtop/pull/36 with the spark branch. That way, it will show up in the upstream PR, and people can make comments as part of the whole spark PR. [19:17] petevg: +1 [19:18] cory_fu: Cool. I just did the same thing w/ the fixes for the hbase tests. === natefinch is now known as natefinch-afk === petevg is now known as petevg_vacation === petevg_vacation is now known as petevg_afk === petevg_afk is now known as petevg_vacation