16:00:02 #startmeeting oslo 16:00:03 Meeting started Mon May 16 16:00:02 2016 UTC and is due to finish in 60 minutes. The chair is harlowja_at_home. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:07 The meeting name has been set to 'oslo' 16:00:09 courtesy ping for amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dims, dougwig 16:00:09 courtesy ping for e0ne, flaper87, garyk, gcb, GheRivero, haypo, ihrachyshka, jd__ 16:00:09 courtesy ping for jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, Nakato 16:00:09 courtesy ping for ozamiatin, rbradfor, redrobot, rpodolyaka, sergmelikyan, sileht, spamaps, sreshetnyak 16:00:09 courtesy ping for sreshetnyak, stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek 16:00:18 o/ 16:00:22 o/ 16:00:41 btw for people that want to be in that ping list 16:00:47 o/ 16:00:50 o/ \o 16:00:51 ./ 16:00:53 o/ 16:00:53 i just updated https://wiki.openstack.org/wiki/Meetings/Oslo#Ping_script with a crappy script, adjustments welcome (or add yor own) 16:00:59 o/ 16:01:10 I have to get to the airport so won't be here. 16:01:16 k 16:01:53 #topic Red flags for/from liaisons 16:01:58 o/ 16:02:04 none that I know of for keystone 16:02:15 Nothing from Cinder. 16:02:19 so i believe taskflow release caused some *existing* bugs to show up in some folks code (cinder, octavia) 16:02:19 none for Trove. 16:02:42 I am not aware of any for neutron, but hey, I am just back from 2week post-summit vacation... 16:02:52 jungleboyj, do u know if those cinder + taskflow things got fixed up 16:04:14 o/ ish 16:04:19 ihrachys, thx seems like mostly issue free :-P 16:04:32 harlowja_at_home: Yeah, I saw there was a patch pushed up for that at the end of last week while I was out. 16:04:38 k 16:04:39 cool 16:04:54 harlowja_at_home: So, I think we got beyond it for now. 16:04:57 harlowja_at_home, heads-up on an eminent red-flag. I'm going to rake up the isotime() issue next week. 16:05:07 jungleboyj, sweet 16:05:09 amrith, lol 16:05:15 ah the ye-olde isotime 16:05:21 jd__, loves that one 16:05:43 #topic Releases for newton 16:05:54 o/ 16:05:57 so I haven't gotten a new release of all the things out yet, but i'll work on that in a bit 16:06:10 anyone need anything to be released explicitly? 16:06:46 (if not i'll just make a release for all oslo libs, and people can yell at me if its incorrect) 16:07:42 :) 16:07:51 #topic Delimiter 16:07:55 o/ 16:08:03 nikhil, do u have some time to describe the whole thing here :)( 16:08:09 * harlowja_at_home hands mic to nikhil 16:08:13 here's the agenda item: 16:08:15 Discuss the home of quota (delimiter) library http://lists.openstack.org/pipermail/openstack-dev/2016-May/thread.html#93959 16:08:30 please follow along the thread to know what exactly is happening here 16:08:45 but without going divergent into things, I can give a tl;dr; 16:08:49 sure :) 16:08:52 there are 2 school of thoughts: 16:09:19 1) people who think this is a cross project library but the problem domain and solutions are not well defined hence it cant be x-prj yet 16:09:55 2) another set of people who think that if we need to make it a successful x-prj library then we need it in a umbrealla that is already a cross project established domain 16:10:26 SO, to established the right apporach here 16:10:40 I need your vetted input on what are the tradeoffs to put this in oslo 16:11:02 what can be the good things (and of course I shouldn't be asking here :-)) what would be the warnings? 16:11:16 everything is good when its in oslo :-P 16:11:27 I think I fall in group 2, and I suggested creating an oslo.quota lib repo to host the work as a sub-project in oslo. I'm not entirely opposed to the project being stand-alone though. 16:11:38 I just think the road to adoption will be longer that way. 16:12:12 (context: both the school of thoughts have pretty experienced and influencial people) 16:12:16 we already have well-established processes for subteams like with messaging, db, and policy so we have the pattern of setting up a team like this 16:12:35 so if we as a group have it be a sub-project nikhil it doesn't guarantee adoption (i assume this is known) 16:12:39 just a word of warning there 16:12:51 adoption still hard (believe me, i know) 16:12:51 yeah, that's true -- there are no guarantees either way 16:13:12 dhellmann : since we tried this oslo.quota before and there's a lot of resistance from folks who have that "feature" i thought it would be better to do it this way as a standalone lib 16:13:21 What's the reason to not have it in oslo? 16:13:54 oslo is all of the common "business logic" that we share in OpenStack, isn't it? 16:13:55 dims : there seems to be a lot of support for sharing something now, though? what did we actually have to share in the past? 16:14:08 SpamapS : that's more or less the idea 16:14:09 dims, I believe that resistence in the past was more because of what the quota library sought to do and how. I believe that more consensus is being built in this process and therefore the odds of adoption may (and I stress may) be higher. 16:14:09 one reason i can think of (others may disagree) is limited people in oslo to maintain it (if the sub-team goes away) SpamapS 16:14:46 amrith : we can always adopt the library when it has some legs.. like os-profiler 16:14:47 harlowja_at_home : that's true. we have the same risk for any piece of code anywhere in openstack. 16:14:59 dhellmann, good point 16:15:26 harlowja_at_home: I do understand that. However, if it is standalone and the team fades away, the projects that adopt it are still in deep water, but without a known team to help them migrate off it while it is deprecated. 16:15:38 dims : that's true. I think this team is doing a better job of collaborating than the os-profiler team did in its early days, though. 16:15:41 SpamapS, understood 16:15:48 dhellmann : yep 16:16:05 Is it being done as a total new thing, or did they start with a forklift from some other project's quota system? 16:16:17 #link https://github.com/openstack/delimiter (if people want to look through the code that exists so far) 16:16:17 SpamapS : i'd give them a bit more time to come up with something that works with early adopters 16:16:24 yes, most of that code i put up over the weekend, lol 16:16:46 SpamapS: a bit of both 16:16:56 but the roadmap is still undefined 16:16:59 if it is not a forklift, then I have a 3rd option: start over. Forklift from the best implementation. Otherwise we end up in the Neutron space again. 16:17:09 and we do not know who is going to work on this long term 16:17:14 SpamapS : this is starting over 16:17:24 dims, that is true too. 16:17:26 SpamapS, i believe its mostly starting over (but doing it strategically/smartly) 16:17:38 harlowja_at_home: correct 16:17:48 this is more strategic effort 16:17:56 right 16:18:00 and we need some space for that to happen 16:18:05 right 16:18:09 nikhil : if we don't see good progress on early adopter project and or if the team loses steam, we don't want oslo core team to be burdened as well 16:18:13 So, put me down as somebody who is very interested in cross-project harmony, and who does not want to see another Neutron situation (I know this is a library and not a service, but the fact remains that whole new efforts are far more painful than incremental migrations) 16:18:19 possibly not have a brand name tagged from the get go (mostly my worry) 16:18:32 dims: I agree and share the sentiment 16:18:59 At the moment the team has a space and talking to whole bunch of folks and iterating, i'd keep that going and revisit later personally 16:19:23 dims makes a convincing case. I'll +1 his suggestion. 16:19:23 there's no rush in my mind to make it "oslo". i'd prefer to have something working first 16:19:42 Also, I do not want some people like (say the liaison from PWG) to stop contributing just because the space belongs more to developers 16:19:44 i'm personally also fine with that, like we can check-in a couple of weeks from now, see where things are at 16:19:52 Oslo is great at having very few people maintain a lot of code...not for this kickstart 16:20:03 the main question in my mind is how are you going to know it works if it's called experimental and being run not as an official project -- who is signed up to adopt what is built? 16:20:09 dims: the point at which to push for a decision on namespace is probably when a project starts adopting it. 16:20:12 i think glance signed up :-P 16:20:17 SpamapS : yep 16:20:22 also, say I have a good intern working on it, she might be a little bit apprehensive on contributing to something like oslo with the experts 16:20:25 dhellmann : Nova too 16:20:25 Keep the blast radius for a namespace change to the early adopters. 16:20:38 nikhil, we don't bite :-P 16:20:44 :) 16:20:45 lots of feeback from jaypipes and others 16:20:57 and amrith is keeping them honest 16:21:06 dhellmann: I have a bunch of people in glance who don't want to import code just because it's oslo too 16:21:17 so we have all sorts of ideas in openstack! 16:21:38 I do not know for sure who is going to sign up 16:21:50 i wrote a skeleton, my job is done :-P 16:21:50 and that's the learning process, I think 16:21:54 great, so one of the reasons for doing this separately is because folks don't want to collaborate with the oslo team? happy days. 16:22:06 i'm concerned about the comment that there may be people who won't import code just because it is oslo but that is a diversion 16:22:16 ya, let 16:22:19 *lets table that for now 16:22:24 that (to put it mildly) sucks. 16:22:47 I agree 16:22:49 nikhil, so how about we have a check-up in 2 weeks, see where things are at? 16:22:57 u don't have to cough or anything ... 16:23:01 and I spend my 10% enerygy fighting that sort of ideas 16:23:19 energy* 16:23:33 so I do not know what the right ways are 16:23:36 nikhil : if they prefer hangouts or other forms of communication to make them comfortable, let us know 16:23:40 I am trying to be honest on my worries here 16:23:50 thx :) 16:23:53 and being open about getting feedback on tradeoffs 16:24:06 That's weird because, they could.. join.. the oslo team.. 16:24:15 dims: whatever makes the cross project experts comfortable 16:24:29 Except it's an exclusive club and we only accept non-nerf-herders right? ;) 16:24:34 nikhil : the only thing that would be different about this project if it was an oslo lib is the name, and the fact that the existing oslo-core team would also have +2 on the repo. 16:24:43 * SpamapS joins the oslo team as a "we" in that sentence whenever it suits him 16:24:47 all I worry about is the end goal - I do not care how we achieve it (we need a successful quota implementation in openstack) 16:24:55 SpamapS : ++ :) 16:25:06 nikhil : agree. 16:26:03 dhellmann: I am okay with oslo or non-oslo as long as we won't be spending another 2 months discussing the weirness in the spec 16:26:10 that was 1) 16:26:22 2) we are okay to put this on "probation" 16:26:33 soooo, checkup in 2 weeks ok with folks? that's somewhat my preference, let's get people to show up to code stuff (besides myself) and see where it goes a little (or that's what i feel) 16:26:43 3) there's freedome to adopt different approaches and no issues with api of the lib version breaks 16:26:48 harlowja_at_home : yeah, that's fine. If the team doesn't want to be part of oslo, we can spend our energy elsewhere. 16:27:02 incase anyone wants to review 16:27:03 4) we do not have a complete re-implmentation of this lib in oslo just because it's not the oslo way 16:27:04 #link https://review.openstack.org/#/q/project:openstack/delimiter 16:27:14 dhellmann : i think of this as a POC, let them get some work done, see if they can make folks like amrith, jaypipes etc comfortable with the impl and they can apply for governance 16:27:18 5) we test this in production before making it non on probation 16:27:22 * nikhil done 16:27:45 nikhil : you will find, as we have learned and could help you work around, that projects adopting this library and trying to maintain CD compatibility will be upset if you start making lots of API changes that break their test systems. 16:28:07 that's regardless of whether it's official, or who runs it, or what program it's in 16:28:22 dhellmann : ++ 16:28:29 nikhil, I think it is important (for the reasons that dhellmann just brought up) that we spend more time now and get the API right. 16:28:44 amrith : ++ 16:28:48 so if you're not prepared to deal with that situation, I think you need a new plan for getting the library into production 16:28:58 FWIW, that's one of the reasons I disagree with jaypipes proposed API. We agree about the implementation now but the API is still a concern to me. 16:29:10 amrith: correct and that's the end goal I am talking about as well 16:29:12 it will be time well spent if we can get that API acceptable to more, at this stage. 16:29:40 api i put up amrith @ https://github.com/openstack/delimiter/blob/master/delimiter/engine.py#L20 (feel free to change it) 16:30:05 main engine access point would be @ https://github.com/openstack/delimiter/blob/master/delimiter/__init__.py#L23 16:30:10 harlowja_at_home: I expect >10 changes tbh (once people from diff projects actually start giving input) 16:30:21 nikhil, likely :) 16:31:07 * amrith mumbles something about main entry point being a comment :) 16:31:10 plus we still haven't settled on the types of drivers 16:31:41 right, work to be done 16:31:52 yep, there's lot to go forward on here! 16:31:58 nikhil, what do you mean about types of drivers? Should we take it offline? 16:32:05 i.e. this is the #oslo meeting 16:32:08 not the #quota meeting 16:32:11 ;) 16:32:13 amrith: yes, please 16:32:18 ok, 2pm today 16:32:42 ok, soooo let's re-connect in a couple of weeks on delimiter, i think that's sane thing to do 16:32:59 seem ok to folks? 16:33:20 +1 16:33:32 ++ 16:33:50 ok, fine. +=1 16:34:21 I am happy to reconnect wherever to get everyone on the same page 16:34:32 cool 16:35:14 #topic Stuck reviews/specs 16:35:27 any stuck reviews or specs that we can try to focus on for folks? 16:36:46 #link http://bit.ly/1oDpFQ5 (all oslo reviews) 16:36:59 specs @ https://review.openstack.org/#/q/project:openstack/oslo-specs 16:37:15 guess everyone getting everything reviewed then, nice :) 16:37:35 harlowja_at_home: what did I mess up https://review.openstack.org/#/c/314603/ 16:37:46 harlowja_at_home: it doesn't appear in the spec list 16:38:03 https://review.openstack.org/#/q/project:openstack/oslo-specs ? 16:38:04 harlowja_at_home: at least on that short url, that is 16:38:07 ah 16:38:14 maybe gotta update the short-url 16:38:31 ya, weird whats up with that 16:38:33 i blame gerrit 16:38:45 * kgiusti is good with that :) 16:39:38 i'll regenerate the short-link a little later, maybe something wonky with it 16:39:50 or ya, evil gerrit, lol 16:40:03 Just offhand - when is the feature freeze date for oslo.messaging features in newton? 16:40:06 harlowja_at_home, re specs, working around the context policy things, https://review.openstack.org/#/c/290907/ has been discussed. I think it's impact needs input from other projects 16:40:33 let's see here http://releases.openstack.org/newton/schedule.html 16:40:35 - Standardize Context Arguments spec, especially if projects abuse putting name values into id releated fields. 16:40:56 I have a q about this spec 16:41:08 Will this change the oslo.context object as it is today? 16:41:19 Trove currently uses it and sends it in an RPC message to guests. 16:41:29 if the object changes, that'd be bad for Trove. 16:41:32 kgiusti, i believe thats 'Aug 29-02' for this 16:42:04 harlowja_at_home: looks like it's going to be a busy summer.... 16:42:24 rbradfor, agreed, it'd nice if some liasons could look at 290907 (for those that use oslo.context) 16:42:40 rbradfor, harlowja_at_home ... question abotu that spec ^^ 16:42:52 amrith, well it's about providing a backwards compatible solution, (at least one full cycle), but moving from the N projects that subclass just to rename an attribute from the the context values 16:43:24 amrith, I'd like to hear of all problems, so we don't cause issues, such as with Trove 16:43:40 rbradfor, I will chat with you about this. 16:43:45 once I understand the spec better 16:43:48 thanks for the heads up 16:43:54 rbradfor, if u want me to send out a ML email, i'd be willing to as well 16:44:06 get people to start thinking about that ... 16:44:13 amrith, trove does none of the mess we are trying to improve on 16:44:17 (people that may not be here that is) 16:44:26 harlowja_at_home, ML will do. 16:44:29 rbradfor, give us time :) 16:44:35 rbradfor, don't challenge us :) 16:45:18 #topic Open discussion 16:45:20 amrith, it's just a spec, I wrote it over 2 months ago, and it will probably be a long time before enough people comment on it, so time is on your side 16:45:33 lol 16:45:37 ha 16:45:46 let me go buy a lottery ticket 16:45:55 time is on your side for those as well 16:46:24 but the odds sure as heck are not 16:46:28 ;) 16:46:40 kgiusti, that's true ... 16:47:12 anything else anyone wants to bring up? 16:47:19 rbradfor, when we gonna start that blog stuffs ;) 16:47:39 * dims runs and hides 16:47:40 harlowja_at_home, yeah, I keep dreading that question. 16:47:44 lol 16:47:55 I know it's important for Oslo and all 16:48:20 but I proposed a plan and made a schedule, so time to man up 16:48:43 i'd be up for trying at least 16:48:48 if it doesn't work out,that's ok 16:49:08 harlowja_at_home, let me dig up my half done kick of post and run it by you Wednesday 16:49:16 cool 16:49:31 harlowja_at_home, thanks for bringing up the topic 16:49:56 np, at least we can try, that's what matters to me 16:50:11 * harlowja_at_home needs to hire a ghost-writer, ha 16:50:44 you can't ghost write technical, e.g. code blocks. 16:51:04 hmmm, good point, lol 16:52:28 okie dokie, back to your regular scheduled programming in 3 16:52:31 2 16:52:38 1 16:52:47 thanks harlowja_at_home 16:52:51 np :) 16:53:03 #endmeeting