[00:00] to do that it would have to be not just tecnical but they would need to be aware of all the reporcusions and how to debug repotly but be certain its not in vein etc [00:01] and well past what can / should be encapsulated in a first draft charm if at all [00:01] Man, I really really really want a "pretend to re-negotiate the relations" command [00:02] oh SpamapS btw, i'm at feature parity with jjc.c now on jujube [00:02] So many times where I just need to tweak something, and run upgrade-charm .. [00:02] imbrandon: lol.. of course you are [00:02] but i did a few thiings that i decided are a little beeter another way so i'm refactoring a little bit of it [00:02] but even that i should be done tonight too [00:08] oh and i said that wrong tooo, i'm not at fp with the whole domain , i broke it up into parts in my head and the README but none else know that LOL ... i intended to say i'm there with all of the charm browser aspects of jjc.c [00:09] includiing both the html output and a .json out out on the same routes if /api/v1/ is prefixed [00:11] like /charms/precise lists all precise charms and /charms/precise/appflower is details for appflower , then /api/v1/charms/precise and same for appflower are json output and also take a optional ?callback=anything returning jsonp so CORS will work as well [00:12] with cross origin domain calls, and later other sites could use JS to just make remote api calls for the data thet want ( or what i'm more excuted about is that juju-jitu could as well should it want to maybe it will spark something cool ) [00:16] http://ec2-54-245-5-73.us-west-2.compute.amazonaws.com/nagios3/ (user:nagiosadmin pass:ohpuipeera) [00:16] So there's my nagios magic [00:17] still needs to add host/service groups [00:18] and I *think* I can do some clever parent/child stuff by inspecting the relationships a bit (provides should be the parent of requires.. perhaps) [00:41] SpamapS: nice re: nagios [01:15] SpamapS: nagios is compelling... can I use this as part of a "mature" stack for Thursday? [01:26] SpamapS, there is no clean up re subs [01:26] SpamapS, thats a significant feature thats needed across the board [01:26] orderly cleanup and instead of parent tree kill [01:27] imbrandon, incidentally i got the oks to push jc.c public [01:29] SpamapS, goju should hopefully have that from the start, it was discussed as part of the mongo storage work [01:29] imbrandon, yes charms are copied on disk for each unit... pls file a bug if its of concern [01:34] for ec2 there's not much to do, it must be present on each machine [01:34] for local.. [01:34] perhaps [01:35] SpamapS, how'd you get juju with ostack working on hpcloud? [02:27] ah.. auth-mode keyapir [02:48] hazmat: I had to use auth-mode: userpass ... see PM [02:48] imbrandon, i'm making some progress with keypair [03:17] hazmat: nice, if you do get keypair to work later that would be cool, much less complex than currently i think for the env.y [03:17] although thats a set and forget thing so ... [03:18] heh' [07:02] m_3: this is pretty solid, I'll chat w/ you tomorrow to get you up to speed on deploying it. I think it should be widely consumable. [07:06] Hi, i am trying to deploy openstack on VM's. I have deployed all required charms, but for most machines in MAAS it shows agent-state: not started, though they are running. Here is output of juju status http://pastebin.com/vAb1mb3r Any ideas why juju is not registering running nodes? [07:08] hitexlt: the agent state is running on machine 2 [07:09] hitexlt: and machine 2's rabbitmq seems to be started actually [07:10] hitexlt: can you look at the console of machine 1 and see if something failed on first boot? === philipballew__ is now known as philballew === almaisan-away is now known as al-maisan === mrevell_ is now known as mrevell [10:27] :( [10:34] jml, sad today? [10:34] oh yeah [10:34] I just had to kill off juju processes that were chewing up all my CPU [10:34] jml, local provider? [10:35] jamespage: yeah. I pretty much never use ec2 [10:35] :-( [10:36] jml: canonistack is actually pretty reasonable currently [10:36] mgz: I can run precise stuff on that, right? [10:37] yup. [10:39] mgz, hows the openstack provider work coming on? [10:40] it's is a working state, but there are a few required features left and some cleanup to do. === al-maisan is now known as almaisan-away [11:27] mgz, i've spent some time yesterday working it across several providers (rspace, hp, cstack)and doing some cleanups. rspace is very different behavior with v2 api [11:27] no floating ips [11:27] auto public ip [11:28] right, hp have also switched to enabling the auto-assign of a public ip [11:28] there's an easy enough work around (see if there's a public ip before allocating a floating ip) [11:28] but that doesn't get me round the sleep unless I have a way of getting the config state out of a particular deployment [11:28] mgz it would be nice to avoid the wait entirely [11:29] what I'd *really* *really* like is juju to move the public ip requirement to the ports handling [11:30] mgz, there's nothing to run that code for the bootstrap node [11:30] it wouldn't be that hard to juju ssh to ensure the instance is accessible [11:30] that's a workaround not a solution [11:31] well, it's moving the requirement of being able to talk to the machine from instantation to when it's actually needed [11:33] any code that currently expects to access public_ip could basically do that lookup with a check that will allocate one on demand [11:33] mgz ah.. so your saying automatically instead of manually. that's reasonable. [11:33] mgz, even distinguishing what's the public ip isn't well defined [11:33] right. [11:34] mgz, also for ec2, it no longer waits for the security group shutdown/delete dance, it just reuses the groups [11:34] on trunk [11:34] for ostack this removes the delete dance at shutdown [11:34] all the providers seem to support just killing the machine [11:36] that's an improvement, is there any cleanup for the groups? [11:41] hazmat: do you have a branch for your changes up anywhere? and did you find my hp tweaks branch? there are a few other differences they have that need properly integrating into the provider [11:48] mgz, it looked like the hp tweaks where already mainlined [11:48] mgz, i'm still in progress on my changes.. but here's the crack in progress ~hazmat/juju/openstack_provider/ [11:49] i need to run an errand, bbiab [11:49] right, I merged Clint's, but last week an HP guy did some more testing as they want to use juju in a demo [11:49] and turned up some more things [11:49] mgz, rackspace has their own auth form derived from v2 but with different fields. [11:49] mgz, where's that branch? [11:49] see lp:~gz/juju/openstack_provider_hp_tweak [11:50] cool, i'll check in when i get back [11:50] I'll take a look at your current state too on the rackspace auth things. [11:51] mgz, i still have to parameterize all the security group work there, since all of those apis are 404s on rspace [11:53] hm, all of them? they don't support security groups at all? [11:56] mgz, at the moment no [11:56] nor floating ips [11:57] mgz none of those apis is in v2 [11:57] okay, those auth changes make sense, shoule be able to integrate that nicely [11:57] there in quantum [11:57] well, there are various things moving from nova to other projects [11:57] in not very backwards compatible ways [11:58] provided detecting can be done sensibly, doing both shouldn't be too hard, just a little annoying === almaisan-away is now known as al-maisan === zyga is now known as zyga-afk [13:35] mgz, there's some minor capability though inconsistent to detect via service catalog version info [13:35] rspace actually publishes multiple compute endpoints of different versions [13:35] hm, probably need to change the endpoint picking logic again then [13:55] Hmmm, so the quotes are interpeded as a string now in the yaml. Is there a different type which will evaluate the quotes? [13:56] you mean will include the quote marks in the string? [13:57] Yes, are we just using the pipe now? [14:00] Well, I mean, will evaluate the quotes as a special character (escape sequence) [14:00] With the default type of string, the quotes are included. I think this was changed. [14:01] Also, referring to the single quote [14:03] hm, was about to say it works for me, but turns out I don't use any quotes in my config [14:06] I am trial/error'ing it now. I will post my results. [14:25] can someone take a look at http://askubuntu.com/questions/162255/does-juju-really-need-two-nodes ? [14:26] I looked upon it an despaired [14:26] he wants to do an openstack deployment with only one box, the maas demo used 9. [14:27] jitsu deploy-to can lesson it [14:27] it seems to me that the JuJu bootstrap node failed to come up. [14:28] smoser, agreed [14:29] it looks like the node is up but not running zk [14:30] I've had similar symptoms from cloud-init steps failing [14:30] so, sshing to the box and looking at the logs is what I'd do next [14:31] I just don't see it's really helping his end goal [14:31] mgz, cloud init does not fail. [14:31] i'm done talking to you [14:31] :) [14:31] :D [14:31] sorry, 'apt-get fails and cloud-init plows on regardless' :P [14:31] mgz, yeah, that is what i woudl have suggested, but i dont know which logs to get. [14:32] mgz, thats better. [14:32] hazmat, or mgz, could you request posting of some logs that might give information? [14:32] /var/log/cloud-init-output.log and the ones under /var/log/juju generally === al-maisan is now known as almaisan-away [14:36] Is it appropiate for me to start bug reports on juju? E.g. Boolean in config uses python interpratation with capital first letter --> "True". But bash uses lowercase --> "true". [15:01] Ahhh crap. Well, if anyone was curious about the quote thing, careful where you put you delimiter settings. IFS="$(echo -e "\n\r")" is not normal for commands. [15:04] surgemcgee, yes re bug reports, that particular one is addressed by some recent changes, but requires the charm to explicitly specify format 2 === zyga-afk is now known as zyga [15:05] which makes hook cli api output normalize to yaml [15:13] hazmat: kind of weird though... format 2 isn't supported by precise... [15:13] hazmat: I suggest that people just use --format=json [15:50] mgz it looks like the fixes re hp tweaks are to support an older form of sec groups extant there [15:51] it seems like the version identifiers here have no meaning re 1.1 nova compute, as they entail quite a bit differences between extant entities === salgado is now known as salgado-lunch [15:52] Has openstack support landed yet? [15:53] marcoceppi, almost, just trying to kick the tires across a few providers [15:53] Awesome, good to hear [15:53] right, the api versioning isn't... er... robust [15:54] considering the size of the branch, i'm sorely tempted to have it just land, and fix per provider incrementally.. [15:54] mgz, does the server respond back with version headers in any meaningful way? [15:54] mgz, the keystone svc catalog doesn't seem to mandate versions [15:55] which makes it hard to utilize that [15:56] mgz, visualizing what v2 compatibility is going to look like with a provider that supports separate network, compute, volume api.. while keeping compatibility with 1.1 feels quite different [15:57] nope, though versions should generally be in the catalog... main issue seems to be they're largely ignored [15:57] the encapsulation needs to flow from abstractions inspecting the svc catalog, but i digress.. its probably better to fix up some of the window dressing [15:57] so, stuff get broken and no one notices [15:58] mgz, ignored by the current code.. or by the svc provider? [15:58] well the former is true.. just curious about the latter [15:58] * hazmat openstack's api innovation makes me sad [15:58] hmm.. s/me/ [16:00] for instance, nova-client handles 1.1 and 2 with the same code under v1_1 module [16:00] there's pushback now it's starting to get use, but the history so far is messy [16:06] mgz, thats going to fail as soon as people start deploying quantum.. its already a fail using the cli against v2 impl [16:07] with v2 we're going to have construct our facade if we want to support both nova-network and quantum and dispatch by version id [16:07] i'm not as concerned about that at the moment though re getting this into trunk, since those are extant [16:08] right, and the volumes code has the reverse problem, I have to use an old version of python-novaclient because the api was moved out of 'compute' into 'volume' and current deployments don't support the new way [16:09] I think these problems aren't too hard from the juju side though, given the api usage it pretty light and we should alwayse be able to pick a method that works [16:09] same problem fundamentally.. two versions address the same core api in different ways [16:09] right. [16:09] mgz, is volume going to be exposed at its own endpoint in the svc catalog as well? [16:09] yes. [16:10] and in fact is, but... canonistack gives an unresolvable internal url, and hp gives an endpoint which uses the old naming :) [16:10] argh.. snowflakes [16:10] :D [16:11] doesn't keystone hand back a map.. "volume -> this url, network -> this url" ? [16:11] SpamapS, in future in theory yes [16:11] i believe rspace has both of those in private beta [16:12] rspace is on v2 of the api.. hp is effectively on a forked version of the 1.1 api from diablo time frame which is different than any other impl.. canoistack is on v1.1 but doesn't advertise versions for its svc catalog endpoints (which keystone hands back). [16:18] I'm surprised HP hasn't spun up an Essex region [16:23] mgz, SpamapS have you guys noticed any oddity about the bootstrap node getting a stringified id in hpcloud stored in zk, and thus not useable for queries to hpcloud about it? [16:24] hazmat: yes [16:24] hazmat: the bootstrap node just is wonky w/ hpcloud [16:24] I haven't looked into it very much [16:24] the provider needs to materialize it back to an int i think before passing it off to the api serialization [16:24] hazmat: yeah, that's an issue, I hacked around it in the hp tweak branch I linked earlier [16:25] mgz, it looked like the branch was trying to serialize all the ids to strs [16:26] oh.. this the curl against the main id [16:26] er bootstrap id against fstorage [16:26] there's a neater way of doing it in StatusCommand._process_machine but I was trying to avoid changes to other bits of juju [16:27] mgz, i'm thinking just sniff the type in the provider [16:27] <_mup_> Bug #966577 was filed: add explicit egress 'owner' rule on non-bootstrapping nodes to require root access to zookeeper < https://launchpad.net/bugs/966577 > [16:29] yup.. that does the trick [16:34] hazmat: ^ the bug above is my hack for preventing non-root users from poking at ZK.. [16:34] hazmat: No diff yet.. just the idea. But I think its worthwhile even after ACL's land [16:34] hazmat: which, btw, are we going to land ACLs ? [16:34] hazmat: or is libzookeeper still an unknown weird fail-generator ? [16:38] zk dosent handle acl's at all? it expects the client to 100% ? [16:40] hazmat: btw i found if you use local placement on the bootstrap node the ssh 0 is still failwhale but you can juju ssh service/0 to it fine and juju status us the same at the top but its correct down at the server part with ip and all [16:41] hazmat: personally i've just been doing juju ( the charm ) deployment or something small just for convience but if that help with the debug path in the code maybe heh [16:41] hpcloud ^^ btw [16:43] 'morning all [16:44] ugh, where are unity's global hotkeys stored anyone know right off to save me 15 minutes of looking , please dont say gconfeditor ... [16:44] heya negronjl [16:44] hi imbrandon [16:44] imbrandon, just fixed that fwiw [16:44] oh sweet, i was aobut to get lunch bvut after mind if i snag ur branch :) [16:44] heh [16:44] i guess clint rolled out [16:45] oh cool cool, i'll catch up when i get back i've been head down in code and only half paying attn to irc today [16:45] ok back in a bit, foooooood [16:47] the ssh fingerprint problem is more pronounced with ostack providers i'm noticing [16:47] i guess thats the habit of reusing the floating ip [16:47] to a different machine [16:48] yup. [16:55] SpamapS, yes stunnel si worthwhile [16:56] SpamapS, i haven't dug into libzk issues [16:56] stunnel would be a bigger deal [16:56] just using the iptables rule we at least limit all traffic to the bootstrap node to root [16:57] imbrandon: not sure what happened while I was split off. ZK has ACL's, but we don't use the (yet) [16:58] imbrandon, just hold down 'windows'/cmd key for a while and the shortcuts appear [16:59] a listing that is [17:00] ooo somebody is learning unity [17:01] hazmat: hey, the charm versions in import/export are pretty bogus.. [17:01] SpamapS, ? [17:01] SpamapS, how so? [17:01] SpamapS, pastebin pls [17:01] hazmat: with local charms at least.. I no longer have "version25" of mysql.. I"m on 31.. but it deployed 31 as local:mysql-25 [17:02] hazmat: causes no harm, but its confusing [17:02] SpamapS, ah.. i actually added explicit support for that [17:02] SpamapS, otherwise it would fail to deploy at all if the version in a local repo wasn't an exact match [17:02] It works fantastically, but its a bit weird. ;) [17:03] hazmat: I'd rather see the actual versions (and warnings). But.. we can do that in the go version, right? ;) [17:03] SpamapS, basically for local charms, the version id isn't a hard requirement, it will look for the specified version and then fallback to namematch [17:03] Interesting question, can I change the region during deployment? to have nodes across regions? [17:03] marcoceppi, no.. that's not supported in constraints atm.. twas a long discussion.. [17:03] well.. you can specify az [17:03] hazmat: thanks, I figured it would be pretty involved [17:03] for a constraint at a service level [17:04] but if you want a multi region service, the result is you need a service in each that are connected [17:04] that way if you need to add capacity (or a node disappears) replacing it is explicit [17:04] I'd love to have a service constraint of ec2-availability-zone=balanced [17:04] meaning, put these in as many different zones as possible [17:05] * hazmat nods [17:05] +1k [17:05] we went back and forth on that one a few times at uds orlando [17:05] not treating individual nodes as special was the concern for supporting it explicitly within a service [17:06] if i have three nodes in one az and one node in another az, and it dies, what does add-unit do to correct properly [17:06] a juju policy level identifier for zones would work though [17:07] but at the moment the recommendation is to have separate services in each zone and relate them [17:08] is it possible to reboot an instance inside an install hook (for example)? [17:09] dpb___, not at the moment, the address change doesn't properly propogate if there is one, if the address is stable then yes === salgado-lunch is now known as salgado [17:10] hazmat: ok, you mean the ip address? [17:10] dpb___, yes, both public and private would have to be stable for it to work reliabily [17:11] hazmat: ah, ok. I guess the private one can change between boots on aws? [17:11] dpb___, both change on reboot in aws [17:11] hazmat: ok, thx, I did not know that. [17:12] dpb___, there's an unloved branch for it, if your interested, that updates address at boot, and propogates to relations.. with it doing things like suspend/restore an ec2 env become possible [17:13] hazmat: well, first let me see if I can do some magic to make the reboot uncessary. that would be speed up the process anyway. [17:13] dpb___, absolutely that would be the best way [17:13] hazmat: thx [17:13] dpb___: I would defer reboot to config-changed [17:16] SpamapS: How do you mean? you mean that config_changed can handle a reboot in the middle? [17:18] dpb___: config-changed is what will be run after the reboot [18:10] SpamapS: heya [18:10] SpamapS: mims is on review this week but I didn't account for oscon [18:10] SpamapS: if it's possible, what do you think about reviewing the queue this week and have mims grab next week, when it was your turn to go. [18:10] basically, wanna swap? [18:11] Yeah I'm going to take his shift [18:11] jcastro: I saw that coming yesterday. :) [18:11] <3 [18:11] thanks dude [18:11] jcastro: which is unfortunate because I was hoping to have Mims review my massive Nagios refactor :) [18:11] but he probably will anyway as he might use it in his demo :) [18:13] indeed [18:13] also we have decided we want you writing more subordinates. :p [18:18] ME TOO :) [18:18] well I already took over james_w's nrpe [18:18] jcastro: http://ec2-54-245-5-73.us-west-2.compute.amazonaws.com/nagios3/ [18:19] jcastro: user:nagiosadmin pass:ohpuipeera [18:19] and no I don't mind if you all pound the crap out of it ;) [18:49] hazmat: yea i knew that actually, cuz its the ones i keep hitting ( cmd ) and so i want to swap enmase` cmd<->ctl so my hotkeys for osx and ubuntu should line up almost identically, as it is i keep bringing up the hud every time i goto save a file or copy/paste etc etc, finaly had enough and gonna find it even if i got to recompiler unity :) [18:49] heh [18:51] SpamapS: can you leave that instance up for a few hours? [18:51] that'd be nice to show during our talk [18:53] jcastro: when are you guys speaking? [18:53] jcastro: I can give you an export to recreate it. :) [18:53] in 1.5 hours. [18:53] well, we didn't want to go too deep into it, actually, I'll just screenshot it [18:53] jcastro: are you guys demo'ing at all or just talking? [18:53] demoing a bunch of stuff [18:54] so we didn't want to add another demo [18:54] hah yeah ok [18:54] jcastro: let me add thinkup back in and then you can screenshot it [18:55] ok, lmk when [18:55] jcastro: its there now, just PENDING [18:55] jcastro: more fun if its all green :) [18:57] I like it with the pending though [18:57] true [18:57] shows that it all just works, and you don't care, you set the relationship, it WILL work, etc. [18:58] except when it doesn't, but whatever. :p [18:58] haha [18:58] jcastro: got a shot yet? I want to refresh one of the relations [18:58] we're good [19:06] jcastro: Ok re do your snap of services now. MUCH more compelling :) [19:07] jcastro: and I can give you some reds if you want. :) [19:08] ok one sec [19:09] thanks dude, got it [19:11] SpamapS: haha ok know what i just realized, ok so like none of this info is new to me ( or you either i dont think ) but it JUST all clicked a few seconds ago [19:11] imbrandon: you forgot one thing. You forgot, to hookup, the doll [19:12] so ... Google had another announcement like 2 days ago that they just finished laying the 200th mile of FttH in Kansas City [19:12] doll ? [19:14] so ok the fiber rollout is almost complete, its double subsidised once by the city/county to get ppl on it and once by google, so total cost to residents at rollout is $30 per month out of pocket and thats for 100GB SYNC connection , not just to the street but all the way to the net AND 16 static IP ..... [19:14] on the residential connection ... ok so add that ... pluss i start rounding up some HP blades and Sun NAS boxes heheh [19:15] toss open stack on it , and start a lil mini Linode in my basemnent [19:15] likely rivaling if not exceding the quality of many mom and pop operations round the country [19:15] hahah [19:16] anyhow i likely will do all that cept the resell part, i dont want that headache :) [19:16] lol [19:16] imbrandon: re doll.. http://www.imdb.com/title/tt0090305/quotes .. look for the word 'doll' [19:16] k [19:16] I'm like the only one who remembers that quote.. but I use it in my head constantly :p [19:17] AHHH [19:18] heh, thats ok i had the audio playing ( very loud too ) for the samuel jakson seen at the start of pulp fiction when my brother came by and dident reconise it [19:18] i told him i disowned him [19:22] imbrandon: your power setup will be crap w/o a diesel generator, but otherwise yeah you will have quite a bit of advantage. :) [19:22] perhaps KC will become us-east-2 ;) [19:22] hrm yea but that would not be too bad :) [19:22] hahaha [19:23] http://gfiber-kansas.appspot.com/fiber/kansascity/news.html [19:24] cant wait for real, i'm just happy as hell that not only its got 16ips static standard but that are quoted to say something very very close to "KC is the pilot city here is some cool shit now go make the next gen web" [19:24] PLUS sync both ways :) [19:25] you should see all the new Tech startup that are already downtown that are newly funded and starting to setup shop now in prep [19:25] gonna be a wild ride the first year i bet [19:27] SpamapS: ok, i'm on Time Warner now ... kc.rr.com , and check this pic out http://www.businessinsider.com/google-fiber-speed-2011-8 [19:27] it looks like hpcloud is blocking private traffic by default now [19:27] they block all by default i thought [19:28] and you had to add pub and priv to the zones [19:28] huh? [19:28] i forgot what they call their security groups [19:28] i couldn't deploy services because the agents couldn't connect back to the bootsstrap node [19:28] security groups.. [19:28] right, juju dont do that on diablo [19:29] SpamapS: had me do it by hand so i just set it to 0.0.0.0/0 [19:29] and never destroyed it [19:29] Oh right I totally forgot about that [19:29] i did too [19:29] untill hazmat said it [19:30] since destroy never took the groups away [19:30] and i used the same name [19:30] this is going to break most of the charms unless we netmask all internal port traffic [19:30] to redeploy , never had to mess with it again [19:30] to the env sec group [19:31] i had the same issue on azure although lacking any notion of a private network there [19:31] right , but you can only do that by name and not ip with the python-novaclient :( [19:31] hazmat: there's no concept of private traffic being allowed between security group members? [19:31] SpamapS: they is but its off and docs say its not in the webui [19:31] SpamapS, there should be but it was pretty broken on diablo [19:32] * hazmat grumbles about snowflakes [19:32] snow ? its over 90f here [19:32] man [19:32] no effin way [19:33] imbrandon, just referencing the individual snowflake implementations of openstack ;-) its a 100+ here [19:33] ahh diablo seems to be just making everything ridiculous [19:33] ohhh ohh ok, i've interntionally stayed clear of the OS guts for now, until it evens out a little [19:34] and i dont waste a ton of time on something that will be bad before i really "get" it [19:34] hehe [19:35] SpamapS, the differences between essexes is just as bad.. ie the delta for rackspace and canonistack is huge [19:35] i figured by the time RAX and that other one rolls em public will be a good time to hunker down and really "get" all the bits that i would need [19:35] hm, a wise man once told me that the browser wars were the only thing that saved the web [19:36] to know about , or maybe not but i still like to understand the full stack eventually, kinda sucks lately intentionally staying out of the juju and OS code just for that [19:36] perhaps we're right at the point where netscape has implemented a billion little extensions, and IE has done the same... [19:36] i dunno about saved it, but they sure as hell are what drove it and still do [19:37] SpamapS: we are, even software devlopemnt as a whole is an insanely young disapline let along generations inside of that [19:37] imbrandon: the theory being that while HTTP RFC's and w3c specs *helped*.. what really kept things honest was users demanding the Netscape/Firefox/etc. interoperate with sites that blindly used IE stuff.. [19:37] Tho I could make a compelling argument that what really put a nail in the IE-special-snowflake was the iphone [19:38] who's got money on hp will give in to the OSapi and join the ranks and goog will be the wild card like IE [19:38] with "alomst" but "better" stuff :) [19:38] Ugh [19:39] subordinates should have a guarantee that their primary relations will have fired before any others [19:39] nah, it was way before the iphone, thats just when everyone realzed it but by that time its tooo late, itunes is what sealed everything [19:39] nrpe killing me here by relating to nagios before it can talk to its local service [19:39] SpamapS: no, bad juju , dont force serialization, lets make the hooks smarter to deal with async [19:39] yea iu know easier said than done [19:39] imbrandon: I do that [19:40] but.. we need a 'defer me until later' to make that easy [19:40] otherwise every hook ends up calling every other hook [19:40] i know, you do, it was really me just "going by the book" but in reality your right [19:40] heh , have you seen my hooks, they do call every other one ;) [19:41] for realz [19:42] yeah I'm doing that too and its just making me sick how crap thats going to be for some use cases [19:42] so i want to charm http://c9.io ... but its got a "magic" build system i dont under stand and cant make work on 12.04 but same git checkout works on OSX ... got time / wanna help on it :) heh [19:42] like nagios.. where I fully expect thousands of units related [19:43] what thousands ? maybe on the top 3% but the vast majority of deployments will be 20 or less i bet, Penton only had about 100 [19:43] there's a really big network effect though [19:44] so even 100 units will be painful to do 4 times every time 1 comes and goes [19:45] yea but having not looked at it at all i know that the "nagios" way of dealing with that is not the typical setup, we ( read you , i aint dont shit but bitch ) might be rtying to bend nagios into a traditional scale out form factor its not gonna work at ... this is problably going to be the most complex charm i bet , including the OS ones [19:46] nah that shouldent be [19:46] those checks are cheap [19:46] think about how many hit apache a second [19:46] it just SEEMS like it would [19:46] its the constant chatter back and forth between juju and the hooks and execing relation-get for every relation-list unit for every relation-id relation [19:47] that and thats one reason they should not all report to the one [19:47] its not about *nagios* [19:47] its about the charm eating up all the CPU cycles just dealing with the churn [19:47] I can scale out nagios really easily [19:47] several ways [19:47] oh well if the charm cant scale thats not nagios's fault [19:48] my point exactly [19:48] then we need to look at mq [19:48] but i thought zk did that for us [19:48] its not that either [19:48] its calling all the hooks all the time [19:48] sure you can slow the queue back [19:48]