=== Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === menn0_ is now known as menn0 === uru_ is now known as urulama === uru_ is now known as urulama === CyberJacob|Away is now known as CyberJacob === dosaboy_ is now known as dosaboy-alt === CyberJacob is now known as CyberJacob|Away === ming is now known as Guest79564 === hloeung_ is now known as hloeung === jog_ is now known as jog === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [14:48] jamespage, your thoughts on https://code.launchpad.net/~gnuoy/charms/trusty/nova-cloud-controller/disable-services-until-db-ready/+merge/230495 would be greatly appreciated if/when you have a moment === roadmr is now known as roadmr_afk === urulama is now known as urulama-afk === urulama-afk is now known as urulama === roadmr_afk is now known as roadmr === urulama is now known as uru__ [20:43] What is the right way to use charmhelpers.core.hookenv.relation_get ? I do not like that it is outputting errors. [20:43] jrwren: what errors are you getting? [20:44] no relation id specified [20:45] jrwren: is this being called out of band of a relation call? [20:45] of a relation hook* [20:45] alternatively, just supply the current JUJU_RELATION_ID [20:45] from os.environ [20:47] jrwren: give me a min to open the code, the docs are light on this one [20:47] yes, out of band. I should look it up. [20:47] jrwren: docs are here, FYI: http://pythonhosted.org//charmhelpers/api/charmhelpers.core.html#charmhelpers.core.hookenv.relation_get [20:47] jrwren: in that case you need to provide the JUJU_RELATION_ID and the unit you wish to query this information [20:47] during a relation hook, both JUJU_RELATION_ID and JUJU_REMOTE_UNIT are environment variables set in the hook environment [20:49] jrwren: hum, the docs are out of date with the function signature [20:49] you pass unit and relation_id as parameters [20:49] elation_get(attribute=None, unit=None, rid=None) [20:49] relation_get(attribute=None, unit=None, rid=None) [20:50] tvansteenburgh: can we get the docs re-generated? [20:50] marcoceppi: where are the format of rid and unit documented? [20:51] jrwren: the format are the values of JUJU_RELATION_ID and JUJU_REMOTE_UNIT respectively [20:51] remote unit being in the format of "service/#" [20:51] relation id is typically "text:#" [20:51] you can query them using relation_id [20:51] you can query them using relation_ids* [20:52] I didn't have much like with any of that when I was debugging the hooks. I'll try again. [20:52] jrwren: they're only set during the execution of a relation hook [20:52] so you'll want to cache them somewhere [20:52] so you can use them later [20:53] marcoceppi: huh, ok. so... no point in aiming for stateless hooks? [20:53] alternatively, you can list all the relations_ids, find the relation_id you want, then get all the units [20:53] jrwren: you can do that [20:53] jrwren: IIRC, relation-id is comprised of : [20:54] so you can infer what relation_id you need by checking the start of the string of the list of items core.hookenv.relation_ids() provides [20:54] marcoceppi: This sounds good. [20:54] then there's core.hookenv.related_units(rid) which will give you a list of all the units in that relation id [20:55] marcoceppi: isn't that a different format of rid? [20:55] using those two pieces of information, jrwren, you should be able to loop through and call relation_get(rid=relation_id, unit=u) [20:55] rid and relation_id are interchangable in this context [20:56] marcoceppi: the call to related_units() still takes a relation:# format? will it work even if # doesn't exist? [20:56] * marcoceppi will bug Tim VanSteenburger to update the docs on pythonhosted.org [20:56] jrwren: probably not, that depends on how flexible juju is [20:57] since it's just a passthrough to `relation-units -r ` [20:57] marcoceppi: Then list and startswith it shall be. [20:57] worth a try, but I'm guessing no [20:57] marcoceppi: understood. The source is easy enough to read, its just what is there, which is unknown. [20:57] right, that's something juju makes up [20:57] typically out of thin air ;) but should follow relation: [20:58] the idea being, if you break and recreate [20:58] you'll get a new unique relation id [20:58] which may or may not be incremental from the last [21:00] It would be very nice if all this was documented on links from https://juju.ubuntu.com/docs/authors-charm-writing.html too. [21:03] jrwren: it's on the roadmap [21:03] both charmhelpers and better author docs [21:04] marcoceppi: Thank you for your help. [21:04] jrwren: np, feel free to ping if you have any others [21:05] fwiw, a lot of the openstack charms have atomic-like functions that do relation calls, so there's use of this pattern in charms already [21:25] marcoceppi: I cannot call relation-ids or relation-list without a relation name [21:25] marcoceppi: I'm pretty sure that hookenv.relation_ids() will always fail. [21:26] marcoceppi: As will hookenv.related_units() [21:26] related_units needs a relation_id [21:27] jrwren: it looks like relation-ids takes a relation now [21:27] which is cool [21:27] jrwren: so you can say, "db" or whatever the relation name is [21:27] and get the ID that way [21:27] isntead of having to iterate through a list [21:27] you'll either get a value or None iirc [21:27] that is good. [21:27] rather, a list of relation ids [21:27] for that relation [21:28] in case there's more than one [21:28] IE, MySQL -> WordPress, MySQL -> MediaWiki [21:28] query database on MySQL you'll get two relation ids [21:28] loop through the ids to get the units, etc, etc [21:28] marcoceppi: indeed. I must have misunderstood what you wrote before. === CyberJacob|Away is now known as CyberJacob === cmagina_ is now known as cmagina [22:23] hey all, has anyone set up multiple l3 agents with the quantum-gateay charm? [22:24] I feel like i'm frustratingly close to getting it working, but i'm getting a TooManyExternalNetwroks exception in the nova-server logs. [22:24] it also seems to be taking away my ability to spell things correctly === CyberJacob is now known as CyberJacob|Away