hazmatniemeyer, using the lp api in bzr doesn't look it will work, too many roundtrips to lp00:43
hazmatits too slow00:43
hazmatit would have to be some sort of secondary cache for querying01:10
hazmatwith bg updates01:10
niemeyerhazmat: What were you looking to do there?01:30
hazmatniemeyer, 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 why01:32
hazmati'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 concept01:32
hazmateven with a cache though, there's too much link traversal/roundtrips to answer some questions01:33
hazmatits a bit slow... it might just need to be a web app01:33
hazmatso i can use the bg updated cache for live views01:34
niemeyerhazmat: Yeah, that's a fairly common complaint about that API01:42
niemeyerhazmat: Even for our store API, it took a few roundtrips before they accepted the traditional way of doing things would be non-efficient01:43
niemeyerhazmat: There's some level of agreement that something must be done to improve the conventions, though01:44
niemeyerREST FTW..01:44
hazmatit 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 cache01:46
hazmatits 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 entity01:47
hazmatproject most likely given that's the common organization level in lp01:48
_mup_Bug #827071 was filed: Improved tmux byobu key bindings <Ensemble:New> < https://launchpad.net/bugs/827071 >02:25
_mup_Bug #827073 was filed: Fixed number of machines placement policy <Ensemble:New> < https://launchpad.net/bugs/827073 >02:43
_mup_ensemble/verify-version r314 committed by jim.baker@canonical.com03:04
_mup_Addressed review, but mocking is still not working for new scheme03:04
_mup_ensemble/verify-version r315 committed by jim.baker@canonical.com03:14
_mup_Try a mocker like solution for the interim03:14
_mup_ensemble/verify-version r316 committed by jim.baker@canonical.com03:16
_mup_Try a mocker like solution for the interim03:16
_mup_ensemble/verify-version r316 committed by jim.baker@canonical.com03:24
_mup_ensemble/verify-version r317 committed by jim.baker@canonical.com03:27
_mup_ensemble/verify-version r318 committed by jim.baker@canonical.com03:28
_mup_Restored blank line03:28
_mup_ensemble/verify-version r319 committed by jim.baker@canonical.com03:30
_mup_Merged trunk03:30
_mup_ensemble/formula-state-with-url r312 committed by kapil.thangavelu@canonical.com03:36
_mup_merge trunk03:36
kirklandhazmat: any action I need to take on that one?04:17
kirklandhazmat: i see it's assigned to me04:17
hazmatkirkland, no just needed to get it onto the kanban view04:17
hazmatkirkland, we've been primarily using that as our view into the review queue, and branches without associated bugs (and milestones) don't show up04:18
kirklandhazmat: coolio;  should i file a bug per branch in the future?04:18
hazmatkirkland, yes, that would be great, also helps to assign it to the current milestone04:19
hazmats/helps/needs to be04:19
kirklandhazmat: sweet, will do04:20
hazmatits 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 workflow04:20
hazmatbut 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 kanban04:21
hazmatit takes too long sadly to make it a useful cli tool by itself04:21
fwereadeso, I was wondering about _run_operation in ec2.MachineProvider11:44
fwereadeit turns all errors raised by the operation into ProviderInteractionErrors11:44
fwereadebut it's only used on .connect11:45
fwereadeand 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 provider11:46
fwereadethey could be, say, attempts to get groups() from an unchecked regex match result11:46
fwereadeniemeyer: morning!11:52
niemeyerfwereade: Hey man11:53
fwereadeniemeyer: I was just talking to nobody in here :)11:53
fwereadeniemeyer: quick recap11:53
fwereadeniemeyer: ec2.MachineProvider._run_operation turns exceptions from the operation it runs into ProviderInteractionErrors11:54
fwereadeniemeyer: only used for .connect11:54
fwereadeniemeyer: I don't think it should exist at all, because the errors aren't necessarily related to provider interaction11:54
fwereadeniemeyer: individual ops can wrap errors in PIEs if they really want to11:55
fwereadeniemeyer: concur?11:55
niemeyerfwereade: Agreed11:55
fwereadeniemeyer: sweet11:55
niemeyerfwereade: This was an easy way to make sure that all operations we cared about would be properly wrapped11:56
niemeyerfwereade: As long as you're sure the operations are indeed taking care of translating the errors into something reasonable, it's not necessary11:56
fwereadeniemeyer: it's just the one operation that uses it anyway11:56
fwereadeniemeyer: the other possibility is that everything should use it (or a variant)11:57
fwereadeniemeyer: but that doesn't feel right to me11:58
niemeyerfwereade: This was used in strategic operations we believed were leaky in terms of which errors they could raise11:58
niemeyerfwereade: We didn't want it to blow in random ways11:59
niemeyerfwereade: Which is why it's fine as long as you indeed check that we're taking care of possibilities there11:59
fwereadeniemeyer: cool, got you11:59
fwereadeniemeyer: we've got some work to do on general provider interactions then12:00
fwereadeniemeyer: EC2Errors, S3Errors and xmlrpc Faults are currently passed through unless they correspond to specific error states we already know about12:00
niemeyerfwereade: This is exception handling "FTW".. in Go we'd just say "if <thing errored> { <do something local to adapt>; <pop error up, perhaps wrapped> }.  That doesn't tend to feel nice when doing exception handling _everywhere_12:01
niemeyerfwereade: Well, there you go.. they shouldn't be passed through12:02
fwereadeniemeyer: writing a bug12:02
niemeyerfwereade: Generic/common code should not worry about EC2Error, or S3Error, etc12:02
fwereadeniemeyer: agreed12:02
niemeyerfwereade: That's why we wrap, and why we had that method there12:03
fwereadeniemeyer: sure, so it feels like we might want provider-specific wrappers12:04
fwereadeniemeyer: any ec2 MachineProvider call should be wrapped in something that converts EC2Errors and S3Errors but lets everything else through12:05
niemeyerfwereade: 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 properly12:05
fwereadeniemeyer: yep, makes sense12:06
niemeyerfwereade: 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 context12:06
fwereadeniemeyer: 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 it12:06
_mup_Bug #827308 was filed: ProviderInteractionError wrapping not consistent <Ensemble:New> < https://launchpad.net/bugs/827308 >12:16
fwereadeniemeyer: btw... how often should the kanban board update?12:20
niemeyerfwereade: I believe the one maintained by IS is broken again12:20
niemeyerPlease use this one for now: people.canonical.com/~niemeyer/dublin.html12:20
=== niemeyer changed the topic of #ubuntu-ensemble to: http://people.canonical.com/~niemeyer/dublin.html | http://ensemble.ubuntu.com/docs
fwereadeniemeyer: cheers12:21
=== niemeyer changed the topic of #ubuntu-ensemble to: http://j.mp/ensemble-dublin | http://ensemble.ubuntu.com/docs
fwereadeniemeyer: https://code.launchpad.net/~fwereade/ensemble/find-all-zookeepers/+merge/71668 may qualify as trivial12:21
niemeyerfwereade: 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 one12:23
fwereadeniemeyer: cheers12:24
niemeyerfwereade: Are the call sites ready to take more than one machine?12:24
fwereadeniemeyer: only client is connect, which currently just grabs the first one12:25
fwereadeniemeyer: I was proposing to grab the first one with an assigned dns_name, if it exists12:26
fwereadeniemeyer: cleverer choosing algorithm can wait until we actually bring up multiple zookeepers, I think12:27
fwereadeniemeyer... oh no it's not12:28
fwereadeniemeyer: I missed bootstrap12:28
fwereadeniemeyer: not sure what the semantics should be there12:28
fwereadeniemeyer: 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 result12:29
fwereadeniemeyer: if we were to decide that start_machine should return a naked machine, it would matter12:30
niemeyerfwereade: I don't understand what you mean?12:30
fwereadeniemeyer: sorry :)12:30
niemeyerfwereade: If we didn't use the result of bootstrap, how would we guess later the machine we bootstrapped?12:31
fwereadeniemeyer: bootstrap() returns the result of get_zookeeper_machines(), or the result of start_machine()12:31
niemeyerfwereade: Sounds sane?12:31
fwereadeniemeyer: isn't that internal?12:31
niemeyerfwereade: What's internal?12:32
fwereadeniemeyer: bootstrap uses the result of start_machine internally to write the state12:32
fwereadeniemeyer: or passes through the result of get_zookeeper_machines12:32
fwereadeniemeyer: well, actually, LaunchMachine itself does the writing if it's constructed in bootstrap mode, that's definitely a bug12:33
niemeyerfwereade: Yes, you're describing what happens.. I don't understand what you think the problem is12:33
fwereadeniemeyer: but it's asymptomatic until we have multiple zookeepers anyway12:34
fwereadeniemeyer: 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_machines12:35
niemeyerfwereade: Yes, you're saying it returns a single machine at all times12:35
niemeyerfwereade: Which is what it already did12:35
niemeyerfwereade: My original question (which remains) is whether all call sites are ready to deal with multiple machines12:36
niemeyerfwereade: Because that's what the branch does12:36
fwereadeniemeyer: let me start again12:37
fwereadeniemeyer: the call sites are in connect, and bootstrap12:37
fwereadeniemeyer: both expect lists12:37
fwereadeniemeyer: 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 that12:38
fwereadeniemeyer: this branch is just preparing a small part of the necessary ground12:38
niemeyerfwereade: The question is simpler than that12:39
niemeyerfwereade: Will the call sites break because you're passing a list?12:39
niemeyerfwereade: with more than one element12:39
fwereadeniemeyer: no12:39
niemeyerfwereade: Phew.. ;_)12:39
fwereadeniemeyer: :)12:40
fwereadeniemeyer: on general principles, shall I add a test for bootstrap with multiple zookeepers, to make it clear?12:42
niemeyerfwereade: Nah12:42
niemeyerfwereade: Whoever adds logic to actually deal with multiple machines will go through that12:43
fwereadeniemeyer: ok, cool 12:43
niemeyerfwereade: I just wanted to make sure we were not consciously adding a bomb12:43
fwereadeniemeyer: just a change, it'd need to be mixed with other stuff to become a bomb ;)12:44
niemeyerfwereade: So, sure.. you can merge it.. it's not clear why that's being done, but fine12:47
fwereadeniemeyer: 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 exist12:49
niemeyerfwereade: Sound sgood12:56
niemeyerSpamapS: ping13:05
niemeyerfwereade: How much time do you think we still need for the "Orchestra works" bits of the problem to be in trunk?13:42
fwereadeniemeyer: 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 separately13:43
fwereadeniemeyer: the orchestra connect should basically be null, it's just a matter of writing tests13:43
niemeyerfwereade: Ok, but by now you have an idea of the pipeline "cost".. how long do you think before your buffer empties?13:44
fwereadeniemeyer: 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
fwereadeniemeyer: this week sounds very plausible though13:47
niemeyerfwereade: Thanks.. that gives me an idea of order of magnitude13:47
niemeyerfwereade: No need for spot on accuracy in this case13:47
fwereadeniemeyer: cool13:48
fwereadeniemeyer: you know, I could have sworn I was at some sort of sprint last week :p14:06
niemeyerfwereade: Oh man, did I miss you?14:06
fwereadeniemeyer: don't worry, the opportunity for a snarky comment makes up for it :)14:07
niemeyerkim0: ping14:10
kim0niemeyer: pong14:16
niemeyerkim0: Can you please tweak the blog post to reflect the points made in the thread? 14:16
jcastrook guys, here's the report for the last week so far: http://pad.ubuntu.com/ensemble-report14:17
kim0niemeyer: sure yeah14:18
niemeyerkim0: Thanks14:19
niemeyerjcastro: Anders and Dustin also worked on the Orchestra provider14:20
niemeyerjcastro: and Clint also worked with Jim on testing the expose/unexpose IIRC14:21
niemeyerjcastro: Kapil also worked on the local development/LXC14:21
niemeyerjcastro: That's why I avoid giving names to the specific tasks.. :)14:22
* jcastro just adds more names instead14:22
niemeyerjcastro: I add all names on the sprint/project.. one boat. :)14:23
niemeyerjcastro: Some times I forget, though..14:23
hazmatfwereade, 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 providers14:31
fwereadehazmat: that's the idea -- in my current branch, ZookeeperConnect has a very simple _pick_machine method, which may become more complex in the future14:34
jimbakerhazmat, there should be support in sshclient for this scenario... but it only takes the first one in the list14:34
fwereadehazmat: 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 list14:35
fwereadejimbaker: there are going to be lots of changes when we have multiple zookeepers... with this, there will be one fewer14:36
fwereadejimbaker: it's not much but it's a start14:36
jimbakerfwereade, ok, i should definitely review your branch. i happened to be looking at test_sshclient to better understand the power of mocker14:37
fwereadejimbaker: oh, sorry, I misread sshclient... yeah, I think that's a very nice idea, I hadn't even thought of that14:38
fwereadejimbaker: but the sshclient code scares me :)14:38
jimbakerfwereade, the sshclient code is simple. you should see test_sshclient ;)14:39
* fwereade cowers14:39
_mup_ensemble/verify-version r320 committed by jim.baker@canonical.com14:40
_mup_At least don't do something stupid/unpythonic with action at a distance module namespace changes14:40
jimbakerthe 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 up14:41
fwereadeabout sshclient...15:03
fwereadewhy do we raise txzookeeper ConnectionTimeoutExceptions?15:03
fwereadeshouldn't we have an ensemble ConnectionTimeout(NoConnection)?15:04
jimbakerfwereade, i believe this is to keep the interface compatible with txzookeeper client15:16
niemeyerfwereade, 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
jimbakerniemeyer, sounds good15:25
niemeyerfwereade: I'll clean the queue today, so expect good feedback tomorrow15:25
niemeyerjimbaker: Can we have a call after lunch?  In.. 1.5h?15:26
jimbakerniemeyer, cool, i was wondering which time zone's afternoon :)15:26
jimbakerso that time works for me15:26
jimbakerniemeyer, 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 that15:27
niemeyerjimbaker: Setting the module name?15:28
niemeyerjimbaker: Don't know what that'd mean15:28
jimbakerniemeyer, i'm trying to do something like the following: http://paste.ubuntu.com/667409/15:31
jimbakerit's a very simple thing: in this test, i want to change ensemble.state.topology.VERSION to another number (say by incrementing it)15:31
jimbakerniemeyer, so action at a distance for code that is relying on this VERSION, specifically InternalTopology.parse15:32
jimbakerniemeyer, 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 working15:33
SpamapSniemeyer: pong, good morning :)15:35
niemeyerjimbaker: Yeah, I get it.. I've sent a mail about it yesterday15:36
fwereadeniemeyer: cool, thanks (I'm around for a little while longer today but not *that* long :))15:36
niemeyerjimbaker: Use the patch method in ensemble.lib.testing15:36
niemeyerSpamapS: morning!15:36
jimbakerniemeyer, cool, that's what i have been trying, as well as seeing how it's used15:37
jimbakerniemeyer, sorry, now i see the difference - this is a separate patch from mocker15:38
niemeyerjimbaker: That's not what I get from your message, but let's talk later.. have to pay attention here15:39
jimbakergiven this is exactly equivalent to what i want to do, just something we have coded up, that should do what i want15:39
fwereadejimbaker: ah, I see, thanks15:40
SpamapSniemeyer: so I was thinking about this, and wondering if there's a way we can run the ftests from the .deb ..15:42
SpamapSniemeyer: That way we can ask people to run them in support situations15:42
jimbakerniemeyer, cool, the correct patch method works15:43
_mup_ensemble/verify-version r321 committed by jim.baker@canonical.com15:46
_mup_Use TestCase.patch for action at a distance change to module namespace15:46
niemeyerSpamapS: Probably not..15:49
niemeyerSpamapS: Well.. maybe yes, depending on what you mean by that15:49
niemeyerSpamapS: You mean running ftests when debs are built, or running ftests with an ensemble that was deb-installed?15:49
niemeyerjimbaker: Super15:50
SpamapSniemeyer: the latter15:50
niemeyerSpamapS: That's doable15:50
jimbakerniemeyer, 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
jimbakernow it's all clear15:51
niemeyerSpamapS: But I think it makes most sense to do against trunk15:51
niemeyerSpamapS: Ideally ftests would be run more frequently than deb-builds15:51
jimbakerat least it got me look at test_sshclient again, just in time to discuss w/ fwereade 15:52
niemeyerjimbaker: Cool, sorry for the confusion15:52
fwereadeserendipitous :)15:52
jimbakerfwereade, indeed :)15:52
niemeyerAlright, I'm off the call, and will get some lunch and get cranking15:52
SpamapSniemeyer: 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:52
jimbakerniemeyer, no worries15:53
niemeyerSpamapS: That's not the point15:53
SpamapSniemeyer: 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:53
niemeyerSpamapS: If a revno from bzr is ftested, it's ftested, no matter if it's within a deb or within a branch15:54
niemeyerSpamapS: For quality assurance, it's beneficial to have ftests running even before they get to a deb15:54
niemeyerSpamapS: Even with interim revisions15:54
SpamapSniemeyer: 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
niemeyerSpamapS: ftests don't test an environment..15:55
niemeyerSpamapS: They test that ensemble works15:55
_mup_ensemble/verify-version r322 committed by jim.baker@canonical.com15:55
_mup_Merged trunk15:55
SpamapSYeah, though they're more sensitive to environment breakage than unit tests.15:55
niemeyerSpamapS: Yes, they are functional tests15:55
SpamapSLike 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
SpamapSBut the ftests should expose that. I think.15:57
niemeyerand that's why we want to run it with every revision from trunk, rather than just packaged revisions15:57
SpamapSall good. I *also* want to have it in the arsenal of things to suggest that a suer try when they're having trouble15:58
SpamapSuser too15:59
SpamapSsuer's are even more scary than users :)15:59
niemeyerSpamapS: LOL15:59
niemeyerSpamapS: I wouldn't do that myself15:59
niemeyerSpamapS: For the same reason we don't ask users to run unittests15:59
niemeyerSpamapS: But if you want to do it.. well..16:00
SpamapSwith 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:01
SpamapSAnyway it was just a thought that passed through my head as I'm planning to setup the jenkins tests16:02
niemeyerSpamapS: Sounds good16:03
niemeyerLunch for reals16:04
jamespageSpamapS: 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 up16:05
jamespagemake sure we are not overlapping/share knowledge etc..16:05
m_3jamespage: +1 flyonthewall for that16:06
jamespagem_3: coolio - I need to write up what I did last week and circulate - it works but its not that elegant16:07
SpamapSjamespage: Yeah, Adam said you had been doing some stuff16:07
m_3jamespage: understand... I've had similar "compromises" in this area16:07
SpamapSjamespage: 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 brilliant16:08
jamespageSpamapS, m_3: thats pretty much what I did - its basic ATM but it can be run from Jenkins to generate graphs etc..16:09
m_3are you mocking or actually relating?16:09
jamespagealso puts writing the tests for a formula IN the formula which feels nice16:09
jamespagem_3: actually relating16:09
jamespagem_3, SpamapS: I implemented it as a single formula-tester service16:10
SpamapSjamespage: so I have a strong desire to test the orchestra -> openstack -> all other formulas chain .. over and over..16:11
jamespageand tester-* hooks each of the services which get related after the environment is deployed16:11
jamespageat which point the tests get executed and collated back to the formula-tester16:11
jamespagewhich jenkins pulls all of the results from16:11
SpamapSjamespage: hah, sweet!16:11
SpamapSjamespage: so the test relation tells jenkins what to relate the formula to?16:12
jamespageits a little 'grey' in some areas as it was hard to tell when relations and finished relating16:12
m_3jamespage: nice... how is it specifying what the relation is expecting/providing?16:13
m_3jamespage: or is it just discovery?16:13
SpamapSI 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, 116:13
jamespageSpamapS: that would be great16:13
SpamapSwe can fake it w/ status for now16:13
jamespagem_3, SpamapS: so I have this new formula - http://bazaar.launchpad.net/~james-page/+junk/formula-tester/files16:14
jamespagewhich provides the 'testing' interface16:14
jamespageSo 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/files16:15
jamespageAll 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 with16:16
m_3nice, and stays out of the way unless the tester relation is joined16:17
jamespageI then hacked together a wrapper script - http://bazaar.launchpad.net/~james-page/+junk/test-formula/files16:17
jamespageto bootstrap, build the environment, collate the test results and kill everything16:17
jamespageit parses the yaml of ensemble status plus other hacks to determine where its up-to16:18
jamespageThen there is a openstack-formula-test branch - http://bazaar.launchpad.net/~james-page/+junk/openstack-formula-test/files16:18
jamespagewhich has the hooks and config for deploying the openstack formulas and testing them16:19
jamespagefreeze/rehydrate environment in ensemble would really help with this16:19
jamespageas it has lots of little snoozes at the moment16:19
jamespage(adam_g and I where not that brave)16:19
m_3jamespage: brilliant man16:20
SpamapSjamespage: 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
jamespageyeah - as I said it lacks polish16:20
SpamapSjamespage: But I do think its a good framework for getting tests written. What is the XML format?16:21
jamespageI'm going to get it up and running somewhere visible so folks can see16:21
jamespageso the tests are written as python unittest16:21
jamespagesubunit + subunit2junitxml is then used to massage the output into JUnit XML format which Jenkins likes16:22
SpamapSjamespage: so it kind of makes sense for all of that to happen on the jenkins side16:22
jamespageI'm not conivinced that python unittest quite the right solution.16:23
m_3jenkins service could actually even _be_ the testing service16:23
jamespagem_3 - hey - neat idea!16:23
SpamapSs/could/should/ ;)16:23
m_3but it might make sense to keep it separate for stability16:23
m_3I can see the tester getting jammed at times16:23
* m_3 grokking ramifications16:24
SpamapSThis can all be quite fluid.16:25
m_3and contained :)16:25
m_3it sort of is a mocker too16:25
m_3so all of those patterns apply16:25
SpamapSFormulas are their own mocks in some way.16:26
SpamapSWant to test if mediawiki's mysql works, before relating it to the database? deploy it.. relate it.. done.16:26
SpamapSSince 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 mediawiki16:27
m_3and it keeps in the spirit of ensemble with freeform tester scripts/hooks in each formula16:27
m_3not forcing a whole lot of framework16:28
m_3SpamapS: right, it's doesn't carry over directly16:28
jamespagem_3, SpamapS: so one thing we did not have a good answer for was how you test a service's relations16:29
m_3what are the goals of a formula unit-test?16:29
jamespagem_3: good question16:29
m_3implements the service's relation APIs?16:29
SpamapSjamespage: 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:30
hazmati 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 cli16:31
hazmateffectively each formula would have a tests/hook-name-test and tests/hook-name-setup16:31
jamespageSpamapS: 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 running16:31
hazmatthe 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 hook16:32
SpamapSjamespage: 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:32
jamespagethats what we have done so far16:33
jamespagethey are pretty easy to implement unittest style 16:33
SpamapSsounds like we should plan to chat about formula testing in Orlando16:33
m_3worth hangouts before then too?16:34
m_3(this is a big deal)16:35
SpamapSat this point i just want to get a bzr triggered test against OpenStack setup.16:44
SpamapSIf I can also make it test against Orchestra.. that would be fabulous. :)16:44
SpamapSooo oo ooo bug 386596 passed QA! :)16:45
_mup_Bug #386596: pushing to a packaging branch can't create a new package <codehosting-ssh> <escalated> <lp-code> <not-pie-critical> <package-branches> <principia> <qa-ok> <stakeholder> <Launchpad itself:Fix Committed by abentley> < https://launchpad.net/bugs/386596 >16:45
m_3ah... nice16:45
hazmatbcsaller, got time for a chat on lxc work?16:47
bcsallerhazmat: absolutely, can you give me 10 minutes16:47
hazmatbcsaller, sure16:48
fwereadenn all, take care16:55
bcsallerhazmat: did the picture of the planning board at the sprint come out? can we share that on U1?16:55
hazmatbcsaller, sure, i've to grab it off my camera17:00
jimbakerniemeyer, ready to talk?17:01
hazmatbcsaller, i'm chilling in a g+ hangout17:08
jimbakerbcsaller, 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 errReceived17:14
_mup_Bug #823586: intermittent failure in test_relation_get_format_shell_bad_vars <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/823586 >17:14
hazmatbcsaller, g+ fail17:15
bcsallerjimbaker: 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 expectations17:16
bcsallerhazmat: I'll start a new one17:16
jimbakerbcsaller, i think relaxing the test is the best course of action. we can still be best effort on the flush17:16
jimbakerbcsaller, anyway i will put a fix in place and push it for review17:17
bcsallerjimbaker: thanks alot17:17
jimbakerbcsaller, 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
bcsallerhazmat: skype?17:17
hazmatbcsaller, installing it now17:18
bcsallerjimbaker: good point17:18
jimbakerbcsaller, that was a change i recently made, r286 (robust-hook-exit)17:19
_mup_ensemble/fix-shell-bad-vars-test r314 committed by jim.baker@canonical.com17:26
_mup_Relax stream ordering requirement in test, but do wait on streams being closed before testing17:26
* robbiew goes to pack for linuxcon flight today :/17:26
jimbakerbcsaller, this looks like a trivial to me, so if you want to review it first and concur, we can do it as such17:32
niemeyerjimbaker: Here17:32
jimbakerbcsaller, lp:~jimbaker/ensemble/fix-shell-bad-vars-test17:32
jimbakerniemeyer, skype?17:33
niemeyerjimbaker: G+?17:33
jimbakerniemeyer, g+ always seems heavyweight for this sort of thing, but sure17:33
niemeyerjimbaker: Luckily we don't have to send packets manually17:34
jimbakerniemeyer, ;), i just mean the setup. let's see here...17:34
niemeyerjimbaker: Setup?  You mean clicking on that button in a web page?17:35
niemeyerjimbaker: What's your gmail account?17:36
niemeyerI'll send the invite17:36
jimbakerniemeyer, still not quite like a skype call. anyway, just waiting here17:36
jimbakerniemeyer, james.edward.baker@gmail.com17:36
niemeyerjimbaker: Danke17:36
niemeyerjimbaker: Done17:37
hazmatjimbaker, 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
hazmati'd like to go ahead and close out the dublin milestone17:42
niemeyerhazmat: It'd be better to do a more realistic selection..17:46
niemeyerhazmat: Or just move everything out, and then include selectively 17:46
niemeyerhazmat: We have a month, pretty much17:46
niemeyerhazmat: Would be great to do the move, though17:49
niemeyerhazmat: I can do the kanban once you've opened the new one17:49
hazmatniemeyer, https://blueprints.launchpad.net/ensemble/+spec/ensemble-local-development17:49
hazmatniemeyer, the new one is open17:50
hazmatbcsaller, https://blueprints.launchpad.net/ensemble/+spec/ensemble-local-development17:50
bcsallerniemeyer: 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:07
niemeyerbcsaller: We can talk now18:09
niemeyerbcsaller: Here or G+?18:09
niemeyerbcsaller: Ok.. waiting for invite18:09
SpamapSshouldn't this be moved out of drafts? https://ensemble.ubuntu.com/docs/drafts/service-config.html18:19
hazmatSpamapS, it should indeed18:20
SpamapSAlso we should do redirects on 404 in drafts to /docs/$filename18:20
SpamapSMaybe some mod_rewrite magic so we can only do it when files of the same name exist there.18:21
niemeyerAlright!  Launchpad formulas (aka source packages) on demand are live!18:22
niemeyerA toast to the Launchpad guys18:23
SpamapShip hip18:23
* SpamapS wishes the bot would say HOORAY when it sees that :)18:23
niemeyerSpamapS: Hah, that'd be nice :-)18:23
SpamapSadam_g: hey, can you try pushing your +junk formulas to /principia/oneiric/xxxx/trunk ?18:33
=== niemeyer_ is now known as niemeyer
niemeyerAlright.. let's see that queue19:02
niemeyerkirkland: Was the version of byobu-tmux that is in review the same you tested in real interactions?19:03
=== otubo is now known as otubo[AFK]
vciagliahi *.*!19:52
SpamapSvciaglia: welcome!20:03
vciagliahi SpamapS!20:03
SpamapSvciaglia: I'm Clint from the mailing list btw. Great job on the initial squid formula. :)20:09
vciagliaSpamapS, nice to meet you!20:09
_mup_ensemble/formula-state-with-url r313 committed by kapil.thangavelu@canonical.com20:11
_mup_ec2 storage.get_url better test verification of hmac signature20:11
vciagliaSpamapS, i'm just hacking around to create a good proftpd formula. It's very interesting because we could work with TLS too.20:12
SpamapSvciaglia: cool. Do you have a use case for these or just wanting to play?20:13
vciagliaSpamapS, currently just playing. I'm identifying some services where i could work on.20:17
SpamapSvciaglia: great. One of the things that Ensemble is really good at is relating services together.. so if you can think of something that proftpd needs to use (like, for instance, a mysql server for auth) thats a great place to start.20:18
vciagliaSpamapS, i saw formulas for worpdress, wikimedia, joomla. To relate togheter services i thought to Magento but unfortunately isn't in Ubuntu Repository.20:19
vciagliais it a problem or we can create a simple bash script to download and install from sources?20:19
SpamapSvciaglia: the only requirement is that you verify it somehow.. so gpg or md5sum works.20:23
SpamapSvciaglia: You can also embed a tarball in the formula itself.20:23
SpamapSvciaglia: curious, why isn't Magento in Ubuntu?20:23
vciagliaSpamapS, dunno :D20:24
SpamapSWow a 13MB download.. :)20:27
niemeyerAnyone able to review a trivial: https://code.launchpad.net/~jimbaker/ensemble/fix-shell-bad-vars-test/+merge/7174920:30
=== daker is now known as daker_
niemeyerkirkland: ping20:44
kirklandniemeyer: pong20:44
niemeyerkirkland: Hey20:45
kirklandniemeyer: howdy!20:45
niemeyerkirkland: The branch byobu-tmux.. is it exactly what you tested last time?20:45
niemeyerkirkland: Just want to make sure what we merge passed through a real use round20:45
kirklandniemeyer: i did test what I proposed for merging;  I do have two branches, though;  let me be explicit here on which one20:45
kirklandniemeyer: one minute20:46
kirklandniemeyer: yes, https://code.launchpad.net/~kirkland/ensemble/byobu-tmux is the correct branch, and yes, tested last week on 11-Aug-201120:48
niemeyerbcsaller, hazmat, jimbaker: ping20:50
niemeyerkirkland: Awesome, merging, thanks!20:50
kirklandNicke: cheers, thanks20:50
hazmatniemeyer, pong20:51
niemeyerhazmat: Easy one: https://code.launchpad.net/~fwereade/ensemble/spike-catchup/+merge/7126920:51
_mup_ensemble/trunk r314 committed by gustavo@niemeyer.net20:52
_mup_Merged byobu-tmux branch from Dustin [r=fwereade,niemeyer]20:52
_mup_This adds supports for the byobu tmux configuration on debug-hooks.20:52
vciagliaSpamapS, maybe i could help with phpmyadmin formula (related to apache). It's already assigned but i don't see any progresses.20:53
hazmatniemeyer, done, easy indeed, looks great20:53
niemeyerhazmat: Thanks!20:53
vciagliaSpamapS, related to apache and mysql20:53
SpamapSvciaglia: I think at this point you're welcome to take it on.. the person who started work on it seems to have gotten stuck.20:55
vciagliaSpamapS, great! Ok, tomorrow i'll start working on20:56
hazmatjimbaker, re mocker.replace from yesterday.. ensembletestcase.patch is perhaps what you where looking for20:58
jimbakerhazmat, yeah, that's definitely the one - i have updated the branch to use that21:59
_mup_ensemble/fix-shell-bad-vars-test r315 committed by jim.baker@canonical.com22:00
_mup_Merged trunk22:00
niemeyerLights went off.. BOOM outside.. lights went on.. lights went off again.. BOOM outside again.. lights do not go on anymore.22:10
niemeyerI suspect this might take a while22:10
_mup_ensemble/trunk r315 committed by jim.baker@canonical.com22:11
_mup_merged fix-shell-bad-vars-test [r=niemeyer][f=823586]22:11
_mup_[trivial] Remove testing of ordering of flushes to different streams22:11
_mup_in intermittent failing test, such ordering cannot be guaranteed when22:11
_mup_collected for logging by HookProtocol.22:11
niemeyerOkay.. fwereade's branches have at least one review each22:49
niemeyerWill clean the rest of the queue tomorrow morning22:50
niemeyerI'll step out for the moment..22:50
=== otubo[AFK] is now known as otubo

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!