21:03:43 #startmeeting nova 21:03:44 Meeting started Thu Mar 7 21:03:43 2013 UTC. The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:03:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:03:47 The meeting name has been set to 'nova' 21:03:49 #chair vishy 21:03:50 Current chairs: russellb vishy 21:03:55 #link https://wiki.openstack.org/wiki/Meetings/Nova 21:04:01 as you can see on the link, we have no agenda \o/ 21:04:11 nap time 21:04:36 dansmith: actually, that's easy; just move to a planet with a slower rotation rate... 21:04:45 I suppose topic of most immediate interest is grizzly-rc1 21:04:46 Vek: can I ride with you? 21:04:48 #link https://launchpad.net/nova/+milestone/grizzly-rc1 21:05:17 One thing worth mentioning is the backportable db migrations blueprint that we had on here, that has been removed 21:05:39 vishy realized there was a problem with the plan to merge blank migrations at the end of grizzly and that right thing to do was to merge the blank ones when havana opens 21:05:41 dansmith: If you'll buy the fuel, sure :) 21:05:53 so we just need to make sure we get his patch merged first in havana, before any other migrations 21:05:59 hi 21:06:17 vishy: hi! was just trying to recap the migrations thing ... *hands it over* 21:06:25 no go ahead 21:06:27 :) 21:06:39 the migrations thing makes me wish we had alembic in... 21:06:42 k, well i think that was about it, unless anyone wants to dive into why 21:06:45 Vek +1 21:07:00 yeah, but at least this gives us *something* for grizzly 21:07:10 oh, I'll grant you that 21:07:25 Vek: I'm planning to shove Alembic down various throats at the summit. 21:07:32 ha 21:07:41 dripton: didn't you have a patch that had it working or close to it? 21:07:43 dripton: cool :) 21:07:57 wish I could be there, especially now that there's sessions on quotas proposed :/ 21:07:58 i guess what you had done was work on auto converting existing migrations? 21:08:11 russellb: yes, but it's only a 90% solution. The other 10% is a lot of work. 21:08:15 Vek: duuuuuuude, you were missed last time, not going again? :( 21:08:29 yeah, RS isn't sending me this time either. 21:09:03 (I don't like flying commercial anyway, but it's about a 14 hour trip if I try to fly it on my own...) 21:09:03 To all employers: if you have someone on whatever-core, you need to send them to the design summit. that is all. 21:09:12 heh. 21:09:41 to be fair, if I had proposed a session on quotas myself, they probably would have sent me. 21:09:57 Vek: what if you propose a design summit session :) 21:10:10 heh :) 21:10:50 so rc1 21:11:10 just one critical bug and comstud is all over it 21:11:21 any other bugs worth discussing here? 21:12:30 * Vek accidentally drops a pin 21:12:37 :) 21:12:56 so I guess we should just fix them all, and that's that 21:13:02 guess so :) 21:13:09 cool. 21:13:20 well then ... anything else about anything? 21:13:58 most eventful nova meeting ever 21:13:59 I would like to move sqlalchemy.utils to common code should I write some blue print? 21:14:10 blueprint* 21:14:16 boris: probably best, and of course that would be havana work... 21:14:19 to oslo-incubator? 21:14:28 yeah 21:14:36 * russellb agrees with Vek 21:14:46 boris-42: Do other projects already use it? 21:14:49 * devananda agrees too 21:15:12 keystone is about to add test_migrations, copied from an older nova version of it 21:15:14 agrees to with Vek =) but I could write it now=) and do in Havana=) 21:15:21 so that may also be worth porting to oslo 21:15:58 devananda: Did you succeed in hoisting a reusable superclass out of test_migrations when you were doing baremetal migrations? 21:16:06 dripton: yep 21:16:12 boris and i both tackled that 21:16:23 devananda: cool, then we have an obvious candidate 21:18:00 * devananda thinks boris should write up a BP for porting sqlalchemy.utils and migration testing to oslo :) 21:18:25 sounds good to me! 21:18:31 One more thing. As you know test_db_api doesn't cover all methods... 21:18:42 for example there is no tests for security_groups at all! 21:18:46 indeed .... 21:18:59 probably there should be also blueprint add missing tests for test_db_api 21:19:06 ++ 21:19:07 there's a nova bug about that 21:19:26 the kind of bug you can never close because you always need more tests 21:19:28 https://bugs.launchpad.net/nova/+bug/828631 21:19:29 Launchpad bug 828631 in nova "nova/db/* almost only tested indirectly" [Low,Confirmed] 21:19:37 opened in August of 2011 21:19:43 ^_^ 21:19:44 boris-42: Error: "_^" is not a valid command. 21:19:58 no wonder i never saw that bug 21:20:02 * devananda adds a "db" tag to it 21:20:13 heh 21:20:14 Yeah I think that BP is better idea=) 21:20:45 yeah, maybe ... kind of in that blueprint <-> bug gray area to me 21:20:53 i guess it's not a bug, nothing is broken 21:20:56 :) 21:21:00 for some definition of broken ... 21:21:11 you don't know if anything is broken because you don't have a test for it. 21:21:16 =)) 21:21:27 * devananda realizes a new way to eliminate bugs... just delete the tests! 21:21:28 in any case, if you open a bp let's close this bug 21:21:41 Ok 21:21:49 devananda: that would make the test suite run a whole lot faster, too! 21:21:57 ;) 21:22:06 Do we have test coverage viewable somewhere out of Jenkins? 21:22:15 dripton: yes ..... somewhere ........ 21:22:22 eyes=) 21:22:40 race to find it! 21:23:07 https://jenkins.openstack.org/job/nova-coverage/ 21:23:19 logs.openstack.org/shortsha/follow/the/path/to/nova-coverage 21:24:27 clarkb: it's like you have advanced IRC conversation highlighting to alert you when you need to appear with a -infra related link :) 21:24:47 I see that page but not any actual useful coverage results. Maybe they're just hiding; maybe we need to install the cobertura plugin and do the right magic to convert Python test results to Java XML format so it can display them. 21:24:52 oO 21:24:52 https://review.openstack.org/#/c/23660/ 21:25:10 example: http://logs.openstack.org/e237698/post/nova-coverage/5635/cover/ 21:25:13 dripton: no, we actually stopped doing that with jenkins because jenkins uses too much resources to do it 21:25:24 instead we generate the html reports then copy them to the log server 21:25:40 #link http://logs.openstack.org/e237698/post/nova-coverage/5635/cover/nova_db_sqlalchemy_api.html 21:26:07 clarkb: makes sense, but it makes it hard to find them if you don't already know where to look 21:26:08 overall total: 80% 21:26:18 I don't believe =) 21:26:36 80% is easy. 100% is difficult :) 21:26:38 88% for the db api :) 21:26:43 dripton: ya 21:26:51 100% is unnecessary. 80% is actually pretty damn good. 21:26:53 dripton: but now you know where it is! 21:27:01 Bookmarking... 21:27:05 heh. 21:27:21 * devananda notices the number of exceptions not getting tested in db/api 21:27:55 clarkb: is this just unit test coverage, or is this after running tempest too 21:28:13 that would be an interesting statistic... 21:28:28 russellb: that is just unittest specific 21:28:35 cool 21:28:36 the tempest coverage is its own thing (a daily job iirc) 21:29:30 https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/ 21:29:42 * russellb guesses that's it ... 21:29:50 yup that looks right 21:30:09 http://logs.openstack.org/periodic/ 21:30:57 http://logs.openstack.org/periodic/periodic-tempest-devstack-coverage-vm-full/58/logs/coverage-report/ 21:31:14 that says 21% 21:31:34 russellb: I think it may only be able to collect nova-api coverage right now 21:31:41 (but I may be mistaken) 21:32:02 clarkb: ok. i know there was some work to support all services, don't remember status 21:32:09 dansmith: do you know? wasn't that a coworker of yours? 21:32:21 russellb: mtreinish yeah 21:32:41 clarkb: it looks like it's crawling all the unit tests, not just the API 21:33:16 its generating results for all of nova/ but at runtime only runs within nova-api 21:33:30 clarkb: ok, got it 21:34:16 so there's the long answer to "do we have code coverage reports" :) 21:34:39 Vek reminds us all that we need to help review python-novaclient patches, heh 21:35:07 this URL is your friend for that: https://review.openstack.org/#/q/status:open+(project:openstack/nova+OR+project:openstack/python-novaclient)+branch:master,n,z 21:35:22 :) 21:35:43 two bookmarks in one meeting 21:36:08 that's productivity of some sort :) 21:36:31 heh 21:36:34 also need to be looking at python-novaclient bugs 21:36:52 and btw, if you want to close out some bugs and feel good, sort bugs by age and start at the oldest 21:36:59 lots of stuff that's not even applicable anymore 21:37:24 the cleaner the bug list, the more useful it is 21:37:55 anything else? 21:37:57 *nod* 21:39:21 guess we can close out then ... thanks everyone 21:39:27 clarkb, russellb: it covers all the services now 21:39:33 mtreinish: nice! 21:39:43 mtreinish: when looking at the coverage results, it looked like it did 21:39:53 but there is still a bug with the coverage module and eventlet so some of the results look really weird 21:40:01 lovely. 21:40:13 eventlet \o/ 21:40:33 * Vek used gevent for Tendril; that looks nice... 21:40:37 for example: http://logs.openstack.org/periodic/periodic-tempest-devstack-coverage-vm-full/57/logs/coverage-report/nova_virt_libvirt_driver.html 21:40:53 russellb: are we gonna have a summit session on eventlet and its future? 21:41:11 jog0: only if someone is motivated enough to make that a priority to work on 21:41:22 just complaining about it isn't hugely useful :) 21:41:27 IMO .... 21:41:32 There's no free lunch. If you want to have asynchronous code that looks like synchronous code then you're going to have a 90% solution and 10% bugs. 21:41:37 russellb: there will be an eventlet session at the conference that may be useful 21:41:39 Probably for the 'i' or 'j' summits, we should be seriously thinking about how to support python3 (if not before then...) 21:41:46 If you want the 100% solution you have to make it explicit and then your code will be ugly. 21:42:00 so gevent isn't a good option to discuss for H? 21:42:03 Vek: indeed 21:42:32 Isn't gevent pretty much the same model as eventlet with slight differences under the hood? 21:42:56 dripton: it's forked from eventlet, in fact, IIRC 21:43:26 I believe it has v6 support available, too, though eventlet is likely to add that before too much longer (if they haven't already) 21:43:50 there are some other ways we could approach this other than just forklifting eventlet 21:43:57 last I looked, though, the 1.x series was going to use a completely different core from the 0.x series... 21:44:09 like, say, try to convert only the nova-compute service to native threads 21:44:40 russellb: true 21:44:44 or nova-conductor 21:45:01 nova-conductor's entire job is db access ... which is kinda hacky with eventlet 21:45:06 also there is the sqlA discussion that ties in to this 21:45:11 yes 21:45:43 * Vek nods 21:45:52 good times 21:46:04 sorry for derailing the meeting 21:46:12 nah, we were pretty much done I think 21:46:16 sounds like we have things to do well beyond the 'm' release :) 21:46:46 one last thing i want to mention ... mikal really wanted to be here, but couldn't because of orientation at RAX 21:46:52 so he's not just avoiding us :) 21:46:57 :) 21:47:09 for some reason, 21:47:09 alright, thanks everyone! 21:47:19 * russellb halts again 21:47:29 when you said "orientation", all I could think of was that the aussie was upside down 21:47:40 *rotcl* 21:47:46 heh 21:47:59 we call it "rookieO", and you're probably right about it being upside down... 21:48:12 ha, sounds like he's enjoying it 21:48:24 he's actually on this side of the earth right now 21:49:07 k, bye! 21:49:11 #endmeeting