| === daker_ is now known as daker | ||
| hazmat | g'morning | 12:01 |
|---|---|---|
| niemeyer | Good morning! | 12:50 |
| hazmat | niemeyer, g'morning | 13:01 |
| niemeyer | hazmat: Hey man | 13:02 |
| niemeyer | hazmat: How did reviews go yesterday? | 13:45 |
| niemeyer | I'll dive in myself now | 13:45 |
| niemeyer | Beautiful queue | 13:45 |
| niemeyer | fwereade: So | 14:19 |
| niemeyer | fwereade: The problem we have in the schema issue is error reporting | 14:20 |
| niemeyer | fwereade: and it happens because all of the cases in the OneOf fail to match | 14:20 |
| niemeyer | fwereade: So it just picks the last one randomly | 14:20 |
| fwereade | niemeyer: yep | 14:20 |
| niemeyer | fwereade: Which is bad | 14:20 |
| niemeyer | fwereade: I think we can do something much better, and very simple too | 14:20 |
| niemeyer | fwereade: I suggest we introduce a new kind of "case selection" | 14:20 |
| fwereade | niemeyer: cool | 14:20 |
| niemeyer | fwereade: Which is based on picking an entry from the enclosed dictionary | 14:21 |
| fwereade | niemeyer: yep, sounds sensible, I think | 14:22 |
| niemeyer | fwereade: Let me come up with an example to make it clear.. just looking at the code | 14:22 |
| niemeyer | fwereade: SelectDict("type", {"ec2": subschema, "orchestra": otherschema}) | 14:23 |
| fwereade | niemeyer: was doing almost exactly the same as you :) | 14:24 |
| fwereade | fwereade: well then, I'll roll that in with the boot-only branch and hopefully sumbit shortly | 14:25 |
| niemeyer | fwereade: Support for that in schema is a nice independent branch (hint! hint! ;_) | 14:25 |
| fwereade | niemeyer: I was attempting to talk to you there :/ | 14:25 |
| fwereade | niemeyer: ah-ha | 14:25 |
| fwereade | niemeyer: sounds like a plan | 14:25 |
| fwereade | niemeyer: and the other one just waits on that? | 14:26 |
| niemeyer | fwereade: Doesn't have to wait | 14:26 |
| niemeyer | fwereade: Merge it into the new branch | 14:26 |
| niemeyer | fwereade: I mean, merge the pre-requisite into the follow up | 14:26 |
| fwereade | niemeyer: ...and then the followup's diff-with-trunk just gets smaller once the prerequisite is in? | 14:27 |
| niemeyer | fwereade: Precisely | 14:30 |
| fwereade | niemeyer: cool, so long as nobody ends up spending time reviewing the bits of the followup that come from the prerequisite before the prerequisite gets merged | 14:31 |
| fwereade | niemeyer: thanks :) | 14:31 |
| niemeyer | fwereade: _If_ the pre-requisite hasn't been merged, you can point out in the merge proposal that there is a pre-requsite branch | 14:31 |
| niemeyer | fwereade: There's a special field for it | 14:31 |
| fwereade | niemeyer: I saw that, I wasn't clear what actual effect it had | 14:32 |
| niemeyer | fwereade: It's informational, and gets the diff correctly | 14:33 |
| fwereade | niemeyer: the implication seemed to me to be that prereq *wasn't* merged into followup, but that it wouldn't make sense to merge followup into trunk until prereq was in | 14:33 |
| niemeyer | (in Launchpad) | 14:33 |
| fwereade | niemeyer: awesome | 14:33 |
| niemeyer | Absolutely | 14:33 |
| fwereade | niemeyer: thanks again :) | 14:33 |
| niemeyer | Merging the follow up into trunk without the pre-req being reviewed would be awkward | 14:33 |
| niemeyer | fwereade: No problem | 14:33 |
| fwereade | niemeyer: a thought | 15:10 |
| fwereade | niemeyer: a SelectDict demands that the values in the initialisation dict actually be dict-like schemas | 15:12 |
| niemeyer | fwereade: Yeah | 15:12 |
| fwereade | niemeyer: I'm inclined to create a SchemaMakesNoSenseError (or something) | 15:13 |
| niemeyer | fwereade: That's why it's called SelectDict (select which dict schema) | 15:13 |
| niemeyer | fwereade: That MakesNoSenseError to me as well :-) | 15:13 |
| fwereade | niemeyer: but I'm not sure it fits with the existing style, which seems to let you put anything in and just blow up on coerce | 15:14 |
| niemeyer | fwereade: Sorry, I don't actually get your original point | 15:14 |
| hazmat | fwereade, an explicit validate method might be nice | 15:14 |
| niemeyer | fwereade: coerce() is a fine place to validate that they are dictionaries for SelectDict as well? | 15:15 |
| niemeyer | fwereade: Not sure if that's your question | 15:15 |
| hazmat | hmm is_valid i guess | 15:15 |
| fwereade | niemeyer: not quite -- it's that the schema itself can be broken if we SelectDict("name", Int()) | 15:16 |
| niemeyer | hazmat: Changing the way validation works in schema is an unrelated issue to what fwereade is trying to address | 15:16 |
| hazmat | Nicke, not validation, but validity of the schema | 15:16 |
| hazmat | er. niemeyer ^ | 15:16 |
| fwereade | niemeyer: (for example), but I don't think we'd detect that made no sense until we tried to parse an actual schema | 15:16 |
| fwereade | niemeyer: just as hazmat says | 15:16 |
| niemeyer | fwereade: Tons of things will break if we pass arbitrary garbage in | 15:17 |
| fwereade | niemeyer: true :) | 15:17 |
| fwereade | niemeyer: which I guess is why I sought guidance before following my initial instinct to validate on schema creation | 15:17 |
| niemeyer | fwereade: Yeah, don't worry about it | 15:18 |
| fwereade | niemeyer, hazmat: I do still quite like the idea of schema validation but -- if nothing else -- I'll skip it in the interest of keeping the branch small ;) | 15:18 |
| niemeyer | fwereade: Schemas are static | 15:18 |
| niemeyer | fwereade: If you create a bad schema, testing will catch it | 15:18 |
| fwereade | niemeyer: cool | 15:19 |
| fwereade | niemeyer: thanks :) | 15:19 |
| niemeyer | fwereade: The whole point of schema.py is schema validation | 15:19 |
| niemeyer | fwereade: It does that through coerce | 15:19 |
| niemeyer | fwereade: Which is elegant,IMO, as it does both things at once | 15:19 |
| negronjl | hi guys: quick question re: open-port/close-port new hook commands.... can they be executed from the install/start/stop scripts ( I am more interested in the install script )? | 15:20 |
| fwereade | niemeyer: true :) | 15:20 |
| niemeyer | fwereade: Well, I guess validating that the schema validator is valid | 15:20 |
| niemeyer | fwereade: SchemaSchema? ;-) | 15:20 |
| fwereade | niemeyer: haha | 15:20 |
| fwereade | niemeyer: that's what I was trying to get at ;) | 15:20 |
| niemeyer | fwereade: That's only a good idea if you also implement SchemaSchemaSchema | 15:21 |
| * niemeyer runs | 15:21 | |
| niemeyer | negronjl: Yes, that must work | 15:21 |
| niemeyer | negronjl: If it doesn't, we're very interested on it | 15:21 |
| SpamapS | I'd like for schema validation to be more flexible | 15:21 |
| fwereade | niemeyer: yeah, I've been meaning to ask, where are the tests for our tests, hmm? :p | 15:22 |
| negronjl | niemeyer: perfect! I'll start modifying formulas and will provide feedback :) | 15:22 |
| SpamapS | while working on different providers, one can't use the same environments.yaml because the sections are invalid | 15:22 |
| SpamapS | it should just ignore these invalid sections | 15:22 |
| niemeyer | SpamapS: Not really.. it should validate these different providers | 15:25 |
| niemeyer | negronjl: Thanks! | 15:25 |
| SpamapS | niemeyer: but lxc and orchestra don't exist in trunk.. so I have to mv environments.yaml to environments.yaml.lxc .. mv environments.yaml.ec2 environments.yaml .. every time I switch | 15:27 |
| niemeyer | SpamapS: I see what you mean, yeah, that's painful | 15:28 |
| SpamapS | Whereas its really of no concern.. so I could see a warning, but a complete failure seems like coarse error handling. | 15:28 |
| niemeyer | SpamapS: This is pretty easy to sort out, though.. we just need a small branch being committed to trunk early on, which adds validation | 15:29 |
| SpamapS | What about people who want to write plugins? | 15:29 |
| niemeyer | SpamapS: That's a separate problem.. plugins are not supported right now | 15:29 |
| * SpamapS intends to change that soon if it pleases the court. ;) | 15:30 | |
| SpamapS | Have a friend who wants to write a jclouds provider to enable rackspace. | 15:30 |
| niemeyer | SpamapS: That's not a plugin.. we can very happily take contributions that implement new providers | 15:31 |
| SpamapS | He's been watching dev and isn't really interested in going through the song and dance to get it into Ensemble.. he just wants to *use* it. | 15:31 |
| SpamapS | And throw it up on github somewhere | 15:31 |
| SpamapS | I'm sure we could then suck it into Ensemble at some point.. | 15:32 |
| SpamapS | but de-coupling his dev process from ours should create a vibrant ecosystem of plugins | 15:32 |
| niemeyer | SpamapS: We certainly want to support plugins at some point, but right now that's not a priority | 15:33 |
| niemeyer | SpamapS: Plugins isn't just "you can throw stuff in" | 15:33 |
| SpamapS | I'm also interested in maintaining my LXC provider outside of Ensemble if its at all possible. | 15:33 |
| niemeyer | SpamapS: We need a stable API that people can trust | 15:33 |
| niemeyer | SpamapS: Otherwise next week his plugin is broken | 15:33 |
| SpamapS | Yeah, hard to write plugins w/o releases :) | 15:34 |
| niemeyer | SpamapS: Heh | 15:34 |
| niemeyer | SpamapS: Having a release is not the same as having a stable API plugin | 15:34 |
| SpamapS | An API release I mean. | 15:35 |
| SpamapS | And releases help w/ that too.. Wordpress plugins work that way.. they simply list the | 15:36 |
| SpamapS | releases of wordpress that they work with | 15:36 |
| SpamapS | when new releases come out.. people try it, and verify it, and add it to the metadata in their plugin repo | 15:36 |
| niemeyer | SpamapS: No, they don't, really.. | 15:36 |
| niemeyer | SpamapS: Ask the bzr guys | 15:36 |
| SpamapS | Are you suggesting wordpress plugins don't work? | 15:37 |
| niemeyer | SpamapS: I'm suggesting they actually care about the API for plugins, rather than simply having releases | 15:37 |
| * SpamapS has to run.. but will think on that. :) | 15:37 | |
| RoAkSoAx | fwereade: ping | 15:49 |
| fwereade | RoAkSoAx: pong | 15:49 |
| RoAkSoAx | fwereade: howdy! How's it going today? | 15:49 |
| fwereade | RoAkSoAx: not too bad, once I figured out squid-deb-proxy was the source of my woes :) | 15:49 |
| RoAkSoAx | fwereade: hehe yeah!! So anyways, I';m gonna start working on the deploying machine stuff | 15:50 |
| RoAkSoAx | fwereade: but before, I wanted to see if you wanted to work on getting the bootstrap validatiosn working first | 15:50 |
| fwereade | RoAkSoAx: I'll want to grab you later to figure out a couple of things but I'm focusing on something else atm | 15:50 |
| RoAkSoAx | fwereade: or shall we leave that for later | 15:50 |
| niemeyer | fwereade: The new changes you pushed into the tweaks branch look awesome! | 15:50 |
| niemeyer | So much cleaner overall | 15:51 |
| hazmat | SpamapS, cli plugins are easy.. server side plugins need a bit of work | 15:52 |
| fwereade | RoAkSoAx: sorry, expand "bootstrap validation" | 15:52 |
| fwereade | RoAkSoAx: thanks, all credit due to hazmat :) | 15:52 |
| fwereade | er, that should have been "niemeyer: thanks" | 15:52 |
| fwereade | :D | 15:52 |
| niemeyer | fwereade: This is ready for merging | 15:52 |
| RoAkSoAx | fwereade: checking if there's another zoopeeker running and things like that | 15:52 |
| niemeyer | fwereade: Yeah, hazmat's idea of putting bootstrap within LaunchMachine itself was great | 15:53 |
| niemeyer | I'll have lunch | 15:53 |
| niemeyer | Had a meeting with Robbie, but he's not around | 15:53 |
| fwereade | RoAkSoAx: ah, cool | 15:54 |
| niemeyer | (and I was the one screwing our original timing..) | 15:54 |
| fwereade | RoAkSoAx: that sounds great | 15:54 |
| fwereade | niemeyer: sweet :D | 15:54 |
| RoAkSoAx | fwereade: I mean if we should work on that before I start working on getting machines deployed | 15:59 |
| fwereade | RoAkSoAx: ah I see | 15:59 |
| * fwereade thinks | 15:59 | |
| fwereade | RoAkSoAx: yeah, please work on the bootstrap validation -- I think that will be most helpful to me | 16:00 |
| fwereade | RoAkSoAx: thanks :) | 16:01 |
| RoAkSoAx | fwereade: ok, I'll look into it ;) but wanna test what will happen if I try to deploy first | 16:06 |
| RoAkSoAx | fwereade: because, as I can recall, we discussing on setting a global variable to obtain the zookeeper instance | 16:06 |
| RoAkSoAx | and stuff like that | 16:06 |
| RoAkSoAx | fwereade: so that will probably involved re-doing part of the start machine code. But anyways, let me look at it first | 16:07 |
| fwereade | RoAkSoAx: as you like -- they're fundamentally independent, but keeping the actual deployment broken will prevent me from indulging my tendency to grow branches further than I should ;) | 16:07 |
| fwereade | RoAkSoAx: I'll just have to maintain my own discipline :p | 16:08 |
| RoAkSoAx | fwereade: hehe ok gonna start working on testing some stuff first as I need it before continue with the coding | 16:09 |
| jcastro | robbiew: any feedback on those graphs? | 16:22 |
| robbiew | jcastro: which ones...only saw the PDF you added | 16:23 |
| robbiew | are there more | 16:23 |
| jcastro | three graphs in one PDF. | 16:23 |
| jcastro | which style should I go with and is the content in each circle right? | 16:23 |
| jcastro | (I was thinking the concentric circles) | 16:24 |
| robbiew | jcastro: oh, heh | 16:25 |
| robbiew | let me look again | 16:25 |
| robbiew | jcastro: man...these are nice | 16:39 |
| jcastro | I know. :) | 16:39 |
| jcastro | total time, 10 minutes. | 16:39 |
| robbiew | I kinda like #2 | 16:39 |
| jcastro | I just need the details you would want in each box, I made it kind of generic | 16:39 |
| jcastro | dunno if you want it that generic or not | 16:39 |
| jcastro | yeah each view has a nice feel for it | 16:40 |
| robbiew | jcastro: so I converted #1 into an odp format | 16:40 |
| robbiew | for editing | 16:40 |
| robbiew | can also do #2 | 16:40 |
| robbiew | then folks can adjust as needed | 16:40 |
| jcastro | that would be swell, I couldn't figure out the conversion | 16:40 |
| RoAkSoAx | fwereade: is everything on tweak-launch-machine already approved into trunk? | 16:42 |
| robbiew | jcastro: no worries...I'll sort that while on this call...multitask | 16:43 |
| fwereade | RoAkSoAx: just merged it recently | 16:43 |
| robbiew | ;) | 16:43 |
| RoAkSoAx | fwereade: nice.. did you do any further changes to what's in ensemble-bootstrap branch? | 16:43 |
| fwereade | RoAkSoAx: I have another branch which is basically a copy, but uses twisted's xmlrpc instead of xmlrpclib | 16:44 |
| fwereade | RoAkSoAx: ...and has a failed translation of the deployment stuff we had so far | 16:44 |
| fwereade | I won't get it to a mergeable state today, but it should be ready earlyish tomorrow | 16:45 |
| fwereade | RoAkSoAx: and, in fact, I think I'll be proposing a merge of just enough to launch a machine, without expecting it to run or even necessarily complete an install | 16:46 |
| RoAkSoAx | fwereade: for cobbler/orchestra stuff? | 16:46 |
| fwereade | RoAkSoAx: yep | 16:46 |
| RoAkSoAx | fwereade: ok, well I think we should be in sync on this | 16:46 |
| RoAkSoAx | as I dont really wanna do stuff | 16:46 |
| RoAkSoAx | that is later gonna be changed :) | 16:46 |
| fwereade | RoAkSoAx: I can understand that | 16:47 |
| fwereade | RoAkSoAx: but my understanding was that niemeyer was asking me to take your stuff, in small pieces, and integrate those individually | 16:47 |
| RoAkSoAx | fwereade: I mean, as I understand, you are gonna require to do changes to get the API interaction with twisted xmlrpc instead of xmlrpclib right? | 16:47 |
| fwereade | RoAkSoAx: yes, changes, but I think not really serious changes | 16:48 |
| fwereade | RoAkSoAx: I still absolutely depend on your stuff to show me how to do the right thing | 16:49 |
| fwereade | RoAkSoAx: I just need to put it in a different coat | 16:49 |
| fwereade | RoAkSoAx: ...as it were ;) | 16:49 |
| RoAkSoAx | fwereade: right, so what I'm syaing is instead of you doing that, why didn't we do that from the beginning :) | 16:50 |
| RoAkSoAx | as in get things working with twisted xmlrpc directly | 16:50 |
| fwereade | RoAkSoAx: heh | 16:51 |
| RoAkSoAx | :) | 16:52 |
| fwereade | RoAkSoAx: I think niemeyer's reading of the situation was that your skills were better spent on the actual interaction, while I'd be best placed wrapping it in tests and, er, local flavour | 16:52 |
| RoAkSoAx | fwereade: alright, I guess we can continue like that for now then ;) | 16:52 |
| fwereade | RoAkSoAx: to be fair, the actual interaction is non-trivial | 16:52 |
| jimbaker | trunk is broken: http://paste.ubuntu.com/648385/ | 16:53 |
| fwereade | jimbaker: curses, odds are that's me... I swear I tested :/ | 16:53 |
| fwereade | jimbaker: ah, no, I think you have a stale .pyc | 16:53 |
| RoAkSoAx | fwereade: fair enough, let's just keep things as is until I finish merging all the stuff then ;) | 16:53 |
| jimbaker | fwereade, no worries. just wanted to try out your refactoring against some branches | 16:53 |
| jimbaker | fwereade, ahh, thanks for that reminder | 16:54 |
| fwereade | phew :) | 16:54 |
| jimbaker | let me try again | 16:54 |
| * fwereade retracts the "phew" until he hears the tests have *actually* passed ;) | 16:54 | |
| jimbaker | i should have bzr merge always do a clean code | 16:54 |
| jimbaker | the pyc problem only bites frequently enough that i remember it after the fact ;) | 16:55 |
| niemeyer | RoAkSoAx: Yeah, the point about xmlrpclib vs. Twisted's xmlrpc is that SpamapS's code was already using xmlrpclib, so it was trivial to move forward that way, and boring to refactor just to learn about the interaction | 16:57 |
| niemeyer | RoAkSoAx: fwereade can now easily port things over into Twisted lingo while doing the integration | 16:58 |
| jimbaker | fwereade, not looking good: http://paste.ubuntu.com/648389/ | 16:58 |
| jimbaker | i wonder if the previous error was a pyc problem that was not allowing this bad cascade | 16:58 |
| niemeyer | fwereade: Have you run tests during merge? | 16:59 |
| niemeyer | fwereade: s/during/before/ | 16:59 |
| fwereade | niemeyer: yes I did | 16:59 |
| fwereade | niemeyer: ...but I can't swear that my *trunk* didn't have its own stale pycs | 17:00 |
| niemeyer | fwereade: Doesn't look like import errors now | 17:00 |
| fwereade | niemeyer: they look a bit like transient errors I *think* I've seen on fresh code before | 17:01 |
| hazmat | hmm.. odd i ran the full suite against it | 17:01 |
| jimbaker | niemeyer, fwereade - not certain what's going on. i'm seeing a lack of repeatibility | 17:01 |
| RoAkSoAx | niemeyer: fair enough | 17:01 |
| fwereade | niemeyer: I am well aware that suites should be green 100% of the time but I felt I should hold off on fixing that sort of thing until I had a clearer idea how everything works together | 17:02 |
| jimbaker | never mind, it does come up with -u looping | 17:02 |
| niemeyer | fwereade: As long as it's not your branch introducing the issues | 17:02 |
| fwereade | niemeyer, jimbaker: ...and it's green for me on a clean trunk | 17:02 |
| jimbaker | ./test -u ensemble.providers.ec2.tests.test_bootstrap will eventually fail it seems | 17:02 |
| niemeyer | jimbaker: Can you reproduce that on trunk? | 17:03 |
| jimbaker | niemeyer, that's against trunk | 17:03 |
| niemeyer | jimbaker: Sorry, on trunk before the branch | 17:03 |
| jimbaker | niemeyer, yeah, i will do that now | 17:03 |
| niemeyer | jimbaker: Thanks | 17:03 |
| fwereade | jimbaker: ooh, I didn't know about -u | 17:03 |
| fwereade | that's really cool :) | 17:04 |
| jimbaker | fwereade, no it's not | 17:05 |
| jimbaker | :) | 17:05 |
| fwereade | jimbaker: heh :) | 17:05 |
| fwereade | jimbaker: I am past 180 successful runs here | 17:05 |
| jimbaker | the fact that we need to test with it is a very good reason for golang | 17:06 |
| fwereade | jimbaker: sorry, expand please | 17:07 |
| jimbaker | fwereade, this is the arg that niemeyer made to convince me why golang was a good direction for this project | 17:08 |
| jimbaker | to summarize: deterministic tests are good | 17:09 |
| fwereade | jimbaker: oh yes indeed -- I didn't realise go would give us that | 17:09 |
| niemeyer | It doesn't come for free.. it's just easier to get there | 17:10 |
| fwereade | niemeyer: would you look at http://paste.ubuntu.com/648398/ and tell me if the assertion against the str of the error makes sense to you? | 17:10 |
| jimbaker | fwereade, niemeyer - i'm running a test now against trunk, but i can't obviously loop ensemble.providers.ec2.tests.test_bootstrap now, since that's new | 17:10 |
| jimbaker | sorry trunk as of r277 | 17:10 |
| jimbaker | and that just passed fine | 17:10 |
| niemeyer | jimbaker: The bootstrap logic isn't changing significantly | 17:11 |
| niemeyer | jimbaker: Can you loop on ec2.tests? | 17:11 |
| fwereade | niemeyer: SAMPLE_ENV in http://paste.ubuntu.com/648405/ | 17:11 |
| niemeyer | jimbaker: Also, you have some experience debugging this sort of issue.. would you mind to give fwereade a hand on it? | 17:11 |
| jimbaker | niemeyer, yeah, i'm seeing the failure now in r277 too. so test_bootstrap is a refactoring of code in launch, as i now recall | 17:12 |
| niemeyer | fwereade: Not really, that doesn't make much sense to me | 17:12 |
| niemeyer | fwereade: It should say something like environments.myfirstenv has no type | 17:13 |
| jimbaker | niemeyer, i can help out fwereade on this | 17:13 |
| niemeyer | jimbaker: THanks a lot | 17:14 |
| fwereade | niemeyer: cool, I'll make it do something like that :) | 17:14 |
| niemeyer | fwereade: Thanks | 17:14 |
| fwereade | niemeyer: also: am I right in thinking that "still running after 5.0 seconds" was code you wrote with me on the sprint? | 17:14 |
| niemeyer | fwereade: Huh!? | 17:15 |
| fwereade | niemeyer: perhaps not then, I didn't quite follow what you did but it was tangential and I didn't want to crash my stack with a new discussion | 17:16 |
| SpamapS | http://spamaps.org/files/mediawiki-plus-slave.svg | 17:16 |
| niemeyer | fwereade: That's an error message from a runaway test, in general | 17:16 |
| fwereade | niemeyer: ...and a closer look reveals that it can't possibly be | 17:17 |
| SpamapS | We need to work on this so it has a more suitable orientation.. way too wide | 17:17 |
| fwereade | niemeyer: so I just saw ;) | 17:17 |
| niemeyer | fwereade: So not code.. are you seeing this when you run tests? | 17:17 |
| fwereade | niemeyer: I have seen similar things cropping up, very rarely, in random tests at random times | 17:17 |
| SpamapS | haproxy is providing something to demo-wiki .. so I don't think it should be on the same level as things demo-wiki is consuming.. would be good if providers went above consumers | 17:17 |
| fwereade | probably once every couple of days | 17:17 |
| SpamapS | err | 17:17 |
| niemeyer | SpamapS: That's really dot generating it.. if you have a patch to the formatter, we can easily put it in | 17:17 |
| SpamapS | demo-wiki is providing something to haproxy I mean | 17:18 |
| jimbaker | fwereade, first thing, need to ensure that we are both getting these random failures | 17:18 |
| niemeyer | fwereade: Ok, that's not something to be taken lightly | 17:18 |
| niemeyer | fwereade: It's usually a big warning that there is uncontrolled logic running | 17:18 |
| niemeyer | fwereade: and hooks into the determinism comments jimbaker made earlier | 17:18 |
| fwereade | niemeyer: indeed, but I didn't feel competent to investigate that in my first few days | 17:19 |
| niemeyer | fwereade: Again, you don't have to, as long as it's not your branch introducing it | 17:19 |
| niemeyer | fwereade: If it's your branch, you can ask for a hand to understand what is going on and someone else can dive in with you | 17:19 |
| niemeyer | fwereade: But don't just let it go through unnoticed, or we'll figure it's broken much later, and will be much harder to debug | 17:20 |
| fwereade | niemeyer: I'm 90% sure I've seen it elsewhere, but that 10% makes me want to take responsibility for now ;) | 17:20 |
| fwereade | niemeyer: besides, I can think of few more effective baptisms by fire :p | 17:21 |
| niemeyer | fwereade: You may have seen it elsewhere, but it may be a new issue | 17:21 |
| niemeyer | fwereade: If you want to be sure, it's easy | 17:21 |
| niemeyer | fwereade: Get the original test in trunk, run it in a loop with -u | 17:21 |
| niemeyer | fwereade: If it's already broken, you don't have to stop what you're doing to fix it | 17:21 |
| niemeyer | fwereade: If you don't see it breaking in trunk, heads up | 17:21 |
| fwereade | niemeyer: assuming there's no pollution between tests ;) | 17:22 |
| niemeyer | fwereade: The advice is the same | 17:22 |
| fwereade | niemeyer: but, yep, I'll get that running now | 17:22 |
| fwereade | niemeyer: and leave it overnight... I need to be off very shortly, I'm afraid | 17:22 |
| niemeyer | fwereade: Cool, thanks for today | 17:23 |
| fwereade | niemeyer: a pleasure, as always :) | 17:23 |
| niemeyer | fwereade: jimbaker will give you a hand on this one | 17:23 |
| fwereade | niemeyer, jimbaker: awesome, if I get a chance to talk tonight I will: otherwise I look forward to figuring it out tomorrow | 17:24 |
| fwereade | nn all :) | 17:34 |
| RoAkSoAx | niemeyer: clear me a doubt... does ensemble need to be installed in the zookeeper? | 17:39 |
| niemeyer | RoAkSoAx: You mean the zk machine, right? | 17:39 |
| RoAkSoAx | niemeyer: yes, the zk machine | 17:40 |
| niemeyer | RoAkSoAx: If so, yes, some of its bits get installed there | 17:40 |
| RoAkSoAx | niemeyer: how? | 17:40 |
| RoAkSoAx | bzr? | 17:40 |
| niemeyer | RoAkSoAx: cloud-init :-) | 17:40 |
| niemeyer | RoAkSoAx: bzr/apt, depending on conf | 17:40 |
| RoAkSoAx | niemeyer: right but I mean how does cloud-init install those bits that needs for ensemble (such as the provider stuff) | 17:41 |
| niemeyer | RoAkSoAx: bzr/apt, depending on conf | 17:41 |
| RoAkSoAx | niemeyer: so how can I tell it to install those bits from an specific branch? | 17:42 |
| niemeyer | RoAkSoAx: You add an option to your environments.conf file under ~/.ensemble | 17:42 |
| niemeyer | RoAkSoAx: Named ... | 17:42 |
| niemeyer | RoAkSoAx: ensemble-branch | 17:43 |
| niemeyer | RoAkSoAx: next to type: orchestra | 17:43 |
| niemeyer | RoAkSoAx: ensemble-branch: lp:~RoAkSoAx/ensemble/... | 17:43 |
| RoAkSoAx | niemeyer: cool thanks!! | 17:45 |
| niemeyer | RoAkSoAx: You're welcome | 17:46 |
| SpamapS | http://spamaps.org/files/mediawiki-circo.svg | 17:56 |
| SpamapS | zoom *way* out ;) | 17:56 |
| SpamapS | + dot.set_prog('circo') | 17:57 |
| SpamapS | one line patch FTW ;) | 17:57 |
| niemeyer | SpamapS: Why is it so spread out> | 17:58 |
| niemeyer | ? | 17:58 |
| niemeyer | dot graphs usually look a lot nicer than both versions | 17:59 |
| niemeyer | It's not clear to me what we're doing wrong there | 17:59 |
| SpamapS | not sure, you could definitely shorten some of the lines. :) | 18:00 |
| niemeyer | SpamapS: I'm used to reading performance graphs with dozens of edges and nodes | 18:00 |
| niemeyer | SpamapS: and it's tight, easier to follow | 18:00 |
| niemeyer | SpamapS: We must be using some crazy setting that puts things aside that way | 18:00 |
| niemeyer | SpamapS: http://labix.org/tmp/pprof.svg | 18:04 |
| SpamapS | ahh, with the circo layout, it specifies a minimum distance of 1.0 .. which is rather far I think | 18:05 |
| niemeyer | SpamapS: The concept of using a circumference looks like a good idea for that sort of map indeed | 18:05 |
| niemeyer | SpamapS: If we can make that tighter, it will look quite nice | 18:06 |
| niemeyer | SpamapS: Can we just disable the minimum distance and let it sort it out by itself? | 18:06 |
| SpamapS | niemeyer: and circo naturally pushes the more connected nodes to the center | 18:06 |
| niemeyer | SpamapS: Exactly | 18:07 |
| SpamapS | niemeyer: thats what I'm looking at doing | 18:07 |
| niemeyer | SpamapS: It's an awesome idea | 18:07 |
| === daker is now known as daker_ | ||
| jimbaker | i'm having problems with the networking card on my laptop | 18:35 |
| jimbaker | unfortunately today i also have my car being repaired... anyway, i should have my MBP in use as a spare shortly | 18:36 |
| hazmat | jimbaker, i noticed that those provider tests fail badly if your not connected | 18:42 |
| hazmat | the mocks for the image query aren't in place | 18:42 |
| * hazmat curses his isp for dropping the connection every 20m | 18:42 | |
| niemeyer | Any bash scripting masters around? | 19:12 |
| RoAkSoAx | niemeyer: ideas? http://pastebin.ubuntu.com/648521/ | 19:48 |
| niemeyer | RoAkSoAx: Are you using the webdav hack? | 19:48 |
| niemeyer | RoAkSoAx: Or is it S3? | 19:48 |
| RoAkSoAx | niemeyer: webdav | 19:49 |
| niemeyer | RoAkSoAx: It's refusing the PUT | 19:49 |
| RoAkSoAx | niemeyer: cool, will look into it further | 19:50 |
| robbiew | niemeyer: google+? | 20:01 |
| dannf | niemeyer: i've been known to write a script or two - what you need? | 20:06 |
| niemeyer | dannf: Oh neat | 20:06 |
| niemeyer | dannf: A review.. | 20:06 |
| niemeyer | dannf: Let me send you the link | 20:06 |
| niemeyer | dannf: https://code.launchpad.net/~bcsaller/ensemble/bash-completion/+merge/68124 | 20:06 |
| dannf | niemeyer: so i tend to stick to posix sh, so i'm unlikely to spot issues w/ bashisms like arrays. agreed spacing needs cleanup, though i don't personally have an issue with the [[ ]] && [[ ]] construct or the lack of ';;' in the case - though the latter is internally inconsistent, and a a single switch in a case seems odd | 20:23 |
| _mup_ | ensemble/security-policy-rules r275 committed by kapil.thangavelu@canonical.com | 20:25 |
| _mup_ | security policy rules for formula, machine, and relations. | 20:25 |
| niemeyer_ | dannf: Cool, does it look good to you overall | 20:25 |
| niemeyer_ | ? | 20:26 |
| _mup_ | ensemble/security-policy-rules r276 committed by kapil.thangavelu@canonical.com | 20:29 |
| _mup_ | additional peer relation test for relation security rule. | 20:29 |
| _mup_ | Bug #813773 was filed: Ensemble should have security rules/acls for every path in zk <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/813773 > | 20:31 |
| dannf | niemeyer_: i'd suggest quoting around $cur $curOpt references to be more liberal wrt user input | 20:37 |
| dannf | other than that, yeah - i think its fine | 20:37 |
| niemeyer_ | dannf: Would you mind to note that in the review, and mark it as Approve? | 20:37 |
| dannf | niemeyer_: sure | 20:37 |
| niemeyer_ | dannf: Under the comment box, that is | 20:38 |
| dannf | right | 20:38 |
| niemeyer_ | dannf: Thanks a lot for your help | 20:38 |
| dannf | np | 20:41 |
| SpamapS | aha! | 21:23 |
| SpamapS | fdp FTW | 21:23 |
| SpamapS | http://spamaps.org/files/mediawiki-slave-fdp.svg | 21:24 |
| SpamapS | nice *3 tier architecture* :-D | 21:24 |
| m_3 | cool man | 21:25 |
| SpamapS | I think that makes sense as a default output | 21:29 |
| SpamapS | Also I think we should actually not call .create when outputting the dot format.. since that adds the positioning.. | 21:29 |
| SpamapS | we should just write out the 'to_string()' | 21:29 |
| _mup_ | Bug #813794 was filed: ensemble status fails with "ERROR unhashable type: 'list' " when scope is passed <Ensemble:New> < https://launchpad.net/bugs/813794 > | 21:36 |
| hazmat | SpamapS, do you have any ideas how to reproduce that status bug? | 21:45 |
| SpamapS | hazmat: pushing a fix now ;) | 21:46 |
| hazmat | SpamapS, even better :-) | 21:46 |
| SpamapS | w/ a test case | 21:46 |
| SpamapS | hazmat: but basically .. 'ensemble status service-name' .. | 21:46 |
| hazmat | ugh | 21:46 |
| hazmat | that should have had a test | 21:47 |
| hazmat | sad if not | 21:47 |
| SpamapS | state = yield status.collect( | 21:50 |
| SpamapS | "wordpress", self.provider, self.client, None) | 21:50 |
| SpamapS | it does.. not sure why that is passing | 21:50 |
| SpamapS | ahh | 22:00 |
| SpamapS | the tests are only *simulating* what they think argparse passes to collect() | 22:00 |
| SpamapS | argparse actually passes a list | 22:00 |
| SpamapS | the things I do to get a good graph for my presentation.. sheesh | 22:04 |
| robbiew | jcastro: who did the DevOps grows up picture...that's great...T-shirt worthy | 22:18 |
| m_3 | robbiew: that was me | 22:21 |
| m_3 | jcastro and I were chatting about message stuff and I remembered the classic "evolution" pic | 22:21 |
| jcastro | I've tossed it in the preso folder | 22:22 |
| robbiew | yeah...sweet | 22:22 |
| m_3 | the last guy should have an arnold-head though | 22:22 |
| * robbiew might play around with this concept a bit...I'm known for cool t-shirts ;) | 22:22 | |
| robbiew | jcastro STILL wants a foundations shirt | 22:22 |
| robbiew | lol | 22:22 |
| m_3 | I'll upload the xcf | 22:23 |
| * robbiew heads out to cloud camp.... | 22:23 | |
| * jcastro heads off to florida | 22:23 | |
| jcastro | catch you guys on tuesday! | 22:23 |
| _mup_ | ensemble/security-policy-rules r277 committed by kapil.thangavelu@canonical.com | 22:27 |
| _mup_ | services and units security rules | 22:27 |
| _mup_ | Bug #813831 was filed: errors can be misleading when environments are specified incorrectly <Ensemble:In Progress by fwereade> < https://launchpad.net/bugs/813831 > | 22:57 |
| hallyn | smoser: hm, the jaunty ec2 image. i can't ssh into it. known? | 23:03 |
| _mup_ | ensemble/security-policy-rules r278 committed by kapil.thangavelu@canonical.com | 23:07 |
| _mup_ | additional unit and service subtree nodes | 23:07 |
| _mup_ | ensemble/security-connection r280 committed by kapil.thangavelu@canonical.com | 23:12 |
| _mup_ | add service and unit rules to the default security rules list | 23:12 |
| _mup_ | ensemble/security-policy-rules r280 committed by kapil.thangavelu@canonical.com | 23:13 |
| _mup_ | add service and unit rules to the default security rules list | 23:13 |
| _mup_ | ensemble/security-connection r281 committed by kapil.thangavelu@canonical.com | 23:20 |
| _mup_ | security policy connection integration | 23:20 |
| RoAkSoAx | niemeyer_: ping? | 23:45 |
| _mup_ | Bug #813847 was filed: status format "dot" should not actually call 'create' so users can process the graph with dot <Ensemble:In Progress by clint-fewbar> < https://launchpad.net/bugs/813847 > | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
