16:00:12 #startmeeting oslo 16:00:13 Meeting started Fri Aug 8 16:00:12 2014 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:17 The meeting name has been set to 'oslo' 16:00:18 o/ 16:00:19 o/ 16:00:27 Our agenda: 16:00:27 #link https://wiki.openstack.org/wiki/Meetings/Oslo 16:00:31 o/ 16:00:43 o/ 16:00:51 hi, everyone! 16:01:25 hi 16:01:54 bnemec, dims, markmc, flaper87, jd__ around? 16:02:15 #topic Review action items from previous meeting 16:02:20 * beekneemech missed his meeting notification 16:02:41 beekneemech: no worries, I tried to start the meeting an hour early 16:02:50 #info viktors, rpodolyaka, zzzeek to prepare report about db driver-specific exceptions caught in integrated and incubated projects and what changes will be needed to handle the new wrapped exceptions from oslo.db. 16:02:50 zzzeek created an etherpad with some details: 16:02:50 #link https://etherpad.openstack.org/p/sqla_exceptions_caught 16:03:13 we are working on fixing items on that list 16:03:19 rpodolyaka, is there any news on that? I've been pretty distracted this week and haven't had a chance to review it yet? 16:03:19 a few patches on review left 16:03:21 ok, great 16:03:32 I'm updating the doc 16:03:57 we'll need another week, I think 16:04:08 https://review.openstack.org/#/c/108935/ is merged in keystone 16:04:18 rpodolyaka: ok, we'll make sure it's on the review priority list for this coming week 16:04:31 bknudson: excellent 16:04:46 #action dhellmann approach the other integrated projects who have not started work on oslo.i18n 16:04:46 carrying this one over 16:05:01 #info jd__ post about pylockfile adoption to the mailing list 16:05:01 #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/038387.html 16:05:01 jd__ also created a spec that details the relationship between pylockfile and our lockutils module 16:05:01 #link https://review.openstack.org/#/c/102202/ 16:05:02 and I think we have enough +2 votes there to accept, so I will do that today unless there are objections? 16:05:35 I'm glad we worked out how to move code into pylockfile to keep that project alive 16:06:07 present... 16:06:07 #action dolphm start discussion on the mailing list to get feedback from the oslo team about taking over pycadf library (DONE) 16:06:07 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/041269.html 16:06:12 hi, zzzeek 16:06:57 moving the pycadf library over to the identity program is up for review by the TC 16:06:59 #link https://review.openstack.org/#/c/109664/ 16:07:09 I don't expect any issues, although there was some discussion about the program scope change 16:07:27 I think that's it for actions from the last meeting 16:07:31 #topic Red flags for/from liaisons 16:07:42 liaisons, how are things going? 16:07:55 so I was working on oslo.utils in keystone, keystoneclient, keystonemiddleware... 16:08:03 and ran into an odd problem... 16:08:42 timeutils provides a utcnow - http://git.openstack.org/cgit/openstack/oslo.utils/tree/oslo/utils/timeutils.py#n106 16:08:50 which is overridden in lots of tests. 16:09:09 but then some oslo-incubator parts still use utcnow in oslo-incubator 16:09:12 hmm, yeah, lots of mocking 16:09:29 so I think this was causing tests in keystoneclient to not work as expected. 16:09:37 yeah, I can imagine 16:09:57 there weren't any issues in keystone. It doesn't mock utcnow as much 16:10:00 first, we should add a fixture to oslo.utils to handle the mocking instead of having each test library do it 16:10:17 +1 16:10:22 I thought we were actually going to remove those. 16:10:24 bknudson: which incubated modules use the utils? was it a lot? 16:10:44 beekneemech: we did talk about that, yes 16:10:52 * dhellmann looks for his notes 16:11:18 keystoneclient/openstack/common/memorycache.py 16:11:28 this one's the problem because of course auth_token middleware uses it 16:12:25 beekneemech: the spec doesn't talk about timeutils https://review.openstack.org/#/c/98431/7/specs/juno/graduate-oslo-utils.rst 16:12:40 I think we decided we had too many users, so even though we don't like the API we need to keep it for now 16:12:58 dhellmann: Yeah, I think the discussion actually predated the graduation. 16:13:00 Yeah. 16:13:08 Might be a good time to start migrating off it though. 16:14:21 bknudson: ok, would you file a bug so we can track work on this? we'll have to spend a little time figuring out the best approach. 16:14:30 beekneemech: yeah 16:14:30 dhellmann: ok 16:14:50 #action bknudson file a bug about timeutils mocking issue 16:14:54 bknudson: thanks 16:15:03 does anyone else have any issues to bring up? 16:15:16 there was another issue with the keystoneclient change 16:15:26 k 16:15:27 the tests failed when I added oslo.utils to keystoneclient. 16:15:33 dhellmann: also i guess what are we deciding about exception catching... 16:15:43 https://review.openstack.org/#/c/112337/ 16:15:54 so I backported the requirement to stable/icehouse 16:16:13 bknudson: yes, I think that's the right fix there 16:16:35 bknudson: +2a on that change 16:16:52 ok, that was it 16:16:56 zzzeek: ? 16:17:08 dhellmann: was referring to the list i compiled at https://etherpad.openstack.org/p/sqla_exceptions_caught 16:17:38 e.g. if this is still a blocker for us 16:17:42 zzzeek: I haven't had a chance to review that (this week was more distracting that expected). It's on my priority list for monday 16:17:53 seems like not every error i listed has a comment about it…so…no movement was made all last week on this ? 16:18:17 zzzeek: rpodolyaka did have some updates 16:18:21 dhellmann: ok 16:18:22 zzzeek: I believe we have patches on review for all integrated projects 16:18:29 rpodolyaka: OK great 16:18:35 zzzeek: and I ran tests with oslo.db from master for all of them 16:18:41 rpodolyaka: wow cool 16:18:41 zzzeek: they actually passed 16:18:44 * zzzeek loves delegation 16:19:24 cinder was actually broken due to a skipped tests 16:19:32 go team! 16:20:09 ok, any other issues from liaisons? 16:20:59 I'll take that as a "no" -- open bugs or stop by #openstack-oslo if you do encounter any 16:21:00 #topic Adoption status 16:21:00 #link https://etherpad.openstack.org/p/juno-oslo-adoption-status 16:22:53 looks like we made some good progress with i18n 16:23:03 thanks for adding those keystone links, bknudson 16:23:22 I think some work started in cinder on oslo.utils, too, but I don't know if that's up for review yet 16:24:11 oh, nice, nova is using oslo.i18n, too 16:24:21 I should go on vacation more often :-) 16:24:21 it was a pretty easy change for oslo.utils 16:24:35 easy is the goal 16:25:00 I suspect we need to do some work on the documentation for oslo.utils 16:25:24 I didn't look at the docs 16:25:36 bknudson, you know, a partial change might be the simplest approach to that timeutils issue 16:25:57 y, there's no reason the change couldn't be split up 16:25:57 but at the same time, I'd hate to have to go back through and update all of the projects when we remove that module from the incubator 16:26:11 seems like something that'd be easy to forget :-/ 16:26:26 ok, let's keep going 16:26:26 #topic Spec status 16:26:33 #info jd__’s pylockfile spec will be approved, as we just discussed. 16:26:39 #info boris-42’s osprofiler spec approval will depend on the outcome of the QA/Rally team discussion about where the profiling code should live. 16:26:51 I'd like to reiterate on pylockfile adoption... 16:26:55 dhellmann +1 16:27:04 does anyone have anything to add to that discussion? 16:27:05 dhellmann nova teem can wait forever=) 16:27:06 hi, boris-42 16:27:09 dhellmann hi 16:27:21 team* 16:27:28 I've missed that discussion, and now I see that pylockfile is not actually used by oslo.db, only by incubator code. 16:27:29 I made a new spec https://review.openstack.org/#/c/112842/ 16:27:57 dhellmann could we bump osprofiler in global requirements? 16:28:06 dhellmann glance team is facing issues ... 16:28:20 dhellmann somewhere somebody found osprofiler version 0.1.0 16:28:20 this is my first spec, so I need attentive review 16:28:32 So I'd suggest us to just remove file locking behavior from oslo.concurrency instead. 16:28:47 boris-42: yes, it seems like we need to update the minimum requirements 16:28:48 #link https://review.openstack.org/#/c/104691/ 16:28:57 dhellmann and nobody except glance is using it 16:29:11 YorikSar: pylockfile is used in incubator? 16:29:14 dhellmann thnaksd 16:29:17 i159: ok, it may be a little while before that gets much attention, since we have a lot of work in process now 16:29:25 beekneemech: Only by openstack.common.db 16:29:44 YorikSar: Oh, yeah. That's going away soon, so not a concern. 16:29:51 And if oslo.db ever needs locks again it can use lockutils. 16:29:56 YorikSar: nova uses the file locking stuff in the incubator, which we want to put into pylockfile 16:30:32 dhellmann: Won't current file locking from lockutils suffice for it? 16:30:58 dhellmann: no problems, anyway I'm in vacation next two weeks =) 16:31:07 Or they even might consider switching to semaphores, I guess... 16:31:29 YorikSar: We're going to move the file locking to pylockfile and make lockutils a wrapper around it. 16:31:33 YorikSar: yeah, read through the spec, I think it covers this. The lockutils module in the incubator will need to graduate, and so we were going to move the class into pylockfile and have an oslo lib that sets up the configuration options and then controls pylockfile 16:31:51 YorikSar: We definitely can't replace lock files with semaphores. 16:31:55 We tried that once. 16:32:00 yeah 16:32:07 It ended with reimplementing file locking. :-) 16:32:21 beekneemech: Oh... I wonder how did that happen... 16:32:38 YorikSar: There are places that lockutils was used that rely on file locking behavior. 16:32:42 the lockutils stuff is used by code in the applications that has nothing to do with the database 16:32:57 This is why I'm concerned about making even seemingly innocuous changes to how lockutils works. 16:33:44 right, no changes, just move the class into pylockfile and make a new release 16:33:47 I think it worth skimming through them once again to verify if that's still the case (or is it gone as with oslo.db). 16:34:03 YorikSar: it had to do with the compute agent downloading things from glance, irrc 16:34:07 dhellmann: Yeah, I was referring to the sysv_ipc change YorikSar has under review. 16:34:24 YorikSar: It's definitely still the case. This didn't happen that long ago. :-) 16:34:26 but we need to stop assuming that just because we can't find something using a library that we can delete it -- that has bitten us too many times this cycle 16:34:42 beekneemech; ah, yeah 16:35:13 Ok, I'll back up then. 16:35:25 ok, let's keep moving 16:35:28 #info gordc's oslo.middleware spec is related to a repo that was already imported 16:35:28 Let’s prioritize reviewing it to make sure we didn’t miss anything important in the import. 16:35:28 #link https://review.openstack.org/#/c/110353/3/specs/juno/graduate-oslo-middleware.rst 16:35:28 #link http://git.openstack.org/cgit/openstack/oslo.middleware 16:36:15 I'm not quite sure how we got that import done without the spec, but let's sync up so we don't go too far to a release without ensuring the API has been reviewed 16:36:33 I think keystone could use oslo.middleware 16:36:52 bknudson: yep, but I want to make sure the version we release is going to have a nice stable api 16:37:31 there are still several specs up for review, but we have enough other work going on at this point that I think we should focus on reviews for those projects, rather than approving more specs. Thoughts? 16:37:41 this one isn't really an api. 16:38:41 bknudson: well, each class has an API and will be imported in a particular way, etc. so we want to make sure we set that up right for future additions 16:38:56 is i18n usually called _i18n? 16:39:04 since it's not public 16:39:09 beekneemech, rpodolyaka, zzzeek, dims: any thoughts on a temporary "specs freeze"? 16:39:19 bknudson: yeah, that's what we want to do with the library versions 16:39:45 dhellmann: im fine with it 16:39:48 dhellmann: makes sense 16:39:54 dhellmann: Most of the other projects are in specs freeze, so that works for me. 16:40:04 looks like it's using config fixture from oslo-incubator when it could be using oslo.config 16:40:21 ok, I don't think we need to have a hard freeze and say no more for juno, but a temporary freeze will let us concentrate on the reviews we have in play right now 16:40:44 bknudson: yeah, there is a series of changes needed before we can release that as a library 16:41:15 #agreed we will have a temporary freeze on approving new specs to concentrate on the graduation work and reviews already in process 16:41:28 speaking of which... 16:41:29 #topic Graduation status 16:41:42 YorikSar has made good progress on oslo.concurrency and has a repo ready for review 16:41:42 #link https://review.openstack.org/#/c/112666/ 16:41:42 #action everyone review the repo being imported as oslo.concurrency 16:41:48 nice work, YorikSar! 16:42:05 YorikSar, was that repo created with your new version of graduate.sh? 16:42:11 dhellmann: Yes 16:42:22 ok, so it needs some careful review 16:42:43 And I'd really like to get that version merged - jumping between branches has already bitten me... 16:43:00 YorikSar: ok, I'll look over the script this afternoon 16:43:17 Not that I'll be using it any time soon though :) 16:43:25 haha 16:43:39 I have oslo.log work planned soon, so I may be the next user 16:43:54 #info oslo.serialization has been imported 16:43:55 #link http://git.openstack.org/cgit/openstack/oslo.serialization 16:43:55 dims, are there changes we need to make before cutting a release? 16:44:03 oh, dims isn't here today, is he? 16:44:36 I think he was out yesterday too. 16:44:39 Vacation season :-) 16:44:47 yeah 16:44:53 ok, we'll hold that question over for next week 16:45:17 #info oslo.utils 0.1.1 was released since the last meeting 16:45:36 good work on that, everyone, and thanks to dims for taking charge of pushing it through 16:45:38 dhellmann: I can take a look at serialization too. 16:45:48 \o/ 16:45:50 beekneemech: great, thanks 16:46:11 #topic oslo.db 16:46:17 rpodolyaka, can you give a brief update about where things stand? 16:46:30 we talked about the exception issue already, is there anything else big we should know about? 16:46:54 dhellmann: a few big changes coming, but those will be internal refactoring 16:47:05 ok 16:47:25 and I'll need your help with reviews, guys, as victors is on PTO :) 16:47:48 ok, sure thing 16:47:52 once we fix the problem with exception we can cut a release 16:48:07 good, that's what I wanted to make sure of 16:48:42 that's probably all I have for now 16:48:59 ok, we have a couple of topics related to future process changes that I want people to start thinking about 16:49:07 #topic Adding functional tests for Oslo libs 16:49:07 There have been some discussions on the -dev mailing list about adding functional tests for projects outside of tempest. 16:49:07 #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/thread.html#31387 16:49:07 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/thread.html#41057 16:49:23 I would like us to think about what that means for the oslo libraries, especially oslo.db and oslo.messaging. 16:49:29 I don’t expect anything to be done this cycle, but we will talk about it at the summit and I want to be prepared to add tests when the tools are available. 16:49:46 dhellmann: I've already added one to oslo.rootwrap :) 16:49:53 also, pay attention to any discussions on the dev list about test job requirements, test node setup, etc. 16:50:05 YorikSar: that's another good example of where we could use functional tests 16:50:21 Although it runs alonng with unit tests. 16:50:21 YorikSar: is there a test job running it? 16:50:38 ah, ok, that's good and it may be all we really need for that app 16:50:51 there aren't a lot of dependencies to set up, like with the db or messaging libraries 16:51:23 dhellmann: Although eventlet becomes an issue there. 16:51:40 yes, we will absolutely need to test under eventlet 16:51:44 (but that's more about my rootwrap daemon work) 16:51:49 until the apps aren't using it, we need to test with it 16:52:10 Yeah. And we'll have to test separately with and without it. 16:52:22 YorikSar: it's ok to add eventlet to the test requirements for rootwrap, even if it's not in the runtime requirements (that's why we have separate lists) 16:52:34 YorikSar: good point 16:52:54 ok, one other thing to think about: 16:52:56 #topic future spec process changes 16:52:56 There’s a thread on -dev about “The future of the integrated release” that talks about some proposed changes to the spec management process that I want everyone to follow and think about. 16:52:56 We will talk about the ideas between now and the summit, and probably in a summit session as well. 16:52:56 #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/042157.html 16:53:10 dhellmann: I even import eventlet from rootwrap code to detect if world is monkey-patched, but it's not a requirement. 16:53:25 we've been doing a fairly good job of keeping up with specs, but I like the idea of setting a realistic limit to the number of things we will try to do at one time 16:53:50 YorikSar: interesting, I'll have to look at that patch :-) 16:54:48 * dhellmann isn't sensing much resistance to the idea of limiting the number of specs in progress at any one time 16:55:17 I think that's it for the main agenda this week 16:55:27 #topic review priorities for this week 16:55:40 we have the new oslo.concurrency, oslo.serialization, and oslo.middleware repositories 16:55:46 and the oslo.db exception changes from https://etherpad.openstack.org/p/sqla_exceptions_caught 16:55:49 lifeless also asked for some help with pbr reviews 16:55:57 is there anything else we need to make a high priority? 16:56:04 that's already a long list... 16:56:27 oslo.serialization is already imported, right? 16:56:53 So no immediate review needed there. 16:56:54 beekneemech: yes http://git.openstack.org/cgit/openstack/oslo.serialization 16:57:17 beekneemech: ah, good point, I was thinking of reviewing it for whatever changes we need to make, rather than code reviews per se 16:57:19 Although I see there is a task to convert it to oslo.i18n, but I don't know that that's a priority. 16:57:30 keystone should be able to use oslo.serialization when it's ready 16:58:33 bknudson: that might be a k-1 change, at this point in the schedule, but we'll see how things pan out 16:58:44 ok, just a couple of minutes left 16:58:47 #topic open discussion 17:00:15 I guess that means we've covered everything. :-) 17:00:19 thanks, everyone! 17:00:28 #endmeeting