hazmat | SpamapS, knock, knock | 03:25 |
---|---|---|
hazmat | SpamapS, re debug hooks, wtf | 03:25 |
* hazmat has been doing travel and presentations | 03:26 | |
hazmat | SpamapS, can give you me a recipe to reproduce | 03:26 |
hazmat | debug hooks only effects a single unit | 03:26 |
hazmat | and if your disconnected when the hooks are enabled, the user still need to connect back to end the session | 03:27 |
SpamapS | hazmat: yes I have a recipe, been working on it | 04:14 |
SpamapS | 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 |
SpamapS | hazmat: when I did it, mysql/0 no longer fired joined/changed hooks (broken still went) | 04:17 |
SpamapS | but I may have the steps wrong | 04:17 |
SpamapS | I'm in the middle of something else entirely | 04:17 |
=== 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 | ||
* SpamapS is *so* close with nagios+nrpe+generic interface | 15:49 | |
=== jimbaker` is now known as jimbaker | ||
_mup_ | Bug #1024447 was filed: Local provider should provide options for bind mounting as a charm delivery method <juju:Confirmed> < https://launchpad.net/bugs/1024447 > | 15:58 |
negronjl | 'morning all | 16:09 |
imbrandon | heya negronjl | 16:10 |
negronjl | imbrandon: o/ | 16:11 |
hazmat | imbrandon, thanks btw for pushing that out :-) | 16:12 |
* imbrandon hoped you would not be mad ... | 16:12 | |
hazmat | 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 |
hazmat | imbrandon, not mad at all | 16:13 |
hazmat | happy even | 16:13 |
imbrandon | sweet :) | 16:13 |
imbrandon | 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:14 |
SpamapS | set based design ftw | 16:15 |
hazmat | imbrandon, i'm doubtful of that, but maybe, the mongo structure for jujucharms predates charmload stuff | 16:15 |
imbrandon | ahh | 16:15 |
hazmat | they happen to match up though in db and collection names | 16:16 |
imbrandon | heh yea , they are pretty generic "juju" and "charms" | 16:17 |
imbrandon | collisoins are sure to ahppen | 16:17 |
imbrandon | the views are just like django templates tho, like litrally | 16:18 |
imbrandon | http://bazaar.launchpad.net/~imbrandon/jujube/trunk/view/head:/includes/templates/base.html | 16:18 |
imbrandon | http://bazaar.launchpad.net/~imbrandon/jujube/trunk/view/head:/includes/templates/index.html | 16:18 |
hazmat | imbrandon, that's cool, but fwiw jujucharms.com isn't django based, its pyramid based and uses chameleon/zopepagetemplates. | 16:18 |
imbrandon | ahhh, never seen those :) | 16:19 |
imbrandon | might have to check into them later | 16:19 |
hazmat | imbrandon, its a slightly different template style that emphasizes valid html for templates | 16:19 |
imbrandon | yea these are "Twig" templates, i love em | 16:19 |
hazmat | ah.. i was wondering | 16:19 |
imbrandon | Twig for the templates and Slim for the routing | 16:20 |
imbrandon | everything else is home grown | 16:20 |
imbrandon | well and bootstrap for the css :) | 16:21 |
bgupta | hazmat: hello! | 16:21 |
bkerensa | 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 |
hazmat | bgupta, greetings | 16:22 |
bgupta | 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 |
hazmat | bgupta, how late did you guys stay at the bar? | 16:23 |
imbrandon | bgupta: yup | 16:23 |
imbrandon | bgupta: yup one sec, just not got them put up yet, give me a moment | 16:23 |
bgupta | hazmat: pretty late.. guessing 11:30ish.. | 16:24 |
imbrandon | bgupta: https://github.com/downloads/jujutools/jujutools.github.com/Install%20juju.zip | 16:24 |
imbrandon | that should give you http://cl.ly/Htjg | 16:25 |
hazmat | 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 |
imbrandon | bgupta: the only pre-req is XCode ( gcc ) | 16:25 |
imbrandon | hazmat: there is a static zkpython module i use on the mac , makes it MUCH easier | 16:26 |
imbrandon | specially since ZK really isnt needed on the client for mac ( no lxc ) | 16:26 |
hazmat | imbrandon, yeah.. zc-static-zookeeper does the magic | 16:26 |
imbrandon | yup yup | 16:26 |
hazmat | the mozilla services folks are maintaining it | 16:26 |
imbrandon | bgupta: https://github.com/downloads/jujutools/jujutools.github.com/Install%20juju.zip | 16:26 |
imbrandon | doh | 16:26 |
m_3 | new release of jitsu otw now... lemme know if there's anything else pending | 16:27 |
hazmat | m_3, thanks.. that should help folks asking about deploy-to/import/export | 16:27 |
* imbrandon waves to m_3 | 16:28 | |
imbrandon | yea i havent got to try any of that yet, /me should do that today | 16:28 |
imbrandon | i'm way way behind on my jitsu foo | 16:28 |
m_3 | I think I might be more excited about import/export.. some cool ramifications there | 16:29 |
m_3 | but we'll see | 16:29 |
* m_3 waves back | 16:29 | |
hazmat | 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:34 |
m_3 | hazmat: agree | 16:35 |
hazmat | but even then its nice to be able to jitsu export -e dev | jitsu import -e stage | 16:35 |
m_3 | yup... that's the magic sauce | 16:35 |
m_3 | I'll be trying out variations of that this weekend | 16:36 |
imbrandon | ohhh yea | 16:38 |
imbrandon | good call | 16:38 |
negronjl | m_3, hazmat: ... and both of those features sailed through the review process with absolutely no drama either :) | 16:38 |
m_3 | unhuh | 16:38 |
imbrandon | well it is jitsu | 16:38 |
imbrandon | :) | 16:38 |
SpamapS | what review process? ;) | 16:39 |
imbrandon | heh | 16:39 |
m_3 | hey... very careful review process... "Is it cool?" "Is it twisted?" | 16:40 |
imbrandon | bgupta: feedback on that installer is more than welcomed too, only about 2 oth ppl have used it so far | 16:40 |
imbrandon | i havent really "announced" it yet | 16:40 |
imbrandon | :) | 16:40 |
bgupta | sure.. | 16:44 |
imbrandon | 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 |
imbrandon | fyi | 16:44 |
bgupta | first feedback is that it "seems" to install in the same directory structure that Macports uses | 16:44 |
imbrandon | it should use the system dirs, as it realy only runs "sudo python setup.py install" once it verifies prereqs | 16:45 |
imbrandon | you can see the exact commands its running after words in /tmp/juju-installer.sh | 16:45 |
imbrandon | or similar ( sorry not on OSX atm to check ) | 16:46 |
imbrandon | but the meat of it is just a gui on that shell script | 16:46 |
imbrandon | but yea if you have python from macports or fink etc it will use those etc | 16:50 |
imbrandon | 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 | 16:56 |
bgupta | 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:04 |
imbrandon | bgupta: sure, but that means your PYTHONPATH or python in general is not setup corectly on your system | 17:05 |
hazmat | m_3, looks like the upload failed.. https://launchpadlibrarian.net/110044309/upload_3949379_log.txt | 17:05 |
imbrandon | 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 |
bgupta | 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:06 |
imbrandon | 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 |
imbrandon | in /etc/profile , to make everything happy | 17:07 |
m_3 | hazmat: yeah, I'm trying to figure out what happened | 17:07 |
imbrandon | bgupta: short awnser for the moment to fix you up is ... | 17:08 |
imbrandon | 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:08 |
imbrandon | that will fix you up for now, but i would look into fixing your python correctly for the long run | 17:09 |
imbrandon | oh once you edit the shell script , run the shell script, as if you run the GUI again it will overite it | 17:09 |
imbrandon | heh | 17:10 |
imbrandon | but really a macport formula would just be the contents of that file as well :) | 17:10 |
* imbrandon stoped using macports about 2 years ago when it stoped getting updated tho | 17:11 | |
m_3 | 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 |
hazmat | m_3, cool, thanks again for taking care of that | 17:14 |
m_3 | SpamapS: any clue why the uploaders are different in juju-jitsu on https://launchpad.net/~juju/+archive/pkgs?field.series_filter= | 17:15 |
imbrandon | once kicked off by recipy and one manually ? | 17:16 |
imbrandon | hazmat: btw http://jujube.websitedevops.com/raw <-- the charmload schema | 17:18 |
hazmat | imbrandon, yeah.. i check it out, its pretty similiar | 17:20 |
imbrandon | cool cool | 17:20 |
SpamapS | m_3: the uploader is the owner of the recipe in most cases | 17:23 |
SpamapS | m_3: so perhaps you accidentlaly tok over the recipe? | 17:23 |
m_3 | SpamapS: but it's different between series in the same build request | 17:24 |
m_3 | recipe ownership still looks like juju-hackers | 17:25 |
m_3 | 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:26 |
SpamapS | ahh | 17:28 |
SpamapS | yeah I just saw the failed ot upload | 17:28 |
SpamapS | m_3: not sure, but I don't sense any disturbance in the force.. ok I think you are | 17:28 |
m_3 | I must've kicked it off twice accidentally | 17:28 |
m_3 | yeah, it looks like the ppa is good (tested it for precise) | 17:29 |
=== salgado is now known as salgado-lunch | ||
=== salgado-lunch is now known as salgado | ||
sn_bsg | 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:22 |
m_3 | 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:27 |
m_3 | 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:28 |
m_3 | (assumes it's in ~/charms/precise/nova-volume) | 19:29 |
marcoceppi | imbrandon: does Jujube have an API endpoint for the charm data? | 20:18 |
negronjl | Who's reviewing today ? | 22:01 |
SpamapS | negronjl: not sure but I'm looking at your haproxy MP | 22:04 |
negronjl | SpamapS: nice ... | 22:04 |
negronjl | SpamapS: let me know what we broke :) | 22:04 |
SpamapS | negronjl: next official reviewer is m_3 next Tuesday | 22:05 |
SpamapS | but I bet he'll be busy w/ oscon stuff | 22:05 |
negronjl | SpamapS: I was hoping for a charitable soul to review the haproxy MP :) | 22:05 |
SpamapS | negronjl: lots of new knobs :) | 22:05 |
negronjl | I don't think it would be appropriate for me to review my own code :D | 22:05 |
SpamapS | negronjl: not sure I see the value of setting the user/group | 22:06 |
negronjl | SpamapS: But it is also backwards compatible | 22:06 |
negronjl | SpamapS: All the switches are there to satisfy ( among other things ) Canonical/IS | 22:06 |
negronjl | SpamapS: Trying to make it so they can use it | 22:06 |
negronjl | SpamapS: plus, I figured since, I am making so many switches ... mind as well go switch crazy :) | 22:07 |
SpamapS | ah | 22:07 |
SpamapS | I like most of the others | 22:07 |
SpamapS | very glad you have monitoring ability | 22:08 |
SpamapS | thats huge | 22:08 |
SpamapS | to be able to toggle it on/off | 22:08 |
negronjl | ...and with ssh proxy, you can monitor the thing ( it also creates a random password if you leave it as changeme ) | 22:09 |
SpamapS | I'm a little puzzled by services | 22:09 |
negronjl | it's a bit overwhelming but, the thing on it is the ability to create multiple services | 22:09 |
negronjl | ie: my_service:80 my_other_service:443 | 22:09 |
negronjl | I take that argument as a string and then parse ( in code ) as yaml.... | 22:10 |
negronjl | that gives me a list of services | 22:10 |
SpamapS | but how do you then assign backends to those? | 22:10 |
SpamapS | negronjl: the python in hooks.py reads really nicely btw | 22:11 |
negronjl | SpamapS: thx ... PITA to make it PEP8 compliant | 22:11 |
SpamapS | I'm about to unleash some nagios stuff that I think will horrify people with its pythonic insanity | 22:12 |
negronjl | too bad pylint still thinks it's crap though ... lol | 22:12 |
SpamapS | tempted to rewrite a lot of it for a *third* time just so its readable | 22:12 |
negronjl | oooh...nagios ... was thinking that we could use a nagios sub for this haproxy thing | 22:13 |
SpamapS | negronjl: a lot of this would be really handy as charm helpers btw | 22:13 |
negronjl | SpamapS: working on a python charm helpers already too :) | 22:13 |
SpamapS | negronjl: nagios sub? | 22:13 |
negronjl | SpamapS: I thought so too | 22:13 |
SpamapS | negronjl: note that there are already some python charm helpers in progress | 22:13 |
negronjl | SpamapS: nagios subordinate to attach to haproxy so it can be monitored | 22:13 |
SpamapS | stalled on my insistance that they package their python modules :) | 22:13 |
negronjl | SpamapS: Who's working on them | 22:14 |
SpamapS | negronjl: I have an NRPE sub right now | 22:14 |
SpamapS | negronjl: and I'm developing a generic monitoring interface so charms can just declare the things they want monitored | 22:14 |
negronjl | SpamapS: re: NRPE cool ... I'll check it out ... re: python charm helper .. who's working on that .. woudl like to contribute | 22:14 |
negronjl | SpamapS: nice | 22:14 |
SpamapS | negronjl: yellow squad did it I think | 22:15 |
negronjl | SpamapS: I'll wait for that before doing any monitoring thing | 22:15 |
negronjl | SpamapS: ok...thx | 22:15 |
negronjl | SpamapS: wrote thos "covenience" functions with the intention of putting them in a helper somewhere | 22:15 |
negronjl | s/thos/those | 22:15 |
negronjl | SpamapS: the services option in config.yaml could be used like this: http://pastebin.ubuntu.com/1090650/ | 22:17 |
SpamapS | negronjl: honestly, the ones you have here are great.. I think they may have abstracted too much | 22:17 |
negronjl | 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 |
negronjl | SpamapS: It just makes things easier for me ... | 22:18 |
negronjl | SpamapS: plus ... it's easier for my simple brain to deal with smaller chunks of code :) | 22:19 |
SpamapS | https://code.launchpad.net/~gmb/charm-tools/add-charm-helpers/+merge/96204 | 22:20 |
SpamapS | 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 |
SpamapS | because I keep failing to find the time to package shelltoolbox | 22:21 |
SpamapS | negronjl: these are actually different entirely.. so they'd mesh well with your stuff | 22:22 |
negronjl | 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:24 |
SpamapS | negronjl: hrm.. this service_name thing.. Hrm.. | 22:25 |
negronjl | SpamapS: err... which one ? | 22:26 |
SpamapS | negronjl: the thing you added to http as an optional field | 22:26 |
SpamapS | I think thats abusing the interface a bit | 22:26 |
negronjl | SpamapS: Are you in the hook or config.yaml ? | 22:26 |
SpamapS | negronjl: hooks.py | 22:27 |
negronjl | SpamapS: checking | 22:27 |
SpamapS | negronjl: I get now how services works.. | 22:27 |
SpamapS | and why its done that way | 22:27 |
SpamapS | just not sure if I like how thats being used | 22:27 |
SpamapS | I'd rather see services created dynamically | 22:27 |
SpamapS | perhaps there's a reason you don't want to do that? | 22:28 |
negronjl | well ... | 22:28 |
negronjl | the services are being created dynamically | 22:28 |
negronjl | 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 |
SpamapS | well thats not entirely true. :) | 22:29 |
negronjl | so, to work around that, I have the services being written to disk and the read ( from config-changed ) | 22:29 |
SpamapS | config-changed can be deferred until relations are established | 22:30 |
negronjl | in config-changed, i was getting a trace about not having relation information | 22:30 |
SpamapS | or rather, relation data is always available | 22:30 |
SpamapS | did you not use 'relation-ids' ? | 22:30 |
SpamapS | thats the key | 22:30 |
SpamapS | its new.. | 22:30 |
SpamapS | but its really powerful | 22:30 |
negronjl | didn't use relation-id .. | 22:31 |
negronjl | I guess I'm outdated ... tell me how relation-id would have helped ? | 22:31 |
SpamapS | you can access relation info from any hook | 22:32 |
SpamapS | as long as you pass in the relation id | 22:32 |
negronjl | there is no relation information on first run of config-changed | 22:32 |
SpamapS | right | 22:32 |
SpamapS | so in that case, you just exit 0 | 22:32 |
SpamapS | then after each relation hook, you run it again | 22:33 |
negronjl | I'm doing something somewhat similar.... | 22:33 |
negronjl | I wrapped it around try/except | 22:33 |
negronjl | and pass | 22:33 |
negronjl | .... and then move it along | 22:33 |
SpamapS | yeah I think I see how that works | 22:33 |
SpamapS | 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 |
SpamapS | I'm not questioning that.. but rather why the 'services' thing is needed | 22:34 |
mthaddon | 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 |
SpamapS | 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:35 |
SpamapS | hooks.py line 457 | 22:36 |
negronjl | SpamapS: checking | 22:36 |
SpamapS | also I wouldn't call it service_name | 22:36 |
SpamapS | but 'http_host' | 22:36 |
SpamapS | or 'endpoint_host' | 22:36 |
SpamapS | and I would generate a service per unique endpoint_host | 22:36 |
SpamapS | but maybe you have a good reason not to do that | 22:36 |
negronjl | SpamapS: service_name is different than the host-name | 22:37 |
negronjl | SpamapS: service_name is just an arbitrary name | 22:37 |
negronjl | SpamapS: listen <service_name> <endoint/host/ip>:<port> | 22:37 |
negronjl | SpamapS: just making sure we are talking about the same thing | 22:37 |
SpamapS | right, I'm saying that it should be on the *backends* not defined by the config.yaml option | 22:38 |
negronjl | 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:38 |
negronjl | SpamapS: also, having control of what services are managed in the service is something that seems to be valuable | 22:39 |
SpamapS | 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:39 |
SpamapS | Then any load balancer that I relate those two services to will listen on www.mywebsite.com | 22:40 |
SpamapS | Now, if I leave it off.. we can talk about ways to split those out... | 22:40 |
SpamapS | negronjl: it can stay optional can't it? | 22:40 |
SpamapS | negronjl: like if its not provided it just goes in the "default" server | 22:40 |
SpamapS | negronjl: I guess my point is that service_name seems a bit arbitrary | 22:41 |
negronjl | SpamapS: give me a sec... let me catch up :) | 22:41 |
negronjl | SpamapS: ok ... re:service_name it is arbitrary | 22:41 |
negronjl | SpamapS: the service_host could be specified or "deduced" | 22:41 |
mthaddon | 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 |
SpamapS | 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 |
negronjl | SpamapS: the service ( read listen stanza ) parameters are something that seems to be good to know before deployment | 22:42 |
SpamapS | I'm just wondering if there's ever a time when that is not the desired listen hostname | 22:42 |
SpamapS | I actually have to run in a minute | 22:42 |
negronjl | SpamapS: ok ... | 22:43 |
negronjl | SpamapS: service_name is arbitrary in the sense that it can be whatever service name you want ... | 22:43 |
negronjl | SpamapS: service_name is not being used as an endpoint .... | 22:43 |
negronjl | 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 |
negronjl | SpamapS: because it could collide | 22:44 |
SpamapS | 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 |
negronjl | SpamapS: if you have www.mysite.com for both 80 and 443 | 22:44 |
SpamapS | negronjl: haproxy can do "name based" virtual hosts in http mode | 22:44 |
negronjl | SpamapS: but, those would be specified in the options | 22:45 |
negronjl | SpamapS: which would also be different from the service_name | 22:45 |
SpamapS | 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 |
mthaddon | yep, that's my understanding too | 22:45 |
negronjl | SpamapS: by having service_names decoupled from hostnames, we provide more flexibility . | 22:45 |
SpamapS | yeah thats exactly what I'm worried about | 22:45 |
negronjl | SpamapS: ack ... it's a big and hairy change so, more time to play with it will be needed ... | 22:46 |
SpamapS | flexibility means more things to break | 22:46 |
SpamapS | negronjl: the rest of it thus far looks fantastic | 22:46 |
SpamapS | anyway, I'm late.. ttyl | 22:46 |
negronjl | 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 |
negronjl | SpamapS: ttyl .. | 22:46 |
mthaddon | negronjl: oh, good point - I'm not sure we'd deal with that too well currently | 22:46 |
mthaddon | 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 |
negronjl | mthaddon: service_name collisions ? | 22:47 |
mthaddon | yeah | 22:47 |
mthaddon | but we do do a config check and bail out if it fails, so that might guard against service_name collisions | 22:48 |
negronjl | 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 |
mthaddon | yep | 22:48 |
negronjl | mthaddon: or .. the second service will override the first | 22:49 |
negronjl | mthaddon: leaving you with just one service as opposed to the desired two | 22:49 |
mthaddon | yeah, I think you're right - it'll just overwrite the first as we loop through creating the dict | 22:49 |
negronjl | mthaddon: yup ... when we read the services ( the yaml thing from config.yaml ), it comes as a list | 22:50 |
negronjl | mthaddon: once we parse that out to services_dict ... we'll override the first with the second | 22:50 |
negronjl | mthaddon: indeed bad things could happen ( all your servers in the same service ). | 22:50 |
* mthaddon nods | 22:50 | |
negronjl | have a good weekend all | 23:05 |
mthaddon | o/ | 23:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!