[03:25] SpamapS, knock, knock [03:25] SpamapS, re debug hooks, wtf [03:26] * hazmat has been doing travel and presentations [03:26] SpamapS, can give you me a recipe to reproduce [03:26] debug hooks only effects a single unit [03:27] and if your disconnected when the hooks are enabled, the user still need to connect back to end the session [04:14] hazmat: yes I have a recipe, been working on it [04:17] hazmat: juju deploy wordpress ; juju deploy mysql ; juju debug-hooks mysql/0 ; juju add-relation wordpress mysql ; [manually do all the hooks then disconnect] ; juju remove-relation wordpress mysql ; juju add-relation wordpress mysql [04:17] hazmat: when I did it, mysql/0 no longer fired joined/changed hooks (broken still went) [04:17] but I may have the steps wrong [04:17] I'm in the middle of something else entirely === zyga-afk is now known as zyga === fenris is now known as Guest73296 === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === zyga is now known as zyga-food === zyga-food is now known as zyga === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [15:49] * SpamapS is *so* close with nagios+nrpe+generic interface === jimbaker` is now known as jimbaker [15:58] <_mup_> Bug #1024447 was filed: Local provider should provide options for bind mounting as a charm delivery method < https://launchpad.net/bugs/1024447 > [16:09] 'morning all [16:10] heya negronjl [16:11] imbrandon: o/ [16:12] imbrandon, thanks btw for pushing that out :-) [16:12] * imbrandon hoped you would not be mad ... [16:13] imbrandon, i'm hoping that will be enough of a push that i can push the code out for jujucharms.com, and i needed the knudge myself to start that process [16:13] imbrandon, not mad at all [16:13] happy even [16:13] sweet :) [16:14] yea i actually set it up so that even though yours is python and this is php that the mongo select logic and the views *might* be able to be shared [16:15] set based design ftw [16:15] imbrandon, i'm doubtful of that, but maybe, the mongo structure for jujucharms predates charmload stuff [16:15] ahh [16:16] they happen to match up though in db and collection names [16:17] heh yea , they are pretty generic "juju" and "charms" [16:17] collisoins are sure to ahppen [16:18] the views are just like django templates tho, like litrally [16:18] http://bazaar.launchpad.net/~imbrandon/jujube/trunk/view/head:/includes/templates/base.html [16:18] http://bazaar.launchpad.net/~imbrandon/jujube/trunk/view/head:/includes/templates/index.html [16:18] imbrandon, that's cool, but fwiw jujucharms.com isn't django based, its pyramid based and uses chameleon/zopepagetemplates. [16:19] ahhh, never seen those :) [16:19] might have to check into them later [16:19] imbrandon, its a slightly different template style that emphasizes valid html for templates [16:19] yea these are "Twig" templates, i love em [16:19] ah.. i was wondering [16:20] Twig for the templates and Slim for the routing [16:20] everything else is home grown [16:21] well and bootstrap for the css :) [16:21] hazmat: hello! [16:22] jcastro: yo so nathwill did two charms and I guess didnt get a mug/shirt because it was during UDS? is that still going? he live here in pdx and hopes to meet ya at OSCON [16:22] bgupta, greetings [16:23] SO was gonn aplay on my mac (I know). and saw the instructions require brew, but I use macports. Are there install instructions somewhere that don't require brew? [16:23] bgupta, how late did you guys stay at the bar? [16:23] bgupta: yup [16:23] bgupta: yup one sec, just not got them put up yet, give me a moment [16:24] hazmat: pretty late.. guessing 11:30ish.. [16:24] bgupta: https://github.com/downloads/jujutools/jujutools.github.com/Install%20juju.zip [16:25] that should give you http://cl.ly/Htjg [16:25] bgupta, its pretty much straightforward to just use virtualenv, once you get python-zookeeper installed.... outside of that its just twisted, yaml, txaws, and bzr branch lp:juju && python setup.py develop [16:25] bgupta: the only pre-req is XCode ( gcc ) [16:26] hazmat: there is a static zkpython module i use on the mac , makes it MUCH easier [16:26] specially since ZK really isnt needed on the client for mac ( no lxc ) [16:26] imbrandon, yeah.. zc-static-zookeeper does the magic [16:26] yup yup [16:26] the mozilla services folks are maintaining it [16:26] bgupta: https://github.com/downloads/jujutools/jujutools.github.com/Install%20juju.zip [16:26] doh [16:27] new release of jitsu otw now... lemme know if there's anything else pending [16:27] m_3, thanks.. that should help folks asking about deploy-to/import/export [16:28] * imbrandon waves to m_3 [16:28] yea i havent got to try any of that yet, /me should do that today [16:28] i'm way way behind on my jitsu foo [16:29] I think I might be more excited about import/export.. some cool ramifications there [16:29] but we'll see [16:29] * m_3 waves back [16:34] m_3, imbrandon i think it would be nice if import could also bootstrap the new env if its not already bootstrapped, atm it requires the new env to already be running/bootstrapped. [16:35] hazmat: agree [16:35] but even then its nice to be able to jitsu export -e dev | jitsu import -e stage [16:35] yup... that's the magic sauce [16:36] I'll be trying out variations of that this weekend [16:38] ohhh yea [16:38] good call [16:38] m_3, hazmat: ... and both of those features sailed through the review process with absolutely no drama either :) [16:38] unhuh [16:38] well it is jitsu [16:38] :) [16:39] what review process? ;) [16:39] heh [16:40] hey... very careful review process... "Is it cool?" "Is it twisted?" [16:40] bgupta: feedback on that installer is more than welcomed too, only about 2 oth ppl have used it so far [16:40] i havent really "announced" it yet [16:40] :) [16:44] sure.. [16:44] oh and i have NO idea if it work on 10.5 or lower, i only tested on 10.6 .7 and .8 [16:44] fyi [16:44] first feedback is that it "seems" to install in the same directory structure that Macports uses [16:45] it should use the system dirs, as it realy only runs "sudo python setup.py install" once it verifies prereqs [16:45] you can see the exact commands its running after words in /tmp/juju-installer.sh [16:46] or similar ( sorry not on OSX atm to check ) [16:46] but the meat of it is just a gui on that shell script [16:50] but yea if you have python from macports or fink etc it will use those etc [16:56] mmmm .... XCode 4.4 GM Seed is on the Apple Developer downloads now , that means OS X 10.8 GM Seed is also there somewhere burried , and that means only a few days Until 10.8 is officialy released [17:04] imbrandon: mmm.. thinking that we should add to macports repo, for macports user. (It's picking up easy_install from system python, but then using macports python for the actual juju install [17:05] bgupta: sure, but that means your PYTHONPATH or python in general is not setup corectly on your system [17:05] m_3, looks like the upload failed.. https://launchpadlibrarian.net/110044309/upload_3949379_log.txt [17:06] bgupta: as its using whats in the $PATH and python and easy_install should both be from the same python install in the $PATH or you have lots of small errors [17:06] probably not. Python isn't a language I work in and is probably only pulled in macports wise to satisfy deps for other macports packages [17:07] bgupta: ahh yea after you install python from macports or fink or brew you need to do some $PATH magic manually that is normally only in the Readme burried [17:07] in /etc/profile , to make everything happy [17:07] hazmat: yeah, I'm trying to figure out what happened [17:08] bgupta: short awnser for the moment to fix you up is ... [17:08] bgupta: edit the /tmp/juju-installer.sh by hand and where it calls easy_install , make it use the full path for the one you want /opt/bin/... etc [17:09] that will fix you up for now, but i would look into fixing your python correctly for the long run [17:09] oh once you edit the shell script , run the shell script, as if you run the GUI again it will overite it [17:10] heh [17:10] but really a macport formula would just be the contents of that file as well :) [17:11] * imbrandon stoped using macports about 2 years ago when it stoped getting updated tho [17:14] hazmat: I think it's good... looks like there were two builds triggered in a row. first passed, second failed. the ppa appears to have it [17:14] m_3, cool, thanks again for taking care of that [17:15] SpamapS: any clue why the uploaders are different in juju-jitsu on https://launchpad.net/~juju/+archive/pkgs?field.series_filter= [17:16] once kicked off by recipy and one manually ? [17:18] hazmat: btw http://jujube.websitedevops.com/raw <-- the charmload schema [17:20] imbrandon, yeah.. i check it out, its pretty similiar [17:20] cool cool [17:23] m_3: the uploader is the owner of the recipe in most cases [17:23] m_3: so perhaps you accidentlaly tok over the recipe? [17:24] SpamapS: but it's different between series in the same build request [17:25] recipe ownership still looks like juju-hackers [17:26] afaict it looks like it built twice, the first passed for all (O,P,Q) but failed the second time (unsurprisingly b/c of orig tarballs) [17:28] ahh [17:28] yeah I just saw the failed ot upload [17:28] m_3: not sure, but I don't sense any disturbance in the force.. ok I think you are [17:28] I must've kicked it off twice accidentally [17:29] yeah, it looks like the ppa is good (tested it for precise) === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado [19:22] so we don't really know what we're doing, but we are trying to set up openstack using juju, and the nova-volume charm seems to be missing (the juju charms page agrees). so, um, what does that mean, and should we expect it to come back? [19:27] sn_bsg: I'm not sure what's going on there... the charmstore seems to not be happy with that one. I'd recommend grabbing it directly from http://jujucharms.com/charms/precise/nova-volume (or https://bazaar.launchpad.net/~charmers/charms/precise/nova-volume/trunk/files) [19:28] sn_bsg: your deploy for that one will need to change to specify a local repository... i.e., `juju deploy --repository ~/charms local:nova-volume` [19:29] (assumes it's in ~/charms/precise/nova-volume) [20:18] imbrandon: does Jujube have an API endpoint for the charm data? [22:01] Who's reviewing today ? [22:04] negronjl: not sure but I'm looking at your haproxy MP [22:04] SpamapS: nice ... [22:04] SpamapS: let me know what we broke :) [22:05] negronjl: next official reviewer is m_3 next Tuesday [22:05] but I bet he'll be busy w/ oscon stuff [22:05] SpamapS: I was hoping for a charitable soul to review the haproxy MP :) [22:05] negronjl: lots of new knobs :) [22:05] I don't think it would be appropriate for me to review my own code :D [22:06] negronjl: not sure I see the value of setting the user/group [22:06] SpamapS: But it is also backwards compatible [22:06] SpamapS: All the switches are there to satisfy ( among other things ) Canonical/IS [22:06] SpamapS: Trying to make it so they can use it [22:07] SpamapS: plus, I figured since, I am making so many switches ... mind as well go switch crazy :) [22:07] ah [22:07] I like most of the others [22:08] very glad you have monitoring ability [22:08] thats huge [22:08] to be able to toggle it on/off [22:09] ...and with ssh proxy, you can monitor the thing ( it also creates a random password if you leave it as changeme ) [22:09] I'm a little puzzled by services [22:09] it's a bit overwhelming but, the thing on it is the ability to create multiple services [22:09] ie: my_service:80 my_other_service:443 [22:10] I take that argument as a string and then parse ( in code ) as yaml.... [22:10] that gives me a list of services [22:10] but how do you then assign backends to those? [22:11] negronjl: the python in hooks.py reads really nicely btw [22:11] SpamapS: thx ... PITA to make it PEP8 compliant [22:12] I'm about to unleash some nagios stuff that I think will horrify people with its pythonic insanity [22:12] too bad pylint still thinks it's crap though ... lol [22:12] tempted to rewrite a lot of it for a *third* time just so its readable [22:13] oooh...nagios ... was thinking that we could use a nagios sub for this haproxy thing [22:13] negronjl: a lot of this would be really handy as charm helpers btw [22:13] SpamapS: working on a python charm helpers already too :) [22:13] negronjl: nagios sub? [22:13] SpamapS: I thought so too [22:13] negronjl: note that there are already some python charm helpers in progress [22:13] SpamapS: nagios subordinate to attach to haproxy so it can be monitored [22:13] stalled on my insistance that they package their python modules :) [22:14] SpamapS: Who's working on them [22:14] negronjl: I have an NRPE sub right now [22:14] negronjl: and I'm developing a generic monitoring interface so charms can just declare the things they want monitored [22:14] SpamapS: re: NRPE cool ... I'll check it out ... re: python charm helper .. who's working on that .. woudl like to contribute [22:14] SpamapS: nice [22:15] negronjl: yellow squad did it I think [22:15] SpamapS: I'll wait for that before doing any monitoring thing [22:15] SpamapS: ok...thx [22:15] SpamapS: wrote thos "covenience" functions with the intention of putting them in a helper somewhere [22:15] s/thos/those [22:17] SpamapS: the services option in config.yaml could be used like this: http://pastebin.ubuntu.com/1090650/ [22:17] negronjl: honestly, the ones you have here are great.. I think they may have abstracted too much [22:18] SpamapS: The idea on that was to not to have much code duplication so if ( or when ) I had to change logic, I wouldn't have to change it in multiple places. [22:18] SpamapS: It just makes things easier for me ... [22:19] SpamapS: plus ... it's easier for my simple brain to deal with smaller chunks of code :) [22:20] https://code.launchpad.net/~gmb/charm-tools/add-charm-helpers/+merge/96204 [22:21] negronjl: the issue is that they made shelltoolbox its own thing.. and I think it would be better to just get rid of that and call subprocess directly in private methods [22:21] because I keep failing to find the time to package shelltoolbox [22:22] negronjl: these are actually different entirely.. so they'd mesh well with your stuff [22:24] SpamapS: I just read the code ... interesting ... I'll see about using that in the future and providing some of my functions as well [22:25] negronjl: hrm.. this service_name thing.. Hrm.. [22:26] SpamapS: err... which one ? [22:26] negronjl: the thing you added to http as an optional field [22:26] I think thats abusing the interface a bit [22:26] SpamapS: Are you in the hook or config.yaml ? [22:27] negronjl: hooks.py [22:27] SpamapS: checking [22:27] negronjl: I get now how services works.. [22:27] and why its done that way [22:27] just not sure if I like how thats being used [22:27] I'd rather see services created dynamically [22:28] perhaps there's a reason you don't want to do that? [22:28] well ... [22:28] the services are being created dynamically [22:29] the service bits ( the listen stanza ) for each service is written as a separate chunk as there is no way for config-changed to know about the relation information [22:29] well thats not entirely true. :) [22:29] so, to work around that, I have the services being written to disk and the read ( from config-changed ) [22:30] config-changed can be deferred until relations are established [22:30] in config-changed, i was getting a trace about not having relation information [22:30] or rather, relation data is always available [22:30] did you not use 'relation-ids' ? [22:30] thats the key [22:30] its new.. [22:30] but its really powerful [22:31] didn't use relation-id .. [22:31] I guess I'm outdated ... tell me how relation-id would have helped ? [22:32] you can access relation info from any hook [22:32] as long as you pass in the relation id [22:32] there is no relation information on first run of config-changed [22:32] right [22:32] so in that case, you just exit 0 [22:33] then after each relation hook, you run it again [22:33] I'm doing something somewhat similar.... [22:33] I wrapped it around try/except [22:33] and pass [22:33] .... and then move it along [22:33] yeah I think I see how that works [22:34] this is sort of the old way, but its quite reliable. You're just writing what you have to disk, and then generating configs from that [22:34] I'm not questioning that.. but rather why the 'services' thing is needed [22:35] SpamapS: do you mean why we're specifying it in the config.yaml rather than on the command line to add new services as needed? [22:35] negronjl: what I'm trying to understand (please bear with me my head is pounding from lack of caffeine.. ) is why you can't just generate a service that isn't around... [22:36] hooks.py line 457 [22:36] SpamapS: checking [22:36] also I wouldn't call it service_name [22:36] but 'http_host' [22:36] or 'endpoint_host' [22:36] and I would generate a service per unique endpoint_host [22:36] but maybe you have a good reason not to do that [22:37] SpamapS: service_name is different than the host-name [22:37] SpamapS: service_name is just an arbitrary name [22:37] SpamapS: listen : [22:37] SpamapS: just making sure we are talking about the same thing [22:38] right, I'm saying that it should be on the *backends* not defined by the config.yaml option [22:38] SpamapS: If I do it on the backends ( which was our initial thought ) I would brake backwards compatibility with the existing haproxy and that would be bad [22:39] SpamapS: also, having control of what services are managed in the service is something that seems to be valuable [22:39] like, 'juju deploy wordpress --constraints='mem=500M' wpskinny ; juju deploy wordpress --constraints='mem=2G' wpfat ; juju set wpskinny endpoint-host='www.mywebsite.com' ; juju set wpfat endpoint-host='www.mywebsite.com' [22:40] Then any load balancer that I relate those two services to will listen on www.mywebsite.com [22:40] Now, if I leave it off.. we can talk about ways to split those out... [22:40] negronjl: it can stay optional can't it? [22:40] negronjl: like if its not provided it just goes in the "default" server [22:41] negronjl: I guess my point is that service_name seems a bit arbitrary [22:41] SpamapS: give me a sec... let me catch up :) [22:41] SpamapS: ok ... re:service_name it is arbitrary [22:41] SpamapS: the service_host could be specified or "deduced" [22:42] SpamapS: sorry, how is it arbitrary? you're using that as a way of grouping a service, and then the backend just has to specify which service_name it wants to connect to [22:42] I don't like arbitrary in this case because it means now every loadbalancer charm has to map it. Hostname is more natural... don't you think? [22:42] SpamapS: the service ( read listen stanza ) parameters are something that seems to be good to know before deployment [22:42] I'm just wondering if there's ever a time when that is not the desired listen hostname [22:42] I actually have to run in a minute [22:43] SpamapS: ok ... [22:43] SpamapS: service_name is arbitrary in the sense that it can be whatever service name you want ... [22:43] SpamapS: service_name is not being used as an endpoint .... [22:44] SpamapS: I do get the endpoint angle but, I haven't seen haproxy used in such a manner before so I didn't think of attaching a hostname to the service name [22:44] SpamapS: because it could collide [22:44] mthaddon: indeed, its a good concept. I'm just worried about using arbitrary things in the very generic "http" interface... lets consider the non loadbalancer case.. like, a security proxy... I haven't thought through what it would do or whether or not it would be useful [22:44] SpamapS: if you have www.mysite.com for both 80 and 443 [22:44] negronjl: haproxy can do "name based" virtual hosts in http mode [22:45] SpamapS: but, those would be specified in the options [22:45] SpamapS: which would also be different from the service_name [22:45] negronjl: I'm going to think a lot about this over the weekend, and I may even try to add it to something like mod_security or squid... just to see if it makes sense and doesn't cause problems to implement/not implement [22:45] yep, that's my understanding too [22:45] SpamapS: by having service_names decoupled from hostnames, we provide more flexibility . [22:45] yeah thats exactly what I'm worried about [22:46] SpamapS: ack ... it's a big and hairy change so, more time to play with it will be needed ... [22:46] flexibility means more things to break [22:46] negronjl: the rest of it thus far looks fantastic [22:46] anyway, I'm late.. ttyl [22:46] SpamapS: ... the only thing that could break with arbitrary service_names would be collissions on the services ( two services with the same names ) [22:46] SpamapS: ttyl .. [22:46] negronjl: oh, good point - I'm not sure we'd deal with that too well currently [22:47] we are kind of relying on people not to shoot themselves in the foot... I'm not sure how far we would want to go in protecting from that [22:47] mthaddon: service_name collisions ? [22:47] yeah [22:48] but we do do a config check and bail out if it fails, so that might guard against service_name collisions [22:48] mthaddon: we really can't do much about it....if you declare two services with the same name...the second entry will corrupt services_dict and bail [22:48] yep [22:49] mthaddon: or .. the second service will override the first [22:49] mthaddon: leaving you with just one service as opposed to the desired two [22:49] yeah, I think you're right - it'll just overwrite the first as we loop through creating the dict [22:50] mthaddon: yup ... when we read the services ( the yaml thing from config.yaml ), it comes as a list [22:50] mthaddon: once we parse that out to services_dict ... we'll override the first with the second [22:50] mthaddon: indeed bad things could happen ( all your servers in the same service ). [22:50] * mthaddon nods [23:05] have a good weekend all [23:06] o/