Thursday, 2020-04-30

*** diablo_rojo has quit IRC00:08
*** ijolliffe has quit IRC01:56
*** evrardjp has quit IRC04:35
*** evrardjp has joined #openstack-tc04:36
*** tetsuro has joined #openstack-tc05:29
*** dklyle has quit IRC05:57
*** zaneb has quit IRC06:37
*** zaneb has joined #openstack-tc06:37
*** e0ne has joined #openstack-tc06:51
*** e0ne has quit IRC06:57
*** slaweq has joined #openstack-tc06:58
*** e0ne has joined #openstack-tc06:58
*** belmoreira has joined #openstack-tc06:58
*** iurygregory has joined #openstack-tc06:58
*** e0ne has quit IRC07:05
*** tosky has joined #openstack-tc07:28
*** rpittau|afk is now known as rpittau07:29
*** e0ne has joined #openstack-tc07:34
*** e0ne has quit IRC07:36
*** e0ne has joined #openstack-tc09:31
openstackgerritRodolfo Alonso Hernandez proposed openstack/governance master: Migrate from olso.rootwrap to oslo.privsep  https://review.opendev.org/71817709:34
*** jaosorior has quit IRC10:17
*** rpittau is now known as rpittau|bbl10:21
*** tetsuro has quit IRC11:12
*** tkajinam has quit IRC12:09
*** rpittau|bbl is now known as rpittau12:22
*** ijolliffe has joined #openstack-tc12:33
*** lpetrut has joined #openstack-tc12:34
*** slaweq has quit IRC12:35
*** slaweq has joined #openstack-tc12:36
*** slaweq_ has joined #openstack-tc12:38
*** slaweq has quit IRC12:41
*** ijolliffe has quit IRC12:41
*** ijolliffe has joined #openstack-tc12:42
*** lpetrut has quit IRC13:14
*** njohnston_ is now known as njohnston13:21
knikollao/14:10
*** lpetrut has joined #openstack-tc14:13
*** tkajinam has joined #openstack-tc14:16
gmanno/14:29
*** ricolin has quit IRC14:37
*** lpetrut has quit IRC14:46
*** dklyle has joined #openstack-tc14:49
*** ricolin has joined #openstack-tc15:01
ricolino/15:02
njohnstono/15:03
*** slaweq_ is now known as slaweq15:03
gmanntc-members: if we have majority, can we discuss on community goal for V cycle.15:04
zanebhi everyone15:05
knikollahi :)15:05
gmannzaneb: hello15:06
evrardjp o/15:10
evrardjphi zaneb!15:11
gmannas you might have seen this ML on V cycle goal:  http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014497.html15:12
gmannand ussuri final release is not so far, we need to finalize the goal so that projects can start planning.15:13
gmannnjohnston and I discussed about deadline for that one option is May 15th ussuri final release15:14
njohnstonI wonder if that might be later than preferable for some projects15:15
gmanndeadline means, freeze the goal selection for V (either one or two) and avoid any late entry which caused issue since last couple of cycles.15:15
gmannnjohnston: good point, early is also good.15:16
njohnstonWhat would you think about putting the deadline at the final RC deadline, R-1?  It's not much but we're already close to release.15:17
*** ricolin has quit IRC15:17
gmann+1.15:17
gmannanther point is about contributor guide U cycle goal where few projects started/completed and lot of projects still need to do- http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014514.html15:18
gmannfor them it will contributor goal  + V cycle goals in V cycle which i think overload for them.15:19
knikollathat is a lot of projects15:19
gmannmy idea is to continue the contributor goal in V cycle also and keep zuulv3 as additional goal for V. no other goal for V cycle.15:20
gmanndiablo_rojo_phon: can input on that idea as goal champion.15:20
gmannthoughts ?15:23
njohnstonI wonder about the mock goal, if that is something that is likely to be a simple forklift or if there is likely to be some of dev work involved15:25
njohnstonthat is https://review.opendev.org/#/c/722924/15:25
gmannnjohnston: yeah that is not so hard but contributor goal was even much easy but many projects might not have bandwidth to do all three in V cycle.15:26
knikollagmann: Contributor goal required actually sitting down and writing words15:26
jungleboyjo/15:27
knikollabased on https://review.opendev.org/#/q/topic:unittest.mock+(status:open+OR+status:merged) it seems the mock goal is scriptable15:27
jungleboyjSorry for being late.  Got distracted by the family.15:27
njohnstonwith the mock, if it can be scripted and changes autogenerated then it's a +2+W15:27
gmannnjohnston: knikolla that will be great.15:29
knikollajungleboyj: that is the best reason for being late to anything :)15:30
jungleboyj:-)  Agreed.15:30
jungleboyjThey are usually low bandwidth but they have their days.  :-)15:31
evrardjpsorry I am catching up15:31
evrardjpfor selection everything is ready, right? So I suppose it can be as late as release, but the sooner the better ofc15:32
evrardjp(because proposal would have ironed out things)15:32
evrardjpor did I get that wrong?15:32
evrardjpI agree with gmann on the fact that we shouldn't require too many goals to avoid some to be not done due to lack of bandwidth15:33
gmannevrardjp: i will not say ready as none is merged in proposed dir yet.15:33
jungleboyjevrardjp: ++15:33
evrardjpI don't disagree there, I meant as a general truth15:33
gmannyeah, mock one is very close.15:34
evrardjp"for goal selection, I suppose preliminary work has been done" -> better wording15:34
jungleboyjI am ok with continuing the contributor guide one into V.15:34
gmannevrardjp: yeah that's correct.15:34
jungleboyjI think the Mock one is also ok to do given that it doesn't look like it will require a lot of work for the projects.15:34
evrardjpso IMO, goals that weren't finished need to be closed, and the project should be listed15:35
evrardjpsorry15:35
evrardjpI meant15:35
gmanntrue but asking review is also one big things. for py2 where projects need to just review but could not on time15:35
evrardjpevery project which hasn't finished the goal should be listed.15:35
evrardjpwasn't community goals a "golden signal" ?15:36
gmannthat is one option.15:36
evrardjpit doesn't mean the project cannot continue it, and finish it15:36
evrardjpto come back to the goals themselves, I personally like the Mock one, because I see that it's reducing tech debt15:37
evrardjpeasily15:37
evrardjpwith no cost for end users15:37
evrardjpbut sadly it doesn't bring value to end users :p15:38
evrardjpsame applies to the zuul legacy jobs15:38
jungleboyjTrue.15:39
evrardjpso if we only have those two, it doesn't show much value to our end users15:39
gmannyeah we do not have user benefits goal for V15:39
gmann zuulv3 goal is not easy for many projects. it is lengthy and complex.15:39
evrardjpI think this has priority over anything else in tech debt15:39
evrardjpIMO15:39
gmanntrue. maintaining legacy jobs and devstack-gate is becoming hard day by day15:40
evrardjp(I don't consider the client to be tech debt for this case, though it technically most likely is)15:40
evrardjpalso it's already approved, so no going back! :p15:40
gmannwhat I am thinking more is we provide the goal as per projects bandwidth in current situation.15:40
evrardjpisn't everyone's bandwidth in net negative?15:41
gmannhave something which can be completed has value.15:41
evrardjptotally15:41
evrardjpso what's your proposal gmann? Decide here what of the other options should be prioritized?15:42
gmannok15:42
evrardjpI am merely asking, "ok" leaves me puzzled15:42
gmannoption1. continue the contributor goal in V cycle as second goal for V cycle15:42
gmannoption2: mark contributor goal as close and let project finish on their own time and select one more goal along with zuulv3.15:43
gmannevrardjp: ok was for giving proposals :)15:44
evrardjpyeah I got it afterwards :D15:44
fungioption 2 is reasonable, we always said don't expect 100% completion for any cycle goal anyway15:44
evrardjpI vote for option2 myself15:44
jungleboyjI think option 2 is fine.15:45
smcginnisFWIW, I will be trying to remove mock whether it is a community goal or not. That could give it some extra needed priority, but it is something we should get done eventually whether or not it is an official cycle goal.15:46
njohnstonoption 2++15:46
gmannsmcginnis +1 thanks. IMO goal give good advantage of getting review attention though everyone agree on changes.15:47
evrardjpsmcginnis: thanks15:47
njohnstonsmcginnis: thanks!15:47
jungleboyjsmcginnis:  Good input.15:47
evrardjpfor me that sounds like a community goal that we are certain winning! :D15:47
gmannok, let's go with option2.15:47
evrardjpwith smcginnis with us, it's impossible to lose!15:47
smcginnisIt should be an easy win.15:47
evrardjpI will help you if you like. For my weekend15:48
evrardjpweekends*15:48
evrardjpwoops, it was sent in the wrong chan15:48
evrardjpI never said that in here!15:48
gmannevrardjp: you said no weekends work to me many times :)15:48
gmannhehe15:48
fungitoo late, now the tc will expect you to help on weekends15:48
evrardjpdarn it15:49
*** belmoreira has quit IRC15:49
evrardjpyeah so I don't commit on this!15:49
njohnstonlol15:49
gmannok, in option2, mock goal is very close, https://review.opendev.org/#/c/722924/ compare to rootwrap -https://review.opendev.org/#/c/718177/615:49
gmannand also applicable to merge also.15:50
jungleboyjOption 2 sounds good to me and you can't lose with smcginnis  helping.  ;-)15:51
smcginnisHah15:51
smcginnisI would actually vote for rootwrap over mock if it was down to the two.15:51
jungleboyjUnless he gets over zealous and just deletes everything.15:51
jungleboyjsmcginnis:  ++15:51
gmannso that can be merged on 4th May monday.15:51
evrardjpI would prefer voting rootwrap15:51
smcginnisGetting rid of rootwrap is actually a security win for our users.15:51
jungleboyjThat is going to be a heavier lift.15:51
evrardjpexactly15:51
smcginnisjungleboyj: That is true.15:51
njohnstonI am skeptical that we will have bandwidth for rootwrap at the same time as zuulv315:52
gmannrootwrap is not doubt good for sec things but we are lacking vote on that.15:52
njohnstonit is the most developer-intense goal here15:52
evrardjpnjohnston: less than the clients15:52
evrardjpisn't it?15:52
njohnstonI don't see a goal proposal for the clients yet.  While Artem is still interested I am not counting my chickens until they katch, as they say.15:53
fungithe zuulv3 goal is increasingly urgent, as the infra folks have effectively washed their hands of all the old legacy glue and far too many teams now consist of people who inherited jobs written by their predecessors and don't even begin to understand how they work15:53
gmannnjohnston: evrardjp yeah, osc is still not proposed so cannot say anything on that15:54
toskyuh15:54
toskyfungi: isn't it approved already?15:54
gmannand 3rd party CI are even more difficult to debug for legacy jobs15:54
fungitosky: if memory serves it was pre-approved for victoria, so basically yes15:55
gmanntosky: it is, we are not changing that just discussing what else we can fit along with that15:55
toskyoh, ok, sorry15:55
gmannfungi: yeah it is selected also for V15:55
gmannhttps://governance.openstack.org/tc/goals/selected/victoria/index.html15:55
fungiperfect15:55
evrardjptosky: it is selected already don't worry15:56
evrardjpsorry for the scare :p15:56
evrardjpnjohnston: are you the only one skeptical over the bandwidth issue of both zuul+privsep?15:57
gmannlet's review and vote both mock and rootwrap and get them merged in proposed dir. and in next office hour or early we can have discussion for Selection part.15:57
knikolla++15:57
evrardjpwell, before that: Is privsep real clear now?15:57
jungleboyjThat sounds reasonable.15:57
gmannevrardjp: i think so. or you mean in term of bandwidth ?15:58
evrardjpin terms of bandwidth15:58
evrardjpin terms of total bandwidth15:58
evrardjpfor the whole openstack15:58
evrardjpbecause these are major projects15:59
njohnstonevrardjp: I don't know if anyone else has doubts.  I think ralonsoh is envisioning the rootwrap goal to be multi-cycle so that may ameliorate the bandwidth concern.15:59
evrardjpand I am now super afraid of what njohnston said, and have an approximatively done thing15:59
evrardjpif it's considered as a multi-cycle thing, that's fine, but how can we measure completion at the end of this cycle?16:00
gmannmulti cycle goal is also not bad idea that is what we might do for OSC16:00
evrardjpI meant next16:00
evrardjpgmann: I have been claiming that we shouldn't have cycle goals but have a roadmap instead16:00
evrardjpmany people shouted at me, so i never followed that road16:01
gmannevrardjp: well we have not done any multi cycle yet but i think dividing the projects can be one way16:01
gmannfor example, projects have less work to do for zuulv3 can be target for rootwrap this cycle16:02
njohnstonevrardjp: The completion criteria per project and overall are both laid out in the "Completion Criteria" section of https://review.opendev.org/#/c/718177/6/goals/proposed/migrate-to-privsep.rst16:02
evrardjpnjohnston: I saw that part :)16:03
gmanntrue, roadmap framework is something we need to preapre for multi cycle things16:03
evrardjpgmann: I like this16:03
jungleboyjI think we are at the point that we are going to have to start considering multi-cycle items.16:03
evrardjpyeah but we need check points16:03
jungleboyjOr doing a Roadmap.16:03
gmannyeah16:03
njohnstonI imagine a multi-cycle goal's process to be like this: start goal, ask all projects to start.  Some complete the work, others don't.  Next cycle, the list of projects is narrower, and the champion can perhaps take a more hands-on role with the smaller number of projects to help bump them over the line.16:03
evrardjpthat was where the problem happened in the past16:03
evrardjpnjohnston: so it means the champion has to deal with a yearly effort16:04
evrardjpthat's a big thing16:04
njohnstonor the goal might change champions, that has to be a possibility we accept16:04
evrardjpeven if champion transfers, it's still quite a big investment16:04
njohnstonchampion fatigue16:04
evrardjpyeah, which is why I think we need to be very clear in the multi-cycle thing. I would love to have this established, as some kind of roadmap, but sadly I am not sure we can solve that (or that we should solve that) right now16:05
evrardjpso what's the tl;dr: for today ?16:06
njohnstonI'm really not sure16:06
evrardjpoption2: and zuul + privsep + mock ?16:06
evrardjpand let's see what happens?16:06
evrardjpwith a priority in that order?16:06
gmannok, let's prepare something on multi cycle in V cycle and then do.16:06
jungleboyjSounds like a good plan.16:06
evrardjpyeah we can probably accept those proposed goals, and select them in a "single cycle" or "multi cycle" fashion if necessary16:07
njohnstonI think your priority list is good: zuul, then privsep, then mock16:07
jungleboyjDo we know how many projects have at least started the privsep work.  I know that Cinder had gotten through part of it.16:07
fungigmann: evrardjp: the python 3 removal was a multi-cycle goal, we just split it into smaller goals each of which was hopefully achievable in a cycle. there was also a roadmap of sorts tying those goals together over time16:07
*** rpittau is now known as rpittau|afk16:07
evrardjpif we could also reduce the overhead of this "community goals" at the same time when moving to multi cycle, that would be lovely.16:07
evrardjpNo need for more red tape16:07
njohnstonneutron started it as well, this comes a lot from our experience with it16:07
jungleboyjOk.  And I think Nova started as well.16:08
evrardjpfungi: correct, but that easier targettable, here I think it's just that the minimum chunk is too big? Or did I get that wrong?16:08
evrardjpI don't want the TC to put too much red tape on community goals tbh16:08
fungii'm not convinced it can't be split into more manageable chunks16:08
evrardjpoh that's an interesting case :)16:09
evrardjpcare to explain?16:09
evrardjpbecause that means that it can be affordable chunks per cycle16:09
fungiset a target like have at least 50% of your outstanding rootwrap entries replaced by the end of victoria16:10
fungithe problem with a multi-cycle goal which only has one target is that it will effectively become a single-cycle goal for the final cycle because most teams will procrastinate if there's no nearer-term goal to meet16:11
njohnstonwhat if we merge the rootwrap proposal into goals/proposed/ and then ask ralonsoh to iterate on it with multi-cycle milestones16:11
fungiso calling it a multi-cycle goal is little more than saying you're giving them a heads-up that it's a goal for a later cycle16:12
njohnstonthat is a very good point, fungi16:12
njohnstonFor your voting convenience: the rootwrap->privsep proposal is https://review.opendev.org/718177 and the mock->unittest.mock proposal is https://review.opendev.org/72292416:16
gmannyeah, let's vote and then we can discuss on them for multi-cycle or which one to go for V cycle. in next Thursday office hour ?16:17
gmannor meeting if that is early but not sure when that is16:17
njohnston+116:17
*** tkajinam has quit IRC16:34
*** evrardjp has quit IRC16:35
*** evrardjp has joined #openstack-tc16:36
*** abhishekk is now known as abhishekk|away17:04
*** diablo_rojo has joined #openstack-tc18:00
*** AJaeger has left #openstack-tc18:04
*** cloudnull2 has joined #openstack-tc19:37
*** cloudnull has quit IRC19:38
*** cloudnull2 is now known as cloudnull19:38
*** slaweq has quit IRC19:57
*** slaweq has joined #openstack-tc19:58
*** slaweq has quit IRC20:29
*** e0ne has quit IRC20:44
*** e0ne has joined #openstack-tc20:45
*** cgoncalves has quit IRC20:53
*** Jeffrey4l has quit IRC20:53
*** openstackgerrit has quit IRC20:53
*** Jeffrey4l has joined #openstack-tc20:53
*** cgoncalves has joined #openstack-tc20:55
*** e0ne has quit IRC21:00
*** smcginnis has quit IRC21:06
*** smcginnis has joined #openstack-tc21:07
*** ijolliffe has quit IRC21:45
*** tkajinam has joined #openstack-tc22:46
*** tosky has quit IRC23:11
*** tkajinam has quit IRC23:43
*** tkajinam has joined #openstack-tc23:43

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!