14:00:15 <dhellmann> #startmeeting oslo
14:00:16 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:19 <openstack> The meeting name has been set to 'oslo'
14:00:22 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
14:00:27 <dhellmann> who's around for the oslo meeting?
14:00:30 <rpodolyaka> o/
14:00:32 <zyluo> O/
14:00:33 <bnemec> o/
14:00:35 <gcb> o/
14:00:47 <gcb> my first time :)
14:00:54 <dhellmann> welcome, gcb!
14:01:23 <dhellmann> dims, markmc, harlowja_away ping?
14:01:31 <dhellmann> let's go ahead and start
14:01:34 <dhellmann> #topic old business
14:01:44 <dhellmann> dhellmann track down owner of qpid test bug
14:01:47 <dhellmann> handled and a patch has been submitted
14:01:52 <dhellmann> #link https://review.openstack.org/#/c/75853/
14:02:12 <dhellmann> that's on our i-3 review list, so please take a look when you have time
14:02:17 <dhellmann> dhellmann talk to infra about whitelisting posix-ipc
14:02:21 <dhellmann> resolved by having author upload to pypi instead
14:02:24 <dhellmann> \o/
14:02:34 <dhellmann> 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> dhellmann look into deprecating oslo.sphinx on pypi without deleting it
14:03:17 <dhellmann> 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 <dhellmann> I think that's it, there were a couple of other things that markmc handled during the meeting last time
14:03:59 <dhellmann> #topic feature freeze EOB Tuesday March 4
14:04:11 <dhellmann> we still have a few open reviews for blueprints or bugs targeted for this release
14:04:43 <dhellmann> how do you all feel about our chances of landing them?
14:05:15 <bnemec> I'm a little nervous about the qpid one.
14:05:25 <dhellmann> the gate doesn't look very full yet today
14:05:37 <dhellmann> #link https://review.openstack.org/#/c/75853/
14:05:39 <bnemec> I haven't looked at it closely, but 41 comments on the latest patch set isn't promising. :-)
14:05:53 <dhellmann> yeah, there were a lot of style comments on that one
14:06:22 <dhellmann> do we want to give those a pass and submit a follow-up patch to clean it up?
14:06:41 <dhellmann> or maybe clean up the patch directly and resubmit?
14:06:59 <bnemec> 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 <dhellmann> I don't recognize the owner's name
14:07:10 <bnemec> Some tests > none :-)
14:07:13 <dhellmann> +1
14:07:38 <dhellmann> 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 <bnemec> Ditto :-)
14:07:54 <dhellmann> rpodolyaka has a couple of db-related patches:
14:07:55 <dhellmann> #link https://review.openstack.org/#/c/74963/
14:08:00 <dhellmann> #link https://review.openstack.org/#/c/74081/
14:08:16 <dhellmann> 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 <rpodolyaka> ha, so this are races
14:09:05 <rpodolyaka> this must be fixed by one of the latest commit to infra
14:09:12 <dhellmann> well, that second one fails pep8
14:09:15 <rpodolyaka> viktors run a recheck no bug a few seconds ago
14:09:43 <rpodolyaka> dhellmann: yeah, but this was a 'happy' run
14:09:50 <viktors_away> yes, infra folks tells, that tests should pass now
14:10:09 <dhellmann> ok, good, so we'll watch for the recheck to finish and then review
14:10:14 <rpodolyaka> dhellmann: when races are fixed, this must be good to go
14:10:35 <dhellmann> rpodolyaka: good
14:10:38 <dhellmann> sileht's notifier patch is almost ready to land:
14:10:42 <dhellmann> #link https://review.openstack.org/#/c/61675/
14:10:47 <dhellmann> needs one more +2
14:11:00 <dhellmann> both, actually:
14:11:01 <dhellmann> https://review.openstack.org/#/c/70106/
14:11:18 <dhellmann> dims, I don't have anything on this list for oslo.vmware -- how is that going?
14:11:31 <dhellmann> do we have any release-critical reviews to do there?
14:12:10 <dhellmann> oh, wait, he isn't here, nevermind
14:12:22 <dhellmann> #action dhellmann check on oslo.vmware status with dims
14:12:52 <dhellmann> the oslotest work is going well -- there are changes up now to add the symmetric gating jobs
14:13:08 <dhellmann> #link https://review.openstack.org/#/c/76654/
14:13:22 <bnemec> \o/
14:13:40 <dhellmann> #link https://review.openstack.org/#/c/76381/
14:14:03 <dhellmann> and also for gate jobs for the other libraries we just adopted:
14:14:05 <dhellmann> #link https://review.openstack.org/#/c/76945/
14:14:34 <dhellmann> those aren't *critical* for release, so I probably won't ask for more infra team time until after the deadline
14:14:49 <dhellmann> let's just be careful about changes to oslotest in the mean time :-)
14:15:13 <dhellmann> are there any other changes we need to be watching?
14:15:44 <bnemec> Nothing I can think of.
14:16:03 <bnemec> Oh wait.
14:16:14 <bnemec> harlowja_away's encoding change.
14:16:25 <bnemec> Been meaning to get back to that and haven't yet.
14:16:33 <bnemec> I think maybe that was targeted to i-3?
14:16:34 <dhellmann> this one? https://review.openstack.org/#/c/71362/
14:16:43 <bnemec> Yeah
14:16:48 <dhellmann> #link https://review.openstack.org/#/c/71362/
14:17:06 <sileht> 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 <bnemec> 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 <dhellmann> 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 <dhellmann> that's going to require some thought
14:18:28 <dhellmann> sileht: ok, is there a bug for those that I can put on the i-3 list?
14:18:42 <bnemec> 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 <bnemec> 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 <sileht> dhellmann, hum I have just missed to link the review to the blueprint, I will add it now
14:20:08 <dhellmann> 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 <dhellmann> sileht: ok
14:21:22 <bnemec> 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 <dhellmann> 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 <dhellmann> I do see the usefulness of calling it ourselves, though
14:23:49 <dhellmann> my unicode-fu may need brushing up
14:23:59 <bnemec> 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 <bnemec> Especially since they were going to be ripping out all the str calls anyway.
14:24:57 <bnemec> But I'm not opposed to just doing this in our code either.
14:25:34 <dhellmann> 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 <dhellmann> ok, we have a couple of other things to discuss, so lets move on
14:26:11 <dhellmann> #topic security team participation
14:26:22 <bnemec> 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 <dhellmann> bnemec: ok, thanks
14:26:45 <dhellmann> 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 <dhellmann> 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 <dhellmann> did everyone have a chance to review the emails I forwarded?
14:27:55 <bnemec> Yep
14:28:05 <dhellmann> basically, we need to designate 1-2 people to be the contacts for those issues
14:28:30 <dhellmann> 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 <dhellmann> and we need to put that list together soon
14:29:08 <dhellmann> if you're interested, let me know so I can put your name down
14:29:21 <dhellmann> if I don't have a full list, I'll start twisting arms to find volunteers :-)
14:29:56 <zyluo> I'll help if it ok.
14:30:12 <bnemec> 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 <zyluo> Same here
14:30:36 <zyluo> S/It/it's
14:30:36 <dhellmann> bnemec: ditto :-)
14:31:16 <dhellmann> ok, I'll talk to you offline about details
14:31:39 <dhellmann> one more topic on the official agenda
14:31:40 <dhellmann> #topic removing oneliner functions for graduation
14:31:45 <dhellmann> zyluo, I think this is yours?
14:32:02 <zyluo> Yup they are mine
14:32:22 <zyluo> So there was a lot of progress
14:32:28 <zyluo> With uuidutils
14:32:49 <zyluo> But neuton seems not to agree with this direction
14:33:00 <dhellmann> do you have a link to that discussion?
14:33:18 <zyluo> It in the patch for neutron
14:33:42 <dhellmann> #link https://review.openstack.org/#/c/58234/
14:34:29 <zyluo> So I was hoping to get a concensus in our team first to pursuade them
14:34:47 <zyluo> Just a second I'll relogin
14:35:59 <zyluo> I'm back
14:36:11 <dhellmann> ok
14:36:30 <dhellmann> it sounds like we have 2 big projects using this library
14:36:39 <zyluo> so I do assume everyone here agrees with removing generate_uuid()
14:36:46 <dhellmann> the nova review:
14:36:48 <dhellmann> #link https://review.openstack.org/#/c/57588/
14:37:08 <dhellmann> I'm questioning that conclusion now based on the actual feedback from other projects
14:37:11 <zyluo> Yeah nova folks say the function should first be removed and then be fixed in Nova.
14:37:18 <zyluo> So that won't be much of a problem.
14:37:30 <dhellmann> they want us to remove it in oslo first?
14:37:35 <zyluo> yeah.
14:38:16 <dhellmann> odd
14:38:21 <zyluo> So maybe dhellmann you can talk with Neutron folks?
14:38:23 <dhellmann> that would prevent them from syncing without removing it in nova at the same time
14:38:35 <zyluo> I don't have much of a voice overthere.
14:39:00 <zyluo> I guess they want it in one patch. Nova
14:39:21 <bnemec> Then it'll be part of an oslo sync they can ignore. ;-)
14:39:21 <dhellmann> 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 <zyluo> Ok so that's the situation with generate_uuid()
14:40:21 <zyluo> if that gets removed we're only left with is_uuid_like.
14:40:26 <dhellmann> zyluo: I'll have to look more closely at their comments, can you summarize their argument?
14:40:37 <zyluo> dhellmann, sure
14:40:59 <zyluo> So I suggest we move is_uuid_like to struils in the future.
14:41:35 <dhellmann> that needs to stay
14:41:50 <dhellmann> #link https://wiki.openstack.org/wiki/Oslo/GraduationStatus#uuidutils
14:41:52 <dhellmann> I have uuidutils as part of an oslol.utils library there
14:41:54 <dhellmann> I'm not sure why it wasn't oslo.text
14:42:08 <zyluo> oh ok then.
14:42:15 <dhellmann> zyluo: what benefit do we gain from moving it?
14:42:35 <dhellmann> I might be wrong about the placement, so I'm open to talking about it
14:42:41 <zyluo> well it just doesn't make sense having just one fuction in the module.
14:43:03 <dhellmann> 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 <zyluo> and most of the projects use strutils and is_uuiid_like is related with strings.
14:43:40 <zyluo> yeah what you're saying makes more sense I guess.
14:44:12 <zyluo> So for uuidutils I'll work on graduating it after removing generate_uuid.
14:44:35 <zyluo> Then there is functions in timeutils which will turn out to be oneliners.
14:44:39 <dhellmann> if the other projects want to keep using generate_uuid(), perhaps we should keep that, too?
14:44:54 <bnemec> 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 <dhellmann> that's more or less what I'm thinking
14:45:45 <zyluo> But the thing is projects don't have common forms of uuids.
14:45:54 <dhellmann> they don't?
14:45:59 <zyluo> some use the hex form.
14:46:27 <bnemec> But they wouldn't be using this anyway, right?
14:46:34 <zyluo> yeah
14:46:54 <zyluo> I remember murano and keystone use hex
14:46:57 <dhellmann> that might actually be a strong argument in favor of keeping it -- to ensure that the format *is* standard
14:47:39 <dhellmann> how are the values typically stored in the database? does that vary between projects, too?
14:48:12 <zyluo> values are all stored in string type, some in the canonical form, some in hex
14:48:29 <dhellmann> ok, well, changing that is a bigger project than we have time to discuss right now
14:48:53 <dhellmann> let's err on the side of keeping the function, I guess
14:49:05 <dhellmann> zyluo: you had a similar question about timeutils?
14:49:49 <zyluo> yeah I'm working on removing set_time_override and its related functions
14:50:16 <dhellmann> zyluo: did you resolve jd__'s use case of mocking the default value for a sqlalchemy column?
14:50:40 <zyluo> because there was a consensus of the function not qualifying for library.
14:50:45 <zyluo> Yeah that was fixed.
14:51:06 <dhellmann> ok, good
14:51:20 <zyluo> So the problem is after all changes, utcnow() and utcnow_ts() are mere one liners.
14:51:24 <dhellmann> IIRC, the thing we wanted to do was remove the test hooks, but keep the utility functions
14:52:02 <dhellmann> because having the utility functions made the mocking easier, even if we didn't provide explicit hooks
14:52:18 <zyluo> then I assume they should move to oslo.test?
14:52:22 <dhellmann> 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 <dhellmann> zyluo: no, production code cannot call oslo.test
14:52:45 <zyluo> but they will only be used in tests.
14:53:02 <dhellmann> I don't think that's true
14:53:13 <dhellmann> is there no production code using these functions now?
14:53:23 <zyluo> I've greped all usage of set_time_override and they were only in test last time I checked.
14:53:34 <dhellmann> what about utcnow()?
14:53:40 <dhellmann> and utcnow_ts()?
14:53:50 <zyluo> they are used in production.
14:53:56 <dhellmann> those are the ones I'm talking about
14:54:00 <zyluo> oh ok.
14:54:38 <zyluo> ok then. all questions solved from my part.
14:54:58 <dhellmann> 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 <zyluo> Got it.
14:55:22 <dhellmann> and we should keep the other functions in that module that are doing things like formatting and parsing timestamps
14:55:48 <dhellmann> but all the stuff that was only used in tests, we want to drop -- if we can
14:56:33 <dhellmann> although I think at this point in icehouse we should stop removing things
14:56:54 <dhellmann> 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 <bnemec> Probably.  We're going to have enough of a headache trying to get nova back in sync.
14:57:08 <dhellmann> because of conflicts or having to introduce large changes in other projects
14:57:38 <dhellmann> 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 <zyluo> well understood. thanks
14:58:00 <gcb> bnemec： yes:)
14:58:06 <dhellmann> ok, we have just a couple of minutes left
14:58:12 <dhellmann> #topic open discussion
14:58:21 <bnemec> Speaking of which: https://etherpad.openstack.org/p/cinder-oslo-incubator-sync-proof-of-concept
14:58:50 <bnemec> I think the lockutils one should be taken care of now.
14:59:01 <dhellmann> you mean it is already fixed, or we need to fix it immediately?
14:59:17 <bnemec> I mean jd__'s posix change should fix it.
14:59:21 <dhellmann> ok, good
14:59:24 <bnemec> We no longer use lock_path on Linux.
15:00:06 <dhellmann> I'll look over that list
15:00:11 <dhellmann> we should talk about any issues on the ML
15:00:14 <dhellmann> and we're out of time
15:00:16 <bnemec> But anyway, we should get started on the Nova sync and find a list of the easy sync modules.
15:00:18 <bnemec> Yep
15:00:23 <dhellmann> thanks, everyone!
15:00:29 <zyluo> I'll help with that, thanks!
15:00:36 <dhellmann> bnemec: jog0 has started some work on that
15:00:43 <bnemec> Yeah, he was the one who made the etherpad.
15:00:44 <dhellmann> #endmeeting