[08:01] <gnuoy> jamespage, https://code.launchpad.net/~gnuoy/charms/trusty/cisco-vpp/amulet/+merge/277787 if you get a moment
[08:48] <jamespage> gnuoy, merged
[08:48] <gnuoy> ta
[09:43] <jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/trusty/odl-controller/doc-updates/+merge/277797
[09:45] <gnuoy> jamespage, don't you need to reference the config.yaml at line 44 of the diff?
[09:45] <jamespage> gnuoy, yes pushed
[09:45] <gnuoy> ta
[09:49] <gnuoy> jamespage, approved
[10:00] <jamespage> gnuoy, I'm working on refreshes to the bundles for liberty and the 15.10 charm release this morning - we should add that to the release checklist
[10:01] <gnuoy> ack, good catch
[10:03] <gnuoy> jamespage, done
[10:23] <jamespage> gnuoy, mind if I do a trivial on all of our charms for "maintainer: OpenStack Charmers <openstack-charmers@lists.ubuntu.com>"
[10:23] <jamespage> ?
[10:23] <gnuoy> jamespage, please do, thanks
[10:55] <jamespage> gnuoy, done
[10:55] <jamespage> gnuoy, I tied some pretty crappy summary and description bits at the same time
[10:56] <jamespage> tided rather
[10:57] <gnuoy> sounds good, thanks
[11:14] <jamespage> gnuoy, can you sanity check:
[11:14] <jamespage> https://code.launchpad.net/~james-page/charms/bundles/openstack-base/bundle/+merge/277798
[11:14] <jamespage> and
[11:14] <jamespage> https://code.launchpad.net/~james-page/charms/bundles/openstack-telemetry/bundle/+merge/277799
[11:14] <jamespage> I've just deployed telemetry in dellstack and run through the README ok
[11:14] <jamespage> telemetry == base + ceilometer
[11:17] <gnuoy> 'num_units: 0' looks odd but since you've deployed with it is looks like it does no harm for subordinates
[11:17] <jamespage> gnuoy, thats a gui-ism
[11:17] <gnuoy> jamespage, why are the mcast ports explicitly stated for a couple of services?
[11:17] <jamespage> gnuoy, again I have not idea why the gui elected to add those...
[11:18] <gnuoy> haha
[11:18] <jamespage> they could be dropped
[11:20] <jamespage> gnuoy, charmstore does some verification of bundles
[11:20] <jamespage> https://jujucharms.com/u/james-page/openstack-base
[11:20] <jamespage> and https://jujucharms.com/u/james-page/openstack-telemetry
[11:20] <jamespage> that validates the format and the charm revs...
[11:20] <gnuoy> the bundles look ok to me
[11:23] <jamespage> gnuoy, ok
[11:23] <jamespage> thanks
[16:10] <kwmonroe> hey folks - what's the difference between "destroy-environment local" and "destroy-environment local --force"?  help tells me that force destroys "directly through the env provider", but i don't know what that means for local.
[18:30] <asanjar1> kwmonroe: hi
[18:30] <kwmonroe> hey asanjar1
[18:31] <asanjar1> kwmonroe: thanks for v9 version. Maria's team could use you onsite for few hours to resolve the remaining issues.. do you have time? I have already asked arosales
[18:32] <kwmonroe> asanjar1: is the caffetteria food any good?
[18:32] <kwmonroe> (and yeah, i can be there around 1:45 this afternoon)
[18:32] <asanjar1> kwmonroe: I wounder if there is something unique with their environment
[18:32] <asanjar1> kwmonroe: no man, it SUCKS
[18:33] <asanjar1> kwmonroe: I am losing weight
[18:33] <asanjar1> okay let me ping here
[20:01] <jcastro> anyone have a tldr on the current state of the jenkins charm?
[20:01] <jcastro> it hasn't been touched for over a year so it's either really awesome or horrible. :)
[20:05] <jcastro> huh wait a minute, it is updated, the jujucharms changelog is broken?!
[20:06] <lazypower> jcastro - correct. its been receiving some attention. The changelog in the store has been silently sometimes-functional due to the v3->v4 transition
[20:08] <jrwren> does juju support ipv6? I can't seem to juju ssh to a machine with ipv6 public-address the proxy-ssh netcat fails. http://pastebin.ubuntu.com/13334236/
[20:09] <jrwren> *doh* nevenmind. i was misinterpreting the message.  works fine
[20:15] <lazypower> jrwren woo! \o/
[20:21] <jcastro> lazypower: ack, filed a bug
[20:26] <jrwren> any write amulet tests which execute on an ipv6 environment? :)
[20:52] <beisner> o/ jcastro, jenkins charm has action in the review queue to, to bring feature parity of the python rewrite back up to le ole bash precise jenkins charm.
[20:52] <beisner> too, even.
[20:55] <jcastro> beisner: do you guys maintain it? you guys being the openstackers
[20:56] <beisner> jcastro, no.  but we consume an old diverged fork, and would like to switch to consuming a converged, updated, works-for-everyone version, ie. the python rewrite + back-filled features.
[20:56] <beisner> jcastro, so, by virtue, contributing to the thing, testing the thing, making proposals of the thing, could be pretty close to "maintaining"  ;-)
[20:59] <jrwren> bash charms <3
[21:01] <beisner> :)
[22:36] <adam_g> hey, ive got a charm questino wrt coordination between two services. i have service A that will eventually get a relation to B. when it does, B will do some stuff on A's API.  before it can, service A needs a complete relation to service 1 and 2 (say, DB and message queue)
[22:37] <adam_g> is there a good way to interrogate that on B's side, short of adding some data in the relation settings exported by A that B can use as a test?
[22:37] <adam_g> its been a while since ive juju'd, but i remember dealing with this often. wondering if a good practice has come up since
[22:38] <adam_g> jamespage, maybe you know
[22:40] <mgz> adam_g: I think the normal way is that B doesn't set it's api details on the B-A relation till it has B-1 and B-2 relations up and whatever real interfaces for those up and ready
[22:40] <mgz> so, A will not get the relation config stuff it needs to start the api poking till B is really ready to act on it
[22:41] <mgz> juju now has nice reporting in status where a charm can say it is "blocked" for these sorts of situations
[22:41] <adam_g> mgz, well, thats complicated by the fact that the API endpoint isn't advertised via relation, its published into a catalog (read: keystone)
[22:42] <adam_g> mgz, ya, im looking at the status stuff now in the openstack charms. will have to go find the docs on that
[22:44] <marcoceppi> adam_g: there really isn't a way to interogate b's relations, Juju doesn't set up that kind of dependency train, otherwise A becomes co-dependant to Bs architecture. Relation data is the best way to handle this
[22:44] <mgz> adam_g: https://jujucharms.com/docs/1.24/reference-status is some of it, there are some new tools for setting that from hooks
[22:45] <adam_g> marcoceppi, yeah, was hoping to get around it without having to extend existing stuff
[22:45] <mgz> adam_g: if you can't set the api details directly, you can just have a api-ready: bool type thing on the relation config
[22:45] <adam_g> mgz, thats what i was thinking, thanks