21:01:48 <ttx> #startmeeting
21:01:49 <openstack> Meeting started Tue Jul 26 21:01:48 2011 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:01:57 <ttx> Welcome to the weekly OpenStack meeting...
21:02:11 <ttx> Today's agenda:
21:02:20 <ttx> #link http://wiki.openstack.org/Meetings/TeamMeeting
21:02:38 <ttx> #topic Swift status
21:02:52 <ttx> scotticus: hey!
21:03:02 <ttx> So we have a 1.4.2 release candidate standing in the milestone-proposed branch
21:03:13 <ttx> While trunk has been switched to 1.4.3 development
21:03:24 <ttx> No milestone-critical bug in https://launchpad.net/swift/+milestone/1.4.2
21:03:37 <ttx> So... unless we have issues, are you OK if I release 1.4.2 Wednesday, as planned ?
21:03:45 <scotticus> yes
21:03:55 <ttx> cool :)
21:04:08 <ttx> scotticus: do you already have plans/dates for the next milestone (1.4.3?) ?
21:04:13 * creiht notes for the record that scotticus is stepping in for notmyname for those who do not know
21:04:22 <scotticus> not that i have noted.
21:04:24 <creiht> while he is at oscon
21:05:03 <ttx> creiht: indeed
21:05:12 <ttx> scotticus: Other announcements/comments ?
21:05:31 <scotticus> nope, thats all.
21:05:35 <scotticus> thank you
21:05:37 <ttx> Raise your hand if you have questions on Swift...
21:06:36 <ttx> #topic Glance status
21:06:40 <jaypipes> https://launchpad.net/glance/+milestone/diablo-3
21:06:44 <jaypipes> https://launchpad.net/glance/+milestone/diablo-4
21:07:04 <ttx> diablo-3 milestone branch was cut this morning
21:07:16 <ttx> We have 4 release-critical bugs on the list -- all assigned
21:07:18 <jaypipes> we're looking good on D3. got to get clayg's latest proposed bug fix in, and figure out some packaging snafus, but should be good to finalize by thursday
21:07:35 <ttx> Bug 816386 (jkoelker)
21:07:36 <uvirtbot`> Launchpad bug 816386 in glance "test_scrubber functional tests fail on package build" [High,In progress] https://launchpad.net/bugs/816386
21:07:42 <ttx> this one is blocking PPA package builds, so needs to be fixed ASAP...
21:07:45 <jaypipes> ttx: the packaging crap is the stumbling block for two of those bugs... the S3 ones (boto versioning)
21:08:16 <jaypipes> ttx: yes, I'm think jkoelker needs help from mtaylor or soren on that one.
21:08:21 <ttx> Apparently it's not just a timing issue, so you need some Ubuntu buildd foo to solve it
21:08:30 <jaypipes> I'm think. Ugh, I'm tired...
21:08:32 <ttx> soren looks into it -- we might disable that specific test on buildds as a D3 workaround
21:08:49 <jkoelker> ttx: yea i can't reproduce it on an ubuntu VM either,
21:09:10 <ttx> jkoelker: no, it looks like it only happens on PPA build daemons
21:09:18 <vishy> ttx, jaypipes, soren: what is the best way to handle this: https://code.launchpad.net/~tr3buchet/nova/lp816612/+merge/69365 branch was made against trunk and went in but i think it should go in milestone as well
21:09:18 <ttx> which makes debugging... a bit painful
21:10:03 <ttx> vishy: anyone on openstack-release can approve it
21:10:12 <ttx> vishy: will talk to you later
21:10:21 <jaypipes> vishy: yeah, back off! :)
21:10:37 <vishy> hehe, sorry jumped the gun a bit
21:10:41 <jaypipes> :)
21:10:44 <ttx> jaypipes: so you need to upgrade to boto2 to fix those s3 things ?
21:10:57 <ttx> jaypipes: I pray it won't trigger as many issues as in nova
21:11:03 <jaypipes> ttx: ok, so I will work with soren on those two issues (3 of the 4 outstanding bugs..)
21:11:38 <jaypipes> ttx: Well, I'm not sure yet. All I know if the method signature of S3Connection.__init__() is different from 1.9 to 2.0
21:11:51 <jaypipes> ttx: and the tests all pass on 2.0 and fail on 1.9. go figure.
21:12:15 * ttx is getting a bit tired with boto, days are not long enough
21:12:28 <jaypipes> yeah..
21:12:30 <ttx> Bug 713154
21:12:31 <uvirtbot`> Launchpad bug 713154 in glance "S3 Backend doesn't support POST either." [Medium,In progress] https://launchpad.net/bugs/713154
21:12:38 <ttx> Bug 794718
21:12:39 <uvirtbot`> Launchpad bug 794718 in glance "S3 requires seekable file. webob versions 0.9.8 through 1.0.7 make_body_seekable() method broken for chunked transfer requests" [Low,In progress] https://launchpad.net/bugs/794718
21:12:45 <jaypipes> ttx: yep, both boto.
21:12:48 <ttx> ok
21:12:52 <ttx> Bug 814981
21:12:53 <uvirtbot`> Launchpad bug 814981 in glance "glance-api fails on image delivery: AttributeError: context" [Medium,Confirmed] https://launchpad.net/bugs/814981
21:13:05 <jaypipes> ttx: clayg gave a good solution to that one. I will work on that.
21:13:22 <ttx> ok, remember to land the fix in trunk before proposing it to milestone-proposed
21:13:23 <jaypipes> ttx: clayg's solution does not require packaging changes, thankfully..
21:13:29 <jaypipes> ttx: yep, will do.
21:13:36 <ttx> iablo-4 plan at https://launchpad.net/glance/+milestone/diablo-4 looks reasonable
21:13:58 <ttx> as in "just twice as many blueprints as the other milestones"
21:14:06 <jaypipes> ttx: yes, now that johannes and Vek are working with us ;)
21:14:17 <ttx> jaypipes: Announcements, comments ?
21:14:28 <jaypipes> ttx: no
21:14:28 <Vek> I haven't looked at that bug 814981, but it relates to code I just merged into glance; fix is to update config files
21:14:29 <uvirtbot`> Launchpad bug 814981 in glance "glance-api fails on image delivery: AttributeError: context" [Medium,Confirmed] https://launchpad.net/bugs/814981
21:14:33 * ttx expects a busy wednesday.
21:14:46 <jaypipes> Vek: actually fix is to make request context noop-able...
21:14:47 <Vek> a more useful error message would probably be helpful, though...
21:14:54 <ttx> Raise your hand if you have a question on Glance / for Jay
21:15:07 <Vek> jaypipes: *nod*
21:15:32 <jaypipes> Vek: but have to solve the broader "how to upgrade ini/paste.deploy files" anyway..
21:15:42 <jaypipes> Vek: https://blueprints.launchpad.net/openstack-ci/+spec/glance-upgrade
21:15:54 <ttx> #topic Nova status
21:15:59 <ttx> vishy: yo!
21:16:10 <ttx> diablo-3 milestone branch was also cut this busy morning
21:16:24 <ttx> We have three release-critical bugs in the list, some needing urgent love
21:16:41 <ttx> See https://launchpad.net/nova/+milestone/diablo-3
21:16:50 <ttx> Bug 816236
21:16:51 <uvirtbot`> Launchpad bug 816236 in nova "Initial 'nova db sync' migration failure on mysql due to foreign key reference" [Critical,Triaged] https://launchpad.net/bugs/816236
21:17:07 <soren> Are the disabled unit tests part of that?
21:17:19 <ttx> soren: part of what ?
21:17:20 <soren> "that" being "the set of critical bugs".
21:17:27 <soren> I guess not.
21:17:29 <vishy> soren: they are not
21:17:39 <ttx> soren: list at https://launchpad.net/nova/+milestone/diablo-3
21:17:39 <vishy> but any that can be fixed would be great
21:18:01 <ttx> I'll gladly accept any of them though :)
21:18:25 <ttx> vishy: do you have a victim^Wassignee for that schema upgrade issue ?
21:18:45 <vishy> so my question from earlier: the problem is that the fix is that it was done against trunk
21:18:51 <vishy> ttx: not yet
21:18:51 <ttx> vishy: I has a quick look at it, but figured an SQL/sqlalchemy-migrate expert would fix it way faster than I could
21:19:04 <vishy> it looks like there was a potential fix included
21:19:07 * jaypipes hides
21:19:15 <vishy> I actually haven't seen the bug manifest yet
21:19:19 <vishy> so step one is reproducing it
21:19:31 <vishy> perhaps it is oneiric only?
21:19:46 <adam_g> i hit that migration bug on natty
21:19:49 <ttx> soren, jaypipes, mtaylor: anything preventing a branch from trunk to be proposed to milestone-proposed ?
21:20:02 <vishy> adam_g: could you make a fix for it?
21:20:06 * ttx is a beliver in DVCS "just works" magic
21:20:07 <soren> I'm not sure I understand what tha tmeans :-/
21:20:14 <jaypipes> me neither.
21:20:19 <soren> If you mean:
21:20:22 <vishy> ttx: the issue is that just merging it will merge in the other three branches that merged
21:20:31 <adam_g> vishy: i was looking into it last night, but need to look at sqlachemy/migrate more to know how to fix it properly.
21:20:35 <soren> "Can a branch that has been merged into trunk also be merged into somthing else", then yes.
21:20:37 <jaypipes> vishy: ah...
21:20:40 <vishy> so i don't know the best way to handle it in bzr
21:20:52 <vishy> should we do a feaux "cherry-pick"
21:20:59 <vishy> and make a new branch?
21:21:04 <soren> Yeah, that's fine.
21:21:05 <vishy> and propose that one in?
21:21:09 <jaypipes> vishy: no, I think the specific merge would have to be proposed to be merged into the milestone release branch...
21:21:35 <vishy> jaypipes: you can't seem to do that through launchpad. i.e. propose just a specific revision
21:21:43 <soren> You can't, no.
21:21:46 <vishy> ok i will remake trebs branch against milestone proposed
21:21:48 <jaypipes> vishy: bzr merge -c REVNO
21:21:54 <vishy> and propose that one against milestone
21:22:18 <ttx> mtaylor: would the gerrit milestone-proposed magic you promised me solve that ?
21:22:20 <vishy> anyone else around that wants to try to fix the mysql issue?
21:22:25 <primeministerp1> what is is
21:22:27 <primeministerp1> er is it again
21:22:32 <primeministerp1> sorry
21:22:37 <ttx> primeministerp1: bug 816236
21:22:38 <uvirtbot`> Launchpad bug 816236 in nova "Initial 'nova db sync' migration failure on mysql due to foreign key reference" [Critical,Triaged] https://launchpad.net/bugs/816236
21:22:39 <primeministerp1> too many threads
21:23:14 <ttx> part of the "save the day, fix a RC bug !" campaign
21:23:21 <primeministerp1> haha
21:23:40 <primeministerp1> has someone reproduced it yet?
21:23:56 <primeministerp1> sorry i can take that off line
21:23:59 <adam_g> its easy to reproduce, install from trunk and try to migrate against a mysql database
21:24:05 <primeministerp1> o ok
21:24:05 <adam_g> migrations against sqlite work fine
21:24:28 <tr3buchet> isnt it the same as if you drop your database and start over?
21:24:33 <ttx> adam_g: are you planning to work on it ? Would definitely be a good idea :)
21:24:36 <primeministerp1> might be over my head but i'll try a poke at it
21:24:54 <ttx> primeministerp1, adam_g: ok, talk to each other to avoid duplication
21:24:55 <vishy> adam_g: I've done that on maverick and it works btw
21:25:04 <adam_g> it would be easy to just remove with sqlalchemy migrate, however, its created with an autogenerated name does not match the name sqlalchemy use to find it on removal
21:25:04 <vishy> adam_g: so it may be a natty+ issue?
21:25:32 <adam_g> ttx: i would like to, however, im at OSCOn currently and will not have a chance to look at it until tomorrow earliest
21:25:41 <ttx> rha
21:26:01 <ttx> we'll get back to this one
21:26:01 <adam_g> vishy: only tested on natty. will check at least oneiric this afternoon
21:26:08 <ttx> Bug 814365
21:26:09 <uvirtbot`> Launchpad bug 814365 in nova "Should support boto 2.0 server-side (was: EC2 API fails with >=boto2.0)" [Wishlist,Confirmed] https://launchpad.net/bugs/814365
21:26:16 <ttx> This one also needs a friend, though I think vishy is closing on a solution
21:26:26 <ttx> vishy: if you're close, maybe assign yourself to it
21:26:27 <vishy> ttx: I fixed it
21:26:33 <vishy> ttx: could use some reviews though
21:26:35 <mtaylor> ttx: yes
21:27:06 <mtaylor> ttx: branch from trunk to milestone-proposed is hard but possibly doable
21:27:07 <vishy> that should fix oneric builds as well
21:27:16 <ttx> vishy: so the cherrypicking stuff to milestone-proposed would probably be handled automatically in a gerrit new world order
21:27:20 <mtaylor> ttx: branch from milestone-proposed to trunk will soon magically happen
21:27:26 <mtaylor> ttx: ++
21:27:58 <ttx> bug 810563 (tr3buchet)
21:27:58 <uvirtbot`> Launchpad bug 810563 in nova "nova-manage lets you create broken networks (was: trying to add VLAN #100 to IF -:None:- error: No such device)" [Medium,Confirmed] https://launchpad.net/bugs/810563
21:28:08 <ttx> tr3buchet: should propose a merge today for that one ?
21:28:17 <tr3buchet> yes
21:28:27 <jaypipes> vishy: fix looks good. I might have to go with a similar switch on boto.Version >= 2 in Glance as well..
21:28:50 <tr3buchet> need to make sure lvov's nova-manage stuff doesn't interfere (it shouldnt)
21:29:26 <ttx> Any other candidates so far for the release-critical bug list ?
21:29:35 <vishy> tr3buchet: can you make the fix against milestone-proposed so it merges cleanly to both branches?
21:29:50 <tr3buchet> sure thing
21:30:00 <tr3buchet> is that two separate merge props then?
21:30:22 <vishy> yeah
21:30:32 <ttx> tr3buchet: yes, though the other one is not "reviewed" in the same sense
21:30:54 <tr3buchet> kk
21:31:33 <vishy> woot cherry pick success https://code.launchpad.net/~vishvananda/nova/milestone816612/+merge/69368
21:31:38 <ttx> primeministerp1: if you want to poke at bug 816236, feel free to assign yourself to it
21:31:39 <uvirtbot`> Launchpad bug 816236 in nova "Initial 'nova db sync' migration failure on mysql due to foreign key reference" [Critical,Triaged] https://launchpad.net/bugs/816236
21:31:57 <ttx> primeministerp1: and maybe team up with adam_g on verification/reproduction
21:32:06 <primeministerp1> ok
21:32:12 <primeministerp1> see if i can help
21:32:15 <vishy> appreciate it guys!
21:32:16 <ttx> I'll try to pick the resulting pieces tomorrow morning
21:32:20 <primeministerp1> we at misc stuff yet
21:32:24 <vishy> if you have trouble, ping me
21:32:26 <primeministerp1> have some hyperv notes to add
21:32:28 <adam_g> primeministerp1: i can pair with you on that one, i spent some time looking at it and have a good idea whats going on
21:32:37 <primeministerp1> we had some major progress w/ netwroking
21:32:56 <primeministerp1> we have scripts now to build virtual switches on windows core
21:33:33 <ttx> primeministerp1: still on nova
21:33:46 <ttx> just a sec and I'll pass to open discussion
21:33:46 <primeministerp1> we'll i'm speaking of nova-compute
21:33:48 <primeministerp1> kk
21:33:55 <ttx> quick note about nova diablo-4
21:34:09 <ttx> Due to all deferrals, plan for diablo-4 at https://launchpad.net/nova/+milestone/diablo-4 looks very unrealistic
21:34:16 <ttx> So I guess we'll trim it once diablo-3 is out of the door.
21:34:23 <ttx> vishy: more comments ?
21:34:35 <ttx> primeministerp1: please continue :)
21:35:18 <primeministerp1> o
21:35:19 <primeministerp1> sorry
21:35:20 <primeministerp1> so
21:35:32 <primeministerp1> we had to drill some hyperv dev's to get the wmi
21:35:35 <primeministerp1> and the sripts
21:35:40 <primeministerp1> er script
21:35:41 <primeministerp1> however
21:35:54 <primeministerp1> we can now automate the building of the virtual switch on hyperv
21:36:04 <vishy> primeministerp1: cool!
21:36:08 <primeministerp1> i know jordan was working on this stuff as well
21:36:14 <primeministerp1> but he must be out
21:36:19 <primeministerp1> hasn't gotten back to me
21:36:22 <primeministerp1> anyway
21:36:26 <ttx> primeministerp1: did you sync with mtaylor on hooking your test rig to the Jenkins infra ?
21:36:33 <primeministerp1> we still need to
21:36:40 <primeministerp1> we needed to get this piece first
21:36:41 <tr3buchet> ttx: i've got a question about a flag in the nova-manage command. i'd like to change "--flat_network_bridge" to just "--bridge". the flat network part is a misnomer
21:36:47 <primeministerp1> we want to move to all windows core
21:36:53 <primeministerp1> for the hypervisor os
21:37:02 <primeministerp1> and unfortunately
21:37:17 <primeministerp1> you apparently couldn't configure networking
21:37:21 <primeministerp1> on core
21:37:25 <primeministerp1> properly
21:37:34 <primeministerp1> but....
21:37:36 <primeministerp1> now we can
21:37:43 <primeministerp1> so i also wanted to share the wmi
21:37:45 <primeministerp1> with jordan
21:38:05 <primeministerp1> i know he was looking into the networking for hyperv
21:38:20 <ttx> tr3buchet: so far we handled backward compat in nova-manage quite badly, so I guess one more break can't hurt... vishy might disapprove though
21:38:22 <vishy> tr3buchet: seems fine, no one is using that new style yet anyway
21:38:36 <ttx> so that's ok ;)
21:38:38 <vishy> (it just went in last night) :)
21:38:42 <tr3buchet> vishy ttx: well i wanted to do it before the milestone so people don't start scripting against it
21:38:55 <ttx> primeministerp1: sounds good, just try to corner him somewhere
21:38:56 <tr3buchet> or less people do anyway
21:39:01 <vishy> agreed, change with your fix for that bug
21:39:02 <primeministerp1> heheh
21:39:09 <salv> primeministerp1: will these scripts enable us to do VLAN networking in Hyper-V as we do with libvirt, xenapi, and ESX?
21:39:10 <tr3buchet> vishy: will do
21:39:16 <primeministerp1> yes
21:39:18 <primeministerp1> it should
21:39:22 <primeministerp1> we just need the right wmi
21:39:35 <primeministerp1> and it might help us get bits of that as well
21:39:49 <ttx> Other questions on Nova ?
21:39:51 <salv> you mean WMI script or object?
21:39:54 <soren> Yes.
21:40:01 <ttx> soren: go ahead
21:40:07 <soren> I'd like to talk about the disabled unit tests.
21:40:15 <soren> I'll make it very short:
21:40:16 <soren> wtf?
21:40:21 <soren> Discuss.
21:40:29 <tr3buchet> i guess i started that one
21:40:33 <creiht> you should add a rule to tarmac to check for commented out unit tests
21:40:34 <creiht> ;P
21:40:39 <soren> We should.
21:40:40 <soren> Really.
21:40:50 * creiht shakes his head and hides in the corner
21:40:56 <soren> We decided at the summit that noone was allowed to decrease test coverage.
21:41:07 <soren> Yet here we are.
21:41:12 <tr3buchet> basically the vmware code doesn't work with nova since multinic
21:41:19 <vishy> soren: the idea was to get multinic in because it was likely to cause some breakages, hoping that others could help in fixing the broken tests
21:41:26 <tr3buchet> so their tests obviously don't either
21:41:29 <soren> So why rush it?
21:41:32 <soren> Why not fix those tests first?
21:41:39 <tr3buchet> because we'd have to fix vmware
21:41:48 <soren> Someone would.
21:41:52 <tr3buchet> but who?
21:41:55 <soren> if noone cares, rip the darn thing out.
21:42:00 <tr3buchet> +1
21:42:05 <soren> This is not about VMWare.
21:42:12 <soren> This is about the general problem.
21:42:15 <tr3buchet> i agree, i just picked that one o ut of the blue
21:42:31 <soren> Why does a new feature make it ok to disable tests?
21:42:38 <tr3buchet> the issue is handling things that change in nova which break many contituent pieces
21:42:50 <tr3buchet> constituent*
21:43:14 <soren> When people offer new patches and we ask them to provide tests as well, the reason I at least tend to give is that it's so that I don't break their stuff when I write new code.
21:43:29 <soren> ...but that really doesn't work if I just disable their tests if I happen to break their stuff anyway.
21:43:43 <ttx> We should at least have targeted the resulting issues to the milestone, to make sure I annoy people enough so that they fix the disabled tests
21:43:50 <ttx> Discovering them late was a problem
21:44:17 <soren> We're basically saying "Our use case is more important than anyone else's."
21:44:23 <vishy> agreed we definitely should have focused more on fixing the tests that broke
21:44:25 <soren> And that's bs.
21:44:44 <tr3buchet> true
21:45:00 <tr3buchet> i had assumed that the hypervisors would be quickly updated, and the tests rewritten
21:45:14 <soren> If a test is not *supposed* to work anymore, then fine. Remove it. Disabling it because you broke it... Not fine.
21:45:35 <tr3buchet> well it isn't that we broke the testas
21:45:38 <tr3buchet> tests
21:45:46 <tr3buchet> it's the the code the tests test is broken
21:45:47 <soren> The way I see it, if someone thinks a feature is important enough they should spend the extra time getting the tests sorted out (or bugging others to help them get the tests sorted out).
21:46:17 <ttx> soren: I'm with you on this one, but to tr3buchet's credit, we kinda anticipated that things would break in areas where he couldn't fix them (aka "less-supported hypervisors")
21:46:25 <tr3buchet> soren: i agree if it were only about the tests
21:46:28 <soren> I have trouble imagining a feature that's important and cool enough that it warrants breaking a bunch of other things.
21:46:34 <creiht> who supports the vmware hypervisor?
21:46:42 <soren> Things whose authors took the time to write unit tests for, no less.
21:46:44 <vishy> soren: disagree, I think there are some features
21:46:51 <vishy> that are that important
21:47:36 <salv> but if code on less-supported hypervisors is now broken, as tr3buchet says, does this mean the less-supported hypervisors are broken as well?
21:47:59 <soren> If there's a feature that we generally think is really important and it requires changes across the board, but noone wants to fix e.g. the VMWare driver... We remove the VMWare driver.
21:48:04 <tr3buchet> salv: until they are updated, yes
21:48:07 <creiht> perhaps you need a chart like the JS frameworks have, where you have "1st class" hypervisors that are guaranteed to work, and others that work to as much as can be supported
21:48:24 <soren> Untested code == broken code.
21:48:27 <vishy> soren: it was more that we didn't want to hold up the wmerge to wait for VMWare to be fixed
21:48:43 <soren> I think talking about VMware is bs.
21:48:44 <vishy> soren: keeping a large change unmerged while the code is plowing ahead is extremely painful
21:48:59 <soren> The libvirt driver got the same treatment.
21:49:06 <soren> And I can promise you that someone cares about libvirt.
21:49:06 <primeministerp1> spectorclan:  question on the design summit?
21:49:09 <soren> Maybe not VMWare.
21:49:14 <soren> I don't care much about VMWare.
21:49:27 <tr3buchet> soren all of the hypervisors got the same treatment, except the one I know how to code for
21:49:35 <salv> Well, this does not mean we should leave it to rot.
21:49:35 <tr3buchet> there are lieutenants for all the rest
21:49:41 <soren> vishy: Doing things right is painful sometimes. Writing tests is painful. But it's worth it.
21:49:58 <salv> People who developed it are still active in the project. Have they been contacted for multi-nic integration?
21:49:58 <tr3buchet> i spent time working with grid dynamics and some of the titan guys to get libvirt working as well
21:50:05 <soren> salv: Not at all, but if noone cares enough to maintain it, kill it.
21:50:12 <ttx> hmm, ok we failed, recommendations on how to fix the mess ?
21:50:15 <soren> tr3buchet: The unit tests remained disabled.
21:50:18 <alekibango> note: its best to start by tests!
21:50:28 <ttx> and on how not to do it ever again ?
21:50:33 <tr3buchet> soren: no one is disagreeing with what you are saying about tests being important
21:50:36 <salv> soren: people do care, and there are people maintaining it!
21:50:45 <soren> salv: Great!
21:51:02 <vishy> soren: so you feel that we should delay the merge until someone volunteers to fix the broken tests...
21:51:03 <soren> tr3buchet: "important" seems to mean different things, then.
21:51:08 <tr3buchet> but if the tests for libvirt are being skipped for whatever reason in trunk, the libvirt lieutenant needs to see to that
21:51:16 <vishy> soren: clearly this feature would never land
21:51:25 <tr3buchet> this is true
21:51:37 <soren> vishy: I call total bs on that.
21:51:51 <vishy> soren: are the tests fixed?
21:51:57 <soren> vishy: No.
21:52:01 <vishy> soren: it has been a whole month
21:52:10 <vishy> soren: with people seeing the skips every day
21:52:27 <soren> Refresh my memory:
21:52:29 <tr3buchet> and obviously not caring...
21:52:36 <tr3buchet> (or not caring enough)
21:52:42 <soren> Did we not all agree at the design summit that we'd increase test coverage for this release?
21:52:49 <tr3buchet> we did
21:52:57 <soren> Ok.
21:53:03 <tr3buchet> look this is not about tests
21:53:09 <soren> This is all about tests.
21:53:14 <tr3buchet> it's about the code that is broken. the tests are being skipped because that code is broken
21:53:20 <soren> Yes.
21:53:24 <tr3buchet> who is in charge of fixing that code, and afterwards, getting the tests to work
21:53:27 <soren> And the tests are supposed to expose that!
21:53:29 <soren> That's the point of tests!
21:53:36 <vishy> actually
21:53:40 <vishy> in the case of libvirt
21:53:42 <soren> Tests are supposed to expose when things are broken, not rub your back when things are fine.
21:53:47 <vishy> it is the tests that are broken
21:53:52 <vishy> libvirt works fine
21:53:57 <soren> How do you know?
21:54:07 <vishy> because i use it and do smoketests against it
21:54:13 <Vek> would you prefer that the code be merged and the tests allowed to fail until the code is either fixed or removed?
21:54:16 <tr3buchet> ah that's true, there are some libvirt tests still be skipped
21:54:35 <soren> Vek: Good god, no.
21:54:36 * ttx whistles innocently and pushed to the next agenda item before there is no time left
21:54:39 <vishy> they were skipped because tr3buchet didn't have the expertise to fix them.
21:54:45 <ttx> #topic Open discussion
21:54:48 <tr3buchet> correct!
21:55:02 <soren> Not having expertise is fine.
21:55:04 <tr3buchet> look before this goes on: " < ttx> hmm, ok we failed, recommendations on how to fix the mess ?"
21:55:04 <soren> so you ask for hlep.
21:55:05 <soren> help, even.
21:55:17 <tr3buchet> let's discuss ttx's idea
21:55:17 <Tushar> I think  skipped libvirt test are fixed in merged prop:https://code.launchpad.net/~rohitkarajgi/nova/libvirt_unittests/+merge/68144
21:55:18 <ttx> soren: it was symptomatic of our inability to work as a unified project
21:55:18 <soren> I'm not sure we can.
21:55:27 <soren> ...because there doesn't seem to be consensus that there's a problem.
21:55:42 <vishy> soren: to be fair, he asked for help many times
21:55:45 <tr3buchet> who here wants for there to be skipped tests?
21:55:57 <Vek> -1
21:56:07 <soren> -1
21:56:19 <tr3buchet> consensus reached
21:56:26 <tr3buchet> let's fix skipped unittests
21:56:33 <tr3buchet> plan?
21:56:40 <soren> that's not what I'm saying.
21:56:48 <soren> Yes, we should fix them...
21:56:57 <soren> ...but they should never have been allowed to break to begin with.
21:57:07 <vishy> soren: You would like a rule saying no putting skipped tests in trunk
21:57:15 <soren> Absolutely.
21:57:17 <Daviey> horse + barn door = bolt.
21:57:51 <vishy> soren: I'm ok with that but I think in this particular case it would have slowed us down tremendously
21:57:53 <tr3buchet> easy enough: remove the decorator, watch em all fail, get to work.
21:57:58 <ttx> soren: which brings back the issue of how to work across knowledge domain to push such a large change affecting multiple hypervisors in
21:58:42 <soren> vishy: It might.
21:58:47 <vishy> soren: all of the network stuff was dependent on multi_nic
21:58:51 <soren> That's where the motivation to fix it comes in.
21:59:05 <Daviey> If someone lands a feature, are they responsible forever on to make sure it's updated to work on-par with the latest core changes?
21:59:15 <salv> tr3buchet: ask people who developed ESX support to fix them
21:59:17 <ttx> We have to stop now, next meeting needs the room
21:59:34 <tr3buchet> i brought this up many times before
21:59:36 <ttx> I propose we continue to discuss how to avoid such situation in the future, in a future meeting
21:59:45 <Vek> Daviey: and if that person gets hit by a bus tomorrow, God forbid?
21:59:52 <ttx> I'd like to make sure we can recover from the current mess though
21:59:59 <soren> Daviey: They are not.
22:00:04 <vishy> I will attempt to fix the test_cloud tests
22:00:07 <soren> Daviey: That's why they provide unit tests and we do code review.
22:00:17 <Daviey> soren: the 'breaker' has to do it? right?
22:00:22 <Daviey> or at least co-ordinate it
22:00:29 <ttx> vishy: maybe target all the bugs to diablo-4 to make sure they are on the radar
22:00:32 <soren> Daviey: Code review should make sure that more people understand the code, and the unit tests are there to make sure that we don't accidentally break it anyway.
22:00:36 <tr3buchet> i am available to assist (from the network side) anyone wanting to fix tests
22:00:40 <soren> Daviey: Absolutely.
22:00:58 <tr3buchet> wasn't this way we made lieutenants?
22:01:02 <tr3buchet> why*
22:01:02 <ttx> soren: the issue of how to push wide changes is certainly interesting, and I'd like to discuss it more
22:01:12 <ttx> soren: but enough for this meeting
22:01:30 <ttx> #endmeeting