=== 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 === defunctzombie is now known as defunctzombie_zz [14:37] mramm: is there a release of core between now and 13.04? [14:38] yes [14:38] later this week I expect another one [14:38] and possibly one early next week [14:56] jcastro: jokes go here [14:57] hey so [14:57] I panged bruno and patrick to clean up the django readme [14:57] since it's like a template right now [14:57] I was thinking for release week we'd have 2 big blog posts [14:57] one for core [14:57] one for charms [14:58] ack [14:58] to go along with newdocs and better juju AU questions [14:59] marcoceppi: jenkins-slave w/ juju sub works great [15:00] excellent [15:00] I'll just now see what direction for the external relation makes sense [15:00] i.e., config on the slave or the master [15:00] prolly elastic-ip on the slave and then config the master [15:00] frickin cool [15:01] don't forget to post your thoughts on rick's metadata thing on the list fellas [15:01] the list is so boring [15:01] Deal with It(tm) :) [15:01] :) [15:01] B) [15:06] lol === defunctzombie_zz is now known as defunctzombie [15:17] marcoceppi: damn... the auth model for jenkins-master/slave really requires them to be local [15:17] at least as far as I can see [15:17] :( [15:17] m_3: You mean local:charm or master slave on the same machine? [15:17] marcoceppi: same subnet / juju environment [15:18] Ugh, what? [15:18] that's pretty lame [15:18] yeah [15:18] well at least the way the charm's written now [15:18] can maybe front it with apache2 configured for auth'd reverse-proxy [15:18] actually, nm... that would probably work [15:19] just won't be as lightweight as we discussed before === salgado is now known as salgado-lunch [15:19] but hey, it's juju [15:19] so that doesnt' really matter as much [15:21] marcoceppi: so I'll maybe extend jenkins so that the master has config to: a.) accept creds to b.) point to an "external" slave [15:22] anyways, I'll run that by ben === salgado-lunch is now known as salgado [15:38] I've got a relation, that essentially provides an API over http. I should probably just make it consume a http interface, because that's all it does [15:38] But during graph testing it'll fail, because not just any http interface will do [15:38] Should this become it's own interface name even though it's basically just a port + http address? === defunctzombie is now known as defunctzombie_zz [15:44] https://juju.ubuntu.com/community/weekly-charm-meeting/ [15:44] thoughts? [15:45] sure man [15:45] +1 [15:45] marcoceppi: touch call, but i would say yea [15:45] maybe we can visit charm quality and audits across the store [15:45] because like port 80 a lot of services run on it [15:45] that are considered diff [15:46] imbrandon: true, the interface defines the service, not so much the protocol which the service is using [15:46] marcoceppi: I'd say leave it http... then it can be wired behind proxies and the like [15:46] right, i mean its a fine line, but thats how i would see it [15:46] the fact that it's an api is just like saying it's special because of its content [15:47] hrm good point … hum [15:47] we'll need to exclude relations from some automated testing... jsut make sure they're caught in $CHARM_DIR/tests [15:47] m_3: What I'm worried about is on the flipside, the charm requires: api: http [15:47] m_3: gotchya, I think http is one of those too broad to test ones [15:47] that's fine imo [15:47] b/c that api server might be balanced, proxied, etc etc [15:48] external perhaps over time [15:48] m_3: btw i tried setting up a slave jenkins and charm runner ( running on OpenShift machines ) but could never get it to quite kick off fully automatic [15:49] might bug ya about that sometimes $soon [15:51] imbrandon: hmmm [15:52] imbrandon: sure.. lemme see if I can get a standalone slave hooked up to an external master here [15:52] its at ci-bluecluster.rhcloud.com:8080 , 3 node jenkins setup just for this … but i got it offline for the moment ( was working on some update to WordPress on my own site this morning ) [15:52] i can give you full root to them in a few , if it helps [15:53] its one master and 2 builders + can run smallish jobs on the master [15:55] imbrandon: ack [15:55] no need atm... I'm gonna run to shower before dinner [15:56] got a set of vCloud machines to play with too ( 6 i think ) unmeetered that i can use to add more builders if we can parallelize(sp?) it like that [15:56] np, yea i got things to finish up for the next few hours but i'll likely be doing that this evening local time [15:57] no if we only had a vCloud provider … :) [15:57] s/no/now [18:40] marcoceppi: can you unpromulgate alice-irc? it's dead upstream [18:49] hazmat: hey what's the ballpark time for jujujcharms.com to render an updated README? [18:49] jcastro, 30m max o u t [18:50] marcoceppi, there's another branch of charmrunner [18:50] with notion of building out juju versions for each test [18:50] marcoceppi, imbrandon, m_3 i think we need a mass change to charms to populate initial tests with rels [18:54] jcastro: unpromulgated [18:54] hazmat: which branch is that? [18:54] marcoceppi: ta [18:54] looking around for it [18:55] marcoceppi: also if you want to rename promulgate/unpromulgate to something more sane while SpamapS isn't looking ... [18:55] jcastro: duh, juju publish ;) [18:55] I was just looking for a way to mess with clint [18:59] marcoceppi, ~hazmat/charmrunner/wip [19:01] its got a little bit of cleanup, and some tests, but i realized that doing graph stuff at all is kinda of bogus long term, we should just seed some test scripts [19:01] digitalocean btw is awesome [19:01] hazmat: I'll take a look and merge the stuff I have done over the week [19:02] marcoceppi, what's your focus for it atm? [19:02] getting the server going? [19:03] hazmat: generating graph tests externally, making it a subordinate, streamlining and separating graph test from unit testing [19:04] giving more granular test statuses [19:04] marcoceppi, there's a useful script in the branch for fetching all the charms into a nice directory structure that includes ownership (ie not a straight charm repo) [19:04] and mods to the planner to generate plans from that structure [19:05] cool [19:06] arg, just realized I've been talking about charm tester not charmrinnwr [19:07] your changes will be great for integrating with charm tester [19:18] ah.. makes more sense now [19:28] promulgate is the right word. Just because you guys don't want plain english.. ;) [19:28] SpamapS: jcastroI think we shouldmake it promulgar [19:29] Could just do "charm yo promulgo" [19:31] asi es mas internacional [20:31] hi guys, I just tried two charms from the charm store and both don't deploy, I guess it's my lucky day [20:31] https://bugs.launchpad.net/charms/+source/etherpad-lite/+bug/1166997 [20:31] <_mup_> Bug #1166997: etherpad-lite doesn't deploy < https://launchpad.net/bugs/1166997 > [20:31] https://bugs.launchpad.net/charms/+source/subway/+bug/1166989 [20:31] <_mup_> Bug #1166989: Subway charm doesn't deploy on precise < https://launchpad.net/bugs/1166989 > [20:31] I tried on lxc, but the error is unrelated === gary_poster is now known as gary_poster|away [20:34] hm, I may have messed up, default-series is precise in my environments.yaml file, but I'm running quantal [20:36] sidnei, re canaries and upgrade.. alternatives environment snapshots === gary_poster|away is now known as gary_poster === markramm is now known as mramm_ [21:39] is it possible to set values of keys defined in the config.xml during a hook execution? I know how to get the values just not sure how to set them. [21:40] paraglade: You can't change the charm's configuration (or at least the values of a config-get) from within the charm itself [21:46] hmm ok. marcoceppi so I am trying to build a zabbix charm, the agent (a subordinate service) can be setup to "talk" to a server via a config set or with a relationship to a server or proxy. I am kinda struggling on trying to implement this. I looked at other charms but nothing really seems to model this setup exactly. [21:47] paraglade: Zabbix! Very exciting. What it sounds like you're tying to do is get the "master" server which can either be a relation or a configuration value, correct? [21:48] yes thats correct [21:50] Cool, there are a few ways to tackle this. You'll have to forgive me, I ususally use Nagios so I'm not sure the inner-workings of Zabbix, but if you can only designate one "master" then I would just choose a pecking order of which is more important. User defined configuration or relation data. [21:51] In my opinion configuration data takes precendence over relation data. So I would have the relation hook check if the configuration value exists. If it doesn't then use the data from the relation, otherwise just exit silently. [21:52] It gets a bit more complicated if you can have multiple "master" monitoring services. In that case I would create a file in the charms root that gets updated by the hooks respectively. So it would just add or subtract values depending on if configuration was changed or if a relation was changed [21:55] ok thanks. I think the configuration over relation data will actually work well with this charm(s). [21:56] paraglade: As long as you clearly document that in the README (and unless someone else corrects me) that should be sufficient [22:11] marcoceppi: if you don’t mind I think I have another question that maybe you can give some wisdom on. I was thinking when a *-relation-changed *-relation-join event fired I would just call config-changed hook in those event hook scripts. The idea is that I would only need to create the config implation in one script file. However it seems that I am able to get the relation data just the config data [22:11] when I do this. [22:11] any suggestions on a [22:11] clean way to handle this? [22:13] That sounds like a great idea! I know a few charms that do this already. The problem with relation data is the environment variables that exist in order for the relation-get to work are only loaded when the relation is actioned upon. So you can't just call relation-get in any other hooks without supplying which _exact_ relation you're referring to. This gets messy when trying to track what relation_id goes where. What I usually recommend is to [22:13] just persist relation data to files and have other hooks look in those files for their respective values [22:13] Here's a small example: [22:14] https://gist.github.com/marcoceppi/5349842 [22:14] In this case you can just replace update_configuration with executing hooks/config-changed [22:19] Does my charm need both a relation-changed and relation-joined hook? | http://askubuntu.com/q/279706 [22:27] marcoceppi: these are cool snippets, I'd hate to lose them.. are they documented anywhere else? or implemented anywhere? :) [22:28] sarnold: I was actually self documenting paraglade's question on to Ask Ubuntu to help keep them alive [22:28] Hopefully help fill up Google's juju/charming questions with better information [22:28] marcoceppi: oh! excellent :)