[04:25] <blahdeblah> Hi all.  I'm trying to learn enough amulet to get my charm accepted: https://bugs.launchpad.net/charms/+bug/999439  Are there any examples of charms which get the "charmers seal of approval" for good amulet tests?
[04:25] <mup> Bug #999439: Need charm for quassel-core <new-charm> <Juju Charms Collection:In Progress by paulgear> <https://launchpad.net/bugs/999439>
[04:27] <blahdeblah> And a related question: Is there a recommended workflow for getting local results from my tests rather than having to wait for them to churn through the various cloud testing setups?
[05:38] <stub> blahdeblah: Setup a makefile so that 'make test' runs your tests against an environment you already have bootstrapped (with JUJU_ENV set if it is not your default).
[05:39] <stub> blahdeblah: Or there is a new docker image that can be used to get the same environment as the jenkins setup. Similar process, except you run the tests inside the vm.
[05:44] <blahdeblah> stub: Thanks - I might have a look into those next time.  Next Q: if I want to run the same set of tests against a precise deploy and a trusty deploy, what's the best way to do it?  I don't want to duplicate whole modules.
[05:46] <stub> I stick "SERIES := $(juju get-environment default-series)" at the top of my Makefile, then reference that environment variable.
[05:47] <stub> So it uses the default series, unless I override it on the make command line.
[05:50] <stub> The jenkins setup sets up the juju environment to have a default series corresponding to your branch, so you unfortunately need to push your branch to two locations to get it to run the tests against two series.
[05:50] <blahdeblah> Cool - thanks stub
[06:02] <stub> blahdeblah: Were you doing ntp charming? I have a charm where the units require clock syncronization. At the moment I'm just installing the ntp package, but was wondering if that is good enough.
[06:02] <blahdeblah> stub: I was helping bradm with it a bit
[06:03] <stub> I could say 'you must also use this subordinate', but it would be nice if that was optional.
[06:03] <blahdeblah> stub: If you really want it to work, you need to deploy a few ntp masters, then deploy ntp clients (which will auto-relate to the masters) on the hosts whose clocks you want synchronized.
[06:04] <stub> Cause now I think of it just installing the package will fail with some egress restrictions.
[06:04] <blahdeblah> NTP egress restrictions, or something else?
[06:04] <stub> NTP egress restrictions
[06:05] <stub> Is there a reason I can't rely on the default NTP masters you get when you install the ntp package? Apart from egress?
[08:32] <apuimedo> gnuoy`: hi
[08:32] <apuimedo> where does the nova-api-metadata server run on a default juju openstack deployment?
[08:33] <lukasa> apuimedo: nova-cloud-controller, I believe
[08:33] <lukasa> apuimedo: Though Calico installs and runs it as part of its neutron-calico subordinate charm
[08:33] <apuimedo> lukasa: I can't find it there
[08:33] <lukasa> I think it's part of nova-api, which does run there
[08:33] <apuimedo> I saw it only in the quantum-gateway charm
[08:33] <lukasa> Oh interesting
[08:34] <lukasa> This isn't a problem we had because we distribute nova-api-metadata, so maybe it is only part of quantum-gateway
[08:34] <apuimedo> ;-)
[08:34] <lukasa> When it comes to the quantum-gateway charm I know almost nothing about it because we don't use it. =d
[08:34] <apuimedo> lukasa: I saw that you put it as a required service for Calico in the charm-helpers ;-)
[08:35] <apuimedo> (nova-api-metadata, I mean)
[08:35] <lukasa> Yeah. =) Wherever we can we distribute services as widely as possible, nova-api-metadata is one of them.
[08:35] <apuimedo> ;-)
[08:35] <lukasa> No reason to have metadata queries wandering all over the network if we can avoid it
[08:35] <apuimedo> true
[08:36] <lukasa> But having it in quantum-gateway sounds plausible too
[08:36] <lukasa> Though I expect that if you don't add neutron-api, it runs on nova-cloud-controller
[08:36] <lukasa> Regardless, try making a metadata query to nova-cloud-controller and see what happens, I wouldn't be surprised if it responds
[08:36] <lukasa> (I don't have a juju deployment up at the minute)
[08:36] <apuimedo> celebdor@nx02 ~/code/nova-cloud-controller $ bzr grep nova-api-metadata
[08:36] <apuimedo> hooks/charmhelpers/contrib/openstack/neutron.py:                         'nova-api-metadata'],
[08:36] <apuimedo> hooks/charmhelpers/contrib/openstack/neutron.py:                          'nova-api-metadata']],
[08:37] <lukasa> =) I mean literally spinning one up and then curling the endpoint. =)
[08:37] <apuimedo> and I believe those two mentions are calico's :P
[08:37] <lukasa> I think they are too. =D
[08:38] <lukasa> However, IIRC nova-api-os-compute also includes nova-api-metadata
[08:38] <apuimedo> makes sense
[08:39] <lukasa> And that *is* deployed by nova-cloud-controller
[12:50] <jamespage> bug 1431286
[12:51] <mup> Bug #1431286: juju bootstrap fails when http_proxy is set in environments.yaml <ubuntu-openstack> <juju-core:Incomplete> <https://launchpad.net/bugs/1431286>
[15:12] <beisner> hi ctlaugh, fyi that change has landed in the nova-compute "next" (development) charm.  https://code.launchpad.net/~clark-laughlin/charms/trusty/nova-compute/arm64-patch-1/+merge/252682    ps thanks, gnuoy`
[15:13] <gnuoy`> np, thanks for the contribution ctlaugh
[15:20] <jamespage> gnuoy`, https://code.launchpad.net/~openstack-charmers/charm-helpers/0mq/+merge/254590
[15:20] <jamespage> if you have 5 secs
[15:22] <gnuoy`> jamespage, approved
[16:04] <web>  Is there a variable I can call on `config-change` hook that gets the name of a service as it is, like `mongo-master` not `mongo-master/0`.  Or will I need to regex the line?
[16:05] <web> oops I mean relation change
[16:06] <web> on `relation-change`.  Thought this would do but it is not: hostservicename=`relation-get $JUJU_RELATION`
[17:01] <stub> web: You need to extract the service name from the unit name as you suggest. It is not available as a separate variable.
[17:03] <web> stud: thank you.  So I would use `relation-get $JUJU_UNIT_NAME`, correct?
[17:04] <web> sorry to ask and not test myself.  Don't want to spin up a server to test value.  I'm being lazy... :)
[17:12] <stub> web: Yes, $JUJU_UNIT_NAME
[17:13] <stub> web: But it is an environment variable, so don't use relation-get
[17:15] <stub> `echo $JUJU_UNIT_NAME | sed -e 's|/.*||'`
[17:15] <web> stud: if I need the relation unit name then??
[17:17] <web> thats more elegant then mine: `expr "$host_service_name_string" : '^\(.[a-z]*\)'`
[17:22] <web> oh i see it : $JUJU_REMOTE_UNIT
[17:23] <web> stub: thank you again
[17:35] <web> never mind I was wrong not right
[17:41] <web> now i see )
[17:41] <web> now i feel stupied
[18:32] <marcoceppi_> web: you can also do ${JUJU_UNIT_NAME%/*}
[18:33] <marcoceppi_> it's bash substitution, but as long as your hooks are /bin/bash and not /bin/dash, that will work
[18:36] <drbidwell> When running openstack-install what kind of name do I set JUJU_BOOTSTRAP_TO so that it creates an lxc container on the maas server?
[18:38] <web> marcoceppi_ :  Always improving things!
[18:41] <marcoceppi_> drbidwell: link to the openstack-install instructions/download? i'm not familiar with the software but I canprobably figire it out
[18:50] <web> haha http://www.newegg.com/Product/Product.aspx?Item=9SIA6N42616299&nm_mc=KNC-GoogleMKP-PC&cm_mmc=KNC-GoogleMKP-PC-_-pla-_-All+Cases+%26+Covers-_-9SIA6N42616299&gclid=Cj0KEQjw6OOoBRDP9uG4oqzUv7kBEiQA0sRYBAv_3qEC_e-rZ2s-jRzIYjGQiso_DaDj3RMnUuMEhx4aAphS8P8HAQ&gclsrc=aw.ds
[18:55] <mhall119> jcastro: marcoceppi_: I think I broke juju
[18:56] <mhall119> trying to update my canonistack deployment
[18:56] <mhall119> juju debug-log's last lines are:
[18:56] <mhall119> machine-0: 2015-03-17 16:36:33 ERROR juju.rpc server.go:554 error writing response: EOF
[18:56] <mhall119> machine-0: 2015-03-17 16:36:36 ERROR juju.state.apiserver debuglog.go:101 debug-log handler error: write tcp 10.172.65.78:57110: connection timed out
[18:56] <mhall119> and no juju command I issue seems to have any impact on the actual instances
[18:57] <mhall119> oh, wait...darnit, I'm in the wrong environment
[18:58] <web> you need to check your environment variables and make sure your connecting to the correct api
[18:58] <web> i think
[18:58] <web> haha
[18:58] <web> or that
[18:59] <mhall119> also, it seems to be doing things now (even on the wrong environment), so maybe it was just slow to respond
[19:00] <marcoceppi_> mhall119: when you run commands use --debug and -v to help give more verbose information
[19:01] <mhall119> marcoceppi_: will keep that in mind, thanks
[19:01] <mhall119> it's all running now, and at least this environment is just another canonistack instance of the same app, so minimal damage done
[19:04] <rharper> is there a way to see which uvt- commands juju runs when creating kvm machines?  when add-machine for kvm fails, I can only see that it failed, but nothing in the logs clearly shows what command failed (I assume a uvt-kvm create, but you can't tell).
[19:05] <marcoceppi_> rharper: did you check the machine-*.log?
[19:05] <rharper> I'll check this time, I did but didn't see anything uvt related
[19:05] <rharper> and ofcourse it works this time since I removed all of the uvt-kvm images first
[19:06] <rharper> well, I'll look there next time
[19:22] <web> okay here is a fun question I wish I thought of before.  Can I deploy a charm from a git (ie: github)?
[19:30] <rick_h_> web: there's a plugin for that
[19:31] <rick_h_> web: https://pypi.python.org/pypi/juju-git-deploy
[19:31] <web> what plug-ins now.  I need to read those docs again don't I.
[19:31] <rick_h_> web: :) lots of cool plugins. Just wait until they show you the dhx video
[19:33] <web> :x I wish I could focus on researching new stuff right now :(  one month left to finish graduate work no time :( so behind and baby on the way
[19:33] <web> have to use what I know
[23:06] <AskUbuntu> Is MasaS, juju, or the charm responsible for ssh-keygen on nodes? | http://askubuntu.com/q/603317