14:00:15 #startmeeting oslo 14:00:16 Meeting started Fri Feb 28 14:00:15 2014 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:19 The meeting name has been set to 'oslo' 14:00:22 #link https://wiki.openstack.org/wiki/Meetings/Oslo 14:00:27 who's around for the oslo meeting? 14:00:30 o/ 14:00:32 O/ 14:00:33 o/ 14:00:35 o/ 14:00:47 my first time :) 14:00:54 welcome, gcb! 14:01:23 dims, markmc, harlowja_away ping? 14:01:31 let's go ahead and start 14:01:34 #topic old business 14:01:44 dhellmann track down owner of qpid test bug 14:01:47 handled and a patch has been submitted 14:01:52 #link https://review.openstack.org/#/c/75853/ 14:02:12 that's on our i-3 review list, so please take a look when you have time 14:02:17 dhellmann talk to infra about whitelisting posix-ipc 14:02:21 resolved by having author upload to pypi instead 14:02:24 \o/ 14:02:34 jd__ should be happy with that 14:02:55 * dhellmann is noticing all of these tasks were assigned to himself, and makes a note to "delegate" more 14:03:01 dhellmann look into deprecating oslo.sphinx on pypi without deleting it 14:03:17 I'll have to carry that one over, unless someone else wants to look into it. We decided not to remove it entirely. 14:03:39 I think that's it, there were a couple of other things that markmc handled during the meeting last time 14:03:59 #topic feature freeze EOB Tuesday March 4 14:04:11 we still have a few open reviews for blueprints or bugs targeted for this release 14:04:43 how do you all feel about our chances of landing them? 14:05:15 I'm a little nervous about the qpid one. 14:05:25 the gate doesn't look very full yet today 14:05:37 #link https://review.openstack.org/#/c/75853/ 14:05:39 I haven't looked at it closely, but 41 comments on the latest patch set isn't promising. :-) 14:05:53 yeah, there were a lot of style comments on that one 14:06:22 do we want to give those a pass and submit a follow-up patch to clean it up? 14:06:41 or maybe clean up the patch directly and resubmit? 14:06:59 It would be good to get some sort of test cases in, so I'd be okay with leaving the cleanup for later. 14:07:01 I don't recognize the owner's name 14:07:10 Some tests > none :-) 14:07:13 +1 14:07:38 ok, I'll take another look with that in mind -- I have to admit to skipping it because of the large number of comments :-) 14:07:48 Ditto :-) 14:07:54 rpodolyaka has a couple of db-related patches: 14:07:55 #link https://review.openstack.org/#/c/74963/ 14:08:00 #link https://review.openstack.org/#/c/74081/ 14:08:16 rpodolyaka, those are failing some of the basic checks -- are you going to have time to fix them up? 14:08:43 * rpodolyaka looking 14:08:52 ha, so this are races 14:09:05 this must be fixed by one of the latest commit to infra 14:09:12 well, that second one fails pep8 14:09:15 viktors run a recheck no bug a few seconds ago 14:09:43 dhellmann: yeah, but this was a 'happy' run 14:09:50 yes, infra folks tells, that tests should pass now 14:10:09 ok, good, so we'll watch for the recheck to finish and then review 14:10:14 dhellmann: when races are fixed, this must be good to go 14:10:35 rpodolyaka: good 14:10:38 sileht's notifier patch is almost ready to land: 14:10:42 #link https://review.openstack.org/#/c/61675/ 14:10:47 needs one more +2 14:11:00 both, actually: 14:11:01 https://review.openstack.org/#/c/70106/ 14:11:18 dims, I don't have anything on this list for oslo.vmware -- how is that going? 14:11:31 do we have any release-critical reviews to do there? 14:12:10 oh, wait, he isn't here, nevermind 14:12:22 #action dhellmann check on oslo.vmware status with dims 14:12:52 the oslotest work is going well -- there are changes up now to add the symmetric gating jobs 14:13:08 #link https://review.openstack.org/#/c/76654/ 14:13:22 \o/ 14:13:40 #link https://review.openstack.org/#/c/76381/ 14:14:03 and also for gate jobs for the other libraries we just adopted: 14:14:05 #link https://review.openstack.org/#/c/76945/ 14:14:34 those aren't *critical* for release, so I probably won't ask for more infra team time until after the deadline 14:14:49 let's just be careful about changes to oslotest in the mean time :-) 14:15:13 are there any other changes we need to be watching? 14:15:44 Nothing I can think of. 14:16:03 Oh wait. 14:16:14 harlowja_away's encoding change. 14:16:25 Been meaning to get back to that and haven't yet. 14:16:33 I think maybe that was targeted to i-3? 14:16:34 this one? https://review.openstack.org/#/c/71362/ 14:16:43 Yeah 14:16:48 #link https://review.openstack.org/#/c/71362/ 14:17:06 dhellmann, unfortunatly we have found other issues for ceilometer in oslo.messaging after markmc have reviewing the ceilometer patches: https://review.openstack.org/#/c/77136/ and https://review.openstack.org/#/c/75365/ 14:17:28 We really do need to stop str-ing things that could contain unicode data, so it would be nice to figure out how we want to handle that. 14:17:29 bnemec: do you know the background there? it seemed odd to me that we didn't just add a __unicode__ method to the objects that need them 14:18:12 that's going to require some thought 14:18:28 sileht: ok, is there a bug for those that I can put on the i-3 list? 14:18:42 dhellmann: One of the issues is user input. In theory someone could send us unicode data that can't be encoded in the current locale. 14:19:10 The other thing was that we don't really test for that sort of thing, so having a safety net would be good. 14:19:49 dhellmann, hum I have just missed to link the review to the blueprint, I will add it now 14:20:08 bnemec: and this function is the safety net? are developers expected to call it, or is this something we need to use in oslo libraries like logging? 14:20:17 sileht: ok 14:21:22 dhellmann: Both, I think. We would probably replace the six.text_type in the log adapter with this call, and all of the times we call str() on an object that could resolve to unicode would need to be replaced in the other projects. 14:22:38 bnemec: I'm reluctant to rely on a utility function *everywhere* -- it seems like objects should always be able to give a valid unicode representation of themselves (not encoded), so shouldn't we just use unicode() or u'message %s' % obj? 14:23:05 I do see the usefulness of calling it ourselves, though 14:23:49 my unicode-fu may need brushing up 14:23:59 dhellmann: Yeah, that was my first thought, but we don't really have any tests for unicode edge cases so I figured better safe than sorry. 14:24:15 Especially since they were going to be ripping out all the str calls anyway. 14:24:57 But I'm not opposed to just doing this in our code either. 14:25:34 yeah, I'm torn. Maybe we can discuss the strategy for dealing with this on the mailing list. I'd like to get some input from the other projects before we introduce another sweeping change. 14:26:03 ok, we have a couple of other things to discuss, so lets move on 14:26:11 #topic security team participation 14:26:22 Yeah, I was actually hoping to do that after the last meeting. I'll follow up with harlowja_away and Jay Bryant since they were the ones pushing it. 14:26:31 bnemec: ok, thanks 14:26:45 every time I think I have the full list of things we need to do to create a new library, someone points out another one :-) 14:27:13 the vulnerability management team, rightly, points out that we should manage security issues for the libraries just as we do for the application projects 14:27:26 did everyone have a chance to review the emails I forwarded? 14:27:55 Yep 14:28:05 basically, we need to designate 1-2 people to be the contacts for those issues 14:28:30 I'd like to have a contact listed for each library, even if the same person handles multiple, to make it easy for the security team to find the right name 14:28:57 and we need to put that list together soon 14:29:08 if you're interested, let me know so I can put your name down 14:29:21 if I don't have a full list, I'll start twisting arms to find volunteers :-) 14:29:56 I'll help if it ok. 14:30:12 I could at least be a contact. Not sure I have the security chops to make any definitive statements on vulnerabilities though. :-) 14:30:18 Same here 14:30:36 S/It/it's 14:30:36 bnemec: ditto :-) 14:31:16 ok, I'll talk to you offline about details 14:31:39 one more topic on the official agenda 14:31:40 #topic removing oneliner functions for graduation 14:31:45 zyluo, I think this is yours? 14:32:02 Yup they are mine 14:32:22 So there was a lot of progress 14:32:28 With uuidutils 14:32:49 But neuton seems not to agree with this direction 14:33:00 do you have a link to that discussion? 14:33:18 It in the patch for neutron 14:33:42 #link https://review.openstack.org/#/c/58234/ 14:34:29 So I was hoping to get a concensus in our team first to pursuade them 14:34:47 Just a second I'll relogin 14:35:59 I'm back 14:36:11 ok 14:36:30 it sounds like we have 2 big projects using this library 14:36:39 so I do assume everyone here agrees with removing generate_uuid() 14:36:46 the nova review: 14:36:48 #link https://review.openstack.org/#/c/57588/ 14:37:08 I'm questioning that conclusion now based on the actual feedback from other projects 14:37:11 Yeah nova folks say the function should first be removed and then be fixed in Nova. 14:37:18 So that won't be much of a problem. 14:37:30 they want us to remove it in oslo first? 14:37:35 yeah. 14:38:16 odd 14:38:21 So maybe dhellmann you can talk with Neutron folks? 14:38:23 that would prevent them from syncing without removing it in nova at the same time 14:38:35 I don't have much of a voice overthere. 14:39:00 I guess they want it in one patch. Nova 14:39:21 Then it'll be part of an oslo sync they can ignore. ;-) 14:39:21 and at this point in the cycle, we don't want to introduce changes to the incubator that prevent syncing, in case we find critical bugs during the release candidate period 14:39:29 * dhellmann hangs head in dispair 14:40:07 Ok so that's the situation with generate_uuid() 14:40:21 if that gets removed we're only left with is_uuid_like. 14:40:26 zyluo: I'll have to look more closely at their comments, can you summarize their argument? 14:40:37 dhellmann, sure 14:40:59 So I suggest we move is_uuid_like to struils in the future. 14:41:35 that needs to stay 14:41:50 #link https://wiki.openstack.org/wiki/Oslo/GraduationStatus#uuidutils 14:41:52 I have uuidutils as part of an oslol.utils library there 14:41:54 I'm not sure why it wasn't oslo.text 14:42:08 oh ok then. 14:42:15 zyluo: what benefit do we gain from moving it? 14:42:35 I might be wrong about the placement, so I'm open to talking about it 14:42:41 well it just doesn't make sense having just one fuction in the module. 14:43:03 remember, though, the goal is not just to reduce the code in the incubator, it's to move it from the incubator to a library 14:43:04 and most of the projects use strutils and is_uuiid_like is related with strings. 14:43:40 yeah what you're saying makes more sense I guess. 14:44:12 So for uuidutils I'll work on graduating it after removing generate_uuid. 14:44:35 Then there is functions in timeutils which will turn out to be oneliners. 14:44:39 if the other projects want to keep using generate_uuid(), perhaps we should keep that, too? 14:44:54 It's a silly function, but we can't drop the module anyway so I wonder if it's worth arguing with them about it. 14:45:10 that's more or less what I'm thinking 14:45:45 But the thing is projects don't have common forms of uuids. 14:45:54 they don't? 14:45:59 some use the hex form. 14:46:27 But they wouldn't be using this anyway, right? 14:46:34 yeah 14:46:54 I remember murano and keystone use hex 14:46:57 that might actually be a strong argument in favor of keeping it -- to ensure that the format *is* standard 14:47:39 how are the values typically stored in the database? does that vary between projects, too? 14:48:12 values are all stored in string type, some in the canonical form, some in hex 14:48:29 ok, well, changing that is a bigger project than we have time to discuss right now 14:48:53 let's err on the side of keeping the function, I guess 14:49:05 zyluo: you had a similar question about timeutils? 14:49:49 yeah I'm working on removing set_time_override and its related functions 14:50:16 zyluo: did you resolve jd__'s use case of mocking the default value for a sqlalchemy column? 14:50:40 because there was a consensus of the function not qualifying for library. 14:50:45 Yeah that was fixed. 14:51:06 ok, good 14:51:20 So the problem is after all changes, utcnow() and utcnow_ts() are mere one liners. 14:51:24 IIRC, the thing we wanted to do was remove the test hooks, but keep the utility functions 14:52:02 because having the utility functions made the mocking easier, even if we didn't provide explicit hooks 14:52:18 then I assume they should move to oslo.test? 14:52:22 and, given that we have hooks for it, I assume we are doing a lot of mocking for time calls in tests somewhere 14:52:32 zyluo: no, production code cannot call oslo.test 14:52:45 but they will only be used in tests. 14:53:02 I don't think that's true 14:53:13 is there no production code using these functions now? 14:53:23 I've greped all usage of set_time_override and they were only in test last time I checked. 14:53:34 what about utcnow()? 14:53:40 and utcnow_ts()? 14:53:50 they are used in production. 14:53:56 those are the ones I'm talking about 14:54:00 oh ok. 14:54:38 ok then. all questions solved from my part. 14:54:58 so we should keep the functions that become one-liners, because having them as one-liners in our module makes them slightly easier to replace with mocks 14:55:20 Got it. 14:55:22 and we should keep the other functions in that module that are doing things like formatting and parsing timestamps 14:55:48 but all the stuff that was only used in tests, we want to drop -- if we can 14:56:33 although I think at this point in icehouse we should stop removing things 14:56:54 based on our discussion last time, we need to make sure we don't put the incubator into a state where syncing critical fixes causes problems 14:57:02 Probably. We're going to have enough of a headache trying to get nova back in sync. 14:57:08 because of conflicts or having to introduce large changes in other projects 14:57:38 so zyluo, I think you've made good progress on this, but we should probably pick it back up after the feature-freeze is lifted 14:57:55 well understood. thanks 14:58:00 bnemec: yes:) 14:58:06 ok, we have just a couple of minutes left 14:58:12 #topic open discussion 14:58:21 Speaking of which: https://etherpad.openstack.org/p/cinder-oslo-incubator-sync-proof-of-concept 14:58:50 I think the lockutils one should be taken care of now. 14:59:01 you mean it is already fixed, or we need to fix it immediately? 14:59:17 I mean jd__'s posix change should fix it. 14:59:21 ok, good 14:59:24 We no longer use lock_path on Linux. 15:00:06 I'll look over that list 15:00:11 we should talk about any issues on the ML 15:00:14 and we're out of time 15:00:16 But anyway, we should get started on the Nova sync and find a list of the easy sync modules. 15:00:18 Yep 15:00:23 thanks, everyone! 15:00:29 I'll help with that, thanks! 15:00:36 bnemec: jog0 has started some work on that 15:00:43 Yeah, he was the one who made the etherpad. 15:00:44 #endmeeting