=== defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === thumper is now known as thumper-afk === defunctzombie is now known as defunctzombie_zz === CyberJacob|Away is now known as CyberJacob === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === CyberJacob is now known as CyberJacob|Away === thumper-afk is now known as thumper === thumper is now known as thumper-afk === JoseAntonioR is now known as JoseeAntonioR [09:14] mgz, do you happen to know if a change/assignment of a public-address/floating-ip get notified to a charm in some way in the context of the openstack provider? === thumper-afk is now known as thumper [09:22] hi, i need to trigger some change when i assign a public ip to an instance. Is there any hook i could use for that, or can you give advice on some workaround? I've only thought in setting a config var with that ip, to trigger a config-changed , but i don't see it very usable [12:37] Hi! [12:37] What's with the "use of closed network connection error" when doing "juju bootstrap"? [12:38] juju 1.11.2 [12:38] It all was working fine on Saturday ... [12:44] jamespage: juju is completely ignorant of ip changes currently, it's one of the things I'm working on fixing this cycle [12:44] mgz, urgh [12:44] ok [12:46] it's also not easy to work around at a charm level, though I think is may have a few magical bits they've done previously [12:48] Ah the error is gone now. I played around with deleting the control bucket which did not help at first but seems to do now. === teknico1 is now known as tekNico [13:08] when a unit is added to a service, wich hooks are supposed to be run ? i think i onluy see a relation-changed, i was expecting to see a unit-added hook of some sort [13:19] melmoth: you mean when you juju add-unit? [13:19] yes. [13:20] i want soemthing to be trigged in the other units when a unit is added. [13:24] marcoceppi, looks like config-changed is all that is triggered...thats all right... as long as i can get a list of all the units associate with the current service [13:25] melmoth: you can use a peer relation, which is fired when a new peer (unit) is added/removed from a service [13:25] i dont see any attempt to fire soemthing in the first unit of the service charm.log [13:26] melmoth: juju-core? [13:26] nope. pyjuju [13:27] melmoth: Speculating, as I know the peer relation works on both, but if there's no peer relation listed in the metadata.yml file juju might not even attempt to describe looking for one in the logs [13:48] marcoceppi, indeed, i added a peer definition in the yaml, now when a new unit is fired it try to call peer-relation-joined. Thanks [13:49] melmoth: excellent! [14:21] how can i list all unit belonging to a service ? i try related_units() from charmhelpers without success: Calling relation related method without relation context: [14:26] jcastro: thanks, mysql showing up in the category now. [14:28] melmoth: you need to call relation-list in the end. That takes a relation-id argument [14:28] hi, i'm writing a charm and i need some event to detect when a public ip has been associated, because some config files depend on it. Is there any hook i could use? [14:28] melmoth: the relation-id is between services [14:28] melmoth: so to grab all relation-ids for a relation name you call relation-ids first [14:28] melmoth: you can't call it from just "any" hook without providing some context either [14:29] melmoth: so, call relation-ids , then loop over the result calling relation-list -r for each one [14:29] yolanda: currently there's no way to trap this event in Juju (from my understanding) [14:29] yolanda: what you can do instead is create a configuration parameter in config.yaml, say `public-ip` that people can set [14:29] marcoceppi, that's what i thought but i didn't find it very usable... i mean, this can be automatic [14:30] you assign a public ip, and you have to remember to set the config var [14:30] yolanda: It can be, if it's not already a bug should be opened in juju-core. The problem is each provider's public ip assignment mechanism varies greatly and not all providers even expose public ip to it's units [14:31] i see [14:34] marcoceppi, so should i open a bug to request it? [14:34] yolanda: certainly! [14:34] and in the meantime do the config workaround [14:35] yolanda: exactly. The config parameter will "just work" for all providers, but it might be more trivial to incorporate public ip address. [14:35] yolanda: there is a `unit-get public-address`, but I don't think that gets updated if you assign it a permenant IP, only gets the ip/address you were provisioned with [14:36] marcoceppi, i did a try, and it's updated. But the problem i have, is i don't get any event to detect when the change has been done [14:36] yolanda: Oh, I see your problem [14:36] if i trigger a config-changed for example,with some other var, unit-get public-address is ok [14:37] but i need to process the event on time [14:37] There's a bigger bug at play, some kind of provider-state-changed hook [14:37] Where you can trap events outside of juju, like getting a new ip address [14:37] marcoceppi, great, and it's on progress then? [14:37] This might be an iteresting discussion for the juju mailing list instead, to see what people think of a feature like this [14:37] yolanda: not that I know of [14:38] I mispoke, there's a bigger topic of discussion other than just getting the public ip [14:38] not that there's already a bug for this [14:38] oh, i misunderstood :) [14:39] I think it could probably exist as a hook, however I'm not sure if everyone would share that opinion. If you mail the idea to juju@lists.ubuntu.com it'll probably spur some good discussion on how to handle events of this nature [14:41] sound like a good idea [14:41] i already filed a bug anyway [14:42] excellent [14:42] related=[u'ntpmaster/2', u'ntpmaster/1'] \o/ [14:44] yolanda, mgz said earlier they are looking to improve this in juju-core this cycle [14:44] so I think the public ip approach via config is best for the time being - even if it sucks badly [14:44] melmoth, nice one! [14:45] jamespage, ok, i'll do that workaround, isn't that bad :) [14:46] jcastro: some good news on my side- I had to doublecheck Juju license would work with Fedora's limitations [14:47] It will. For us to get access to code do we have to sign the Canonical CLA? My guess is no. [14:47] * MarkDude was made aware that the license COULD be changed in the future- and at that point we would have to fork [14:48] But we are good, and can see about working on this and getting it INTO the Fedora repos [14:50] the CLA is for contributing, not using [14:50] Yep, that was my guess [14:51] http://www.uncuartotech.com/ we plan on trying to use it with these cooll folks [14:52] * MarkDude is wondering if we would actually make any code you folks could use- most of what we do would be centered on getting it to work with Fedora [14:53] But, if we create sumthin' you might want, we would of course make it available in the spirit of FOSS [14:53] And we are cleared on doing that too :) [14:54] The legal thing appears to be a hassle - but I got a response to my question from legal- in less than 5 minutes, sometimes it may even take an hour :) [14:55] * MarkDude is a bit sad to be missing OSCON for the 1st time in 8 years or so. I was looking forward to seeing the newest Charm school [14:57] What is the most recent video or walkthru for creating charms? Im not sure some of my people UNDERSTAND how awesome Juju is in function AND to lower the entrance to getting folks into the concept of being a dev :) === dosaboy_ is now known as dosaboy === mbarnett` is now known as mbarnett === defunctzombie_zz is now known as defunctzombie [15:55] adam_g: Do you have any plans to package juju-deployer anytime soon? [15:55] I'm trying to figure out if it's best to just wait, or to just embed juju-deployer in what I'm working on now [15:56] hi, having this problem suddenly when deploying my charm, without any code changes from the last working version: http://paste.ubuntu.com/5855747/ [15:56] any idea? [15:57] yolanda: what's the first three lines of hooks/install look like? [15:57] Just out of curiosity [15:58] #!/usr/bin/python [15:58] import os [16:00] huh, I'm not sure why you're getting that error [16:01] i'll redeploy [16:14] hey guys, who's reviewing charms today? [16:43] JoseeAntonioR: Mims and I. I've got your charm on my list for reviewing today since I didn't get to it last week [16:43] (Though officially mims is on review) [16:43] marcoceppi: great, thanks :) [16:43] wanted to know as I'm willing to push another charm that's dependant of postfix being approved [16:44] JoseeAntonioR: go ahead and throw it in the queue! [16:44] just make sure you mention it depends on postfix [16:44] * JoseeAntonioR goes for it [16:51] done :) [17:03] * MarkDude <3 cooperation and sharing of code and ideas. === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === cmagina_away is now known as cmagina [18:33] can i get the up of the hostname of a machine if i know its unit name ? (and nope, it s not the current machine the charm runs on) [18:34] grmblblb, keyboard, ifingres... i meant can i get the IP OR the hostname [18:35] melmoth: only if it's called upon in a relation [18:36] then i need to store somewhere the name of all peers in a unit. [18:36] i need to get the list of all the peers each time i need to rewrite a conf file [18:36] melmoth: you'll probably want to record them to a file then [18:36] wich can be when a a unit join in, or out, but also if the config change. [18:36] in a file... [18:36] bouhou [18:50] y === CyberJacob|Away is now known as CyberJacob === koolhead11|away is now known as koolhead17 [21:26] I am attempting to upgrade charms I have installed and keep running into the following exception: ERROR 'ServiceRelationState' object has no attribute 'role' [21:27] I found bug filing #1185198, but nothing else. [21:27] <_mup_> Bug #1185198: ERROR 'ServiceRelationState' object has no attribute 'role' === defunctzombie_zz is now known as defunctzombie [21:49] michaelb: I don't know, but that looks like a py-juju error, not juju-core, which is the current focus of development === JoseeAntonioR is now known as j === j is now known as JoseeAntonioR === JoseeAntonioR is now known as jose === CyberJacob is now known as CyberJacob|Away === defunctzombie is now known as defunctzombie_zz