| _mup_ | ensemble/robust-hook-exit r288 committed by jim.baker@canonical.com | 00:32 |
|---|---|---|
| _mup_ | Comments and better MATCH for mocking | 00:32 |
| _mup_ | ensemble/robust-hook-exit r289 committed by jim.baker@canonical.com | 00:37 |
| _mup_ | PEP8 and better test name | 00:37 |
| jimbaker | adam_g, did the robust-hook-exit branch work for you? | 00:45 |
| jimbaker | in any event, i have pushed up a version of this branch that i'm going to now submit for review, now that it has comprehensive testing | 00:45 |
| jimbaker | (unless of course it doesn't actually work ;) ) | 00:46 |
| jimbaker | adam_g, i did find one bug in the reaping mechanism, but i suspect it would not have actually impacted your use, just a resource exhaustion problem for long-term running in the machine agent | 00:47 |
| jimbaker | and again fixed in this most recent push | 00:47 |
| adam_g | jimbaker: sorry. yes, i did test it on friday and it worked just fine. | 01:17 |
| jimbaker | adam_g, cool. if you could please try the latest version of the branch, which i just pushed for review, that would be very helpful | 01:33 |
| jimbaker | i believe in a nutshell we can model such bad hooks as something like this: sleep 0.05 && echo "Slept for 50ms" && sleep 1 && echo "Slept for 1s" && sleep 1000000 & | 01:34 |
| jimbaker | the & at the end be the operative part to fork, but not to close file descriptors in the child | 01:35 |
| SpamapS | hmm.. toying with a Venn diagram explaining why service orchestration is not config management, but encompasses some of it.. | 05:23 |
| SpamapS | http://spamaps.org/files/venn-config-service.png | 05:23 |
| SpamapS | The suggestion there is that the blue stuff on the right is what is being bolted on to config management.. | 05:24 |
| adam_g | SpamapS: what do you mean 'bolted on'? | 05:30 |
| SpamapS | adam_g: meaning they're being added as afterthoughts. | 05:41 |
| SpamapS | adam_g: I don't even think, actually, that any of the free cfg mgmt solutions have a built in coordination method.. they just fake it by running themselves over and over. | 05:42 |
| SpamapS | adam_g: and the elasticity comes from that paradigm too | 05:42 |
| adam_g | SpamapS: i dont know about chef, but the way puppet traditionally worked was, you install a central puppet master that hosts the configuration, and an agent sleeps on client machines, awakens at interval and to see if they need updates | 05:44 |
| adam_g | err, checks in to see.. | 05:45 |
| SpamapS | Right, and there's no telling who will see the changes first unless you force a run, right? | 05:45 |
| adam_g | right | 05:45 |
| adam_g | well | 05:45 |
| adam_g | using mcollective, now, though | 05:45 |
| adam_g | you essentially "turn off" puppet on the clients | 05:45 |
| SpamapS | right, that new bolt on that is, IMO, a healthy competitor to ensemble. :) | 05:45 |
| adam_g | and dispatch puppet runs via mcollective, which is running on the clients | 05:46 |
| SpamapS | because a lot of the time you need to upgrade clients first, then update the server to use some new feature.. | 05:46 |
| adam_g | zright | 05:47 |
| SpamapS | I've felt for a while that puppet is nothing like Ensemble, and mcollective is a little like ensemble. :P | 05:47 |
| adam_g | what puppet realy lacks IMHO is coordination between systems, especially for encforcing ordering dependencies with regards to state changes | 05:47 |
| * adam_g agrees 100% | 05:47 | |
| adam_g | :) | 05:47 |
| SpamapS | Ensemble ends up having that by the nature of doing things in a service oriented fashion.. but the upgrade-formula hook is, IMO, a bit weak for ongoing coordination. | 05:48 |
| SpamapS | I really need to be able to enumerate and act on relations in upgrade-formula.. so I can wake up the related pairs and tell them about any new necessary info. | 05:49 |
| SpamapS | This is where mcollective's simpler approach wins out.. because all it has to do is dispatch puppet. | 05:50 |
| _mup_ | Bug #816264 was filed: PYTHONPATH causing corrupt environment <Ensemble:New> < https://launchpad.net/bugs/816264 > | 06:49 |
| === daker_ is now known as daker | ||
| kim0 | oh we now have config-set \o/ yaay | 10:56 |
| === wrtp_ is now known as wrtp | ||
| fwereade | hey all | 11:28 |
| fwereade | is there a way to give a merge proposal more than one prerequisite branch? | 11:28 |
| hazmat | fwereade, no.. | 11:35 |
| fwereade | hazmat: does that imply I'm Doing It Wrong? ;) | 11:35 |
| hazmat | fwereade, logically no.. typically i use a straight line of deps for merges.. but that's tool limitation imo. | 11:35 |
| fwereade | hazmat: I resisted the urge to just keep everything in one straight line | 11:36 |
| fwereade | hazmat: the thing that's bugging me is it's only going to get worse | 11:36 |
| hazmat | fwereade, :-) bzr-pipeline is a nice bzr plugin that can automate some of the tedium of managing a straight-line of dependent branches | 11:36 |
| fwereade | hazmat: the next thing I want to do wants to build on the results of 2 independent pipelines | 11:37 |
| fwereade | hazmat: mreging trunk updates through the whole pipeline and suchlike? | 11:37 |
| hazmat | fwereade, i'm using it for the security work right now, which is like 7 branches atm, pipeline helps me automate pushing changes through, as well keeping a single checkout workspace for the work on all the branches | 11:37 |
| hazmat | fwereade, yup | 11:37 |
| fwereade | hazmat: cool, I'll check it out | 11:37 |
| fwereade | hazmat: can I retrofit it onto an existing pipeline or does it need to remember its own state? | 11:38 |
| fwereade | hazmat: actually, now I think of it, I can suspend work on that feature and go back to the last one I suspended because it was breaking my brain (I think my brain has recovered a bit now ;)) | 11:39 |
| hazmat | fwereade, you can retrofit an existing *branch* with just bzr reconfigure-pipeline, you can retrofit an existing pipeline but its effectively just adding a new branch and merging the existing branch to it.. | 11:39 |
| hazmat | i also appreciate the single workspace model for working with multiple branches | 11:40 |
| fwereade | heh, I think I'd go even more insane without separate workspaces | 11:40 |
| * hazmat looks around for pre-review coffee | 11:41 | |
| hazmat | fwereade, out of curiosity what editor do you favor? | 11:48 |
| fwereade | hazmat: vim | 11:49 |
| fwereade | hazmat: and yourself? | 11:49 |
| hazmat | fwereade, right on.. i'm an emacs guy.. i believe we now have achieved 50/50 parity on the dev team ;-) | 11:49 |
| fwereade | hazmat: haha, nice | 11:49 |
| fwereade | hazmat: I had a bad early impression of emacs... a colleague used it and we seemed to spend about 50% of our pairing time fiddling with the settings | 11:50 |
| fwereade | hazmat: not really a fair test ofc ;) | 11:51 |
| hazmat | fwereade, yeah.. i think i try to keep my settings fiddling to once a year... i know incredibly little about mucking with emacs actually. | 11:52 |
| fwereade | hazmat: the bad early impression of vim came from trying to type in command mode, ofc... that was exciting, but at least it wastes minimal time | 11:53 |
| hazmat | fwereade, yeah.. my first vim experience was modifying some oracle setup on an ancient solaris, i ended up tracking down a sysadmin for a cheat sheet... i'm not sure that i ever fully recovered ;-) | 11:58 |
| hazmat | although i've grown to like solaris since | 11:59 |
| fwereade | hazmat: heh | 11:59 |
| fwereade | hazmat: I think having someone who knows the tool to hold your hand is probably the critical factor | 12:00 |
| niemeyer | GOod mornings! | 12:16 |
| niemeyer | What a beautiful review queue | 12:25 |
| fwereade | niemeyer: heh :) | 12:28 |
| fwereade | niemeyer: good morning | 12:28 |
| niemeyer | fwereade: No irony.. it's awesome to come back to a review queue like that.. it'd be better to not have it because everything was already merged, but it's much more pleasant than coming back to nothing | 12:29 |
| fwereade | niemeyer: cool :) | 12:33 |
| Aram | moin. | 12:35 |
| Aram | heh, editor discussions. | 12:35 |
| niemeyer | Hey Aram! | 12:35 |
| Aram | anyone else using acme or sam? :-). | 12:36 |
| Aram | hi! | 12:36 |
| niemeyer | Aram: Was just checking out your PDP11 emulator.. crazy stuff :-) | 12:36 |
| niemeyer | Aram: I think you'll find mostly emacs/vim users around here | 12:37 |
| Aram | yeah, I imagine :-). | 12:38 |
| Aram | I actually read all the PDP-11/40 manual and really liked it. very concise and sane compared to 4833 pages of intel manual. | 12:39 |
| niemeyer | Aram: How are the Intel manuals when compared to ARM's? | 12:45 |
| Aram | never read the ARM manuals. I assume they are at least smaller, as ARM is a very small arch and doesn't have 30+ years of legacy cruft. | 12:46 |
| niemeyer | Aram: Yeah, they feel quite pleasant overall | 12:49 |
| niemeyer | Aram: I know ARM itself (not the SOC makers) actually sells exactly that kind of thing, so it's somewhat expected that they'd do a good job on it | 12:49 |
| niemeyer | Aram: I'm curious if Intel had similar material | 12:49 |
| Aram | I would add ARM support in my emulator at some point to test the power of Go inferred interfaces. | 12:50 |
| Aram | yeah, Intel has tons of material. very very very very detailed. | 12:50 |
| Aram | also, guides for kernel developers and compiler writers. | 12:50 |
| Aram | guides for optimizing etc. | 12:50 |
| Aram | the only problem is that x86 itself is insane. | 12:50 |
| Aram | the manuals are good. very sterile, but good. | 12:51 |
| Aram | (though I like the docs coming from AMD more). | 12:51 |
| niemeyer | Aram: Nice/not nice :) | 12:51 |
| niemeyer | Aram: I note you don't have many tests on the emulator yet (hint!) | 12:52 |
| Aram | yeah... that's true. | 12:53 |
| Aram | I'm reading about the Go test framework now. | 12:53 |
| niemeyer | Aram: It's quite neat, even if a bit slim to my taste | 12:54 |
| niemeyer | Aram: I came up with a slightly more comprehensive version when I started playing with it, following more well-known xunit styles (http://labix.org/gocheck) | 12:54 |
| niemeyer | Aram: It builds on the standard one, though, rather than replacing it entirely | 12:55 |
| Aram | aha, nice. I'll take a look into it. | 12:55 |
| wrtp | Aram: i use acme | 13:10 |
| Aram | :-). | 13:11 |
| wrtp | smiley face every time i use it indeed :-) | 13:11 |
| hazmat | niemeyer, g'morning! re review queue, it looks like kanban generation has gone stale again | 13:14 |
| niemeyer | hazmat: Hmm, indeede | 13:14 |
| wrtp | PS hi gustavo! | 13:15 |
| niemeyer | wrtp: Rog! | 13:17 |
| niemeyer | wrtp: How're things going there? | 13:17 |
| wrtp | niemeyer: pretty good thanks; just hacking up a website for our wedding guests and realising how terrible i am at html/css... | 13:19 |
| wrtp | so many rules, so little clarity :-( | 13:19 |
| wrtp | still, it's fun doing it in Go | 13:20 |
| niemeyer | wrtp: Hah, yeah.. coming back to HTML is always tricky after getting used to the level of cleanliness/power of a CLI | 13:21 |
| wrtp | niemeyer: more like the first time. CSS didn't exist the last time i wrote a web site :-) | 13:22 |
| wrtp | and some people [ahem, looks over shoulder] don't like the "vanilla" look... | 13:23 |
| niemeyer | wrtp: Wow, ok, that's been a _while_ :-) | 13:25 |
| wrtp | yeah, probably coming up for 15 years :-) | 13:25 |
| niemeyer | Kanban is unblocked | 14:20 |
| niemeyer | jimbaker: ping | 14:22 |
| niemeyer | fwereade: ping | 14:22 |
| * hazmat checks out the new golang course | 14:26 | |
| jcastro | robbiew: ok I am relocated and back 100% now. Went over the slides with bacon and he gave me some stuff to fix. | 14:28 |
| robbiew | cool | 14:28 |
| fwereade | niemeyer: heyhey | 14:34 |
| niemeyer | fwereade: yo | 14:35 |
| niemeyer | fwereade: Would you mind to review this branch: https://code.launchpad.net/~jimbaker/ensemble/expose-provider-ec2/+merge/68478 | 14:35 |
| fwereade | niemeyer: a pleasure :) | 14:35 |
| niemeyer | fwereade: This is touching the EC2 provider API, so might be nice to have your view on it since you've been so close to it | 14:35 |
| niemeyer | fwereade: Thanks! | 14:35 |
| _mup_ | ensemble/security-agents-with-identity r297 committed by kapil.thangavelu@canonical.com | 14:39 |
| _mup_ | hierarchy initialization includes otp container. | 14:39 |
| jcastro | any sexy new formulas that people are tackling this week? (already got cloud foundry) | 14:40 |
| jimbaker | niemeyer, hi | 14:42 |
| jimbaker | fwereade, thanks for looking at the expose-provider-ec2 | 14:42 |
| fwereade | jimbaker: np at all | 14:43 |
| fwereade | jimbaker: I'm happy to see the ugliest code in ec2 is gone now :) | 14:43 |
| jimbaker | fwereade, you mean the use of all of those callbacks + authz? | 14:44 |
| fwereade | jimbaker: I think we're talking about the same thing, yeah | 14:44 |
| fwereade | jimbaker: for some reason it really stuck out ;) | 14:45 |
| jimbaker | fwereade, i couldn't really read that code, so i just had to refactor it first. it does feel cleaner | 14:45 |
| niemeyer | jimbaker: Hello | 14:48 |
| jimbaker | niemeyer, hi | 14:48 |
| niemeyer | jimbaker: I have one feedback on this too | 14:48 |
| jimbaker | niemeyer, ? | 14:49 |
| niemeyer | jimbaker: It doesn't feel like there's a reason to be using classes and inheritance there | 14:49 |
| jimbaker | niemeyer, you mean the use of EC2PortOperation for get_machine_group_name? | 14:50 |
| niemeyer | jimbaker: Yeah, and also the classes themselves | 14:51 |
| niemeyer | jimbaker: Foo(x).do_bar() can easily be do_bar() | 14:51 |
| jimbaker | niemeyer, oh sure, that's just following the existing convention. but i agree about it being unnecessary. if i were to do it again, i would not group it this way for the provider ops as a whole | 14:52 |
| niemeyer | jimbaker: Conventions are nice until they are not | 14:52 |
| jimbaker | niemeyer, absolutely | 14:53 |
| niemeyer | jimbaker: I think this should be fixed.. let's not grow up classes which are really just functions | 14:53 |
| jimbaker | niemeyer, so in my case, i'm reading through this operations (hey! command pattern. or something like that) trying to think, what the heck is the reason for them | 14:53 |
| jimbaker | because generally in python if we have classes they mean something | 14:53 |
| jimbaker | but in this case, even the fact that some params go in __init__, others in run, made no sense | 14:54 |
| niemeyer | jimbaker: Overengineering in some cases, caused by us trying to figure a good way to organize code there | 14:54 |
| niemeyer | jimbaker: Would you mind to reorganize it as functions and see how it goes? | 14:54 |
| jimbaker | so it was definitely unhelpful noise because it made it harder to start working with the code | 14:54 |
| jimbaker | niemeyer, sounds good, i can definitely pilot what it could look like | 14:55 |
| jimbaker | niemeyer, in general i think the way it's done in the dummy provider is nicer | 14:55 |
| smoser | niemeyer, its not in go, but https://gist.github.com/1100458 is a "get the right ubuntu ami" tool | 14:55 |
| jimbaker | the other thing that i found annoying was the use of __init__.py when we don't use that convention elsewhere in the code | 14:56 |
| niemeyer | smoser: Hah, sweet! | 14:57 |
| niemeyer | smoser: I'll dump that in my bin and start playing with it | 14:57 |
| niemeyer | smoser: any chance of an entry in the contest for that? ;-) | 14:57 |
| smoser | maybe | 14:57 |
| smoser | is there an sh2go converter ;-) | 14:58 |
| smoser | or maybe i'll just write that instead | 14:58 |
| ahasenack | smoser: it's in awk, you mean, not shell | 15:04 |
| ahasenack | ;) | 15:04 |
| smoser | well, yeah, sh2go would have to include implementations of sed and awk and cat and perl and wget.... | 15:05 |
| smoser | i leave that as an exercise to you | 15:05 |
| fwereade | jimbaker: I'm a bit confused about the machine_id thing: I understand we can't use the instance ID, but is there really no way to figure out the machine ID giver a ProviderMachine? | 15:06 |
| fwereade | given a ^^^ | 15:06 |
| jimbaker | fwereade, perhaps the better api would be to have the ProviderMachine know its logical machine id | 15:07 |
| fwereade | fwereade: I would personally strongly favour that, but not enough to actually disapprove of the branch ;) | 15:08 |
| fwereade | er, I have no idea where I got this habit of talking to myself :/ | 15:08 |
| jimbaker | fwereade, it looks like i'm going to do more refactoring anyway in light of the conversation i just had w/ niemeyer | 15:09 |
| fwereade | jimbaker: I saw that | 15:09 |
| jimbaker | it would definitely clean things up, so that's a good thing | 15:09 |
| fwereade | jimbaker: I'm not sure the scope we're talking about though | 15:10 |
| jimbaker | fwereade, i don't believe the scope is very much at all, fortunately | 15:10 |
| fwereade | jimbaker: cool, as long as we're not planning to change every single operation from a class to a function | 15:11 |
| fwereade | because that feels a bit drastic to me | 15:11 |
| jimbaker | fwereade, i'm not going to do a general refactoring of the code, but a small one to try out just using functions for the securitygroup instead of java-like commands | 15:11 |
| fwereade | jimbaker: cool | 15:11 |
| jimbaker | fwereade, if that looks good, the next step is to have a refactoring branch that can apply it to the rest of the code in ec2 provider | 15:12 |
| fwereade | jimbaker: sounds good to me | 15:12 |
| jimbaker | fwereade, maybe that branch can remove having both MachineProvider and ProviderMachine ;) | 15:13 |
| fwereade | jimbaker: <3, that gives me a headache | 15:14 |
| jimbaker | fwereade, indeed. i know why that came about, but it must die ;) | 15:14 |
| fwereade | jimbaker: anyway, I'l like the machine_id thing to go, but it feels separate to me -- we'll need some independent code to make machine_id gettable given a machine | 15:15 |
| fwereade | jimbaker: so I don't think it's a reason to disapprove | 15:15 |
| fwereade | jimbaker: but I'm not sure how to track my concern -- just file another bug, and point out that it dirties up the port interface? | 15:16 |
| jimbaker | fwereade, i think in general we would use "approve" for a branch at this point if the remaining changes are obvious and agreed upon. but it probably is best to just say "needs fixing" | 15:17 |
| fwereade | jimbaker: cool, thanks | 15:17 |
| jimbaker | fwereade, so no more bug, just point it out in the review | 15:17 |
| RoAkSoAx | fwereade: i. | 15:26 |
| RoAkSoAx | fwereade: o/ | 15:26 |
| fwereade | RoAkSoAx: er, what? | 15:32 |
| RoAkSoAx | fwereade: was just saying hi (o/) | 15:32 |
| fwereade | RoAkSoAx: heyhey :) | 15:32 |
| RoAkSoAx | fwereade: heh how's it going | 15:33 |
| fwereade | RoAkSoAx: I ought to recognise translated gestures ;) | 15:33 |
| fwereade | RoAkSoAx: not too shabby; yourself? | 15:33 |
| RoAkSoAx | fwereade: good good | 15:34 |
| RoAkSoAx | fwereade: bug squashing day for me | 15:34 |
| RoAkSoAx | fwereade: any updates on the key related stuff? | 15:35 |
| === andreas__ is now known as ahasenack | ||
| fwereade_ | RoAkSoAx: hey again :) | 15:38 |
| RoAkSoAx | fwereade_: hehe troubles with xchat? | 15:38 |
| fwereade_ | RoAkSoAx: yeah, today seems to be a stuff-breaking-randomly day | 15:39 |
| fwereade_ | RoAkSoAx: seem to have VMs actually installing though which is reassuring | 15:39 |
| RoAkSoAx | fwereade_: yeah either installer or mirror/proxy issue | 15:41 |
| RoAkSoAx | fwereade_: any luck on the key thingy? | 15:42 |
| fwereade_ | RoAkSoAx: niemeyer explained how config stuff gets to other machines, if I think a mo I might find it again ;) | 15:42 |
| RoAkSoAx | fwereade_: cool | 15:43 |
| RoAkSoAx | fwereade_: no I think that by the time of the sprint, we should have everything merged in trunk, or, at least have a common branch | 15:44 |
| fwereade_ | RoAkSoAx: yep, at least there's a way we can do it ;) | 15:44 |
| RoAkSoAx | fwereade_: cool, let's coordinate that tomorrow as today I'll be working on unrelated stuff | 15:47 |
| * hazmat heads out to lunch | 15:59 | |
| kim0 | TeTeT: glad to see you o/ :) | 15:59 |
| SpamapS | m_3: hey, how's that NFS formula looking? | 15:59 |
| TeTeT | kim0: the class starts in one hour, right? | 15:59 |
| kim0 | TeTeT: yes | 16:00 |
| kim0 | thanks man | 16:00 |
| SpamapS | RoAkSoAx: hey, how did the cloud days presentation go? I missed it. | 16:00 |
| RoAkSoAx | SpamapS: i think it went well | 16:00 |
| kim0 | m_3: please ping me when u're back :) | 16:00 |
| RoAkSoAx | SpamapS: we couldn't demo anything as there were installation/installer issues | 16:01 |
| SpamapS | RoAkSoAx: thats pretty understandable given the number of moving parts involved in bare metal deployment. | 16:01 |
| RoAkSoAx | SpamapS: indeed | 16:02 |
| adam_g | jimbaker: i used your branch pretty extensively last night while working on some formulas, works well! | 16:05 |
| jimbaker | adam_g, glad to hear that! | 16:05 |
| niemeyer | Lunch time here | 16:09 |
| niemeyer | Back for more reviews in a moment | 16:09 |
| SpamapS | Hrm.. so I am running into an interesting situation that I think we need an answer to. | 16:25 |
| SpamapS | Basically, I have a service config that affects the relationships a service has. I want to be able to set the database that a service uses. | 16:26 |
| SpamapS | adam_g: did you see that service configs have landed? | 16:27 |
| adam_g | SpamapS: i haven't but thats cool, show me how to use it over beer :) | 16:29 |
| SpamapS | adam_g: Indeed. :) It should let you get rid of any hard codes you have in the openstack stuff | 16:30 |
| SpamapS | adam_g: can I say that there are formulas for openstack in my talk? | 16:30 |
| adam_g | SpamapS: cool, maintaining that has bitten me a bunch | 16:33 |
| adam_g | SpamapS: yah, definitely! i wanted to actually "release" those formulas out o fmy +junk branches but a bunch of openstack bugs were introduced last week that broke everything | 16:33 |
| * SpamapS is almost done w/ slides.. just need to add a few more lolcatz | 16:33 | |
| SpamapS | adam_g: son of a! ;) | 16:33 |
| SpamapS | hrmph.. 13 slides.. 40 minute presentation. I don't know if 3 minutes per slide is a good average | 16:51 |
| m_3 | SpamapS: sorry, been head-down on a stack for ubuntu-classroom | 16:51 |
| SpamapS | m_3: no worries. :) | 16:52 |
| m_3 | ec2 picks now to be dog-slow | 16:53 |
| kim0 | m_3: if that demo is broken, feel free to replace with any formula that works :) | 17:02 |
| m_3 | kim0: thanks | 17:03 |
| m_3 | kim0: still testing | 17:03 |
| kim0 | rock n roll | 17:03 |
| m_3 | kim0: you know how to get the screen bigger in byobu classroom? | 17:03 |
| m_3 | kim0: it's maxing out at half the screen | 17:03 |
| kirkland | m_3: the host session needs to be a bigger terminal | 17:04 |
| kirkland | m_3: resize the terminal running the host session, and press F5 in byobu | 17:04 |
| m_3 | kim0: perfect... thanks! | 17:04 |
| SpamapS | m_3: are you practicing or is this going now? | 17:08 |
| m_3 | kim0: scratch that | 17:08 |
| m_3 | kirkland: perfect... thanks! | 17:08 |
| m_3 | SpamapS: at 1800UTC | 17:08 |
| m_3 | think I'll just set up the stack and talk about it rather than wait for it | 17:09 |
| kirkland | m_3: which reminds me, i need to test your updates to byobu-classroom and propose it for principia | 17:10 |
| kirkland | m_3: i'll try to do that today | 17:10 |
| SpamapS | kirkland: you're a composer, just push :) | 17:11 |
| m_3 | kirkland: simple update... oneliner | 17:11 |
| kirkland | SpamapS: k | 17:11 |
| kirkland | m_3: kewl, just want to retest | 17:11 |
| === andreas__ is now known as ahasenack | ||
| fwereade_ | must dash, later all | 17:22 |
| SpamapS | http://spamaps.org/files/ensemble-oscon-2011.odp | 17:40 |
| SpamapS | Note that it doesn't make much sense w/o the notes | 17:40 |
| niemeyer | SpamapS: Is it done, or is it to-do? | 17:42 |
| SpamapS | niemeyer: Thursday afternoon. | 17:42 |
| SpamapS | to-do | 17:42 |
| SpamapS | http://www.oscon.com/oscon2011/public/schedule/detail/18367 | 17:43 |
| niemeyer | SpamapS: Awesome! | 17:43 |
| niemeyer | SpamapS: Re. config vs. relations, yeah, we'll need dynamic relations at some point | 17:43 |
| SpamapS | niemeyer: I think its a corner case that can be dodged right now | 17:43 |
| SpamapS | niemeyer: but one that will come up as diagrams get bigger and bigger | 17:44 |
| SpamapS | I wonder if there couldn't just be a command... refresh-relations .. that just tells the local unit agent to re-run all the hooks as if the relation data had changed. | 17:45 |
| niemeyer | SpamapS: Absolutely.. I don't have a good design in mind for it yet, to be honest, but I think we can do something good | 17:45 |
| niemeyer | SpamapS: It's a bit tricky because we have to take into account dependency resolution too | 17:46 |
| niemeyer | SpamapS: So in terms of ordering, we should get dependency resolution in first, so that we can implement this in light of the understanding that dep-resolv will provide | 17:46 |
| SpamapS | Yeah.. I'm less excited about dependency resolution than you guys are. :) | 17:47 |
| SpamapS | I can't really articulate why tho | 17:48 |
| niemeyer | SpamapS: Well, it's not that I'm terribly excited either. I'm much more excited about stacks | 18:05 |
| niemeyer | SpamapS: But feels like a very nice convenience we want to get in place | 18:05 |
| SpamapS | Yeah, stacks! | 18:08 |
| hazmat | i think dynamic relations i think config based dependencies for generic formulas, that run apps, and have app spec'ified deps | 18:11 |
| niemeyer | hazmat: parsing failure :) | 18:13 |
| SpamapS | I think hazmat was just using lossy compression | 18:14 |
| SpamapS | up the bitrate a bit | 18:14 |
| hazmat | connection loss | 18:15 |
| hazmat | but just as a common example a rails or wsgi app that checkouts from vcs, and deploys the app.. but it has to assume currently a set of optional/required deps representing app infrastructure choices, does it use memcached or postgres v. mysql v. nosql. | 18:17 |
| hazmat | really their runtime dynamic deps, and what we capture are static ones | 18:17 |
| niemeyer | hazmat: Right.. that's exactly the context | 18:17 |
| hazmat | niemeyer, effectively we're another cli api.. for declaring additional deps.. although we lack an execution context that's service local rather than unit local. | 18:19 |
| niemeyer | hazmat: We don't declare additional deps.. the dependencies can be pre-defined, since they are always fixed | 18:20 |
| niemeyer | hazmat: Unless there's some genetic voodoo within the formula :-) | 18:20 |
| niemeyer | hazmat: E.g. the hooks will be pre-defined | 18:22 |
| niemeyer | There's very cool stuff we can do around this.. | 18:23 |
| niemeyer | Hopefully before 2017 | 18:23 |
| hazmat | :-) | 18:23 |
| _mup_ | Bug #816581 was filed: Ensemble needs easy end user initial configuration <Ensemble:New> < https://launchpad.net/bugs/816581 > | 18:32 |
| _mup_ | ensemble/expose-hooks r282 committed by jim.baker@canonical.com | 18:36 |
| _mup_ | Merged trunk | 18:36 |
| === niemeyer_ is now known as niemeyer | ||
| niemeyer | jimbaker: robus-hook-exit looks nice in general, but I'm missing some of the context about why it's needed | 18:49 |
| niemeyer | jimbaker: I've posted some comments there | 18:49 |
| === daker is now known as daker_ | ||
| jimbaker | niemeyer, ok. i will take a look at your comments | 18:50 |
| niemeyer | jimbaker: Feel free to bring any of them up for debate here, please | 18:50 |
| jimbaker | niemeyer, yes, i assume you read the corresponding bug? | 18:51 |
| niemeyer | jimbaker: I've read your merge proposal description, the code, and the test | 18:51 |
| jimbaker | niemeyer, re the refactoring, sounds good to me, again i was following the convention in this code | 18:52 |
| niemeyer | jimbaker: Which convention? | 18:52 |
| jimbaker | niemeyer, so does it make sense the scenario being described, that a hook script may exit, but w/o its file descriptors being closed? | 18:52 |
| jimbaker | niemeyer, the convention of the existing file | 18:52 |
| niemeyer | jimbaker: Which convention, specifically? | 18:53 |
| jimbaker | niemeyer, the usage of the nested functions cleanup_process, which i followed in doing cleanup_ended | 18:54 |
| niemeyer | jimbaker: Ok, I see | 18:54 |
| niemeyer | jimbaker: When introducing new logic, some reevaluation is needed to ensure the style used still makes sense | 18:54 |
| jimbaker | niemeyer, sure, we just had that discussion earlier ;) | 18:55 |
| niemeyer | jimbaker: It might not be a big deal with a small closure.. when you have more than a full screen of closure which doesn't really use the fact it's a closure in a good way, something isn't right | 18:55 |
| jimbaker | niemeyer, correct neither nested function closes over variables | 18:56 |
| niemeyer | Right, anyway.. mionr | 18:56 |
| niemeyer | mionr | 18:56 |
| niemeyer | miNNOr | 18:56 |
| niemeyer | :-0 | 18:56 |
| niemeyer | jimbaker: So | 18:56 |
| niemeyer | jimbaker: On the actual meaning of the branch | 18:56 |
| jimbaker | niemeyer, i think it is captured succinctly in a hook like this one: | 18:57 |
| niemeyer | jimbaker: I don't understand the scenario.. a hook exiting without fds being closed? How's that a problem? | 18:57 |
| jimbaker | sleep 0.05 && echo "Slept for 50ms" && sleep 1 && echo "Slept for 1s" && sleep 1000000 & | 18:57 |
| jimbaker | some computation, some output | 18:57 |
| jimbaker | and of course the very relevant & at the end to fork it in the background | 18:58 |
| hazmat | jimbaker, but how is that an exceptional condition outside of its a taking a long time | 18:58 |
| hazmat | :-) | 18:58 |
| niemeyer | jimbaker: Ok.. sorry, I'm not trying to be difficult in any way. How's that an issue? | 18:58 |
| jimbaker | hazmat, niemeyer - this arises in certain formulas where we have badly behaving code | 18:58 |
| niemeyer | jimbaker: This feels pretty normal? | 18:59 |
| hazmat | rabbitmq specifically per the bug | 18:59 |
| jimbaker | so in particular adam_g brought it up | 18:59 |
| hazmat | niemeyer, it shouldn't be normal but it exists | 18:59 |
| niemeyer | What exists? | 18:59 |
| jimbaker | i worked on the branch because i made the original change from exited to ended semantics | 18:59 |
| niemeyer | hazmat: It's a problem, and it exists.. ookaaay :-) | 18:59 |
| hazmat | and this adds robustness to how we handle hooks, we had switched in the past to get better testing output | 18:59 |
| jimbaker | thomas herve diagnosed it | 18:59 |
| niemeyer | jimbaker: What was the problem he diagnosed? | 19:00 |
| niemeyer | jimbaker: and how is the branch fixing it? | 19:00 |
| hazmat | indeed.. that was very helpful.. he pointed out the difference between processEnded vs processExited on the process protocol | 19:00 |
| jimbaker | that child processes were not properly closing file descriptors because how they were redirecting things | 19:01 |
| hazmat | in the context of a rabbitmq, which had some odd behavior per its start scripts | 19:01 |
| jimbaker | hazmat, correct | 19:01 |
| jimbaker | and apparently this not so uncommon and there's an easy fix for us | 19:01 |
| niemeyer | jimbaker: How not closing file descriptors affect the way process ending happens? | 19:02 |
| hazmat | niemeyer, its waiting for the file descriptors to be closed | 19:02 |
| hazmat | vs waiting for the process to exit | 19:02 |
| jimbaker | niemeyer, waiting on process ending means waiting for the FDs to be closed | 19:02 |
| jimbaker | niemeyer, so this is generally the right thing to do because it means we fully capture useful stdout/stderr for logging | 19:02 |
| jimbaker | niemeyer, i had changed the semantics from exited to ended when i standardized the logging | 19:03 |
| jimbaker | niemeyer, as you may recall, we were doing some odd things there that ultimately was just making the tests to *usually* wait long enough for the logs to be complete | 19:03 |
| niemeyer | jimbaker: No, it doesn't mean that in general.. if you fork a process, and wait for it to exit with normal system calls, you don't wait for FDs to be closed | 19:04 |
| jimbaker | niemeyer, correct | 19:04 |
| jimbaker | niemeyer, so that's the distinction between waiting on process exited vs process ended | 19:04 |
| jimbaker | niemeyer, the twisted process protocol supports both, since they both have some nice qualities | 19:05 |
| SpamapS | m_3: is your mongo formula in principia yet? | 19:05 |
| niemeyer | jimbaker: Which fd is processEnded holding out on? stdin? | 19:05 |
| jimbaker | niemeyer, the FD is going to be stdout or stderr | 19:05 |
| jimbaker | or both | 19:05 |
| jimbaker | niemeyer, in this particular test hook that i just pasted here, it's stdout | 19:06 |
| m_3 | SpamapS: nope, I just got hazmat's and stripped it of replication | 19:06 |
| m_3 | SpamapS: negronjl has one inbound that I expect will be nice | 19:06 |
| jimbaker | niemeyer, so because we capture these streams for logging, ideally we work with them | 19:06 |
| niemeyer | jimbaker: There's some detail missing still.. if a process exits, you get a SIGPIPE | 19:07 |
| jimbaker | niemeyer, in general this doesn't impact hook code - the process exits, it's done for the invoker. however if there's still more output, these are still written to logs | 19:07 |
| negronjl | m_3: I'll push it soon .. | 19:07 |
| niemeyer | jimbaker: and the process ended | 19:07 |
| niemeyer | jimbaker: Your example shows a sleep going into background, and never returning | 19:08 |
| jimbaker | niemeyer, correct - a child process just hanging around just like what we see in real cases | 19:08 |
| jimbaker | niemeyer, who knows when it returns? | 19:09 |
| niemeyer | jimbaker: Hmm, ok, I think I start to see what you mean | 19:09 |
| jimbaker | niemeyer, in any event, in that case we reap them because we don't want processes like that around indefinitely | 19:09 |
| niemeyer | jimbaker: There's a child process, started by the hook, and we want it to continue running | 19:09 |
| niemeyer | jimbaker: Is that the case? | 19:09 |
| jimbaker | niemeyer, i chose 5 seconds because it's much larger than reasonable for good children, but doesn't matter in practice even w/ lots of bad children | 19:10 |
| niemeyer | jimbaker: Uh.. lost again | 19:10 |
| jimbaker | niemeyer, only for a little bit, just to let its logs settle | 19:10 |
| jimbaker | the actual reaper time probably would be fine w/ something like 200 ms | 19:10 |
| SpamapS | jimbaker: there are daemons that take a long time to start up .. but usually they don't let the parent die until they're ready for it to die. | 19:10 |
| jimbaker | SpamapS, correct - this doesn't impact such "good" children | 19:11 |
| jimbaker | niemeyer, so we are not trying to solve a larger problem of having time limits on hooks | 19:11 |
| SpamapS | In rabbit's case, it seems like we should report a bug in the init script that it needs to run w/ nohup | 19:11 |
| jimbaker | SpamapS, correct, that would be the normal simple way to get the desired behavior | 19:12 |
| SpamapS | which turns bad children into good children by first redirecting its own fds to dev null or a log | 19:12 |
| jimbaker | SpamapS, :) | 19:12 |
| m_3 | like long-term care insurance | 19:12 |
| jimbaker | the analogies just pour in | 19:12 |
| SpamapS | m_3: Great example node.js app btw.. | 19:12 |
| SpamapS | m_3: you may not have gotten much uptake on that... today is node.js day at OSCON ;) | 19:13 |
| m_3 | cool thanks man | 19:13 |
| hazmat | jimbaker, we are and there is a bug open for that, but that has other things it needs to take into account like respecting debug hooks which will break time limits.. a standard hook timeout though needs to be quite large (large installs come to mind). | 19:13 |
| m_3 | didn't know if I was going into too much detail | 19:13 |
| m_3 | lots of zzzz's I think | 19:13 |
| jimbaker | hazmat, correct, a much larger problem | 19:13 |
| SpamapS | m_3: The log of the session may prove useful to someone. :) | 19:13 |
| m_3 | wish there was a way to get the ajaxterm session too | 19:14 |
| niemeyer | jimbaker: Ok, I think I understand, and the approach looks good | 19:14 |
| m_3 | should create a screencast I guess | 19:14 |
| niemeyer | jimbaker: It just needs proper documentation | 19:14 |
| jimbaker | hazmat, i think such a solution should allow for measuring *useful* progress back to the agent | 19:14 |
| niemeyer | jimbaker: I'll read the handling of processEnded, just to make sure I'm indeed getting what happens there | 19:14 |
| jimbaker | niemeyer, cool, i will work on that | 19:14 |
| niemeyer | jimbaker: Thanks for the patience explaining it | 19:14 |
| jimbaker | niemeyer, np | 19:14 |
| jimbaker | SpamapS, speaking of node.js, seeing any golang interest at oscon? | 19:15 |
| SpamapS | jimbaker: I'm not there yet. :-/ | 19:15 |
| SpamapS | trying to keep up with keynotes and goings on so I won't be lost when I arrive on Thursday | 19:16 |
| jimbaker | SpamapS, cool, makes sense | 19:16 |
| niemeyer | jimbaker: Are you able to reproduce the problem easily? | 19:16 |
| adam_g | jimbaker: google people led a 3.5 hour go tutorial this morning | 19:19 |
| adam_g | niemeyer: the problem is easily reproduced deploying lp:principia/rabbitmq-server | 19:19 |
| SpamapS | Hey guys, I could use feedback on this.. please view w/ the notes .. http://spamaps.org/files/ensemble-oscon-2011.odp | 19:19 |
| niemeyer | adam_g: Yeah, by easily I was wondering about a trivial test case | 19:20 |
| niemeyer | I suspect the real issue here is that Python is eating SIGCHLD | 19:20 |
| niemeyer | which is the standard way by which a parent gets to know it child has died | 19:20 |
| jimbaker | niemeyer, pretty certain that the ProcessProtocol stuff is quite robust with respect to that | 19:24 |
| jcastro | SpamapS: too many lolcats, that's like 2 years ago | 19:24 |
| jimbaker | niemeyer, i can readily see the child process not completing its writes to output before process exit, simply by looping test_invoker | 19:25 |
| jimbaker | niemeyer, on this laptop maybe occurs 50% of time (don't recall specifics!) if i don't have the yields on process ended | 19:26 |
| jimbaker | niemeyer, so that's often enough that one really doesn't need to loop ;) | 19:27 |
| niemeyer | jimbaker: I think I get it.. I'm wondering mostly about this sentence from therve now: | 19:29 |
| niemeyer | """I don't think that bug is related to what's done during the install hook, fwiw. It happened to me with an empty install script.""" | 19:29 |
| niemeyer | jimbaker: There's no "sleep" in this case, as per your example | 19:30 |
| niemeyer | jimbaker: So why would it remain un-ended | 19:30 |
| ahs3 | probably a dumb n00b question...is there a way to have ensemble install a service on one or more existing machines (real ones, not EC2 instances)? i'm not finding it in the docs, if there is... | 19:31 |
| jimbaker | niemeyer, i'm reading that a bit differently - there's some actual hook being executed, just not an install one | 19:31 |
| jimbaker | or at least just a trivial "empty" install one | 19:32 |
| jimbaker | niemeyer, so in particular i'm looking at reply #9 where we start to move into actual diagnosis | 19:32 |
| niemeyer | jimbaker: Ah, interesting, could be | 19:32 |
| niemeyer | jimbaker: That'd make more sense | 19:32 |
| hazmat | ahs3, that's a good question.. not at the moment re a standalone machine, there is work being done today for physical machine integration is in the context of using something like orchestra (cobbler) | 19:32 |
| jimbaker | niemeyer, yeah, i'd be very concerned if a empty hook would act like an infinite sleep ;) | 19:33 |
| hazmat | for setting up ensemble deployment with a physical machine data center | 19:33 |
| niemeyer | jimbaker: Exactly | 19:33 |
| jimbaker | niemeyer, but again we would fix that in the other one, bug 705433 | 19:34 |
| _mup_ | Bug #705433: Hooks need to have an enforceable timeout. <hooks> <Ensemble:New> < https://launchpad.net/bugs/705433 > | 19:34 |
| niemeyer | def maybeCallProcessEnded(self): | 19:34 |
| niemeyer | # we don't call ProcessProtocol.processEnded until: | 19:34 |
| niemeyer | # the child has terminated, AND | 19:34 |
| niemeyer | # all writers have indicated an error status, AND | 19:34 |
| niemeyer | # all readers have indicated EOF | 19:34 |
| niemeyer | # This insures that we've gathered all output from the process. | 19:34 |
| hazmat | jimbaker, well an empty hook and a timeout are different, the question is really do want to use processExited instead | 19:35 |
| ahs3 | hazmat: hrm. thx. i thought that might be the case. what i would especially like is something that assumes a machine is already up, running and available, and then just puts the service on it. | 19:35 |
| jimbaker | hazmat, to clarify: this branch now uses processExited | 19:35 |
| hazmat | jimbaker, indeed it does both | 19:35 |
| niemeyer | jimbaker: Beautiful.. all looks great | 19:36 |
| jimbaker | hazmat, the only thing it uses processEnded for is to do the loseConnection handshake. unless the time between processExited and processEnded is larger than a ludicrous amount (5 s), in which case it simply kills the process with loseConnection | 19:36 |
| hazmat | jimbaker, yeah.. the branch looked good to me | 19:36 |
| niemeyer | jimbaker: Just a sentence or two highlighting the distinction between processEnded and Exited, given that these names are entirely unhelpful | 19:36 |
| jimbaker | i expect closing < 50 ms. 5 seconds ensures the probability of delays in normal closing to be exceedingly low, which seems a reasonable cost | 19:37 |
| niemeyer | jimbaker: This, specifically, will bite us when we read it again: | 19:37 |
| niemeyer | + # The corresponding process has ended, so output streams have | 19:37 |
| niemeyer | jimbaker: The process has already ended by the time processExited was called | 19:37 |
| niemeyer | jimbaker: (in unix/non-twisted lingo) | 19:38 |
| hazmat | jimbaker, the long inline functions seem a little strange stylistically, but thats minor | 19:38 |
| jimbaker | hazmat, yeah, no worries, they are moving to our established convention of _ methods since they are not actual closures (in the sense of actually closing over a non-empty set of variables) | 19:39 |
| jimbaker | hazmat, i was simply following the convention in that particular file, but it | 19:39 |
| jimbaker | represents somewhat earlier code for us | 19:40 |
| niemeyer | jimbaker: The convention is still the same.. we often put short local snippets in-context, but for 40+ lines the convention changes | 19:40 |
| hazmat | indeed that was so last year ;-) | 19:40 |
| niemeyer | as hazmat says, no big deal.. that's what reviews are for | 19:41 |
| jimbaker | niemeyer, oh sure, i think we all understand what's what | 19:41 |
| niemeyer | jimbaker: Cool, thanks again for the explanation | 19:42 |
| niemeyer | jimbaker: Had no idea about the processEnded concept used by Twisted | 19:42 |
| jimbaker | niemeyer, until this came up, neither did i, that's for certain | 19:42 |
| niemeyer | hazmat: have you looked over the branch? | 19:43 |
| jimbaker | but it makes perfect sense in the overall context of daemonization | 19:43 |
| hazmat | niemeyer, i have | 19:43 |
| niemeyer | jimbaker: Not sure it does.. the only use case I've seen so far was a bug. ;-D | 19:43 |
| hazmat | i think i looked at it when i implemented it, and used exited for the initial implementation, but i definitely understood and agreed why it was switched, and this additional robustness around usage looks good to me | 19:44 |
| niemeyer | hazmat: Cool, would you mind to put your concerns in the MP if you have any, or +1 it? | 19:44 |
| hazmat | niemeyer, sure | 19:45 |
| niemeyer | hazmat: Thanks | 19:45 |
| niemeyer | hazmat: This MP is empty: https://code.launchpad.net/~hazmat/ensemble/security-connection/+merge/68621 | 19:50 |
| niemeyer | hazmat: Is it missing a push? | 19:50 |
| hazmat | perhaps.. let me check | 19:53 |
| hazmat | i think that was one of the borked branches | 19:54 |
| hazmat | niemeyer, it says its up to date revno 285 | 19:54 |
| hazmat | niemeyer, to answer the mp question lp is on crack for that branch | 19:55 |
| _mup_ | Bug #816621 was filed: Ensemble doesn't appear to set up a complete environment while running the installation scripts and hooks <Ensemble:New> < https://launchpad.net/bugs/816621 > | 19:55 |
| niemeyer | hazmat: Cool | 19:57 |
| niemeyer | I'll step out for a coffee break.. | 19:57 |
| hazmat | negronjl, re cloud foundry bug above, did you have ruby's eventmachine installed via package locally? | 20:01 |
| hazmat | negronjl, i'm wondering if the issue is dep not specified in packaging | 20:02 |
| SpamapS | jcastro: I need a new meme. :) | 20:03 |
| === koolhead17 is now known as koolhead17|afk | ||
| hazmat | negronjl, the package software is depending on eventmachine, and its not being installed via package per the hook logs, unless there's a private copy to cloudfoundry, it definitely seems like a missing dep issue. | 20:05 |
| SpamapS | jcastro: should I go with fuuuuuuuuuuu instead? | 20:11 |
| jcastro | SpamapS: you started with a terminator-skynet meme | 20:12 |
| jcastro | SpamapS: "ensemble with me if you want to live." | 20:12 |
| jcastro | SpamapS: deployment day = judgement day. I mean, there's so many places to go with this | 20:13 |
| SpamapS | jcastro: my reason for lolcats was to say that ensemble was invented primarily to help process all of the pictures of cats incoming from smart phone users.. but it never materialized | 20:13 |
| SpamapS | jcastro: This is true.. and open source can be John Connor's rebels. ;) | 20:14 |
| jcastro | SpamapS: use the fuuuuuu-maker thing from reddit | 20:14 |
| jcastro | wait, no, that's a bad idea, that will just lead to hilarity | 20:15 |
| niemeyer | hazmat: The contributor's page is up-to-date already | 20:23 |
| niemeyer | s/'// | 20:23 |
| hazmat | niemeyer, url? | 20:26 |
| niemeyer | hazmat: http://www.canonical.com/contributors | 20:26 |
| hazmat | niemeyer, cool, thanks | 20:29 |
| SpamapS | jcastro: I want the last 20 minutes back... distractions... http://spamaps.org/files/hadoop-rage.png | 20:33 |
| hazmat | :-) | 20:34 |
| jcastro | I new you wouldn't let me down | 20:35 |
| jcastro | knew even | 20:35 |
| SpamapS | jcastro: Not sure thats hilarity.. its a little too commercial for me. ;) | 20:45 |
| negronjl | hazmat: All the deps are satisfied. If you run the script manually, everything works just fine. | 20:54 |
| negronjl | hazmat: It only breaks when run via ensemble | 20:54 |
| hazmat | SpamapS, slides look nice | 21:06 |
| niemeyer | hazmat: lp is seriously wedged on that branch | 21:13 |
| niemeyer | % bzr branch lp:~hazmat/ensemble/security-connection | 21:13 |
| niemeyer | bzr: ERROR: Not a branch: "/home/kapil/canonical/ensemble/mine/security/.bzr/pipes/security-connection/". | 21:13 |
| niemeyer | hazmat: !!! | 21:13 |
| niemeyer | SpamapS: Good stuff in the slides indeed | 21:24 |
| hazmat | niemeyer, ugh | 21:34 |
| hazmat | niemeyer, locally it looks fine.. trying with push --overwrite | 21:36 |
| hazmat | yeah.. still nothing | 21:36 |
| niemeyer | hazmat: Trying branching to the side, maybe? | 21:37 |
| niemeyer | hazmat: Worth saving the whole tree somewhere else first! | 21:37 |
| niemeyer | hazmat: To avoid losing any work | 21:37 |
| hazmat | niemeyer, its the middle branch of a pipeline already, additional branches have pushed succesfully | 21:37 |
| _mup_ | ensemble/trunk-merge r273 committed by kapil.thangavelu@canonical.com | 21:38 |
| _mup_ | merge trunk | 21:38 |
| hazmat | niemeyer, redid the merge proposal with a copy of the branch | 21:44 |
| niemeyer | hazmat: Phew, glad it worked | 21:44 |
| niemeyer | That was weird | 21:45 |
| kirkland | m_3: what's your LP id? | 21:45 |
| kirkland | m_3: https://launchpad.net/~mark-mims ? | 21:46 |
| kirkland | m_3: okay, I'm sufficiently convinced that's you :-P | 21:48 |
| m_3 | kirkland: yes, ~mark-mims | 21:52 |
| RoAkSoAx | lol | 21:54 |
| * RoAkSoAx once again remembers the pains of having a nick name different for a LP id... :) | 21:54 | |
| kirkland | RoAkSoAx: for the love, yes, standards! | 21:55 |
| RoAkSoAx | kirkland: tried to change my nick to lp id but it was simply better to keep it as is cause nobody knew me with the new nicknam,e :) | 21:56 |
| niemeyer | hazmat is the review queue lord | 21:57 |
| hazmat | niemeyer, slave? ;-) | 21:57 |
| niemeyer | hazmat: Nah, I'm the slave | 21:57 |
| niemeyer | :-) | 21:57 |
| lynxman | hey guys, just wanted to share the news | 22:02 |
| lynxman | Ensemble is already in Macports | 22:02 |
| lynxman | lynxman@kreuzberg:~ $ sudo port search ensemble | 22:02 |
| lynxman | ensemble @0.5 (python, net) Ensemble is a next generation service orchestration framework. | 22:02 |
| lynxman | err false alarm, I'm too sleepy :) | 22:03 |
| lynxman | sorry | 22:03 |
| lynxman | :D | 22:05 |
| SpamapS | well, cool anyway ;) | 22:05 |
| m_3 | +1 | 22:05 |
| niemeyer | lynxman: neat :-) | 22:10 |
| lynxman | thought the package was just added to the repo, as soon as it's there I'll let you know :) | 22:11 |
| niemeyer | jimbaker: Finally got to review your debug-log-relations branch | 22:38 |
| niemeyer | jimbaker: Some comments, but good stuff overall | 22:38 |
| niemeyer | jimbaker: Sorry for the delay | 22:38 |
| daker | hazmat, sorry to disturb you, on this page http://www.canonical.com/contributors there is no mention of "ensemble" | 22:49 |
| niemeyer | daker: Indeed.. feel free to send it to kapil himself | 22:51 |
| niemeyer | daker: In addition to the email there | 22:51 |
| daker | niemeyer, i send what ? don't tell i need to download the pdf, fill it with my name, then scan it. | 22:53 |
| niemeyer | daker: Ok, I won't tell it.. :-) | 22:54 |
| hazmat | daker, afaik, that's what needs to be done for contribution to any canonical sponsored software project, i guess a photo would suffice in lieu of a scan | 22:55 |
| daker | that sucks :/ | 22:56 |
| niemeyer | daker: Sorry for the boilerplate.. note this is somewhat normal on contributions | 22:57 |
| SpamapS | Heh.. so.. I'm preparing to upload trunk to Ubuntu .. and I've started the process of running the test suite when the package builds. | 23:02 |
| SpamapS | It doesn't fail the build.. | 23:02 |
| SpamapS | But it will record the results in /usr/share/doc/ensemble/test-results.txt ... so we can start the process of fixing bugs where tests fail on the buildd. | 23:03 |
| _mup_ | Bug #816736 was filed: debian dir gets in the way of packaging and is no longer necessary <Ensemble:New> < https://launchpad.net/bugs/816736 > | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
