[03:25] <hazmat> SpamapS, knock, knock
[03:25] <hazmat> SpamapS, re debug hooks, wtf
[03:26]  * 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:27] <hazmat> and if your disconnected when the hooks are enabled, the user still need to connect back to end the session
[04:14] <SpamapS> hazmat: yes I have a recipe, been working on it
[04:17] <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
[15:49]  * SpamapS is *so* close with nagios+nrpe+generic interface
[15:58] <_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 >
[16:09] <negronjl> 'morning all
[16:10] <imbrandon> heya negronjl
[16:11] <negronjl> imbrandon: o/
[16:12] <hazmat> imbrandon, thanks btw for pushing that out :-)
[16:12]  * imbrandon hoped you would not be mad ... 
[16:13] <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:14] <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:15] <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:16] <hazmat> they happen to match up though in db and collection names
[16:17] <imbrandon> heh yea , they are pretty generic "juju" and "charms"
[16:17] <imbrandon> collisoins are sure to ahppen
[16:18] <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:19] <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:20] <imbrandon> Twig for the templates and Slim for the routing
[16:20] <imbrandon> everything else is home grown
[16:21] <imbrandon> well and bootstrap for the css :)
[16:21] <bgupta> hazmat: hello!
[16:22] <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:23] <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:24] <bgupta> hazmat: pretty late.. guessing 11:30ish..
[16:24] <imbrandon> bgupta: https://github.com/downloads/jujutools/jujutools.github.com/Install%20juju.zip
[16:25] <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:26] <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:27] <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:28]  * 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:29] <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:34] <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:35] <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:36] <m_3> I'll be trying out variations of that this weekend
[16:38] <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:39] <SpamapS> what review process? ;)
[16:39] <imbrandon> heh
[16:40] <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:44] <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:45] <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:46] <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:50] <imbrandon> but yea if you have python from macports or fink etc it will use those etc
[16:56] <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
[17:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <imbrandon> heh
[17:10] <imbrandon> 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] <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:15] <m_3> SpamapS: any clue why the uploaders are different in juju-jitsu on https://launchpad.net/~juju/+archive/pkgs?field.series_filter=
[17:16] <imbrandon> once kicked off by recipy and one manually ?
[17:18] <imbrandon> hazmat: btw http://jujube.websitedevops.com/raw <-- the charmload schema
[17:20] <hazmat> imbrandon, yeah.. i check it out, its pretty similiar
[17:20] <imbrandon> cool cool
[17:23] <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:24] <m_3> SpamapS: but it's different between series in the same build request
[17:25] <m_3> recipe ownership still looks like juju-hackers
[17:26] <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:28] <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:29] <m_3> yeah, it looks like the ppa is good (tested it for precise)
[19:22] <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:27] <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:28] <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:29] <m_3> (assumes it's in ~/charms/precise/nova-volume)
[20:18] <marcoceppi> imbrandon: does Jujube have an API endpoint for the charm data?
[22:01] <negronjl> Who's reviewing today ?
[22:04] <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:05] <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:06] <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:07] <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:08] <SpamapS> very glad you have monitoring ability
[22:08] <SpamapS> thats huge
[22:08] <SpamapS> to be able to toggle it on/off
[22:09] <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:10] <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:11] <SpamapS> negronjl: the python in hooks.py reads really nicely btw
[22:11] <negronjl> SpamapS: thx ... PITA to make it PEP8 compliant
[22:12] <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:13] <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:14] <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:15] <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:17] <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:18] <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:19] <negronjl> SpamapS: plus ... it's easier for my simple brain to deal with smaller chunks of code :)
[22:20] <SpamapS> https://code.launchpad.net/~gmb/charm-tools/add-charm-helpers/+merge/96204
[22:21] <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:22] <SpamapS> negronjl: these are actually different entirely.. so they'd mesh well with your stuff
[22:24] <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:25] <SpamapS> negronjl: hrm.. this service_name thing.. Hrm..
[22:26] <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:27] <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:28] <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:29] <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:30] <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:31] <negronjl> didn't use relation-id ..
[22:31] <negronjl> I guess I'm outdated ... tell me how relation-id would have helped ?
[22:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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
[23:05] <negronjl> have a good weekend all
[23:06] <mthaddon> o/