16:00:24 #startmeeting oslo 16:00:24 courtesy ping for GheRivero, amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dougwig, e0ne, flaper87, garyk, harlowja, haypo, 16:00:24 Meeting started Mon Feb 1 16:00:24 2016 UTC and is due to finish in 60 minutes. The chair is dims. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:25 courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, ozamiatin, redrobot, rpodolyaka, spamaps 16:00:26 courtesy ping for sergmelikyan, sreshetnyak, sileht, sreshetnyak, stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek, gcb 16:00:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:28 courtesy ping for dukhlov, lxsli, rbradfor, mikal, nakato, tcammann1 16:00:28 The meeting name has been set to 'oslo' 16:00:28 o/ 16:00:29 o/ 16:00:31 o/ 16:00:33 hi 16:00:34 o/ 16:00:36 sup 16:00:38 o/ 16:00:39 o/ 16:00:41 o/ 16:00:48 ./ 16:00:49 o/ 16:00:52 o/ 16:00:54 o/ 16:01:22 #topic welcome to new cores - rbradfor and lxsli for Oslo and dukhlov for Oslo-Messaging 16:01:30 yay! 16:01:33 hurray! join the fun 16:01:36 o/ 16:01:36 o/ 16:01:38 Woo, thank you all! 16:01:42 welcome!! 16:01:50 Welcome 16:01:53 thank you! 16:02:08 dims, thanks for including me in the Oslo team 16:03:04 welcome!!!! 16:03:08 rbradfor : hope you have as much fun as i do :) thanks goes to the team 16:03:16 lol 16:03:19 _o/ 16:03:35 #topic Red flags for/from liaisons 16:03:43 congrats rbradfor 16:03:44 nothing from trove at this time. 16:03:45 none for keystone that I know of 16:03:47 welcome rbradfor, lxsli and dukhlov 16:03:50 Nothing to report Octavia/LBaaS 16:03:54 congratulations to all new cores. 16:04:06 stevemar, gcb thanks, and thanks to all 16:04:14 johnsom, have u guys started using the new taskflow stuff? 16:04:23 Yes! 16:04:25 cool 16:04:36 Looking good so far 16:04:39 nice nice 16:04:43 [off-topic] FYI glance, designate & solum now work on python 3 16:04:52 haypo : great! 16:04:58 is python 4 out yet? 16:05:13 we'll get python 3 on keystone one of these days 16:05:24 harlowja_at_home: ... 16:05:33 lol 16:05:34 bknudson: when we get ldap support for py3 16:05:40 bknudson: tell me if i can help 16:05:55 stevemar: what? the ldap project was ported to py3, like 2 months ago 16:06:01 we need to switch off python-ldap to ldap3 16:06:05 #topic - python3 support :) 16:06:06 haypo: ^ 16:06:07 stevemar: https://github.com/pyldap/pyldap/ some colleagues work on it 16:06:22 now its' on topic 16:06:31 lol 16:06:39 haypo: what bknudson said, we have to actually switch over 16:06:41 bknudson: nope. my colleague told me that ldap3 lacks important features for FreeIPA 16:06:58 dims: to come back to Oslo, oslo.context has a bug fixed on the request_id attribute 16:07:13 dims: see https://review.openstack.org/#/c/274719/ for a release bumping major version to 2.0 ;-) 16:07:18 ok, maybe we can switch to pyldap rather than ldap3 16:07:30 stevemar: it's just a matter of replacing import lines, no? 16:07:37 stevemar: i'm talking about pyldap 16:07:51 stevemar: pyldap is a fork of python-ldap, no API change 16:07:58 haypo: oh nice 16:08:08 haypo: we were looking at ldap3 16:08:31 maybe i'll poke around it in the afternoon 16:08:34 stevemar: tell me if you need more precise information, i'm not in the FreeIPA at Red Hat 16:08:54 i'm just repeating what i heard 16:09:10 stevemar : bknudson : there's a #openstack-python3 irc channel as well to find like-minded folks later 16:09:14 rbradfor: congrats (i'm late) 16:09:30 #topic Releases for Mitaka 16:09:31 No scheduled releases for this week. Please file reviews in openstack/releases repo if/when you need something 16:09:31 dims: yeah, we should continue the discussion there, sorry for the noise 16:09:42 haypo : no worries, it's relevent 16:09:44 dims: https://review.openstack.org/#/c/274719/ oslo.context 2.0 16:09:57 dims: https://review.openstack.org/#/c/274726/ oslo.concurrency 3.4.0 16:10:00 haypo: cool, i'm reading the pyldap docs now i'll poke around later 16:10:01 i am expecting a review for oslo.messaging as well 16:10:14 haypo : ack will review them 16:10:17 dims: in progress 16:10:21 dims, and I'd like an included part of oslo.context 2.0 16:10:38 hi 16:10:58 rbradfor : check the list changes job in that oslo.context 2.0 review to see if the changes you need are in there 16:10:58 dims: i'd love a new oslo.config release :) 16:11:00 toabctl_ Hi 16:11:13 stevemar : push a releases repo request please? 16:11:17 dims: ack 16:11:24 dims, it is listed in oslo.context 2.0 16:11:31 rbradfor: which change do you need? 16:11:48 haypo, 22ad2c2 Define method for oslo.log context parameters 16:12:11 work on the app-agnostic-parameters blueprint which I need for work in oslo.log 16:12:29 rbradfor: https://review.openstack.org/#/c/274186/ hum ok 16:12:34 rbradfor : haypo : looks like we need a requirements bump too 16:12:41 haypo, yes 16:12:44 dims: for what? 16:12:53 oslo.context 2.0 16:13:11 bump the upper-constraints.txt? 16:13:31 if rbradfor needs something in that for oslo.log, we should raise the minimum in global-requiremenst.txt too 16:13:35 dims: it can be done later, no? what needs olso.context 2.0? 16:14:00 haypo : the release process calls for having the requirements patch filed before the release is done to ensure that it is available to merge shortly after the relase 16:14:04 sorry global-requirements... +1 to dhellmann's coment 16:14:21 haypo : http://docs.openstack.org/releases/instructions.html#requesting-a-release 16:15:06 dhellmann: "to ensure the new release is tested in the gate" ah ok, now i understand :) 16:15:16 dims: did both the release and the requirements patch 16:15:17 sorry, i'm still tired of my long week-end at FOSDEM ;) 16:15:31 stevemar : thanks! 16:15:44 haypo : np, that's why we have the review process in place :-) 16:17:32 #topic Encourage PTL candidates for Newton 16:17:32 Folks, Thanks for all the help and encouragement during my PTL stint. I'd like someone else to take over. If folks are interested, i can show the ropes over the next few weeks before the PTL elections. Please ping me. 16:18:20 uh oh 16:18:27 for he was a jolly good fellow 16:18:32 and no one shall deny 16:18:39 LOL harlowja_at_home 16:18:42 here here! 16:18:43 he still is a jolly good fellow 16:18:52 lol 16:19:00 *for he is a jolly good fellow 16:19:06 #topic Open discussion 16:19:06 Any other stuck reviews? 16:19:12 before this gets out of hand :) 16:19:16 ha 16:19:51 So there was a thread about -2's in oslo project 16:20:29 ya, about that 16:20:45 i'd like folks to revisit that thread - 16:20:49 #link http://markmail.org/message/xcenlg4lrgjoyfiy 16:21:00 to see if we can do something better 16:21:05 harlowja_at_home Just another thanks for that taskflow patch. It really makes a difference in our code. 16:21:22 it'd be nice if a person that posts a -2 that it would initiate a phone call with the person that makes the code, lol 16:21:23 if someone asks you to remove a -2 then remove it... that's what I do. 16:21:26 johnsom, np 16:21:39 It will make more when I get around to cleaning up the old hacks 16:21:44 sometimes I don't have a lot of time to do a new review 16:22:02 :) 16:22:22 bknudson : +1 16:22:38 the person who started that thread was involved in 2 patches with -2 in a short time, which is not just unusually high for an individual it's unusually high for oslo I think 16:23:03 I'm not sure I want to call it a fluke, but it doesn't seem like we have a persistent ongoing issue, either 16:23:08 dhellmann : agree. 16:23:32 it looks like oslo.versionedobjects is somehow different, because it linked to nova 16:23:33 so it's unfortunate, but I stand by my -2 on the utc time logging change 16:23:37 and nova is more conservative, no? 16:23:41 yeah 16:23:45 it seemed inappropriate this was not started in a separate ML thread. 16:23:46 an idea, if a -2 gets added, we could try to have the policy be that said -2 being done automatically requires a ML email 16:23:47 the -2 also shows a lack of trust of other core reviewers. 16:23:52 dhellmann : am with you on that 16:24:01 a ML email either by the code reviewer or the code creator 16:24:06 if you don't trust cores to not merge something when you -1 then we have another problem. 16:24:13 haypo: and I think it's reasonable for us to be saying in general "prove there's utility in that feature by running it in your app" for a time 16:24:27 how about when we -2, we tell them to bring it to the next weekly oslo meeting? 16:24:29 haypo : esp. in vo, where it's easy to add a type class locally 16:24:35 so at least they know what to do 16:24:36 so a suggestion is if anybody gives a -2 they ask for a ML discussion to be started. 16:24:39 dims, that seems fair also 16:24:40 dims : that's a good procedural tweak, sure 16:24:51 rbradfor, ya, either that or we talk about -2 here 16:24:53 either ML or meeting 16:24:54 dims and bring to oslo meeting 16:24:57 rbradfor: good idea 16:25:13 dhellmann, I think both 16:25:21 cool. guess part of the frustration was not knowing what to do next 16:25:22 so this will help 16:25:27 the ML enables inputs, the meeting should be to finalize any decisions 16:25:29 sorry, i didn't have time to read the thread. but maybe the problem is the messaging explaining the -2 vote? we should write a template :) 16:25:41 we are very good at templates :-P 16:25:43 for example, "-2 your code sucks" is not good :) 16:26:05 haypo : I will admit that I assumed the submitter knew what to do next, and didn't explicitly ask. I'll be more careful about that in the future. 16:26:20 "-2 you code sucks, because ... try maybe ... or come to the ML or oslo meeting to discuss" is maybe beetter :-D 16:26:37 dhellmann : y not sure if they knew 16:26:39 i understand that it can be *very* frustrating to get a -2 16:26:52 i always hate getting -2 (yeah, it occurred me, like multiple times!) 16:26:52 another one... 16:27:01 haypo, ya, something like that template seems ok 16:27:06 o/ 16:27:07 Another observation was in the thread for Alexis' nomination 16:27:12 #link http://markmail.org/message/i5hfaknvpgxyhvrg 16:27:17 harlowja_at_home: or maybe just a link to a wiki page, somewhere 16:27:25 haypo, possibly 16:27:31 we as a team would like to welcome both specialists and generalists 16:27:52 and get people to grow their expertise 16:27:53 to be more positive, rather than "your code sucks" I really liked sdague who said elsewhere "violates the principle of least surprise?" 16:27:56 dims, haypo also started a whole new thread on that 16:28:12 we've done a great job at shepherding all the technical debt from oslo-incubator days 16:28:18 ++ 16:28:27 dims: i'm in favor of trusting people, see my "It's better to ask forgiveness than permission" thread :) 16:28:30 I was concerned when somebody +2d a change in oslo.policy that I didn't think keystone would agree with... needed more discussion 16:28:45 #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/085467.html 16:28:54 if we are welcoming newcomers, it's more likely that they start to look at other oslo projects, not only the one they started to hack 16:29:06 bknudson : let's bring instances like that to be more visible. would that work? 16:29:29 i'm proud of being part of oslo, but i also feel guilty if it don't review enough changes :) 16:29:39 more powers means more responsabilities :) 16:29:47 dims: yes. I don't want to make a big deal out of it. 16:29:48 oslo.policy and oslo.versionedobjects need to be looked at by keystone folks and nova folks respectively 16:30:22 for sure 16:30:25 bknudson : ack 16:30:25 (although i'd still like to figure out how to avoid nova having downstream patch-like-things in ovo) 16:30:37 but i gotta investigate that one more 16:30:52 harlowja_at_home +1 16:31:12 i can also understand that other projects like nova have motivation to be more conservative, but being conservative has serious side effect (technical debt) 16:31:14 maybe ovo needs experimental features, idk 16:31:27 at least, i want oslo to remain as open as possible :) 16:31:33 o.vo is a really special case because a breaking patch there ruins everything so badly 16:31:38 haypo : +1000 16:31:49 dims: they are plan to use oslo.versionedobjects in other proejcts, no? 16:31:54 lxsli_web : that applies to a lot of the oslo libs :-/ 16:31:56 dims: i don't recall which ones :-/ cinder? 16:31:57 lxsli_web : right, so good test matrix 16:32:08 dhellmann : well said :) 16:32:09 haypo, ironic, cinder, nova i thnk 16:32:13 also because it's more growing out of nova than being separately developed, hence the up/downstream relationship 16:32:28 haypo: Yes, Cinder is working hard to move to ovo . 16:32:28 harlowja_at_home: ah cool. are you aware of any concrete progress on these projects? 16:32:35 haypo, unsure 16:32:36 jungleboyj: cool :) 16:32:43 dhellmann: fair point 16:32:44 jungleboyj: thanks for the confirmation ;) 16:32:46 dansmith : around? (just in case :) 16:32:59 haypo: We have a bunch of patches that dulko has been working on and we just agreed in the meetup to work to get them in. 16:33:05 lxsli_web, perhaps ovo has a ovo.experimental module, idk 16:33:10 dims: only barely.. running a meeting at the moment 16:33:26 lxsli_web: my point is that it's ok to break the world 16:33:32 dansmith : no worries. just making sure you know we are raising the concerns :) 16:33:34 lxsli_web: shit happens, it's part of the development process 16:33:46 lxsli_web: working hard to avoid shit is pointless 16:33:59 harlowja_at_home: the way rlrossit explained it, the "experimental" features are already in Nova, he's just tweaking them slightly before porting to o.vo 16:33:59 dims: thanks, I'll read the scrollback here when I'm done :) 16:33:59 lxsli_web: it's better to be reactive when bugs are noticed 16:34:10 haypo : it's ok to have accidents. it's not ok to willfully break things. 16:34:12 harlowja_at_home: so an ovo.experimental would just clutter the process 16:34:16 lxsli_web: (well, i'm not asking to remove all tests :-)) 16:34:17 haypo: breaking the world let's you figure out exactly how things break! 16:34:25 lxsli_web, fair enough 16:34:34 dhellmann: "willfully break things" nobody said that 16:34:34 haypo: there's a fine line between "move fast" and being careless :) 16:34:43 haypo : right, the idea is to make sure specialists get first preference at some of the project reviews 16:34:51 haypo : 'working hard to avoid shit is pointless'? 16:35:11 dhellmann: hum ok. i picked the wrong words :) 16:35:16 lol 16:35:41 haypo : :-) 16:35:49 haypo :) i know translation and then typing quickly at irc meeting is hard 16:36:03 dhellmann: i mean that we should not deny people to contribute just because of a theoric risk of regressions. there is a grey arreay in code reviews and development 16:36:44 dhellmann: for the grey area, i prefer to trust people and having more core reviewers able to fix issues quickly 16:36:46 haypo : ok, I can agree with that. We should still be reviewing for potential issues, but dealing with them when they get through 16:36:55 dhellmann: rather than letting reviews rotten for months 16:37:00 haypo : so we continue what we have done recruiting both folks specific to projects and oslo cores as appropriate i think 16:37:05 Trust has been given, it's now up to rbradfor + me to be careful and ask for help when needed 16:37:12 lxsli_web : +1 16:37:21 dhellmann: the thread started by a vote to welcome a new core reviewer 16:37:21 group hug 16:37:22 lxsli_web : +100 16:37:29 :) 16:37:56 speaking as a newcomer I'm only really comfortable in about 3 oslo projects, I look and comment in reviews in about 3 more, and while I look into other projects, I'm only observing, certainly not voting. 16:38:08 lxsli_web: in my experience, new (core) contributors are too afraid to make mistake, so the problem doesn't exist :) 16:38:20 until I become more comfortable. 16:38:23 lxsli_web: if you break the world, it's because we failed to be good mentors 16:38:25 right rbradfor 16:38:27 rbradfor : that's ideal 16:38:34 in python, we have a mentoring process for new core developers 16:38:45 the mentor is responsible to watch changes made new core developers 16:39:14 but also help to handle practical things, to reply to simple questions if the contributor is too shy to ask in public 16:39:20 * rbradfor goes to comment on a review and now I see +2 for the first time, it's a bit too close to the +1. 16:39:41 haypo : y, here the major question was if Nova folks were uncomfortable with size of oslo core since there's a possiblity that "bad" reviews may get in 16:39:48 rbradfor: FYI i prefer to restrict myself to +1 (no +2) for some oslo projects 16:40:04 haypo, I agree 16:40:04 haypo: +1 :) 16:40:07 haypo : good tip at least for starters 16:40:17 dims: is the risk theorical? or is it common that oslo break the [nova] world? 16:40:31 if you don't understand the change, don't +2... this means some reviews are going to sit around for months since nobody understands it. (probably due to the code or commit message) 16:40:46 haypo : it used to be far more common than it is, but it's still quite easy 16:40:48 dims: and if oslo break things, is it possible to detect these issues earlier? 16:40:51 we don't have any code that's so complicated a reasonably skilled reviewer can't figure it out. 16:40:52 haypo : we have been good at not breaking Nova or the core project masters. stable is a whole another story 16:40:52 bknudson: you have to know a lot to know that you don't know, in a lot of cases 16:41:15 dhellmann: in my experience, it's really hard to predict during a code review that a change will break a random openstack project 16:41:16 bknudson: but by increasing core team size, hopefully someone will comment and ask for clarity 16:41:34 dhellmann: sometimes, even "experts" need several hours to investigate a regression 16:41:51 dhellmann: that's what i'm calling the "grey area" 16:42:03 dansmith : "you have to know a lot to know that you don't know, in a lot of cases" :) 16:42:12 haypo : I agree, it's hard 16:42:14 dims, a suggestion to point threads to in the future, lets expand "Generalist Core reviewers" in https://wiki.openstack.org/wiki/Oslo#Generalist_Code_Reviewers, we could even create a table for "core reviews primary projects", especially for newer cores. 16:42:22 and even then u get old, and admit u don't know alot 16:42:22 lol 16:42:33 15min warning 16:42:40 dhellmann: IMHO we made huge progress on testing oslo changes on other projects (as dims said, especially on nova) last 12 months 16:42:56 haypo : oh, definitely, the work dims has done on that is superb 16:43:13 dhellmann: dims has a travis job, we added more tests on requirements updates 16:43:16 etc. 16:43:22 rbradfor : i'll let you all self-organize :) 16:43:25 yep, all of that is really helpful 16:43:50 dims, I'll take on expanding the public wiki. 16:43:51 haypo : dhellmann : my next step is to figure out how to get the stuff out from travis into regular CI 16:44:14 rbradfor : ack thanks 16:44:21 dims: oh, huge project, no? 16:44:30 dims: you should ask help to the infra team 16:44:31 dims : it would be interesting to see if we could set up some jobs to run for release requests of oslo things 16:44:44 rbradfor, http://truben.no/table/ has a nice GUI table generator that i think u can use to make the wiki markdown 16:44:46 dhellmann : right 16:45:02 (vs having to create it manually) 16:45:14 as usual, many people complain of oslo regressions, but nobody is volunteer to work on more tests or help on code review ;-) 16:45:15 dims : you'd have everything you need to set up libs from source 16:45:18 harlowja_at_home, thanks. 16:45:31 (i'm talking about people *consuming* Oslo) 16:45:32 dhellmann : true 16:45:44 dims : anyway, just thinking out loud 16:46:12 dims, dhellmann : maybe we need to discuss all of this by email, to include the whole OpenStack community 16:46:13 haypo : before the oslo regressions, i'd ask for gate failure volunteers, that's even more critical. 16:46:19 it's wider than this short meeting, no? 16:47:12 (ok, and also, i have to go :-)) 16:47:30 dims: sorry, what is a "gate failure volunteer"? 16:47:36 haypo : feel free to start appropriate threads. i just wanted to get a sense here if we are all on the same page and appropriate heads up for some specific projects with concerns 16:48:45 haypo : let's talk about that after the meeting, it's mostly diagnosing quickly when things go wrong in the zuul gate 16:49:06 so anyone else have things to discuss? 16:49:25 dims, I should mention I've picked up the older app-agnostic-parameters spec and will be working on pre-requisites in a number of TC projects to cleanup oslo.log usage 16:49:40 rbradfor : sounds good! thanks 16:50:03 dims, I see it as pre-requisite for other things discussed at tokyo. 16:50:04 wrapping up for today then. thanks everyone. 16:50:11 thanks 16:50:12 np 16:50:21 #endmeeting