16:01:01 #startmeeting oslo 16:01:01 Meeting started Fri Jun 20 16:01:01 2014 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:05 The meeting name has been set to 'oslo' 16:01:05 who's around for the oslo meeting? 16:01:07 aloha 16:01:12 o/ 16:01:17 o/ 16:01:26 o/ 16:01:29 hey 16:01:33 #link https://wiki.openstack.org/wiki/Meetings/Oslo 16:01:43 o/ 16:01:47 hi 16:02:04 bnemec_away told me he was likely to miss today 16:02:07 Hi 16:02:29 dims, flaper87|afk, victors, rpodolyaka : ping? 16:02:49 hello 16:02:49 o/ 16:02:50 o/ 16:02:53 dhellmann: here 16:03:10 ok, let's get started 16:03:17 #topic review action items from previous meeting 16:03:25 #info bnemec sent email to the dev list asking for liaisons to review app-agnostic-logging-parameters https://review.openstack.org/#/c/95281 16:03:30 #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/038027.html 16:03:40 I think that's it for old business 16:03:59 #topic red flags from liaisons 16:04:05 do we have any urgent issues this week? 16:04:16 can't think of anything for keystone 16:04:30 dhellmann, hit refresh on your wiki page 16:04:42 * dhellmann reloads 16:04:45 thanks, markmc 16:04:49 np 16:04:54 * markmc just added a few things 16:05:02 so I have the blocker patch https://review.openstack.org/#/c/93398/ needed by Keystone ) 16:05:03 dhellmann, o/ here as well 16:05:09 hi, morganfainberg 16:05:12 asking liasons to take a look at oslo-config-generator 16:05:27 #link https://review.openstack.org/100946 - oslo-config-generator 16:05:31 will get a spec up next week 16:05:33 thanks, markmc 16:05:46 * dhellmann fights the cat away from his sandwich so he can type again 16:06:06 we had some good feedback on https://review.openstack.org/95281 - Add spec for app-agnostic-logging-parameters 16:06:12 I think I've replied to jogo's comments 16:06:15 I think now that oslo.db is lib keystone can make progress with i159 patches (I assume that's Ilya) 16:06:28 bknudson: excellent 16:06:41 bknudson: yes it's me 16:07:27 so, if the liaisons could review those two specs again, that would help us get them approved by the end of next week 16:08:01 #topic adoption status 16:08:02 #link https://etherpad.openstack.org/p/juno-oslo-adoption-status 16:08:26 That patch is Roman's code. Keystone could become better soon with this test case. 16:08:27 it looks like there has been some progress in neutron on oslo.messaging 16:08:29 neutron oslo.messaging, yay ihar ! :) 16:08:37 indeed! 16:08:53 dhellmann: main patch merged, there is a string of minor patches to merge yet 16:08:55 #info making progress on neutron/oslo.messaging 16:09:14 completion of blueprint for juno-2 is on target 16:09:14 * jogo walks in late 16:09:23 salv-orlando: do you foresee any issues aside from reviewer bandwidth? 16:09:24 ok, good 16:09:53 not really. And me mestery and markmcclain are regurarly reviewing these patches 16:10:06 dhellmann, I suspect it's pretty much functionally done now 16:10:11 i.e. neutron works with oslo.messaging 16:10:12 great, that makes me happy :-) 16:10:22 next up, heat 16:10:23 the patches looks like they're just unwinding some compat layering 16:10:29 salv-orlando, right ? 16:10:40 markmc: correct 16:10:45 the main port has been done. 16:10:47 salv-orlando, awesome 16:11:10 \o/ 16:11:33 therve asked me to look at https://review.openstack.org/#/c/100457/ 16:11:42 (Use oslo.messaging to publish log errors) 16:11:49 suspect that's related to the heat port 16:11:52 didn't get to it today 16:12:14 ok, we should add that to our review priority list if it's blocking heat 16:13:12 do we have a trove patch series, yet? 16:13:33 not that I've seen 16:13:36 * markmc looks again 16:13:47 yeah, I don't see anything attached to the blueprint 16:14:04 oh, https://review.openstack.org/#/c/94484/ 16:14:16 "Updates RPC API to use oslo.messaging" 16:14:33 for this blueprint? https://blueprints.launchpad.net/trove/+spec/rpc-versioning 16:14:35 hmm 16:14:49 I was looking at https://blueprints.launchpad.net/trove/+spec/oslo-messaging 16:15:32 https://wiki.openstack.org/wiki/Trove-rpc-versioning 16:15:56 "Get Trove on the same page w/ other projects + oslo" 16:16:05 seems like some blueprint overlap alright 16:16:12 * markmc adds to etherpad 16:16:24 yeah, I've added those links to the etherpad to make them easier to find again 16:16:30 cool 16:17:16 I think that's it for oslo.messaging, so pressing on... 16:17:19 #topic oslo.db graduation status 16:17:20 #info version 0.2.0 was released this week! 16:17:29 congratuations victors and rpodolyaka ! 16:17:31 woop 16:17:31 when's 1.0 16:17:37 \o/ 16:17:38 :) 16:17:39 oops, viktors, sorry 16:17:45 np :) 16:17:52 also, is this one good for projects to use? 16:18:07 bknudson: it should be 16:18:10 bknudson: this version is suitable for projects to start adopting, and we'll release a 1.0 at the end of this cycle 16:18:29 https://review.openstack.org/#/c/77210/ looks good here 16:18:29 bknudson: don't hesitate do file any bugs you run into, though :) 16:18:30 I assume nobody's using it? 16:18:32 https://wiki.openstack.org/wiki/Oslo/VersioningPolicy 16:18:35 dhellmann: good to know. Neutron has already a dev lined up for the porting. 16:18:50 bknudson: not yet, it was release only yesterday :) 16:18:53 bknudson: it's brand new, so I don't think there's anything official yet, but some projects have started working on the port 16:19:21 i159: were you planning to do the changes for keystone to use oslo.db? 16:19:42 * dhellmann adds oslo.db to https://etherpad.openstack.org/p/juno-oslo-adoption-status 16:19:46 we should probably have a spec in keystone to track it 16:20:37 that makes sense 16:21:02 i do have a goal to do a more deep and detailed review of oslo.db, but I’m waiting to get to it somewhat organically as I am just learning to use openstack and get into nova’s source 16:21:04 i159: oh, that's the review you pointed to! 16:21:11 bknudson: There is the patch which done some critical changes, which I mentioned a few lines ago 16:21:16 bknudson: are you lookin for this i159 patch https://review.openstack.org/#/c/77210/ ? 16:21:27 bknudson: yes 16:21:32 zzzeek: thanks, that's good to hear 16:21:34 certainly if neutron or nova port to it that will make it easier 16:21:53 sweet 16:22:01 i started a bit on trying to work in the transactional testing port for nova but this week I got caught up just getting better openstack run environments going 16:22:04 +28, -2959 is what I like to see 16:22:12 :-) 16:22:29 things move slowly with OS which is good b.c. this is taking awhile on my end :) 16:22:33 zzzeek: can we take this list as a plan? 16:22:48 i159: when you say “this list".... 16:23:06 zzzeek: I mean Nova, Neutron 16:23:21 i159: oh. Well im looking at nova the most since it seems to be where the DB patterns originated 16:23:31 true 16:23:46 we are going to port Nova and Neutron to oslo.db soon 16:23:50 also I get to talk to russell bryant all day and he’s on nova specifically 16:23:51 probably next week :) 16:24:00 he’s sort of my sherpa at redhat 16:24:01 so, Nova is the first candidate? 16:24:09 no, Ironic 16:24:16 i159: akurilin is already working on that 16:24:30 rpodolyaka: ok, I see 16:24:35 i159: and I'm going to help with neutron 16:24:41 viktors, rpodolyaka : would you help keep track of who is doing the work in each project by adding names to https://etherpad.openstack.org/p/juno-oslo-adoption-status please? 16:24:54 dhellmann: ok, sure 16:25:01 viktors: thanks 16:25:24 * dhellmann is gaining a better understanding of how ttx must feel tracking all of the openstack projects 16:25:38 viktors: Ironic already have a patch. Is it? 16:26:00 i159: yes, see https://review.openstack.org/#/c/42159/ 16:26:39 is there anything else on oslo.db? 16:26:50 great job on this 16:26:53 dhellmann: i've a few things, but they are at the end of the agenda, i think 16:27:09 devananda: yeah, I have those on the list of review priorities 16:27:26 ok, then 16:27:27 #topic oslo.i18n graduation status 16:27:34 It would be good to get 0.1.0 released next week, since we have so many other new libraries depending on this. 16:27:56 there's one more patch I would like to land before we release, the one to fix the docs 16:28:01 #link https://review.openstack.org/96961 16:28:04 the docs look great, btw 16:28:17 that should clear up a lot of confusion 16:28:37 the one I came across was whether to use _() or _LE() with LOG.exception() 16:28:40 yeah, we've started seeing push-back on making the logging changes, so I want to get those docs published asap 16:28:40 I'm guessing the latter? 16:28:57 it depends on whether the exception is logged and raised or just logged 16:29:04 I need to make that case explicit, if I haven't already 16:29:23 like LOG.exception(_(..)) or LOG.exception(_LE()) 16:29:24 basically, all _() messages will be translated, so exceptions should use those 16:29:26 not sure that depends? 16:29:34 but logging errors that aren't raised as exceptions should use _LE() 16:29:37 so I guess that doesn't depend 16:29:40 :-) 16:29:48 right, the language just confused mikal I think 16:29:53 * markmc wasn't totally sure either 16:29:59 I think LOG.exception is just a small wrapper (helper function) 16:30:02 #action dhellmann clarify language about when to use _() vs. _LE() 16:30:19 I assume it just LOG.error with exception info 16:30:32 bknudson: it includes the traceback, IIRC 16:30:40 * markmc has to run 16:30:45 right, you can get the traceback with any LOG.xxx 16:30:47 thanks, markmc 16:30:49 dhellmann, figure I'll do a1 of oslo.messaging early next week 16:30:51 dhellmann, ++ 16:30:59 markmc: ok 16:31:13 bknudson: true 16:31:52 since it logs at error I'd expect _LE() 16:32:23 bknudson: we have some places where people build a message, log an exception, then raise. For that case, they need to use _(). Otherwise, use _LE(). 16:32:51 I'll add some more examples to the docs 16:33:09 #topic release review 16:33:18 We have 4 libraries ready for new releases. I’ve been holding off until the alpha release publishing stuff was working, but I think we’re ready to go now. 16:33:28 make that 5, since markmc added oslo.messaging 16:33:36 I set up etherpads to track the release notes for each library 16:33:45 #info stevedore 1.0.0.0a1 16:33:45 #link https://etherpad.openstack.org/p/stevedore-1.0.0 16:33:45 #info oslotest 1.1.0.0a1 16:33:45 #link https://etherpad.openstack.org/p/oslotest-1.1.0 16:33:46 #info oslo.config 1.4.0.0a1 16:33:47 #link https://etherpad.openstack.org/p/oslo.config-1.4.0 16:33:48 #info oslosphinx 2.2.0.0a1 16:33:49 #link https://etherpad.openstack.org/p/oslosphinx-2.2.0 16:34:13 #info oslo.messaging 1.4.0a1 16:34:14 #link https://etherpad.openstack.org/p/oslo.messaging-1.4.0 16:34:33 we will have lots of opportunities to make more alphas, so I don't think there's any need to hold these up 16:34:41 are there any other releases we should be planning for monday? 16:34:59 for example, are we ready for another oslo.db? :-) 16:35:38 not yet ) 16:35:46 ok, I would have been surprised if you said yes :-) 16:35:47 we haven't merged anything new, I think 16:36:15 I have mentioned the impending releases during the release meeting this week, but liaisons keep an eye out for any issues that might come up with the new versions in your projects 16:36:34 we haven't fixed up the cross-project unit test gating, so that's where I would expect issues to surface 16:37:05 any questions from liaisons on that? 16:38:02 ok, then, let's talk about review priorities 16:38:04 #topic review priorities for this week 16:38:10 #info db migration test issues (devananda) 16:38:14 #link https://bugs.launchpad.net/ironic/+bug/1327397 16:38:15 Launchpad bug 1327397 in nova "No notice given when db migrations are not run due to missing engine" [Low,Fix committed] 16:38:25 if there are any issues that arise in the gate from the alphas don't forget to file elastic-recheck patches 16:38:39 flashgordon: good point, thanks for the reminder 16:38:42 dhellmann: that one ^ is still present in oslo.db, afaict 16:39:05 devananda: ok 16:39:11 dhellmann: because tests iterate over self.engines, without concern to whether that's an empty list 16:39:16 this shuld be fixed by patch https://review.openstack.org/#/c/93424/ , but at the moment Ironic use it's own implementation, instead of oslo code 16:39:17 is there a patch in progress for it? 16:39:32 #link https://review.openstack.org/#/c/93424/ 16:39:56 * devananda adds taht to his review queue 16:39:58 viktors: are the implementations very different? 16:40:40 at the moment - almost equal, but we suppose to use "opportunistic" approach in the future 16:40:52 so this path refactors migration tests 16:40:55 ironic and nova migration test code is very similar to oslo-incubator code 16:41:01 viktors: ok, as long as we don't hold up fixing it for a feature addition 16:41:17 yes, because ironic ann oslo took this code from nova 16:41:35 devananda: ^ 16:41:39 makes sense 16:41:59 second bug there is also coming from the same inherited code - https://bugs.launchpad.net/nova/+bug/1328997 16:42:01 Launchpad bug 1328997 in nova "Unit test failure: openstack_citest" is being accessed by other users\nDETAIL: There are 1 other session(s) using the database." [Critical,In progress] 16:42:14 * dhellmann didn't notice those were different numbers 16:42:20 this bug was caused, by different approaches in the database testing in Nova 16:42:30 i believe that that is *not* fixed in oslo.db - only a partial fix was landed 16:42:35 but I can not change the bug status 16:42:57 this will be fixed by https://review.openstack.org/#/c/93424/ too 16:43:02 we need to use opportunistic migration test for Nova db migrations to get this bug totally closed 16:43:07 It should be fixed with opportunistic approach 16:43:13 see my discussion with viktors on https://review.openstack.org/#/c/99614/ 16:43:15 I changed the bug status to triaged 16:43:58 viktors: so patch 93424 will fix both of those bugs? 16:44:01 so while these two bugs affect(ed) nova and ironic, I'm not sure what other projects inherited their db migration test code from oslo-incubator - -I suspect any project which did that will be affected 16:44:30 and wanted to raise that question to ya'll who might know better than I what other projects use the common test code 16:44:41 dhellmann: we have fix in Ironic and nova code and workaround in oslo.db code 16:44:44 devananda: I'm sure that's right. The shortest path to the fix might be to put this in oslo.db, and then update the projectss to use oslo.db instead of the broken incubator version 16:45:11 dhellmann: that's fair, if projects are willing to make that switch soon 16:45:15 dhellmann: with a high probability 16:45:35 dhellmann: fwiw, as soon as ya'll tell me that oslo.db is stable, and I have a couple hours to play with it, i think ironic can switch to it 16:45:40 devananda: I'm trying to minimize the number of syncs we have to do, too, since those tend to drag on. 16:45:49 dhellmann: indeed 16:45:53 devananda: it should be stable enough to start that work now 16:46:10 yeah, it's no really different from the incubator code 16:46:16 viktors, we don't anticipate any API changes, right? just improvements and fixes underneath? 16:46:39 right, it's not a new implementation, just new packaging, fixes, etc. 16:46:41 dhellmann: yes, just improvements and fixes 16:46:52 great. but i dont want to derail this meeting into "when should ironic switch" -- we were talking about bugs :) 16:46:58 hep 16:47:01 yep 16:47:15 I have a few more items to raise before we close out 16:47:16 #info notifier middleware security fix 16:47:21 #link https://review.openstack.org/#/c/100414/ 16:47:39 oh, hey, that merged when I wasn't looking :-) 16:48:01 liaisons, if your project uses the notifier middleware and not oslo.messaging, you should look at ^^ 16:48:17 actually, that's a backport, so you probably want it for havana anyway 16:48:24 there's also an icehouse version of the patch 16:48:34 #info log handler for oslo.messaging notifier (blocking heat) 16:48:38 #link https://review.openstack.org/#/c/100457/ 16:48:46 markmc mentioned that one earlier, but repeating here for the meeting logs 16:48:51 #info oslo.i18n docs 16:48:55 #link https://review.openstack.org/96961 16:49:00 that's another repeat 16:49:12 does anyone else have anything they would like to add to the review priority list? 16:50:12 silence means "no" :-) 16:50:13 #topic open discussion 16:50:22 Since we’re spread out across many different time zones, I want to mention a tool I’ve found useful. 16:50:31 ZNC is an “IRC bouncer” that you can run on a cloud server, and then connect to as though it was a regular IRC server. 16:50:47 It can monitor channels even when you are disconnected, so when you reconnect you see messages people left when you were not online — especially if they mention your nickname. 16:50:48 #link http://wiki.znc.in/ZNC 16:50:58 If you combine ZNC with the practice of asking for something specific instead of just pinging people, it makes IRC much more useful. 16:51:21 id mention it is often run from docker or some other container as it can kind of be a security point of failure 16:51:36 that's good to know 16:52:57 I think we're done for today, then. 16:53:29 thanks, everyone! 16:53:40 lates 16:54:04 #endmeeting