[14:37] <jcastro> mramm: is there a release of core between now and 13.04?
[14:38] <mramm2> yes
[14:38] <mramm2> later this week I expect another one
[14:38] <mramm2> and possibly one early next week
[14:56] <m_3> jcastro: jokes go here
[14:57] <jcastro> hey so
[14:57] <jcastro> I panged bruno and patrick to clean up the django readme
[14:57] <jcastro> since it's like a template right now
[14:57] <jcastro> I was thinking for release week we'd have 2 big blog posts
[14:57] <jcastro> one for core
[14:57] <jcastro> one for charms
[14:58] <m_3> ack
[14:58] <jcastro> to go along with newdocs and better juju AU questions
[14:59] <m_3> marcoceppi: jenkins-slave w/ juju sub works great
[15:00] <marcoceppi> excellent
[15:00] <m_3> I'll just now see what direction for the external relation makes sense
[15:00] <m_3> i.e., config on the slave or the master
[15:00] <m_3> prolly elastic-ip on the slave and then config the master
[15:00] <m_3> frickin cool
[15:01] <jcastro> don't forget to post your thoughts on rick's metadata thing on the list fellas
[15:01] <m_3> the list is so boring
[15:01] <jcastro> Deal with It(tm) :)
[15:01] <m_3> :)
[15:01] <marcoceppi> B)
[15:06] <robbiew> lol
[15:17] <m_3> marcoceppi: damn... the auth model for jenkins-master/slave really requires them to be local
[15:17] <m_3> at least as far as I can see
[15:17] <m_3> :(
[15:17] <marcoceppi> m_3: You mean local:charm or master slave on the same machine?
[15:17] <m_3> marcoceppi: same subnet / juju environment
[15:18] <marcoceppi> Ugh, what?
[15:18] <marcoceppi> that's pretty lame
[15:18] <m_3> yeah
[15:18] <m_3> well at least the way the charm's written now
[15:18] <m_3> can maybe front it with apache2 configured for auth'd reverse-proxy
[15:18] <m_3> actually, nm... that would probably work
[15:19] <m_3> just won't be as lightweight as we discussed before
[15:19] <m_3> but hey, it's juju
[15:19] <m_3> so that doesnt' really matter as much
[15:21] <m_3> 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] <m_3> anyways, I'll run that by ben
[15:38] <marcoceppi> 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] <marcoceppi> But during graph testing it'll fail, because not just any http interface will do
[15:38] <marcoceppi> Should this become it's own interface name even though it's basically just a port + http address?
[15:44] <jcastro> https://juju.ubuntu.com/community/weekly-charm-meeting/
[15:44] <jcastro> thoughts?
[15:45] <m_3> sure man
[15:45] <marcoceppi> +1
[15:45] <imbrandon> marcoceppi: touch call, but i would say yea
[15:45] <m_3> maybe we can visit charm quality and audits across the store
[15:45] <imbrandon> because like port 80 a lot of services run on it
[15:45] <imbrandon> that are considered diff
[15:46] <marcoceppi> imbrandon:  true, the interface defines the service, not so much the protocol which the service is using
[15:46] <m_3> marcoceppi: I'd say leave it http... then it can be wired behind proxies and the like
[15:46] <imbrandon> right, i mean its a fine line, but thats how i would see it
[15:46] <m_3> the fact that it's an api is just like saying it's special because of its content
[15:47] <imbrandon> hrm good point … hum
[15:47] <m_3> we'll need to exclude relations from some automated testing... jsut make sure they're caught in $CHARM_DIR/tests
[15:47] <marcoceppi> m_3: What I'm worried about is on the flipside, the charm requires: api: http
[15:47] <marcoceppi> m_3: gotchya, I think http is one of those too broad to test ones
[15:47] <m_3> that's fine imo
[15:47] <m_3> b/c that api server might be balanced, proxied, etc etc
[15:48] <m_3> external perhaps over time
[15:48] <imbrandon> 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] <imbrandon> might bug ya about that sometimes $soon
[15:51] <m_3> imbrandon: hmmm
[15:52] <m_3> imbrandon: sure.. lemme see if I can get a standalone slave hooked up to an external master here
[15:52] <imbrandon> 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] <imbrandon> i can give you full root to them in a few , if it helps
[15:53] <imbrandon> its one master and 2 builders + can run smallish jobs on the master
[15:55] <m_3> imbrandon: ack
[15:55] <m_3> no need atm... I'm gonna run to shower before dinner
[15:56] <imbrandon> 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] <imbrandon> 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] <imbrandon> no if we only had a vCloud provider … :)
[15:57] <imbrandon> s/no/now
[18:40] <jcastro> marcoceppi: can you unpromulgate alice-irc? it's dead upstream
[18:49] <jcastro> hazmat: hey what's the ballpark time for jujujcharms.com to render an updated README?
[18:49] <hazmat> jcastro, 30m max o u t
[18:50] <hazmat> marcoceppi, there's another branch of charmrunner
[18:50] <hazmat> with notion of  building out juju versions for each test
[18:50] <hazmat> marcoceppi, imbrandon, m_3 i think we need a mass change to charms to populate initial tests with rels
[18:54] <marcoceppi> jcastro: unpromulgated
[18:54] <marcoceppi> hazmat: which branch is that?
[18:54] <jcastro> marcoceppi: ta
[18:54] <hazmat> looking around for it
[18:55] <jcastro> marcoceppi: also if you want to rename promulgate/unpromulgate to something more sane while SpamapS isn't looking ...
[18:55] <marcoceppi> jcastro: duh, juju publish ;)
[18:55] <jcastro> I was just looking for a way to mess with clint
[18:59] <hazmat> marcoceppi, ~hazmat/charmrunner/wip
[19:01] <hazmat> 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] <hazmat> digitalocean btw is awesome
[19:01] <marcoceppi> hazmat: I'll take a look and merge the stuff I have done over the week
[19:02] <hazmat> marcoceppi, what's your focus for it atm?
[19:02] <hazmat> getting the server going?
[19:03] <marcoceppi> hazmat: generating graph tests externally, making it a subordinate, streamlining and separating graph test from unit testing
[19:04] <marcoceppi> giving more granular test statuses
[19:04] <hazmat> 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] <hazmat> and mods to the planner to generate plans from that structure
[19:05] <hazmat> cool
[19:06] <marcoceppi> arg, just realized I've been talking about charm tester not charmrinnwr
[19:07] <marcoceppi> your changes will be great for integrating with charm tester
[19:18] <hazmat> ah.. makes more sense now
[19:28] <SpamapS> promulgate is the right word. Just because you guys don't want plain english.. ;)
[19:28] <marcoceppi> SpamapS: jcastroI think we shouldmake it promulgar
[19:29] <marcoceppi> Could just do "charm yo promulgo"
[19:31] <SpamapS> asi es mas internacional
[20:31] <ahasenack> 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] <ahasenack> https://bugs.launchpad.net/charms/+source/etherpad-lite/+bug/1166997
[20:31] <_mup_> Bug #1166997: etherpad-lite doesn't deploy <etherpad-lite (Juju Charms Collection):New> < https://launchpad.net/bugs/1166997 >
[20:31] <ahasenack> https://bugs.launchpad.net/charms/+source/subway/+bug/1166989
[20:31] <_mup_> Bug #1166989: Subway charm doesn't deploy on precise <subway (Juju Charms Collection):New> < https://launchpad.net/bugs/1166989 >
[20:31] <ahasenack> I tried on lxc, but the error is unrelated
[20:34] <ahasenack> hm, I may have messed up, default-series is precise in my environments.yaml file, but I'm running quantal
[20:36] <hazmat> sidnei, re canaries and upgrade.. alternatives environment snapshots
[21:39] <paraglade> 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] <marcoceppi> 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] <paraglade> 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] <marcoceppi> 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] <paraglade> yes thats correct
[21:50] <marcoceppi> 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] <marcoceppi> 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] <marcoceppi> 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] <paraglade> ok thanks.  I think the configuration over relation data will actually work well with this charm(s).
[21:56] <marcoceppi> paraglade: As long as you clearly document that in the README (and unless someone else corrects me) that should be sufficient
[22:11] <paraglade> 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] <paraglade> when I do this.
[22:11] <paraglade> any suggestions on a
[22:11] <paraglade> clean way to handle this?
[22:13] <marcoceppi> 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] <marcoceppi> just persist relation data to files and have other hooks look in those files for their respective values
[22:13] <marcoceppi> Here's a small example:
[22:14] <marcoceppi> https://gist.github.com/marcoceppi/5349842
[22:14] <marcoceppi> In this case you can just replace update_configuration with executing hooks/config-changed
[22:19] <AskUbuntu> Does my charm need both a relation-changed and relation-joined hook? | http://askubuntu.com/q/279706
[22:27] <sarnold> marcoceppi: these are cool snippets, I'd hate to lose them.. are they documented anywhere else? or implemented anywhere? :)
[22:28] <marcoceppi> sarnold: I was actually self documenting paraglade's question on to Ask Ubuntu to help keep them alive
[22:28] <marcoceppi> Hopefully help fill up Google's juju/charming questions with better information
[22:28] <sarnold> marcoceppi: oh! excellent :)