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