16:00:03 #startmeeting oslo 16:00:04 Meeting started Mon Jan 26 16:00:03 2015 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:09 The meeting name has been set to 'oslo' 16:00:10 o/ 16:00:12 o/ 16:00:12 #link https://wiki.openstack.org/wiki/Meetings/Oslo 16:00:13 o/ 16:00:20 courtesy ping for jd__, dims, bnemec, flaper87, harlowja, viktors, rpodolyaka1, zzzeek, sileht, kgiusti 16:00:21 courtesy ping for redrobot, jungleboyj, zhiyan, therve, amotoki, GheRivero, bknudson, ihrachyshka, jogo, dougwig, sreshetnyak, amrith 16:00:34 o/ more or less 16:00:43 o/ 16:00:45 o/ 16:00:48 o/ 16:00:57 lol 16:01:05 o/ 16:01:35 \o 16:01:45 o/ 16:02:02 I think we have quorum to start :-) 16:02:04 #topic Review action items from previous meeting 16:02:13 #info bknudson to work on patch to add fixture for timeutils in oslo.utils 16:02:21 bknudson: do you have an update on that? 16:02:28 dhellmann: merged. 16:02:33 cool, thanks 16:02:44 ok, that's it for old business 16:02:45 #topic Red flags for/from liaisons 16:02:50 https://review.openstack.org/#/c/146719/ 16:02:54 #undo 16:02:55 Removing item from minutes: 16:03:04 #link https://review.openstack.org/#/c/146719/ 16:03:08 #topic Red flags for/from liaisons 16:03:30 for keystone, I'm wondering if there's a release of oslo.messaging planned with change to oslo_messaging 16:03:32 how are things looking? any critical issues? 16:03:50 bknudson: we're currently blocked on that until we fix some issues in other projects where we know a release will break them 16:04:03 it's my highest priority item right now 16:04:11 I would like to have a release before the end of the week 16:04:18 cool, neutron would also like to see earlier 16:04:33 ok. I proposed the change to oslo_messaging in keystone already since it's easier to do in reverse-alphabetical order 16:04:38 #link https://etherpad.openstack.org/p/oslo-messaging-1-6-0-blockers 16:04:38 dhellmann, end of week. sounds scary 16:04:58 some of the known issues have been dealt with, but when I re-ran the tests over the weekend I got more failures that I haven't debugged yet 16:05:10 bknudson, I'm going to do it with one huge blobs for all libraries :) 16:05:10 ihrachyshka: *before* -- if it isn't ready wed, we'll plan on doing it next week 16:05:37 /s/blobs/blob 16:05:38 One of our sacred truths is that we don't release on Friday. :-) 16:05:47 indeed 16:06:02 * ihrachyshka bows with his stable maint hat in his hand 16:06:18 we have a release of oslo.i18n coming, too, but it is also blocked for similar reasons 16:06:36 are there backwards-incompatible changes? 16:06:48 oh, wait, no, that's not blocked -- I just needed to ask kgiusti if we actually needed to release it with the packaging change 16:06:56 * dhellmann is confused by his own notes this morning 16:07:08 I hate when that happens. 16:07:28 * dhellmann also 16:07:37 * kgiusti / 16:07:41 * kgiusti ? 16:07:42 Had a very awkward moment once where I couldn't remember what my presentation notes meant. 16:08:05 bnemec: yeah, I always write the presentation out long form, even though I don't read it on stage -- just in case 16:08:51 kgiusti: there was a bug with a patch to oslo.i18n having to do with packaging, and I wondered if we needed a release for that. It looked like the sort of thing that I would have expected to see people clamoring for a fix right away, but I haven't seen that so I wonder how critical it really is. 16:09:09 ugh 16:09:14 kgiusti: sorry, I meant jecarey 16:09:19 kgiusti, a link? 16:09:22 * dhellmann needs to start over 16:09:32 #link https://review.openstack.org/146733 16:09:37 Mondays. ;-) 16:09:54 I'm going to blame the traveling I did last week. 16:10:01 * kgiusti :) 16:10:06 I don't really understand those patches, but Dan tells me they fix the problem. 16:10:19 we can use Mondays to blame kgiusti about world's problems 16:10:23 ok, I'll go ahead and cut a release later today 16:10:25 I'm sure he's cool with that 16:10:31 flaper87: get in line. 16:10:40 * flaper87 jumps the line 16:11:20 are there any other liaison reports, or can I go back to my meeting notes and stop extemporizing? :-) 16:11:51 moving on then... 16:11:51 Nothing for tripleo 16:12:01 #topic Review MySQL driver decision 16:12:02 zzzeek, victors, rpodolyaka1: which of you was going to lead this discussion? 16:12:38 hmm, none of them appear to be online 16:12:44 we'll reschedule that for next week 16:12:48 dhellmann: we are 16:12:53 ah, sorry, wrong nic 16:13:00 dhellmann: we made a wiki page 16:13:01 dhellmann: zzzeek prepared a wiki page 16:13:06 * viktors looking for link 16:13:20 zzzeek did email me that he wasn't going to be able to make the meeting today 16:13:31 dhellmann: https://wiki.openstack.org/wiki/PyMySQL_evaluation 16:13:53 so looks like we are stuck with PyMySQL 16:14:15 MySQL-Connector-Python looks the winner, but it missed on Pypi 16:14:16 though MySQL-Connector-Python is a better choice, except it's not PyPi hosted 16:14:34 anyway, PyMySQL should be ok 16:14:41 are all these projects well maintained? 16:15:17 zzzeek, rpodolyaka, viktors : this wiki page has good information, thank you for putting it together 16:15:42 thanks, zzzeek and viktors! 16:15:48 bknudson: PyMySQL - yes, as for MySQL-Connector-Python - it's Oracle stuff ) 16:16:08 did you get input from clarkb and the other infra folks? I know they had some interest in the topic. 16:16:31 no, I didn't manage to get around to that. Way to much travel and things on fire 16:16:34 viktors: we should probably start an email thread 16:16:45 with a link to ^ 16:16:51 rpodolyaka: agreed 16:16:57 clarkb: ok, no problem 16:17:08 rpodolyaka: yes, a mailing list discussion is a good next step 16:17:12 dhellmann: ack 16:17:41 but looks like you reached the same conclusion as me (pymysql isn't perfect but it is pragmatic and solves a bunch of problems) 16:17:44 I suspect we will want a spec somewhere, but I'm not sure if it should be an Oslo spec or a cross-project spec. Let's worry about that after we see how the discussion goes on the mailing list 16:18:04 dhellmann: ok 16:18:05 clarkb: yeah, I thought I remembered that as your position 16:18:34 viktors, rpodolyaka : which of you will start that thread? 16:18:42 dhellmann: ok 16:19:30 it's cool to see the initiative to finally move forward, even if with pymysql. I thought all my work was going to sink. 16:20:01 ihrachyshka: yeah, sometimes "big" decisions like this can take a while, because we want to make sure we have enough input 16:20:36 #action rpodolyaka & viktors to start a mailing list thread discussing mysql driver change 16:21:05 is there anything else on this topic, or are we ready to move on? 16:21:21 * bnemec will watch for the ml thread 16:21:46 #topic Adding policies to specs repo 16:21:47 #link https://review.openstack.org/#/q/status:open+project:openstack/oslo-specs+branch:master+topic:policy,n,z 16:22:03 I spent some time on planes last week, so one of the things I did was some housekeeping work for us. 16:22:23 I started a series of patches for "policies" that we have written down in the wiki, to move them to our specs repository 16:22:39 the idea is that this way we'll have an official vote recorded, and we'll have all of our policies in one place 16:22:53 good idea. 16:22:58 the wording is mostly based on what we already had, but some were out of date from what I thought we were actually doing so I updated those 16:23:13 Hey look, some of those relate to the topic I added to the agenda. :-) 16:23:19 :-) 16:23:42 as we get enough votes to approve them, I'll remove the old content from the wiki and replace it with links to the new location 16:23:57 * dhellmann wonders if he should have written a policy approval policy 16:24:34 Poliception 16:24:46 I guess we can use the same voting rules that we do for other specs, and discuss conflicts on the reviews or here in the meeting as needed 16:25:06 #action dhellmann write down spec approval policy in the specs repository 16:25:57 are there questions about that? 16:27:03 ok, let's move on then 16:27:11 #topic Expanding the target audience of oslo.* libs 16:27:11 #link https://review.openstack.org/#/c/130047 16:27:11 bnemec, harlowja: You added this to the agenda. Who wants to go first? 16:27:22 o/ Sorry I am late. 16:27:31 So yeah, this kind of relates the the policy on oslo.config usage. 16:27:44 hi, jungleboyj__, no worries -- we should have time to catch up with any red flags you have during open discussion 16:27:50 cinder meetup 16:28:01 Right now we basically say that if you use oslo.config you're in the oslo namespace and you don't expect to be used outside of OpenStack. 16:28:18 bknudson: Yes, and the Austin site took me a while to navigate. 16:28:28 yes, that's the one policy that was newly written down in that patch series 16:28:44 it's something I've been telling people as guidance, but I don't think I ever actually wrote it down anywhere 16:28:47 harlowja_at_home's spec is basically a way to make it easier for other people to use oslo.config-consuming libs. 16:29:02 #link https://review.openstack.org/149837 16:29:15 ya, by using proxy helpers/objects that allow them to interact with said libraries 16:29:43 It's a significant enough change in policy that I thought it deserved discussion. 16:29:53 Although now maybe we should have that talk on the policy spec. 16:30:15 yeah, I'll have to look at that proposal again. It wasn't clear how an application using a library would know what it could put in the data blob passed to the library without requiring the programmer to have intimate knowledge of the library's options 16:30:35 I'm worried there's going to be several different ways to work with libs using oslo.config and every lib will use something different and be confusing 16:30:45 the proposal I had was to use a wrapper lib, so we might have oslo.taskflow that wraps taskflow and defines interfaces that use oslo.config directly 16:31:17 and then taskflow itself would be unencumbered, but the knowledge of what options go where would only have to be written once 16:31:36 and applications using oslo.taskflow would not have to define configuration options themselves 16:32:39 possibly, a couple different ways to make this work 16:33:49 harlowja_at_home: the proxy idea is coming from the other direction, isn't it? so taskflow can use oslo.messaging and oslo.db, for example? 16:34:53 agreed, thats part of it 16:35:16 So maybe we need more discussion on the spec then. 16:35:32 I think the part I don't understand is how an app that does use oslo.config would pass info through a lib that doesn't to another lib that does, without assuming a global configuration object 16:35:47 nova -> taskflow -> oslo.db, for example 16:36:02 I think I'm a draft behind on this spec, though, so I'll read the latest and comment there 16:36:22 ya thats an interesting question to go through that many levels 16:36:37 Hmm, yeah. 16:36:46 harlowja_at_home: that's what we actually have, right? maybe not nova, but cinder uses taskflow, doesn't it? 16:36:59 ya, but they don't use the db stuff yet 16:37:05 "yet" :-) 16:37:08 ;) 16:37:13 or messaging or ... 16:37:26 anyway, that's the problem I think we need to figure out how to solve 16:37:34 my proposal doesn't address that use case, fwiw 16:37:44 at least not directly 16:38:51 shall we talk more about that in the various reviews? 16:39:43 moving on... 16:39:45 #topic kilo feature freeze 16:39:45 #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054351.html 16:39:45 The general feature freeze date is 19 March, so I proposed that we freeze feature work in Oslo on 12 March. 16:39:45 right, i start to feel that the above kind of stuff almost shouldn't be a concern; but idk, the point of having abstractions that hide the inner details of 'oslo.db' or whatever behind a higher-level api is well to not expose the inner details 16:39:58 #undo 16:39:59 Removing item from minutes: 16:40:02 #undo 16:40:03 Removing item from minutes: 16:40:45 yeah, it works a lot better if we keep libs that don't use oslo.config at the bottom of the stack, instead of in the middle 16:41:12 maybe that means refactoring some of what we have in our libs, or living with a bit of duplication :-/ 16:42:19 #topic kilo feature freeze 16:42:19 #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054351.html 16:42:19 The general feature freeze date is 19 March, so I proposed that we freeze feature work in Oslo on 12 March. 16:42:49 planning to do final releases of the libs that week? 16:42:56 and then get into global-requirements. 16:43:18 yes, we'll only do critical bug fixes after that point 16:43:55 and we need to freeze this cycle, and not land patches until we're unfrozen 16:43:57 cool. is oslo.log consumable till that point? 16:44:05 ? 16:44:17 we still expect to have oslo.log released by k-2 16:44:25 hopefully we'll get oslo.policy released. 16:44:27 dims and I have been working on a patch to nova to prove out the api 16:44:36 ok tnx 16:44:40 btw - are you expecting oslo.policy to also follow that date? 16:44:49 I don't know who's running oslo.policy 16:44:54 bknudson: yes, everything will need to freeze 16:45:01 ayoung has been leading that effort 16:45:23 hopefully he knows the date and it'll be all ready by then 16:45:25 Well, unless it's not released yet, right? 16:45:31 bnemec: true 16:45:37 Last cycle we didn't freeze stuff like concurrency that wasn't in use yet. 16:46:11 right, I should have been more clear on that 16:46:37 Definitely the exception to the rule though. 16:46:57 bnemec, in that case you should also tell liaisons what you think is not to be used the cycle, otherwise some of projects may migrate to those in k-2 16:47:00 *k-3 16:47:33 ihrachyshka: typically we support releases after we announce them, but that's a good point 16:47:58 Yeah, freeze would only not apply to libs that hadn't actually released. 16:48:07 we have not encouraged adoption of libs near the 3rd milestone in the past 16:48:36 dhellmann, near - not really, but right after k-2 - totally possible 16:48:44 neutron considers it for some libs 16:49:09 ihrachyshka: early in the cycle we actively encourage adoption; later in the cycle we support it but make allowances for other work going on in the projects 16:51:02 #action dhellmann document policy assumptions for library adoption among applications, including milestones and support for incubator code after graduation 16:51:22 can I get a volunteer to write a policy spec for the feature freeze? 16:52:01 * dhellmann looks meaningfully at bnemec 16:52:14 Heh 16:52:21 dhellmann: So what would that include? 16:52:35 When and which code it applies to? 16:52:46 basically just that we freeze 1 week before the other projects and -- yeah 16:52:59 with appropriate reference links as supporting documents 16:53:19 I guess I did write https://wiki.openstack.org/wiki/Oslo#Why_does_Oslo_observe_feature_freeze too 16:53:29 dhellmann: So yeah, I'll do that. 16:53:33 cool, thanks 16:53:43 #action bnemec write policy spec on feature freezes 16:54:16 #topic Ongoing work & Review priorities 16:54:16 #link https://launchpad.net/oslo/+milestone/next-kilo 16:54:16 #link https://launchpad.net/oslo/+milestone/kilo-2 16:54:16 Is anyone blocked on work we prioritized for this release? 16:54:49 anyone want to look over 16:54:51 https://review.openstack.org/#/q/status:open+project:openstack/debtcollector,n,z :) 16:55:04 ^ new hotness, ha 16:55:38 harlowja_at_home: added to my list -- would you update the oslo review dashboard links to include it? https://wiki.openstack.org/wiki/Oslo#Review_Links 16:56:01 k 16:56:01 harlowja_at_home: either jd__ or I can show you how to update the gerrit dashboard creator files 16:56:17 Oh, I should target my oslo.config deprecated opt change so it shows up there. 16:56:39 I would like to get that in ASAP so we start notifying deployers when they use deprecated opts. 16:57:39 bnemec: is there a blueprint or bug? 16:57:51 dhellmann, ok dokie 16:58:01 harlowja_at_home: I just updated that wiki page with a link to the source files 16:58:07 k 16:58:17 will adjust 16:58:19 dhellmann: Yeah. 16:58:28 https://bugs.launchpad.net/oslo.config/+bug/1390408 16:58:53 bnemec: ok, I set that to kilo-next 16:59:13 we're about out of time 16:59:24 good discussion this week, thank you all! 16:59:37 cheers! 17:00:03 #endmeeting