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