[00:43] niemeyer, using the lp api in bzr doesn't look it will work, too many roundtrips to lp [00:43] its too slow [01:10] it would have to be some sort of secondary cache for querying [01:10] with bg updates [01:30] hazmat: What were you looking to do there? [01:32] niemeyer, my intent was to do a bzr plugin that gave us the lp integration we want.. i also started playing with colo/pipeline.. stuff i basically wrote a spec for it.. and then realized i needed to backtrack to not dictate bzr workflow... so i went ahead and started a cli implementation that can answer questions, like show me my pending branches that need work, show me things i can review, show things that are misisng for the kanban and why [01:32] i've got a few of them already done, although its a library that i'm driving from the interpreter rather than a cli but i wanted to explore the concept [01:33] even with a cache though, there's too much link traversal/roundtrips to answer some questions [01:33] its a bit slow... it might just need to be a web app [01:34] so i can use the bg updated cache for live views [01:42] hazmat: Yeah, that's a fairly common complaint about that API [01:43] hazmat: Even for our store API, it took a few roundtrips before they accepted the traditional way of doing things would be non-efficient [01:44] hazmat: There's some level of agreement that something must be done to improve the conventions, though [01:44] REST FTW.. [01:44] not [01:44] :-) [01:46] it would be nice an app could keep a local cache and then just get a stream/feed of changes against a higher level entity like a project or milestone, to do its own cache invalidation.. the other issue for interactive use is that it requires a good connection... it would be nice if the bzr integration could do its read functionality soley against its local cache [01:47] its really not clear what would make it nicer, as is the api is very functional, but i'm almost wish for incremental data dumps against a top level entity [01:48] project most likely given that's the common organization level in lp [02:25] <_mup_> Bug #827071 was filed: Improved tmux byobu key bindings < https://launchpad.net/bugs/827071 > [02:43] <_mup_> Bug #827073 was filed: Fixed number of machines placement policy < https://launchpad.net/bugs/827073 > [03:04] <_mup_> ensemble/verify-version r314 committed by jim.baker@canonical.com [03:04] <_mup_> Addressed review, but mocking is still not working for new scheme [03:14] <_mup_> ensemble/verify-version r315 committed by jim.baker@canonical.com [03:14] <_mup_> Try a mocker like solution for the interim [03:16] <_mup_> ensemble/verify-version r316 committed by jim.baker@canonical.com [03:16] <_mup_> Try a mocker like solution for the interim [03:24] <_mup_> ensemble/verify-version r316 committed by jim.baker@canonical.com [03:24] <_mup_> Cleanup [03:27] <_mup_> ensemble/verify-version r317 committed by jim.baker@canonical.com [03:27] <_mup_> PEP8 [03:28] <_mup_> ensemble/verify-version r318 committed by jim.baker@canonical.com [03:28] <_mup_> Restored blank line [03:30] <_mup_> ensemble/verify-version r319 committed by jim.baker@canonical.com [03:30] <_mup_> Merged trunk [03:36] <_mup_> ensemble/formula-state-with-url r312 committed by kapil.thangavelu@canonical.com [03:36] <_mup_> merge trunk [04:17] hazmat: any action I need to take on that one? [04:17] hazmat: i see it's assigned to me [04:17] kirkland, no just needed to get it onto the kanban view [04:18] kirkland, we've been primarily using that as our view into the review queue, and branches without associated bugs (and milestones) don't show up [04:18] hazmat: coolio; should i file a bug per branch in the future? [04:19] kirkland, yes, that would be great, also helps to assign it to the current milestone [04:19] s/helps/needs to be [04:20] hazmat: sweet, will do [04:20] its getting a bit cumbersome, i've been exploring alternate options based on lp extensions, but it looks like we'll need either a 3rd party system, or an alternate web front end onto launchpad to get things simpler for the project workflow [04:21] but till then, that's the mechanism..i was just testing out the lp extension which mentioned all the merge proposals that weren't showing up in the kanban [04:21] it takes too long sadly to make it a useful cli tool by itself [11:44] so, I was wondering about _run_operation in ec2.MachineProvider [11:44] it turns all errors raised by the operation into ProviderInteractionErrors [11:45] but it's only used on .connect [11:46] and I feel it should either wrap everything, or wrap nothing, with a moderate preference for wrapping nothing -- individual operations can turn appropriate exceptions into PIEs if they want, but errors in operations don't necessarily imply errors interacting with the provider [11:46] they could be, say, attempts to get groups() from an unchecked regex match result [11:52] niemeyer: morning! [11:53] fwereade: Hey man [11:53] niemeyer: I was just talking to nobody in here :) [11:53] niemeyer: quick recap [11:54] niemeyer: ec2.MachineProvider._run_operation turns exceptions from the operation it runs into ProviderInteractionErrors [11:54] niemeyer: only used for .connect [11:54] niemeyer: I don't think it should exist at all, because the errors aren't necessarily related to provider interaction [11:55] niemeyer: individual ops can wrap errors in PIEs if they really want to [11:55] niemeyer: concur? [11:55] fwereade: Agreed [11:55] niemeyer: sweet [11:56] fwereade: This was an easy way to make sure that all operations we cared about would be properly wrapped [11:56] fwereade: As long as you're sure the operations are indeed taking care of translating the errors into something reasonable, it's not necessary [11:56] niemeyer: it's just the one operation that uses it anyway [11:57] niemeyer: the other possibility is that everything should use it (or a variant) [11:58] niemeyer: but that doesn't feel right to me [11:58] fwereade: This was used in strategic operations we believed were leaky in terms of which errors they could raise [11:59] fwereade: We didn't want it to blow in random ways [11:59] fwereade: Which is why it's fine as long as you indeed check that we're taking care of possibilities there [11:59] niemeyer: cool, got you [12:00] niemeyer: we've got some work to do on general provider interactions then [12:00] niemeyer: EC2Errors, S3Errors and xmlrpc Faults are currently passed through unless they correspond to specific error states we already know about [12:01] fwereade: This is exception handling "FTW".. in Go we'd just say "if { ; }. That doesn't tend to feel nice when doing exception handling _everywhere_ [12:02] fwereade: Well, there you go.. they shouldn't be passed through [12:02] niemeyer: writing a bug [12:02] fwereade: Generic/common code should not worry about EC2Error, or S3Error, etc [12:02] niemeyer: agreed [12:03] fwereade: That's why we wrap, and why we had that method there [12:04] niemeyer: sure, so it feels like we might want provider-specific wrappers [12:05] niemeyer: any ec2 MachineProvider call should be wrapped in something that converts EC2Errors and S3Errors but lets everything else through [12:05] fwereade: Indeed, or no wrapper at all if you can ensure that all errors are indeed being taken care of or reraised in a way outside logic can catch properly [12:06] niemeyer: yep, makes sense [12:06] fwereade: Ideally these errors wouldn't exist.. because the user can't really react to "Instance does not exist".. or "S3 auth error".. without any kind of context [12:06] niemeyer: potentially easy to forget to do if it's not automagic but we can worry about that if we do turn out to be forgetting it [12:16] <_mup_> Bug #827308 was filed: ProviderInteractionError wrapping not consistent < https://launchpad.net/bugs/827308 > [12:20] niemeyer: btw... how often should the kanban board update? [12:20] fwereade: I believe the one maintained by IS is broken again [12:20] Please use this one for now: people.canonical.com/~niemeyer/dublin.html === niemeyer changed the topic of #ubuntu-ensemble to: http://people.canonical.com/~niemeyer/dublin.html | http://ensemble.ubuntu.com/docs [12:21] niemeyer: cheers === niemeyer changed the topic of #ubuntu-ensemble to: http://j.mp/ensemble-dublin | http://ensemble.ubuntu.com/docs [12:21] niemeyer: https://code.launchpad.net/~fwereade/ensemble/find-all-zookeepers/+merge/71668 may qualify as trivial [12:23] fwereade: I'm planning to go over all your branches once I get rid of a summary for last week that I'm writing, but let me see that one [12:24] niemeyer: cheers [12:24] fwereade: Are the call sites ready to take more than one machine? [12:25] niemeyer: only client is connect, which currently just grabs the first one [12:26] niemeyer: I was proposing to grab the first one with an assigned dns_name, if it exists [12:27] niemeyer: cleverer choosing algorithm can wait until we actually bring up multiple zookeepers, I think [12:28] niemeyer... oh no it's not [12:28] niemeyer: I missed bootstrap [12:28] niemeyer: not sure what the semantics should be there [12:29] niemeyer: it bothers me slightly that start_machine returns a list of one machine; the fact that bootstrap will return a list of pre-existing bootstrapped machines is not necessarily material, because I don't think anyone uses that result [12:30] niemeyer: if we were to decide that start_machine should return a naked machine, it would matter [12:30] fwereade: I don't understand what you mean? [12:30] niemeyer: sorry :) [12:31] fwereade: If we didn't use the result of bootstrap, how would we guess later the machine we bootstrapped? [12:31] niemeyer: bootstrap() returns the result of get_zookeeper_machines(), or the result of start_machine() [12:31] fwereade: Sounds sane? [12:31] niemeyer: isn't that internal? [12:32] fwereade: What's internal? [12:32] niemeyer: bootstrap uses the result of start_machine internally to write the state [12:32] niemeyer: or passes through the result of get_zookeeper_machines [12:33] niemeyer: well, actually, LaunchMachine itself does the writing if it's constructed in bootstrap mode, that's definitely a bug [12:33] fwereade: Yes, you're describing what happens.. I don't understand what you think the problem is [12:34] niemeyer: but it's asymptomatic until we have multiple zookeepers anyway [12:35] niemeyer: I don't think there's a problem, I was trying to explain why the change isn't a problem, even though bootstrap also uses the result of get_zookeeper_machines [12:35] fwereade: Yes, you're saying it returns a single machine at all times [12:35] fwereade: Which is what it already did [12:36] fwereade: My original question (which remains) is whether all call sites are ready to deal with multiple machines [12:36] fwereade: Because that's what the branch does [12:37] niemeyer: let me start again [12:37] niemeyer: the call sites are in connect, and bootstrap [12:37] niemeyer: both expect lists [12:38] niemeyer: neither are perfectly specialised to deal with multiple zookeepers yet, but I don't believe the differences are material because the changes necessary for working with multiple zookeepers will be more wide-ranging than that [12:38] niemeyer: this branch is just preparing a small part of the necessary ground [12:39] fwereade: The question is simpler than that [12:39] fwereade: Will the call sites break because you're passing a list? [12:39] fwereade: with more than one element [12:39] niemeyer: no [12:39] fwereade: Phew.. ;_) [12:40] niemeyer: :) [12:42] niemeyer: on general principles, shall I add a test for bootstrap with multiple zookeepers, to make it clear? [12:42] fwereade: Nah [12:43] fwereade: Whoever adds logic to actually deal with multiple machines will go through that [12:43] niemeyer: ok, cool [12:43] fwereade: I just wanted to make sure we were not consciously adding a bomb [12:44] niemeyer: just a change, it'd need to be mixed with other stuff to become a bomb ;) [12:47] fwereade: So, sure.. you can merge it.. it's not clear why that's being done, but fine [12:49] niemeyer: cheers -- just because I'd rather write upcoming code to deal with get_zookeeper_machine*s* as if there really were machine*s*, rather than encoding time-sensitive assumptions in more places than they need to exist [12:56] fwereade: Sound sgood [13:05] SpamapS: ping [13:42] fwereade: How much time do you think we still need for the "Orchestra works" bits of the problem to be in trunk? [13:43] niemeyer: all rather depends on the merge queue; just to ensure it's as speedy as possible, I think I'll get a minimal orchestra connect in very soon, and work on nicening up the UI separately [13:43] niemeyer: the orchestra connect should basically be null, it's just a matter of writing tests [13:44] fwereade: Ok, but by now you have an idea of the pipeline "cost".. how long do you think before your buffer empties? [13:47] niemeyer: it's totally dependent on review speed and verdicts -- I wouldn't MP if I didn't think they were good, but I'm not always right ;) [13:47] niemeyer: this week sounds very plausible though [13:47] fwereade: Thanks.. that gives me an idea of order of magnitude [13:47] fwereade: No need for spot on accuracy in this case [13:48] niemeyer: cool [14:06] niemeyer: you know, I could have sworn I was at some sort of sprint last week :p [14:06] fwereade: Oh man, did I miss you? [14:07] niemeyer: don't worry, the opportunity for a snarky comment makes up for it :) [14:10] kim0: ping [14:16] niemeyer: pong [14:16] kim0: Can you please tweak the blog post to reflect the points made in the thread? [14:17] ok guys, here's the report for the last week so far: http://pad.ubuntu.com/ensemble-report [14:18] niemeyer: sure yeah [14:19] kim0: Thanks [14:20] jcastro: Anders and Dustin also worked on the Orchestra provider [14:21] jcastro: and Clint also worked with Jim on testing the expose/unexpose IIRC [14:21] g'morning [14:21] jcastro: Kapil also worked on the local development/LXC [14:22] jcastro: That's why I avoid giving names to the specific tasks.. :) [14:22] * jcastro just adds more names instead [14:23] jcastro: I add all names on the sprint/project.. one boat. :) [14:23] jcastro: Some times I forget, though.. [14:31] fwereade, my understanding is the only reason not to return multiple machines for zk, is that sshclient can't really use them atm, but it maintains the same interface as txzk.. its probably a better idea to just specialize for that in sshclient then in the providers [14:34] hazmat: that's the idea -- in my current branch, ZookeeperConnect has a very simple _pick_machine method, which may become more complex in the future [14:34] hazmat, there should be support in sshclient for this scenario... but it only takes the first one in the list [14:35] hazmat: in practice, it works the same as it already does, but I'm trying to avoid assuming that get_zookeeper_machine*s* returns a one-element list [14:36] jimbaker: there are going to be lots of changes when we have multiple zookeepers... with this, there will be one fewer [14:36] jimbaker: it's not much but it's a start [14:37] fwereade, ok, i should definitely review your branch. i happened to be looking at test_sshclient to better understand the power of mocker [14:38] jimbaker: oh, sorry, I misread sshclient... yeah, I think that's a very nice idea, I hadn't even thought of that [14:38] jimbaker: but the sshclient code scares me :) [14:39] fwereade, the sshclient code is simple. you should see test_sshclient ;) [14:39] * fwereade cowers [14:40] <_mup_> ensemble/verify-version r320 committed by jim.baker@canonical.com [14:40] <_mup_> At least don't do something stupid/unpythonic with action at a distance module namespace changes [14:41] the specific code is going away once i figure out how to get mocker patch to do what i want, but at least it's been cleaned up [15:03] about sshclient... [15:03] why do we raise txzookeeper ConnectionTimeoutExceptions? [15:04] shouldn't we have an ensemble ConnectionTimeout(NoConnection)? [15:16] fwereade, i believe this is to keep the interface compatible with txzookeeper client [15:25] fwereade, jimbaker: I'm in a call right now, but I'm debt with both of you, and would like to sort it out this afternoon. [15:25] niemeyer, sounds good [15:25] fwereade: I'll clean the queue today, so expect good feedback tomorrow [15:26] jimbaker: Can we have a call after lunch? In.. 1.5h? [15:26] niemeyer, cool, i was wondering which time zone's afternoon :) [15:26] so that time works for me [15:27] niemeyer, i still haven't figured out how to use mocker to perform the equivalent of just setting the module name, but i will keep working on that [15:28] jimbaker: Setting the module name? [15:28] jimbaker: Don't know what that'd mean [15:31] niemeyer, i'm trying to do something like the following: http://paste.ubuntu.com/667409/ [15:31] it's a very simple thing: in this test, i want to change ensemble.state.topology.VERSION to another number (say by incrementing it) [15:32] niemeyer, so action at a distance for code that is relying on this VERSION, specifically InternalTopology.parse [15:33] niemeyer, now when i had first constructed this test, VERSION was defined in a completely separate file, ensemble.common. for whatever reason, perhaps due to importing, this was working. likely accidentally working [15:35] niemeyer: pong, good morning :) [15:36] jimbaker: Yeah, I get it.. I've sent a mail about it yesterday [15:36] niemeyer: cool, thanks (I'm around for a little while longer today but not *that* long :)) [15:36] jimbaker: Use the patch method in ensemble.lib.testing [15:36] SpamapS: morning! [15:37] niemeyer, cool, that's what i have been trying, as well as seeing how it's used [15:38] niemeyer, sorry, now i see the difference - this is a separate patch from mocker [15:39] jimbaker: That's not what I get from your message, but let's talk later.. have to pay attention here [15:39] given this is exactly equivalent to what i want to do, just something we have coded up, that should do what i want [15:40] jimbaker: ah, I see, thanks [15:42] niemeyer: so I was thinking about this, and wondering if there's a way we can run the ftests from the .deb .. [15:42] niemeyer: That way we can ask people to run them in support situations [15:43] niemeyer, cool, the correct patch method works [15:46] <_mup_> ensemble/verify-version r321 committed by jim.baker@canonical.com [15:46] <_mup_> Use TestCase.patch for action at a distance change to module namespace [15:49] SpamapS: Probably not.. [15:49] SpamapS: Well.. maybe yes, depending on what you mean by that [15:49] SpamapS: You mean running ftests when debs are built, or running ftests with an ensemble that was deb-installed? [15:50] jimbaker: Super [15:50] niemeyer: the latter [15:50] SpamapS: That's doable [15:51] niemeyer, i see my source of confusion - you mentioned in your email "ensemble.state.testing" which doesn't exist, but i error corrected to the tests on ensemble.state, which use self.mocker.patch extensively (as well as one use of self.patch) [15:51] now it's all clear [15:51] SpamapS: But I think it makes most sense to do against trunk [15:51] SpamapS: Ideally ftests would be run more frequently than deb-builds [15:52] at least it got me look at test_sshclient again, just in time to discuss w/ fwereade [15:52] jimbaker: Cool, sorry for the confusion [15:52] serendipitous :) [15:52] fwereade, indeed :) [15:52] Alright, I'm off the call, and will get some lunch and get cranking [15:52] niemeyer: I'm more thinking of the integration w/ the OS.. agreed that at some point you guys will want to see if trunk fixes somebody's problems. :) [15:53] niemeyer, no worries [15:53] SpamapS: That's not the point [15:53] niemeyer: the results of ftests with the version somebody is reporting a bug on are interesting to see if they've mucked up their environment. [15:54] SpamapS: If a revno from bzr is ftested, it's ftested, no matter if it's within a deb or within a branch [15:54] SpamapS: For quality assurance, it's beneficial to have ftests running even before they get to a deb [15:54] SpamapS: Even with interim revisions [15:55] niemeyer: right, you're looking at it from a "testing the code" perspective. I'm looking at it from a "testing the environment" perspective. [15:55] SpamapS: ftests don't test an environment.. [15:55] SpamapS: They test that ensemble works [15:55] <_mup_> ensemble/verify-version r322 committed by jim.baker@canonical.com [15:55] <_mup_> Merged trunk [15:55] Yeah, though they're more sensitive to environment breakage than unit tests. [15:55] SpamapS: Yes, they are functional tests [15:57] Like I could run through all the unit tests, and still have a broken system because I'm pointed at a DNS resolver that is doing something wonky with my requests to amazon. [15:57] But the ftests should expose that. I think. [15:57] Yep [15:57] and that's why we want to run it with every revision from trunk, rather than just packaged revisions [15:58] all good. I *also* want to have it in the arsenal of things to suggest that a suer try when they're having trouble [15:59] user too [15:59] suer's are even more scary than users :) [15:59] SpamapS: LOL [15:59] SpamapS: I wouldn't do that myself [15:59] SpamapS: For the same reason we don't ask users to run unittests [16:00] SpamapS: But if you want to do it.. well.. [16:01] with other projects I've asked users to run unit tests before.. and found out all kinds of things.. like broken paths.. missing files.. weird compilers.. [16:02] Anyway it was just a thought that passed through my head as I'm planning to setup the jenkins tests [16:03] SpamapS: Sounds good [16:04] Lunch for reals [16:05] SpamapS: what are you planning in terms of automated testing? I spent some time last week thinking about how we test the OpenStack formulas so it would be good to sync up [16:05] make sure we are not overlapping/share knowledge etc.. [16:06] jamespage: +1 flyonthewall for that [16:07] m_3: coolio - I need to write up what I did last week and circulate - it works but its not that elegant [16:07] jamespage: Yeah, Adam said you had been doing some stuff [16:07] jamespage: understand... I've had similar "compromises" in this area [16:08] jamespage: m_3 has some thoughts as well. :) I think formulas embedding a test that can be scooped up and run in an automated fashion would be brilliant [16:09] SpamapS, m_3: thats pretty much what I did - its basic ATM but it can be run from Jenkins to generate graphs etc.. [16:09] are you mocking or actually relating? [16:09] also puts writing the tests for a formula IN the formula which feels nice [16:09] yes! [16:09] m_3: actually relating [16:10] right [16:10] m_3, SpamapS: I implemented it as a single formula-tester service [16:11] jamespage: so I have a strong desire to test the orchestra -> openstack -> all other formulas chain .. over and over.. [16:11] and tester-* hooks each of the services which get related after the environment is deployed [16:11] at which point the tests get executed and collated back to the formula-tester [16:11] which jenkins pulls all of the results from [16:11] jamespage: hah, sweet! [16:12] jamespage: so the test relation tells jenkins what to relate the formula to? [16:12] its a little 'grey' in some areas as it was hard to tell when relations and finished relating [16:12] kinda [16:13] jamespage: nice... how is it specifying what the relation is expecting/providing? [16:13] jamespage: or is it just discovery? [16:13] I do think we need an 'ensemble watch x=y' command where you can say "just wait here until state x changes." .. if it changes to y.. then exit 0, other wise, 1 [16:13] SpamapS: that would be great [16:13] we can fake it w/ status for now [16:14] m_3, SpamapS: so I have this new formula - http://bazaar.launchpad.net/~james-page/+junk/formula-tester/files [16:14] which provides the 'testing' interface [16:15] So a formula that wants to be tested optionally requires the 'testing' interface - branch of rabbitmq as an example - http://bazaar.launchpad.net/~james-page/+junk/rabbitmq-server/files [16:16] All the relation does it setup SSH keys and exchanges identification to allow the formula-tester to execute the tests and collate the results on each of the service units its hooked up with [16:17] nice, and stays out of the way unless the tester relation is joined [16:17] I then hacked together a wrapper script - http://bazaar.launchpad.net/~james-page/+junk/test-formula/files [16:17] to bootstrap, build the environment, collate the test results and kill everything [16:18] it parses the yaml of ensemble status plus other hacks to determine where its up-to [16:18] Then there is a openstack-formula-test branch - http://bazaar.launchpad.net/~james-page/+junk/openstack-formula-test/files [16:19] which has the hooks and config for deploying the openstack formulas and testing them [16:19] freeze/rehydrate environment in ensemble would really help with this [16:19] as it has lots of little snoozes at the moment [16:19] (adam_g and I where not that brave) [16:20] jamespage: brilliant man [16:20] jamespage: quite interesting... I'd actually create a user for running the tests, not rely on the ubuntu user. That way you can drop the user when the tester relation is broken. [16:20] yeah - as I said it lacks polish [16:21] jamespage: But I do think its a good framework for getting tests written. What is the XML format? [16:21] I'm going to get it up and running somewhere visible so folks can see [16:21] so the tests are written as python unittest [16:22] subunit + subunit2junitxml is then used to massage the output into JUnit XML format which Jenkins likes [16:22] jamespage: so it kind of makes sense for all of that to happen on the jenkins side [16:22] probably [16:23] I'm not conivinced that python unittest quite the right solution. [16:23] jenkins service could actually even _be_ the testing service [16:23] m_3 - hey - neat idea! [16:23] s/could/should/ ;) [16:23] but it might make sense to keep it separate for stability [16:23] I can see the tester getting jammed at times [16:24] awesome... [16:24] * m_3 grokking ramifications [16:25] This can all be quite fluid. [16:25] and contained :) [16:25] it sort of is a mocker too [16:25] so all of those patterns apply [16:26] Formulas are their own mocks in some way. [16:26] Want to test if mediawiki's mysql works, before relating it to the database? deploy it.. relate it.. done. [16:27] Since the formula defines that mysql will be on 3306 and have x,y,z .. you couldn't mock without overriding the mysql client library in mediawiki [16:27] and it keeps in the spirit of ensemble with freeform tester scripts/hooks in each formula [16:28] not forcing a whole lot of framework [16:28] SpamapS: right, it's doesn't carry over directly [16:29] m_3, SpamapS: so one thing we did not have a good answer for was how you test a service's relations [16:29] what are the goals of a formula unit-test? [16:29] m_3: good question [16:29] implements the service's relation APIs? [16:30] jamespage: relations should test themselves really... after receiving user/pass/host/port for mysql, you should try it in the relation-changed hook.. and error out if it doesn't work. [16:31] i was thinking that a testing framework for formuls would work in two parts, a per hook test script which would validate what the hook had done executed on the units, and a setup script that would execute with the admin cli [16:31] effectively each formula would have a tests/hook-name-test and tests/hook-name-setup [16:31] SpamapS: guess so; so scope of the formula unit test should be how it validates its working once its up and has it minimal set of relations running [16:32] the setup could add units/relations etc, anything needed to test, its a bit minimal in terms of number of test scenarios that could be run though against an individual hook [16:32] jamespage: indeed. poke the web service and see if you get a login screen instead of "It works!" .. make sure rabbitmq is running and listening on port XYZ .. those sorts of things, right? [16:33] thats what we have done so far [16:33] they are pretty easy to implement unittest style [16:33] sounds like we should plan to chat about formula testing in Orlando [16:34] worth hangouts before then too? [16:35] (this is a big deal) [16:44] at this point i just want to get a bzr triggered test against OpenStack setup. [16:44] If I can also make it test against Orchestra.. that would be fabulous. :) [16:45] ooo oo ooo bug 386596 passed QA! :) [16:45] <_mup_> Bug #386596: pushing to a packaging branch can't create a new package

< https://launchpad.net/bugs/386596 > [16:45] ah... nice [16:47] bcsaller, got time for a chat on lxc work? [16:47] hazmat: absolutely, can you give me 10 minutes [16:48] bcsaller, sure [16:55] nn all, take care [16:55] hazmat: did the picture of the planning board at the sprint come out? can we share that on U1? [17:00] bcsaller, sure, i've to grab it off my camera [17:01] niemeyer, ready to talk? [17:08] bcsaller, i'm chilling in a g+ hangout [17:14] bcsaller, i was taking a look at bug 823586. although the stream.flush() in RelationGetCli.format_shell does guarantee that the stream is in fact flushed before stderr is written to, i don't believe this guarantee can be respected by HookProtocol in outReceived and errReceived [17:14] <_mup_> Bug #823586: intermittent failure in test_relation_get_format_shell_bad_vars < https://launchpad.net/bugs/823586 > [17:15] bcsaller, g+ fail [17:16] jimbaker: ahh, that could be why it still randomly fails. I think I'd remove the stderr output in this case then, but I suppose we could just loosen up the tests placement expectations [17:16] hazmat: I'll start a new one [17:16] bcsaller, i think relaxing the test is the best course of action. we can still be best effort on the flush [17:17] bcsaller, anyway i will put a fix in place and push it for review [17:17] jimbaker: thanks alot [17:17] bcsaller, the other thing to be aware of is that any log tests must wait for the process to end (in this case, that would be yield exe.ended) [17:17] hazmat: skype? [17:18] bcsaller, installing it now [17:18] jimbaker: good point [17:19] bcsaller, that was a change i recently made, r286 (robust-hook-exit) [17:26] <_mup_> ensemble/fix-shell-bad-vars-test r314 committed by jim.baker@canonical.com [17:26] <_mup_> Relax stream ordering requirement in test, but do wait on streams being closed before testing [17:26] * robbiew goes to pack for linuxcon flight today :/ [17:32] bcsaller, this looks like a trivial to me, so if you want to review it first and concur, we can do it as such [17:32] jimbaker: Here [17:32] bcsaller, lp:~jimbaker/ensemble/fix-shell-bad-vars-test [17:33] niemeyer, skype? [17:33] jimbaker: G+? [17:33] niemeyer, g+ always seems heavyweight for this sort of thing, but sure [17:34] jimbaker: Luckily we don't have to send packets manually [17:34] niemeyer, ;), i just mean the setup. let's see here... [17:35] jimbaker: Setup? You mean clicking on that button in a web page? [17:36] jimbaker: What's your gmail account? [17:36] I'll send the invite [17:36] niemeyer, still not quite like a skype call. anyway, just waiting here [17:36] niemeyer, james.edward.baker@gmail.com [17:36] jimbaker: Danke [17:37] jimbaker: Done [17:42] jimbaker, bcsaller niemeyer, i'm going to go ahead and move over all open bugs in the dublin milestone to eureka milestone, any objections? [17:42] i'd like to go ahead and close out the dublin milestone [17:46] hazmat: It'd be better to do a more realistic selection.. [17:46] hazmat: Or just move everything out, and then include selectively [17:46] hazmat: We have a month, pretty much [17:49] hazmat: Would be great to do the move, though [17:49] hazmat: I can do the kanban once you've opened the new one [17:49] niemeyer, https://blueprints.launchpad.net/ensemble/+spec/ensemble-local-development [17:50] niemeyer, the new one is open [17:50] oops [17:50] bcsaller, https://blueprints.launchpad.net/ensemble/+spec/ensemble-local-development [18:07] niemeyer: we have a debate still about if we should be using cloud-init for local containers or not. There are strong arguments for doing it that way as it more closely mirrors what ec2 does, but in the case of local container creation it adds latency and defers to boot that which could already be cached on the local machine. do you want to have a talk about this now or another time? [18:09] bcsaller: We can talk now [18:09] bcsaller: Here or G+? [18:09] g+ [18:09] bcsaller: Ok.. waiting for invite [18:19] shouldn't this be moved out of drafts? https://ensemble.ubuntu.com/docs/drafts/service-config.html [18:20] SpamapS, it should indeed [18:20] Also we should do redirects on 404 in drafts to /docs/$filename [18:21] Maybe some mod_rewrite magic so we can only do it when files of the same name exist there. [18:22] Alright! Launchpad formulas (aka source packages) on demand are live! [18:23] A toast to the Launchpad guys [18:23] hip hip [18:23] woohaa [18:23] * SpamapS wishes the bot would say HOORAY when it sees that :) [18:23] SpamapS: Hah, that'd be nice :-) [18:33] adam_g: hey, can you try pushing your +junk formulas to /principia/oneiric/xxxx/trunk ? === niemeyer_ is now known as niemeyer [19:02] Alright.. let's see that queue [19:03] kirkland: Was the version of byobu-tmux that is in review the same you tested in real interactions? === otubo is now known as otubo[AFK] [19:52] hi *.*! [20:03] vciaglia: welcome! [20:03] hi SpamapS! [20:09] vciaglia: I'm Clint from the mailing list btw. Great job on the initial squid formula. :) [20:09] SpamapS, nice to meet you! [20:11] <_mup_> ensemble/formula-state-with-url r313 committed by kapil.thangavelu@canonical.com [20:11] <_mup_> ec2 storage.get_url better test verification of hmac signature [20:12]