| === 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 | ||
| jcastro | mramm: is there a release of core between now and 13.04? | 14:37 |
|---|---|---|
| mramm2 | yes | 14:38 |
| mramm2 | later this week I expect another one | 14:38 |
| mramm2 | and possibly one early next week | 14:38 |
| m_3 | jcastro: jokes go here | 14:56 |
| 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:57 |
| m_3 | ack | 14:58 |
| jcastro | to go along with newdocs and better juju AU questions | 14:58 |
| m_3 | marcoceppi: jenkins-slave w/ juju sub works great | 14:59 |
| 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:00 |
| 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:01 |
| robbiew | lol | 15:06 |
| === defunctzombie_zz is now known as defunctzombie | ||
| 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:17 |
| 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:18 |
| m_3 | just won't be as lightweight as we discussed before | 15:19 |
| === salgado is now known as salgado-lunch | ||
| m_3 | but hey, it's juju | 15:19 |
| m_3 | so that doesnt' really matter as much | 15:19 |
| 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:21 |
| m_3 | anyways, I'll run that by ben | 15:22 |
| === salgado-lunch is now known as salgado | ||
| 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:38 |
| === defunctzombie is now known as defunctzombie_zz | ||
| jcastro | https://juju.ubuntu.com/community/weekly-charm-meeting/ | 15:44 |
| jcastro | thoughts? | 15:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| imbrandon | might bug ya about that sometimes $soon | 15:49 |
| m_3 | imbrandon: hmmm | 15:51 |
| 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:52 |
| imbrandon | its one master and 2 builders + can run smallish jobs on the master | 15:53 |
| m_3 | imbrandon: ack | 15:55 |
| m_3 | no need atm... I'm gonna run to shower before dinner | 15:55 |
| 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:56 |
| imbrandon | no if we only had a vCloud provider … :) | 15:57 |
| imbrandon | s/no/now | 15:57 |
| jcastro | marcoceppi: can you unpromulgate alice-irc? it's dead upstream | 18:40 |
| 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:49 |
| 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:50 |
| marcoceppi | jcastro: unpromulgated | 18:54 |
| marcoceppi | hazmat: which branch is that? | 18:54 |
| jcastro | marcoceppi: ta | 18:54 |
| hazmat | looking around for it | 18:54 |
| 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:55 |
| hazmat | marcoceppi, ~hazmat/charmrunner/wip | 18:59 |
| 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:01 |
| hazmat | marcoceppi, what's your focus for it atm? | 19:02 |
| hazmat | getting the server going? | 19:02 |
| marcoceppi | hazmat: generating graph tests externally, making it a subordinate, streamlining and separating graph test from unit testing | 19:03 |
| 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:04 |
| hazmat | cool | 19:05 |
| marcoceppi | arg, just realized I've been talking about charm tester not charmrinnwr | 19:06 |
| marcoceppi | your changes will be great for integrating with charm tester | 19:07 |
| hazmat | ah.. makes more sense now | 19:18 |
| 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:28 |
| marcoceppi | Could just do "charm yo promulgo" | 19:29 |
| SpamapS | asi es mas internacional | 19: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:31 |
| === gary_poster is now known as gary_poster|away | ||
| ahasenack | hm, I may have messed up, default-series is precise in my environments.yaml file, but I'm running quantal | 20:34 |
| hazmat | sidnei, re canaries and upgrade.. alternatives environment snapshots | 20:36 |
| === gary_poster|away is now known as gary_poster | ||
| === markramm is now known as mramm_ | ||
| 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:39 |
| 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:40 |
| 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:46 |
| 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:47 |
| paraglade | yes thats correct | 21:48 |
| 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:50 |
| 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:51 |
| 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:52 |
| paraglade | ok thanks. I think the configuration over relation data will actually work well with this charm(s). | 21:55 |
| marcoceppi | paraglade: As long as you clearly document that in the README (and unless someone else corrects me) that should be sufficient | 21:56 |
| 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:11 |
| 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:13 |
| 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:14 |
| AskUbuntu | Does my charm need both a relation-changed and relation-joined hook? | http://askubuntu.com/q/279706 | 22:19 |
| sarnold | marcoceppi: these are cool snippets, I'd hate to lose them.. are they documented anywhere else? or implemented anywhere? :) | 22:27 |
| 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 :) | 22:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!