14:01:13 #startmeeting oslo 14:01:13 Meeting started Fri Jan 31 14:01:13 2014 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:17 The meeting name has been set to 'oslo' 14:01:28 #link https://wiki.openstack.org/wiki/Meetings/Oslo 14:01:51 dims, markmc, flaper87: ping? 14:02:10 we have quite a few topics on the agenda, so I'll go ahead and start 14:02:13 #topic adopting cliff and stevedore into oslo (dhellmann) 14:02:34 pong 14:02:38 :) 14:02:42 at the summit, I had the opinion that we should encourage stand-alone libraries as much as possible 14:03:06 since that time, with the number of gate issues related to changes in repositories we don't control, I've had a change of heart 14:03:24 so to set the example, I'd like to move the cliff and stevedore libraries off of stackforge and into the openstack tree 14:03:35 that would let us introduce symmetric gating with the rest of openstack 14:03:45 but requires that we have a program to "own" them 14:04:00 does anyone object to bringing these 2 libraries in? 14:04:19 Seems like Oslo is the right place for them to me. 14:04:20 I'll obviously add oslo-core as reviewers and we will introduce the 2 +2 rule 14:04:26 o/ 14:05:00 Yeah, sounds like oslo makes sense 14:05:19 sounds like the right thing to do 14:05:22 And symmetric gating all the things is good. 14:05:32 yeah, sdague has convinced me of that :-) 14:05:54 ok, I'll go ahead and start working on that migration with the infra team next week 14:05:56 He's such a subversive. :-) 14:06:02 heh, I try :) 14:06:06 #action dhellmann work with infra team to move cliff and stevedore into oslo 14:06:11 i'm ok with that 14:06:23 I found it! 14:06:24 http://j.gs/3Nkb ! 14:06:24 Oh, wrong channel 14:06:25 Sorry Guys, Kisses, Bye! 14:06:30 hmm 14:06:32 lol 14:06:33 ,,, 14:06:40 :D 14:06:42 moving on 14:06:44 #topic adopting taskflow (dhellmann/jharlow) 14:06:51 same question, different lib 14:06:52 nice spam technique though 14:07:11 I've talked with harlowja about moving taskflow over too 14:07:24 dhellmann: is there any difference except harlowja_away being the owner? 14:07:26 dhellmann: honestly, I think once we sorted out the dependency issues on taskflow, I'm ok with it not being in the oslo pool 14:07:26 he already has a review team, so we'll add oslo-core to that and they will continue managing it 14:07:28 not really 14:07:43 then go 14:07:48 I think mostly there was extreme confusion on global requirements 14:08:14 sdague: ok, harlowja_away has the team ready to make the move, so I'll re-confirm with him but I wanted to ask the oslo team before taking action one way or the other 14:08:19 sure 14:08:34 ok, I think that concludes the "easy" portion of the meeting 14:08:36 :-) 14:08:43 #topic log translations (dhellmann) 14:08:49 #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/025572.html 14:09:08 we may have reached consensus on the approach for this? 14:09:47 I'm onboard with the current approach now. 14:09:51 Daisy, I think there was one open question on that thread from bnemec where we were waiting for your response 14:10:07 bnemec: cool 14:10:20 I do have one thing to bring up that I realized while working on graduation stuff 14:10:26 dhellmann, I will take a look at it. 14:10:43 when we move gettextutils out of the incubator and into a library, each project will need to set up its own copies of _, _LD, etc. with the right domain 14:10:55 they are getting that for free now because of the way we copy code into the app repos 14:11:15 but when we stop doing that, everyone will need a small module like ceilometer.i18n that creates those functions 14:11:26 ok. Do people from other projects agree it? 14:11:31 I don't think that changes the approach fundamentally 14:12:01 Daisy: most of the feedback we've had from other projects is to not translate logs at all, which obviously doesn't meet your needs 14:12:16 Yeah, it would be nice if we can wrap the six logging functions in a way that makes them easier to use. 14:12:18 #action bring up log translation at the next project meeting to poll the other PTLs 14:12:31 * ozstacker is away: I'm out smoking crack with triplecheesesina. how we roll. 14:12:33 bnemec: yeah, I thought about a factory function, or maybe a class 14:12:47 what is going on in this channel today? 14:13:00 Friday. ;-) 14:13:02 Daisy: do you need DEBUG level logged as well? 14:13:03 heh 14:13:07 lol 14:13:10 sorry translated as well 14:13:23 Yeah, that was my question too. 14:13:30 I think a lot of the push back on log translations from devs would go away if we stopped doing DEBUG 14:13:31 http://lists.openstack.org/pipermail/openstack-dev/2014-January/025828.html 14:13:51 It would drop around 850 translations from Nova, if my numbers are remotely correct. 14:14:02 sdague: it's not my need. But I think, the approach should be consistent among different levels. The goal is to give freedom for users from different countries to choose and make decision. 14:14:14 Daisy: sure 14:14:43 Daisy: I was saying your need, as a proxy for users that want that. As you are best in touch with their needs 14:14:50 I guess that kind of relates to sdague's log normalization. Do we consider debug messages user-facing, or are they only for devs? 14:14:58 right, that was my thinking 14:14:59 And I'm considering if the same approach can be applied to other messages catagories. 14:15:00 deployers are users too, right? 14:15:09 INFO and up, is for operators 14:15:14 DEBUG is for developers 14:15:26 so I agree INFO and up, translate them 14:15:27 Agree 14:15:30 Actually, I don't think users need debug messages to be translated. 14:15:33 but DEBUG ... less clear 14:15:38 ok, good point 14:15:57 it's just as easy for us to make it *possible* to do that translation, but we can leave debug out for now 14:16:00 Daisy: I think if you made that part of the i18n statement, INFO and up get translated 14:16:04 DEBUG doesn't 14:16:15 it would make lots of people happy, and there would be less pushback 14:16:23 we could even enforce that in hacking pretty easily 14:16:50 Daisy, can you attend the next project release meeting? https://wiki.openstack.org/wiki/Meetings#OpenStack_Project_.26_Release_Status_meeting 14:17:15 dhellmann: that's a super terrible time for .cn :( 14:17:17 that's a good chance to talk to the PTLs 14:17:22 ah, yeah, just did that math 14:17:28 ok, I'll take care of advocating 14:17:43 I'm checking the time of the release meeting now. 14:18:02 so if we agree we're only worried about INFO and up I can change the patches I have up for review to reflect that 14:18:06 Diasy 2100 UTC 14:18:15 Daisy: just want to make sure you are ok on the INFO / DEBUG split. As I consider you the expert opinion here. 14:18:35 yeah, I'm completely relying on Daisy to set these requirements :-) 14:19:24 I'm not that comfortable on INFO/DEBUG split, actually. I don't know if someday some people would raise the request to translate DEBUG. I cannot make sure of that. 14:19:53 Daisy: can we start by saying that we won't worry about debug messages, and add them later if we have users who want them translated? 14:19:56 I only reach part of the users, not all. 14:20:10 * dhellmann looks for the incremental approach 14:20:27 I think it make sense, dhellmann. 14:20:31 ok, good 14:20:43 Daisy: sure, it's going to be a compromise. Mostly I was trying to figure out if we did that, we'd get less push back from developers 14:20:46 #agreed we will advocate for translation of log messages at INFO level and above 14:20:56 which would let us move forward on the other stuff easier 14:21:00 understand, sdague. 14:21:01 #action dhellmann amend patches to reflect INFO/DEBUG log translation split 14:21:33 is there anything else on this topic? 14:21:45 We need to make sure we have good docs on the new log standards before we start pushing those changes in. 14:21:46 I'm good. I will try to attend the release meeting. 14:21:55 bnemec: good point 14:22:05 sdague: can we add some of this to the log standards doc you are building? 14:22:11 dhellmann: sure 14:22:28 https://wiki.openstack.org/wiki/LoggingStandards 14:22:32 bnemec: we can commit the code to implement the feature without requiring other projects to use it, right? 14:22:32 #link https://wiki.openstack.org/wiki/LoggingStandards 14:22:45 dhellmann: I would think so. 14:23:13 #action dhellmann update LoggingStandards in wiki with info about using translation functions for log messages 14:23:33 ok, I think we're ready to move on 14:23:35 #topic parallelizing tests (dhellmann) 14:23:39 sdague: you may have input here, too 14:24:01 I tried to run tests in parallel and added some comments to bug 14:24:02 I've heard several times, from different sources, that one of the impediments for projects pulling code straight from oslo-incubator is that our tests don't work when run in parallel 14:24:11 viktors: cool, thanks! 14:24:22 I ran the tests myself, and they appeared to hang 14:24:37 #link https://bugs.launchpad.net/oslo/+bug/1272035 14:24:37 * jd__ did try to debug that months ago 14:24:49 some of the trouble is coming from the rpc tests, I think 14:25:00 I'm less concerned with those, because we have them running in oslo.messaging 14:25:14 I wonder if we could split the test suite and run the others in parallel? 14:25:25 that sort of relates to our next topic 14:25:29 is it worth it? 14:25:49 yes, the other thing I was thinking about was graduating the code to libraries and making sure the tests work in parallel there 14:26:13 so at this point I've got 2 conflicting paths in my head, and am looking for input from everyone else :-) 14:26:47 I think we really need to get o-i working parallel since that gets synced directly to other projects without unit tests. 14:27:15 I agree for the most part, but it's less clear how much we should emphasize the deprecated parts of the tree 14:27:30 dhellmann, lets' leave things as-is. once we nuke rpc from our tree, we can do the parallel test work 14:27:33 hence the idea of splitting the tests into 2 passes -- one that runs in parallel and another where we don't worry about it 14:27:48 dims: log, police, timeutils, peiodic and notifier also ) 14:27:55 dims: removing rpc from the tree may take quite a while, and I'd really really like to have the other projects syncing 14:27:56 Yeah, maybe splitting the tests deprecated/not deprecated would be a good idea. 14:28:19 k 14:28:21 as it is now, I believe nova is cherry picking changes, and some of the other projects have started to follow that example 14:28:27 Multiple people have looked at the rpc tests and not come up with a solution so far, so it seems like it would be a large amount of work to fix the problem. 14:28:37 I would like, by the end of juno, for the incubator to be empty of everything except any code we add in juno 14:28:54 bnemec: the oslo.messaging tests run in parallel, don't they? 14:28:57 * dhellmann checks 14:28:57 +10000 14:29:09 looks good to me 14:29:32 Not sure. Last I saw oslo.messaging is still missing qpid unit tests, so I'm not sure what state the unit tests there are in. 14:29:35 yes, the tox.ini for oslo.messaging does not have any special settings controlling concurrency 14:30:03 ok, I need to make sure we have a bug reported to address that 14:30:26 #action dhellmann check on qpid unit tests for oslo.messaging and open a bug if there are none 14:30:37 I'm pretty sure I opened one a while back. 14:30:46 ok, that'll make that task simpler :-) 14:31:11 is anyone willing to volunteer to look at splitting the test suite to run in 2 phases, one in parallel and one serial? 14:31:21 #link https://bugs.launchpad.net/oslo.messaging/+bug/1255239 14:31:32 that would just mean figuring out which tests already work that way, and not imply that you're going to fix any tests at this point 14:31:38 but it would be good to know where we stand 14:31:56 bnemec: thanks 14:32:17 no takers? 14:32:21 I can look at splitting the tests. 14:32:28 great, thank you 14:32:44 #action bnemec to investigate splitting test suite into parallel and serial passes 14:33:13 #topic policy for maintaining graduating code in the incubator (dhellmann) 14:33:31 this came up in the context of several rpc-related reviews in the last week or so 14:34:03 I've been considering the version of the rpc code in oslo-incubator as the "stable branch" for oslo.messaging, and only accepting significant patches 14:34:14 but there has been some push-back on that, so I wanted to see what everyone else thought 14:34:54 should we accept help string updates, for example? 14:35:03 I like that it's pushing the migration to oslo.messaging. 14:35:12 that was part of the goal 14:35:53 We're planning to get every project onto oslo.messaging by the end of I? 14:36:01 dhellmann, would it be ok for them to submit 2 reviews, one against oslo.messaging and one against oslo-incubator? 14:36:07 I don't know if that's realistic, at this point in the schedule 14:36:18 the nova port is taking a long time to land 14:36:37 dims: yeah, backporting from messaging to the incubator would match the stable branch approach 14:36:47 but we wouldn't necessarily accept everything -- no new features for example 14:36:56 dhellmann, agree 14:37:12 it seems more realistic to say we will have the other projects moved to messaging by the end of juno 14:37:18 Yeah, I could see allowing something like help string updates, especially if there will still be projects using it in the Icehouse release. 14:37:37 yeah, that feels like a reasonable compromise 14:37:55 and using the stable branch rules gives us a precedent that people already understand, more or less 14:38:18 +1 14:38:18 does anyone else have anything to add? 14:39:03 no 14:39:10 #agreed follow the stable branch rules for changes to graduated code that is still in the incubator 14:39:24 ok, moving on 14:39:26 #topic oslo.db graduation status (viktors) 14:39:30 viktors: you have the floor 14:39:37 ok ) 14:39:40 #link https://blueprints.launchpad.net/oslo/+spec/oslo-db-lib 14:39:52 during the last few month oslo.db library in the “mostly done” state ) 14:40:04 see ropodolyaka github repository - https://github.com/malor/oslo.db 14:40:28 at the moment we should remove global engine, to be in able to work with multiple engines, and drop oslo log usage 14:40:43 please correct me, if I miss something. Should we make something else before we can split oslo.db? 14:41:00 I would like to see the sql_mode change land before graduation. 14:41:13 there was some reliance on eventlet that we talked about removing, did that land yet? 14:41:34 and yes, it would be simpler if we landed any other outstanding changes like the mode flag, I think 14:41:36 we already removed eventlet form oslo db code 14:41:51 bnemec: ok, will look at it 14:42:06 viktors: ok, good 14:42:22 as far as graduation goes, I had been planning for us to work from the bottom of the dependency graph up 14:42:27 viktors: Tail end of the review chain: https://review.openstack.org/#/c/69032/ 14:42:31 #link https://wiki.openstack.org/wiki/Oslo/Dependencies 14:42:50 oslo.db will rely on some other packages that are not yet ready to graduate 14:42:56 do you see that as a problem? 14:43:16 dhellmann: we plain to sync it like anothe openstack projects 14:43:22 temporally 14:44:13 that's going to make more work for graduating some of those other libraries, to find the other consumers and update them 14:44:23 it's not a deal-breaker, it's just something to think about 14:44:51 dhellmann: looks like, that oslo.messaging do it also 14:45:01 it's likely I could try to move py3kcompat into six 14:45:26 I see four lines from db, log, importutils, timeutils, and py3kcompat - is that all of them? 14:45:40 viktors: true, and that's what started me thinking about it 14:45:46 bnemec: all but log 14:45:51 jd__: that would be cool, one less thing for us to manage 14:45:52 But the log dep has already been handled, and I thought timeutils and importutils might be going away. 14:46:01 dhellmann: added to my todo list 14:46:09 jd__: thanks 14:46:24 jd__: could you make a note of that on https://wiki.openstack.org/wiki/Oslo/GraduationStatus please? 14:46:39 sure, doing it now 14:46:55 bnemec: importutils may be able to disappear eventually, but I think timeutils is with us to stay 14:47:13 we talked about removing some of the hacks for mocking times, but not removing the whole module, iirc 14:47:31 Ah, okay. That's what I was thinking of. 14:47:50 some more questions? 14:47:54 still, if it's only one or two modules, that won't be hard to manage 14:48:02 btw I think that time mocking feature has a usecase we can't patch with mock – at least I failed to 14:48:11 viktors: will you or someone on your team be stepping up to be the lead maintainer for the library? 14:48:12 I forgot to comment on the bug 14:48:29 dhellmann: hm... :) 14:48:34 jd__: oh? yeah, please do so we don't remove it prematurely 14:48:51 lemmedothatrightnow 14:48:59 viktors: it seems appropriate, since you are doing so much work on it 14:49:08 and we need a lead for each library we graduate 14:49:19 * dhellmann can only do so much project planning for ttx 14:49:21 dhellmann: can we discuss ti with our team? 14:49:26 viktors: certainly 14:49:31 dhellmann: ok 14:49:49 also I want to ask everyone to review patches related to db :) 14:50:26 yes, if we're close to being ready to graduate it, let's see if we can do it this release cycle 14:50:32 Yeah, our oldest pending review is for db. :-/ 14:50:51 shall we make the db code a focus for reviews over the next week? 14:50:53 dhellmann: I hope ) 14:51:17 FYI https://bugs.launchpad.net/oslo/+bug/1266962/comments/20 14:51:26 jd__: thanks 14:51:50 oh, interesting case 14:52:14 so we may have to take another look at removing the timeutils thing entirely 14:52:21 * dims dropping off. apologies. 14:52:25 thanks dims 14:52:48 Maybe we could eventually move that to db, if sqlalchemy is the only use case. 14:52:49 well, everyone please take a look at those db reviews over the next week and let's help viktors and the other people working on the graduation 14:52:55 bnemec: good point 14:52:58 Would make it clear that it's not supposed to be used for regular tests. 14:53:03 I like it 14:53:18 one more topic 14:53:20 #topic oslo.config futures question from sdague 14:53:36 sdague: you have the floor 14:53:55 oh, right 14:54:10 so has anyone thought about validation callback on oslo.config options? 14:54:28 I'm not sure what you mean? 14:54:50 have a function for validating the value given to a config 14:55:05 I wrote patches for that long time ago 14:55:05 so for instance, if it has to be > 0 14:55:06 Wasn't there just a change merged related to that? 14:55:16 the first step was to validate the type 14:55:18 I didn't see anything, but I might have missed it 14:55:29 because there was things like IntOpt(default='foobar') 14:55:36 sure 14:55:52 so there's a partial validation now, but it's really lazy and I think not enabled by default 14:55:55 yeah, we have a "type" argument now that can do some validation 14:55:57 basically, I just approved a nova change that was basically config value validation for an option 14:56:08 IIRC people were afraid of config file backward compaty 14:56:10 -y 14:56:10 ensuring it wasn't a negative number 14:56:23 I think the type support just added would do that 14:56:24 which sucks to have to do up in core logic 14:56:31 agreed 14:56:31 dhellmann: how? 14:56:43 set type=Integer(min=0) 14:56:48 ah 14:56:59 OTOH it looks like writing a validation mechanism in 2014 for a configuration library is a sign of failure, isn't there anything we could use and layer over for compat? 14:57:02 thinking out loud 14:57:50 dhellmann: well if there were docs on that more, that would help get rid of some of this logic 14:58:06 sdague: yeah 14:58:08 I think it just went in like last week. 14:58:15 But +1 to more doc. 14:58:20 yeah, it's pretty new 14:58:22 I did actually look at an oslo.config pull and couldn't find anything 14:58:32 but it was probably unobvious to me 14:58:36 #action dhellmann open bug to document type arg to config options 14:58:57 calling it "type" was maybe not the best choice 14:59:24 ok, we're about out of time 14:59:27 yeh, I definitely grepped for valid :) 14:59:31 sdague: https://review.openstack.org/#/c/58960/ 14:59:55 :( 15:00:03 one other question before we wrap: would it be useful for us to have these meetings more regularly? 15:00:07 dhellmann: about doing project planning for me... you could also argue that some (most?) libs would have their dev disconnected from common release milestones 15:00:19 ttx: yes, I expect so 15:00:33 I know markmc feels strongly about this.. wants oslo libs to be aligned... 15:01:07 but they are in fact released out of band 15:01:14 ttx: that discussion will require beer 15:01:30 ("as-needed") 15:01:34 heh 15:01:54 so I don't want to create unnecessary constraints 15:01:58 we're a bit over time, so think about whether it would be useful to meet more regularly and let me know if you see value 15:02:21 I don't want to meet just to meet, but coordinating like this is helpful 15:02:34 Yeah, especially as we're trying to get stuff in for I. 15:02:36 and thanks for the input and help today, everyone 15:03:00 thanks :) 15:03:17 I think I'll start being less shy about scheduling meetings and see how that goes 15:03:37 Sounds good to me. 15:03:47 yep 15:03:53 cool 15:04:05 we should free up the room in case there's someone else waiting 15:04:08 thanks again, everyon 15:04:13 *everyone 15:04:15 #endmeeting