Thursday, 2019-03-07

*** tosky has quit IRC00:06
dhellmannmriedem : is it possible to close a story without closing its tasks?00:59
clarkbdhellmann: no the story will show up in queries for open stories until all tasks are closed01:03
clarkbprometheanfire has requested that this be modified so that the story doesn't show active for projects where all the tasks for that project are closed01:04
*** whoami-rajat has joined #openstack-tc01:07
*** lbragstad has quit IRC01:09
mriedemdhellmann: i wondered about that too, but wasn't sure how to word 'close the story and any open tasks' without going into...what should you say about the tasks that weren't completed01:32
smcginnisIt probably makes sense to keep things open so it's apparent there is still work that should be done for that effort.01:32
mriedemwell, from my pov, i won't be tracking the story in train if these straggling projects actually do merge their change to close their task01:34
mriedemone option is just removing the incomplete tasks...01:35
smcginnisYeah, not saying the champions should do any more past the cycle.01:35
gmannor  other option is to say "Close the original story with all tasks closed and move open tasks under new story which stay open with projects as an owner"01:35
gmannchampions should not own those story for non-complete projects01:36
fungidhellmann: clarkb: to clarify, the general "state" of a story is inferred (and calculated on the fly) from the state of all its tasks. what we're looking at altering is the project-specific and project-group-specific story list views to filter that story state calculation so it's only based on the states of tasks for projects relevant to that particular view01:46
fungithat comes closer to how launchpad's project-filtered bug lists worked since they showed you a heuristic inference of that project's collective bugtask states (across all series for that project which had a bugtask)01:49
mriedemi replied on the change with some suggested wording01:50
mriedemand now it's time for me to eat ice cream on the couch and conclue the original stargate from the 90s with my 7 year old01:50
mriedem*conclude01:50
mriedemspoiler: they smoked cigarettes in movies in the 90s01:50
*** mriedem is now known as mriedem_afk01:51
*** mriedem_afk has quit IRC01:59
*** jamesmcarthur has joined #openstack-tc02:01
*** jamesmcarthur has quit IRC02:08
*** jamesmcarthur has joined #openstack-tc02:08
*** jamesmcarthur has quit IRC02:17
*** jamesmcarthur has joined #openstack-tc02:24
*** marst has quit IRC02:35
*** jamesmcarthur has quit IRC02:38
*** lbragstad has joined #openstack-tc03:11
*** marst has joined #openstack-tc03:18
*** dtruong has quit IRC03:21
*** ricolin has joined #openstack-tc03:48
*** dtruong has joined #openstack-tc04:03
*** marst has quit IRC04:06
*** penick has quit IRC04:26
*** scas has quit IRC04:26
*** dtruong has quit IRC04:45
*** penick has joined #openstack-tc04:53
*** scas has joined #openstack-tc04:53
*** ricolin_ has joined #openstack-tc05:07
*** ricolin has quit IRC05:09
*** lbragstad has quit IRC05:33
*** Bhujay has joined #openstack-tc05:34
*** marst has joined #openstack-tc05:39
*** marst has quit IRC06:03
*** marst has joined #openstack-tc06:05
*** ricolin_ has quit IRC06:09
*** ricolin has joined #openstack-tc06:09
*** marst has quit IRC06:10
*** zbr has joined #openstack-tc06:14
*** zbr|ssbarnea has quit IRC06:15
*** e0ne has joined #openstack-tc06:32
*** lxkong has quit IRC06:52
*** Luzi has joined #openstack-tc06:54
*** Bhujay has quit IRC07:08
*** Bhujay has joined #openstack-tc07:09
*** Bhujay has quit IRC07:10
*** Bhujay has joined #openstack-tc07:10
*** Bhujay has quit IRC07:11
*** Bhujay has joined #openstack-tc07:12
*** Bhujay has quit IRC07:13
*** Bhujay has joined #openstack-tc07:13
*** Bhujay has quit IRC07:14
*** Bhujay has joined #openstack-tc07:15
*** Bhujay has quit IRC07:16
*** Bhujay has joined #openstack-tc07:16
*** e0ne has quit IRC07:17
*** Bhujay has quit IRC07:17
*** Bhujay has joined #openstack-tc07:18
*** Bhujay has quit IRC07:19
*** Bhujay has joined #openstack-tc07:19
*** Bhujay has quit IRC07:20
*** Bhujay has joined #openstack-tc07:21
*** lxkong has joined #openstack-tc07:21
*** e0ne has joined #openstack-tc07:21
*** Bhujay has quit IRC07:22
*** Bhujay has joined #openstack-tc07:23
*** david-lyle has joined #openstack-tc07:36
*** dklyle has quit IRC07:37
*** dklyle has joined #openstack-tc07:41
*** david-lyle has quit IRC07:42
evrardjpmriedem I expect to see the mc hammer pants on next summit now.07:52
evrardjpthanks for the closure document07:52
evrardjpgmann: I agree on we should not force campions to own those stories for projects forever.07:54
*** dklyle has quit IRC07:55
*** dklyle has joined #openstack-tc07:55
evrardjpCan we instead create a "Community goals unfinished stories tasks" thingy, so we can pile them up there, and basically see trends of what's going on?07:55
*** dtantsur|afk is now known as dtantsur07:55
*** e0ne has quit IRC08:04
*** tosky has joined #openstack-tc08:27
*** jpich has joined #openstack-tc08:44
*** adriant has quit IRC08:47
*** adriant has joined #openstack-tc08:48
asettleMorning o/08:50
*** cosss_ has quit IRC08:51
*** cosss_ has joined #openstack-tc08:51
*** Bhujay has quit IRC08:55
*** Bhujay has joined #openstack-tc08:56
*** Bhujay has quit IRC08:57
*** Bhujay has joined #openstack-tc08:58
*** Bhujay has quit IRC08:59
*** Bhujay has joined #openstack-tc08:59
*** Bhujay has quit IRC09:00
*** Bhujay has joined #openstack-tc09:01
evrardjpmorning09:01
*** Bhujay has quit IRC09:02
*** Bhujay has joined #openstack-tc09:02
*** Bhujay has quit IRC09:03
*** Bhujay has joined #openstack-tc09:04
*** Bhujay has quit IRC09:05
*** Bhujay has joined #openstack-tc09:05
*** Bhujay has quit IRC09:06
*** Bhujay has joined #openstack-tc09:07
*** Bhujay has quit IRC09:08
*** Bhujay has joined #openstack-tc09:08
*** Bhujay has quit IRC09:09
mugsieo/09:10
*** Bhujay has joined #openstack-tc09:10
*** Bhujay has quit IRC09:11
*** Bhujay has joined #openstack-tc09:11
*** Bhujay has quit IRC09:12
*** Bhujay has joined #openstack-tc09:13
*** Bhujay has quit IRC09:14
*** Bhujay has joined #openstack-tc09:14
*** Bhujay has quit IRC09:15
*** Bhujay has joined #openstack-tc09:16
*** Bhujay has quit IRC09:17
*** Bhujay has joined #openstack-tc09:17
*** Bhujay has quit IRC09:18
*** Bhujay has joined #openstack-tc09:19
*** Bhujay has quit IRC09:20
*** Bhujay has joined #openstack-tc09:20
*** Bhujay has quit IRC09:21
*** Bhujay has joined #openstack-tc09:22
*** Bhujay has quit IRC09:23
*** Bhujay has joined #openstack-tc09:23
*** Bhujay has quit IRC09:24
*** Bhujay has joined #openstack-tc09:25
*** cdent has joined #openstack-tc09:25
*** Bhujay has quit IRC09:26
*** Bhujay has joined #openstack-tc09:26
*** Bhujay has quit IRC09:27
*** Bhujay has joined #openstack-tc09:28
*** Bhujay has quit IRC09:29
*** Bhujay has joined #openstack-tc09:29
*** Bhujay has quit IRC09:30
*** Bhujay has joined #openstack-tc09:31
*** Bhujay has quit IRC09:32
*** Bhujay has joined #openstack-tc09:32
*** Bhujay has quit IRC09:33
*** Bhujay has joined #openstack-tc09:34
*** Bhujay has quit IRC09:35
*** Bhujay has joined #openstack-tc09:35
*** Bhujay has quit IRC09:36
*** Bhujay has joined #openstack-tc09:37
*** Bhujay has quit IRC09:38
*** Bhujay has joined #openstack-tc09:38
*** Bhujay has quit IRC09:39
*** Bhujay has joined #openstack-tc09:40
*** Bhujay has quit IRC09:41
*** Bhujay has joined #openstack-tc09:41
*** Bhujay has quit IRC09:42
*** Bhujay has joined #openstack-tc09:43
*** Bhujay has quit IRC09:44
*** Bhujay has joined #openstack-tc09:44
bauzasevrardjp: my personal take on goals (which I tried to say in some candidacy threads) is that we shouldn't ask for projects knowing if they can be done by one cycle09:45
bauzasif that's needing more than one cycle after discussing it in the PTG, fine by me09:45
*** Bhujay has quit IRC09:45
*** Bhujay has joined #openstack-tc09:46
bauzasbecause OSc feature on par with the project CLIs is IMHO very important for our users09:46
bauzasif some projects only need one cycle for the feature parity, good good09:46
bauzasif some others need more, then OK too09:47
*** Bhujay has quit IRC09:47
bauzaseven if we don't know *yet* how many of those projects will need more than one cycle09:47
*** Bhujay has joined #openstack-tc09:47
*** Bhujay has quit IRC09:48
ttxwhat we've seen in the past is that setting a goal without some sort of deadline was not very effective.09:49
*** Bhujay has joined #openstack-tc09:49
ttxIt was easier to rally behind a "Train release goal" than a TC mandate to work on something09:49
ttxBut I agree that sometimes a release cycle is not the best unit of time09:50
*** Bhujay has quit IRC09:50
*** Bhujay has joined #openstack-tc09:50
*** Bhujay has quit IRC09:51
*** Bhujay has joined #openstack-tc09:52
*** ianw is now known as ianw_pto09:52
*** Bhujay has quit IRC09:53
*** Bhujay has joined #openstack-tc09:53
*** Bhujay has quit IRC09:54
evrardjpWe can have larger goals, split into smaller milestones, all achievable in a certain unit of time. I have an opinion about not hardly link goals to cycles, but that's a side point for that discussion I guess.09:55
*** Bhujay has joined #openstack-tc09:55
*** Bhujay has quit IRC09:56
*** Bhujay has joined #openstack-tc09:56
*** Bhujay has quit IRC09:57
*** Bhujay has joined #openstack-tc09:58
*** Bhujay has quit IRC09:59
*** Bhujay has joined #openstack-tc09:59
*** Bhujay has quit IRC10:00
*** Bhujay has joined #openstack-tc10:01
*** Bhujay has quit IRC10:02
*** Bhujay has joined #openstack-tc10:02
*** Bhujay has quit IRC10:03
*** Bhujay has joined #openstack-tc10:04
*** Bhujay has quit IRC10:05
*** Bhujay has joined #openstack-tc10:05
*** Bhujay has quit IRC10:06
*** Bhujay has joined #openstack-tc10:07
*** Bhujay has quit IRC10:08
*** Bhujay has joined #openstack-tc10:08
*** Bhujay has quit IRC10:09
*** Bhujay has joined #openstack-tc10:10
*** Bhujay has quit IRC10:11
*** Bhujay has joined #openstack-tc10:11
*** Bhujay has quit IRC10:12
*** Bhujay has joined #openstack-tc10:13
*** Bhujay has quit IRC10:14
*** Bhujay has joined #openstack-tc10:14
*** Bhujay has quit IRC10:15
*** Bhujay has joined #openstack-tc10:16
*** Bhujay has quit IRC10:17
*** zbr|ssbarnea has joined #openstack-tc10:17
*** Bhujay has joined #openstack-tc10:17
*** Bhujay has quit IRC10:18
*** zbr has quit IRC10:18
*** Bhujay has joined #openstack-tc10:19
*** Bhujay has quit IRC10:20
*** Bhujay has joined #openstack-tc10:20
*** Bhujay has quit IRC10:21
*** Bhujay has joined #openstack-tc10:22
*** Bhujay has quit IRC10:23
*** Bhujay has joined #openstack-tc10:23
*** Bhujay has quit IRC10:24
*** Bhujay has joined #openstack-tc10:25
*** e0ne has joined #openstack-tc10:25
*** Bhujay has quit IRC10:26
*** Bhujay has joined #openstack-tc10:26
*** Bhujay has quit IRC10:27
*** Bhujay has joined #openstack-tc10:28
*** Bhujay has quit IRC10:29
*** Bhujay has joined #openstack-tc10:29
*** Bhujay has quit IRC10:30
*** Bhujay has joined #openstack-tc10:31
*** Bhujay has quit IRC10:32
*** Bhujay has joined #openstack-tc10:32
*** Bhujay has quit IRC10:33
*** Bhujay has joined #openstack-tc10:34
*** Bhujay has quit IRC10:35
*** Bhujay has joined #openstack-tc10:35
*** Bhujay has quit IRC10:36
*** Bhujay has joined #openstack-tc10:37
*** Bhujay has quit IRC10:38
*** Bhujay has joined #openstack-tc10:38
*** Bhujay has quit IRC10:39
*** Bhujay has joined #openstack-tc10:40
*** Bhujay has quit IRC10:41
*** Bhujay has joined #openstack-tc10:41
*** Bhujay has quit IRC10:42
*** Bhujay has joined #openstack-tc10:43
*** Bhujay has quit IRC10:44
*** Bhujay has joined #openstack-tc10:44
*** Bhujay has quit IRC10:45
*** Bhujay has joined #openstack-tc10:46
*** jpich has quit IRC10:55
*** jpich has joined #openstack-tc10:57
*** zbr has joined #openstack-tc10:57
*** zbr|ssbarnea has quit IRC10:59
*** zbr|ssbarnea has joined #openstack-tc11:17
*** dtantsur is now known as dtantsur|bbl11:19
*** zbr has quit IRC11:19
*** ricolin has quit IRC11:20
*** zbr has joined #openstack-tc11:46
*** zbr has quit IRC11:46
*** zbr has joined #openstack-tc11:48
*** zbr|ssbarnea has quit IRC11:48
*** ricolin has joined #openstack-tc12:27
dhellmanntc-members: I could use a couple of quick code reviews, if you have a minute today: https://review.openstack.org/641466 and https://review.openstack.org/64146813:12
openstackgerritMerged openstack/governance master: Update TC members for Train cycle election results  https://review.openstack.org/64117113:24
openstackgerritMerged openstack/governance master: automatically derive the release team PTL for delegating those changes  https://review.openstack.org/64146513:24
*** mriedem has joined #openstack-tc13:30
*** jaypipes has joined #openstack-tc13:32
*** marst has joined #openstack-tc13:34
dhellmanntc-members: reminder that we have a meeting in ~15 minutes here in channel13:45
mnaser\o/13:45
gmanno/13:45
asettleo//13:45
*** marst has quit IRC13:46
ricolino/13:47
fungiyup13:47
ttxyou can use the next 15min to fill https://etherpad.openstack.org/p/DEN-Train-TC-brainstorming with session ideas13:47
fungior go find more caffeine13:47
ttxTrying to come up with topics right now13:47
*** lbragstad has joined #openstack-tc13:48
mnaserdhellmann: +w those two patches after checking it locally, i like it13:50
ttxI'm hesitating to propose yet another session on part-time / casual contributors13:55
ttxI think that is an essential question, but past forum sessions around that were not very useful13:55
ttxprobably because it's a topic that is more easily tackled at project team level13:56
* mnaser queues the final countdown13:59
evrardjpo/14:01
* mugsie is lost somewhere in the building, will join when he finds his desk14:01
* bauzas sits on the back near the radiator14:01
fungiis it that cold?14:01
ttxo/14:01
openstackgerritMerged openstack/governance master: show the owner of each patch in status report  https://review.openstack.org/64146814:01
bauzasthat's where bad kids are, right?14:01
bauzas(jk)14:02
openstackgerritMerged openstack/governance master: add vote list to status report  https://review.openstack.org/64146614:02
asettlefungi, yes. It is.14:02
fungibauzas: the bad kids are skipping14:02
asettleThem winds about.14:02
ttxdhellmann: are you starting the meeting?14:02
fungiwe can all draw straws14:03
mnaserdoug should be starting it, let's give him a few minutes14:03
fungia straw poll14:03
* jroll is here but has to step away for a few :(14:03
* dhellmann is wrapping acall14:03
dhellmann#startmeeting tc14:04
dhellmann#link http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002231.html agenda for this meeting14:04
openstackMeeting started Thu Mar  7 14:04:10 2019 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.14:04
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:04
*** openstack changes topic to " (Meeting topic: tc)"14:04
openstackThe meeting name has been set to 'tc'14:04
dhellmann#topic roll call14:04
dhellmanntc-members (new and old) please indicate if you are present for the logs14:04
*** openstack changes topic to "roll call (Meeting topic: tc)"14:04
dimso/14:04
mnaserbonjour o/14:04
lbragstado/14:04
zaneb\o/14:04
gmanno/14:04
jroll\o14:04
asettleo/ hola14:04
ricolino/14:04
evrardjpo/14:05
mugsieo/14:05
fungialoha14:05
dhellmanno/14:05
dhellmannok, we have 11 of 13 so far so we have quorum.14:05
cdenti'm here for nostalgia14:06
dhellmann#topic TC election results14:06
*** openstack changes topic to "TC election results (Meeting topic: tc)"14:06
dhellmann#link https://review.openstack.org/#/c/641171/14:06
dhellmannI workflowed the patch to update the membership this morning, and updated the gerrit group yesterday14:06
dhellmannif anyone has trouble using the rollcall vote, let me know14:06
fungithanks!14:06
evrardjpthank you dhellmann14:06
dhellmannthank you to cdent, dims, and smcginnis for serving on the TC!14:07
dhellmannwelcome asettle, jroll, and ricolin as new members!14:07
dhellmannand welcome back mugsie, mnaser, ttx, and zaneb, thank you for continuing to serve14:07
mnaser\o/14:07
asettle:D14:07
zaneband thanks also bauzas and flwang14:07
asettleThanks pal14:07
ricolindhellmann, thanks! happy to be here14:07
dhellmannyes, good point, zaneb14:07
bauzasheh was a pleasure to run14:07
dimswelcome to the new tc members!14:07
ttx\o/14:07
lbragstadwelcome :)14:07
evrardjpwelcome14:08
evrardjpand thanks everyone14:08
bauzasand congrats to the new elected members one more time :)14:08
asettleThank you all :)14:08
ttxbauzas: next time let me know you'll run ni advance, so that I can safely skip!14:08
dhellmann#topic new chair for train14:09
dhellmannAs I mentioned last month, I will stepping down as chair.14:09
*** openstack changes topic to "new chair for train (Meeting topic: tc)"14:09
bauzasI'm not sure to run again but i note ;)14:09
dhellmannWe have mnaser's self-nomination to act as chair.14:09
dhellmannI would like to have the chair either selected or the voting started by the end of today.14:09
dhellmannIf anyone else wants to run, now is the time to announce it.14:09
dhellmannIf we have no other candidates, we can approve mnaser during the meeting.14:09
dhellmannok, everyone please go cast a rollcall vote on that application14:10
dhellmann#link https://review.openstack.org/#/c/641405/114:10
evrardjphesitating to do a bad joke about furniture right now.14:10
*** dtantsur|bbl is now known as dtantsur14:10
ttxevrardjp: there is no bad time for a furniture joke14:10
asettleevrardjp, don't leave us hanging man14:12
ricolingood, now I'm waiting for that joke haha14:12
* bauzas won't say anything about Belgian jokes14:13
dhellmannlooking for jroll and evrardjp to cast their votes...14:13
* jroll just returned, sorry14:13
evrardjpstill thinking :)14:13
jroll+1'd14:14
ttxevrardjp: I think your launch window just closed14:14
dhellmannok, there we go14:16
dhellmannthank you, mnaser, for volunteering to chair14:16
gmannthanks mnaser14:16
fungithanks a ton mnaser!14:16
evrardjpcongratulations mnaser14:17
dhellmannI'll finish out this meeting, and then mnaser will pick up duties from there14:17
asettleYay mnaser14:17
ttxcongrats mnaser14:17
mnaserthank you all, look forward to serving as chair for the upcoming session14:17
ricolinmnaser, congrats14:17
fungior condolences ;)14:17
mugsiemnaser: RIP any free time you may have had left :)14:17
*** marst has joined #openstack-tc14:17
mugsiebut thanks for stepping up14:17
lbragstadthanks mnaser!14:17
asettleI expect big things mnaser14:18
mnaser:)14:18
ttxmugsie: he did not have nay free time left already, so nothing lost14:18
ttxany*14:18
dhellmannindeed14:19
* dhellmann thought ttx was working on his 18th century english accent14:19
dhellmannok, let's start with old business14:19
dhellmann#topic project team evaluations based on technical vision14:19
ttxaye aye sir14:19
*** openstack changes topic to "project team evaluations based on technical vision (Meeting topic: tc)"14:19
dhellmann#link http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001417.html14:19
dhellmannlast month cdent took the action to "republish the projects review vision notion"14:19
dhellmannis there anything new to report this month?14:19
cdentthere was a lot of discusson in email, (on the new thread), but not much actionable14:20
dhellmannI think TheJulia was also working on this?14:20
dhellmannok. do we have a next step to record, is this an ongoing thing, or is it "done"?14:21
TheJuliaI have noticed some projects have taken to drafting such documents14:21
cdent#link feb thread on that http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002524.html14:21
dhellmannoh, thanks, I linked to the old thread there14:21
TheJuliaBut only in passing, I simply have not had time to look.14:21
dhellmannshould we carry it over to next month and check in again?14:21
evrardjpI have asked some projects I am involved in to react on this, but didn't actively query for feedback every week. I probably should14:21
zanebI have been meaning to review/comment on stuff that has come up, but the elections, travel &c. sucked up all of the time I would have had to do that14:22
dhellmannperhaps someone else wants to volunteer to help with this?14:22
evrardjpcarry on to next month?14:22
TheJuliadhellmann: sounds reasonable unless someone else wants to take a look across the community. Maybe it would be a good thing to check for with health assessments14:22
evrardjpTheJulia: ++14:22
evrardjpTheJulia: I think it would be wise as an additional thing to query14:23
fungiyeah, i'm good with the idea that we got the ball rolling down hill and the rest of the community is picking it up14:23
dhellmannevrardjp : sorry, carry the agenda item over to the next meeting and discuss it again14:23
gmannTheJulia: good idea about adding it in health check14:23
fungiit makes for a good touchpoint in health checks and as a guiding document when evaluating fit for new projects14:23
TheJuliaYeah, another project just mentioned that they had just uploaded theirs into review, so seems like the ball is rolling14:23
evrardjpdhellmann: sorry, I meant I was okay with it... :p14:23
evrardjpbut not with 100% certainty14:23
dhellmannevrardjp : ah, sorry, I thought my idiom wasn't clear14:23
evrardjpyup, got it afterwards :p14:24
fungii don't think the tc really has any further actions to take on it unless the community brings them to us in the form of edits or future discussions?14:24
evrardjpfungi: true14:24
jrollfungi: agree, I think all we can do is encourage folks to do it14:25
TheJuliaI concur14:25
fungiit seems like they're starting to encourage each other to do it at this point14:25
fungiso smells like success to me14:25
mnaseri think it would be good for someone to compile a list of the projects that have done it14:25
jrollmaybe worth tracking, but not sure it needs formal follow-up. I guess quick reviews of the uptake for another month or two doesn't hurt, though14:25
mnaserperhaps slot in somewhere inside openstack/governance to link out to those documents/reviews generated?14:26
dhellmannoh, interesting, yeah14:26
evrardjpmnaser: collaborative edit on etherpad or something?14:26
evrardjpmnaser: oh good idea there, better than etherpad14:26
asettleIf a formal follow-up is required, nothing to say it can't be an in person discussion point at the forum.14:26
mugsieI like that idea14:26
evrardjpmugsie: which one?14:26
cmurphymight be worth a reminder email, i feel like it would have gone in one ear and out the other if i wasn't so much following the tc activity14:26
mnaseretherpad might be hard to find and navigate.  i think slotting it somewhere in the governance repo might be useful so that other projects that want to write up their own can see how others have done it14:26
mugsielinks off the o.o/goverance14:27
TheJuliafungi: that is a good observation, I do agree.14:27
dhellmanncmurphy : good point14:27
evrardjpcmurphy: I think that's what indeed happened14:27
asettle+114:27
jrollcmurphy: +114:27
jrollare we just encouraging teams to do this, or requiring?14:27
dhellmannok, so it sounds like we want a reminder email and to compile links to existing work. who wants to volunteer to do that?14:27
dhellmannencouraging14:27
* jroll assumes the former14:27
jrollok, thanks14:27
* dhellmann wonders where all of the active "go getters" who just ran in the election are when it comes time to volunteer14:28
mnaseri think we have two action items: slot in a spot in openstack/governance to add them, and use the review that adds it in there to say "hey, thanks projects who did this, we've added your to this document, and for projects that haven't done it, you've got some examples"14:28
fungiand add to the forum ideas pad if it's not there already (thanks asettle!)14:28
gmannadding the forum sessions and explain/remind teams why and what they should do14:28
gmannyeah14:28
asettlefungi, gmann - writing up a short thing now14:28
gmannthanks14:28
fungiyou rock14:28
zanebdhellmann: I, for one, am trying to avoid getting to involved in this one for fear that the vision will be seen as just my thing14:29
mnaserso asettle is going to write the reminder14:29
jrollasettle: thanks!14:29
dhellmannzaneb : that's reasonable14:29
evrardjpmnaser: in teams.py for example?14:29
asettleHey yo what14:29
mnaser:P14:29
asettle"join the TC" they said14:29
fungiso for adding to governance we likely need an externalized discussion on where to extend the data model (please not in-meeting)14:29
TheJulialol14:29
asettle"you won't be bullied into writing emails" they said14:29
mnaserevrardjp: the details are to be discussed, we just want to find someone to own that action14:29
dhellmannfungi : or we could just link from the vision page itself14:29
jrollI'm happy to help with this, but am traveling next week so it'll be the following week at the earliest14:29
TheJuliaasettle: "it will be fun" they said ?:)14:30
asettle^^ ditto, I'm afraid. I'm off 10 - 18 for SUSE14:30
evrardjpjroll: welcome to the club14:30
fungidhellmann: hah, i said please not in meeting! (that gets us yet another different place we list arbitrary projects/deliverables)14:30
asettleTheJulia, you asking who said that or why I'm already making those comments? :p14:30
dhellmannok, I think we have a couple of volunteers then. I'll leave it for mnaser to follow up with asettle and jroll on this14:30
asettleCool14:30
TheJuliaasettle: no, more remarking similar discussions14:30
jrollwfm, thanks in advance for the reminder mnaser :P14:30
dhellmannanything else before we move on?14:31
dhellmann#action mnaser follow up with asettle and jroll on reminder and placement of links for vision alignment docs14:31
dhellmann#topic defining the role of the TC14:31
*** openstack changes topic to "defining the role of the TC (Meeting topic: tc)"14:31
dhellmann#link https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Next_steps_in_TC_Vision_.2F_defining_role_of_the_TC14:31
dhellmannlast month we talked about syncing with zaneb when he returned from the volcano14:31
dhellmannand that we needed to do that before settling on next steps14:31
ttxohai14:31
dhellmannttx, TheJulia, cdent, do you have an update on this?14:31
ttxWe merged a small change iirc around the wording for technical direction14:32
openstackgerritMerged openstack/governance master: Add Mohammed Naser nomination as chair  https://review.openstack.org/64140514:32
dhellmannah, yes, we did14:32
cdentgood change14:32
zanebI feel like we've had some good discussions on the ML about this over the course of the election14:32
cdent#link giant thread: http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001711.html14:32
ttxwhich was the only major missing point expressed14:32
cdentand the election discussion was _very_ good14:32
fungii blame cdent for the election discussion14:33
ttxcdent: would you say other changes are needed to capture that discussion?14:33
* cdent accepts that blame14:33
ttxI felt like it reinforced the current wording more than it objected to it14:33
cdentnot at this stage, no, but I'm expecting a lot from the newly elected people :)14:33
* cdent accepts the blame for setting high expectations14:33
ttxNow is a good moment to re-explain that it is meant as a living document14:33
*** mriedem is now known as mriedem_afk14:34
ttxbasically, our role can evolve or be precised.14:34
dhellmann#link https://governance.openstack.org/tc/reference/role-of-the-tc.html14:34
* jroll needs to read back through that doc and the ML discussion14:35
ttxBUT at this point I'd focus on doing a better job at the described role, rather than necessarily in evolving it14:35
dhellmannit sounds like this is an ongoing discussion, but can come off of the tracker for now, then?14:35
ttx"Defining global technical goals" for example is not somethign we excel at14:35
ttxwhile it is part of our role14:35
ttxwhich is why I followed-up with a Forum session proposal14:35
dhellmannyes, I agree there14:35
ttxI'm not very inspired today and time is running out, so feel free to evolve the proposal in https://etherpad.openstack.org/p/DEN-Train-TC-brainstorming14:37
dhellmannso, next steps are the forum session?14:37
dhellmannor is it safe to remove this from the tracker?14:37
ttxI'd say next step forum session14:37
dhellmannok14:37
ttxactually...14:37
mugsiewell, it is a different thing to defining the role14:37
mnaserttx, diablo_rojo: fyi, from a foundation/organization pov .. it could be nice if we somehow could be slotted a seperate time for our sessions so PTLs can easily attend.14:38
ttxI would close the "define role" task and open a new "how to drive technical change" one?14:38
dhellmannok14:38
mnaserour = TC14:38
mugsieit is work on how we do the thing we said we are supposed to do effectvily14:38
jrollttx++14:38
evrardjp+1 on mnaser14:38
dhellmann#action ttx close the role defining task and create a "driving technical change" task14:38
ttxThe role is defined, the task is more on how to do a better job at one of the facets of our role14:38
evrardjpagreed with ttx too14:38
zaneb+114:39
ricolin+1 on that14:39
dhellmanndo we have a second volunteer to help ttx with that forum session?14:39
fungihaving 0% overlap with other forum sessions is probably not achievable. ptls are going to need to delegate folks to attend one or the other in some cases14:39
TheJuliadhellmann: help how so? moderate?14:39
fungiwe basically have a total of 2.5 days for forum sessions14:39
dhellmannlet's stay on topic please14:39
dhellmannTheJulia : yes, plan and moderate14:39
zanebdhellmann: I can help14:40
dhellmannthanks zaneb14:40
dhellmann#undo14:40
openstackRemoving item from minutes: #action ttx close the role defining task and create a "driving technical change" task14:40
dhellmann#action ttx and zaneb close the role defining task and create a "driving technical change" task14:40
TheJuliaI was going to say that I'm likely a risk to try and commit to help ttx as I'm already over-committed.14:40
dhellmann#undo14:40
openstackRemoving item from minutes: #action ttx and zaneb close the role defining task and create a "driving technical change" task14:40
ttxzaneb: I'll do the task update dance14:41
dhellmann#action ttx and zaneb close the role defining task and create a "driving technical change" task and forum session14:41
* dhellmann will get it right eventually14:41
dhellmannok, we have a few more topics to cover14:41
dhellmann#topic keeping up with python 3 releases14:41
dhellmannstand by for paste bomb14:41
*** openstack changes topic to "keeping up with python 3 releases (Meeting topic: tc)"14:41
zanebttx: ack, thanks14:41
dhellmannwe had several tasks for this last month14:41
dhellmann#info gmann raise the topic of porting legacy jobs to bionic on the mailing list14:41
dhellmann#info fungi to propose flag day for proposing moving centrally managed jobs to bionic14:41
dhellmann#info fungi propose a default node flag day to switch to ubuntu bionic14:41
dhellmann#info TheJulia investigate PTI updates for Train14:41
dhellmannis there anything else to be done for either stein or train?14:41
TheJuliadhellmann: we only need to update the page to say it is the same for train AFAIK. I looked everything up during the last meeting and haven't had time to actually put the patch in14:41
zanebthere's a *lot* of confusion around Stein because we didn't announce anything at the start of the cycle14:41
zanebI think we really need to come up with some sort of statement on what to do14:42
zanebeven if it's "you're on your own until Train opens"14:42
TheJulias/same for train/same as stein as for train/14:42
dhellmannwe're getting very close to the cut-off deadline for the release, so I agree we should clarify14:43
dhellmannwho wants to take the lead on resolving the stein question?14:43
dhellmann(we'll talk train next)14:43
zanebI think we actually need to talk Train first, and work back14:43
* dhellmann feels his chair powers waning14:43
dhellmannok14:44
evrardjpzaneb: please clarify?14:44
TheJuliazaneb: yes, clarity ++14:44
asettle^14:44
mnaseri think those best placed to take an action moving forward are those who have been working on this topic14:44
TheJuliayes, but it is clear we have differing expecatations and understandings14:44
zaneblike, if we know what it's going to look like for Train, then it's pretty easy to tell people where we're heading and therefore what they should do right now14:44
gmannyou mean to consolidate the items we are doing in stein as overall or as python3 work14:44
TheJuliaso we need to resolve that before we move off the topic, otherwise we risk the same thing happening in the next meeting14:44
dhellmannthat makes sense14:45
mnasershould we call for an ad-hoc meeting to _discuss_ the python3 issue?14:45
evrardjpfine for me mnaser14:45
zanebright now we don't know if the Bionic migration will get completed before Train opens, so we don't know what will fall out of the formula in the resolution14:45
dhellmannmnaser : that works for me, do you want to set that up?14:45
TheJuliazaneb: but did we not do that with the PTI and the documentation related to it?14:45
*** mriedem_afk is now known as mriedem14:46
mnaseryes, i can set it up.  i think this is something we need to flush out asap.  can i get some times that work for those that were involved in this?14:46
dhellmannok14:46
dhellmann#action mnaser to set up a meeting to discuss the python 3 transition plans for stein and train14:46
gmann+1 on ad-hoc meeting14:46
fungii'm free at 1700z today14:46
zanebif we assume that gmann will be successful in getting everyone migrated to Bionic, then we can announce the release goal for Train ~now14:46
dhellmannwe have 3 more topics, so let's do the planning in office hours14:47
dhellmann#topic Train cycle goals selection update14:47
*** openstack changes topic to "Train cycle goals selection update (Meeting topic: tc)"14:47
dhellmannlbragstad and evrardjp, how is that process going?14:47
lbragstadat this point, we have two goals in review making it easier for us to use the normal review flow with Gerrit14:47
lbragstadevrardjp and I sent a note to the mailing list summarizing next steps14:47
lbragstad#link http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003549.html14:47
lbragstadand it is generating discussion14:48
dhellmannit looks like we really only have 2 contenders for train, then?14:48
lbragstadcorrect14:48
lbragstadat least up to this point14:48
dhellmannwith the possibility of the platform upgrade item from the last topic14:48
dhellmannmaybe that's a third14:48
dhellmannok14:48
lbragstadfwiw - those two goals were the ones with the most pre-work done14:48
dhellmann#action tc-members review candidate goals and provide feedback14:49
mnaserdo we have reviews that we want to link to?14:49
mnaseror a topic, or something to point to14:49
dhellmann#link project deletion goal proposal https://review.openstack.org/63901014:49
dhellmann#link openstack client goal proposal https://review.openstack.org/63937614:50
lbragstad++ thanks dhellmann14:50
dhellmannlbragstad , evrardjp : do you have anything else on this topic?14:50
mnaserdo we also have an ideal timeline to have this merged by?14:50
lbragstadwe sent the timeline in a previous email about the goal selection process for train14:51
lbragstadbut let me find the date14:51
ttxI feel like both had valid objections posted on them already that need to generate another patchset14:51
dhellmannlbragstad , evrardjp : perhaps it would be good to remind the goal champions of those timelines14:51
lbragstadmnaser we'd like to have the goals merged, if possible, by the end of this month14:51
evrardjpdhellmann: fair14:51
mnaserok, great, will keep in mind. thanks14:52
lbragstadthat gives teams 4 weeks to work the goals into their PTG schedules14:52
dhellmann#action lbragstad and evrardjp to remind champions for proposed goals of the approval deadlines14:52
mnaser#action mnaser follow-up with progress of goal merging in 2 weeks14:52
lbragstadthe last thing we want is to merge something *right* before we're all in denver and not be able to leverage face-to-face time14:53
dhellmannremember that having a goal approved by the end of the month needs to include the time that patch needs to sit open for comments14:53
dhellmannok, good14:53
dhellmannyeah, I think we wouldn't do that14:53
dhellmannin our last few minutes...14:53
dhellmann#topic forum planning14:53
*** openstack changes topic to "forum planning (Meeting topic: tc)"14:53
dhellmanngmann has started collecting ideas for forum sessions we need to ensure happen14:53
dhellmann#link https://etherpad.openstack.org/p/DEN-Train-TC-brainstorming14:53
dhellmannwho is planning to attend?14:53
dhellmannremember the joint leadership meeting is the sunday before the summit14:53
smcginniso/14:53
mugsieo/14:53
asettleo/14:53
zanebo/14:53
TheJuliao/14:53
lbragstado/14:53
jrollI won't be at the summit, unfortunately :(14:53
ricolino/14:53
ttxo/14:54
gmanno/14:54
dhellmann#link board meeting schedule https://wiki.openstack.org/wiki/Governance/Foundation#OpenStack_Board_of_Director_Meetings14:54
fungii'll be there14:54
dhellmanno/14:54
evrardjpWill be there14:54
dhellmannjroll :-(14:54
gmannyeah we have good amount of forum ideas. deadline is 10th which is sunday so i will say we propose or give feedback on existing topic by today and start proposing on site by tomorrow.14:54
mugsiedhellmann: is it morning BoD, afternoon Joint meeting?14:54
mugsiejroll: :'(14:54
dhellmannmugsie: I don't have a schedule yet14:55
mugsiegmann: sounds like a good timeline14:55
dhellmannI'm sure Alan will share that with mnaser as soon as it is available14:55
smcginnisLikely something like that schedule based on past ones.14:55
dhellmannpro tip: set a watch on that foundation page in the wiki for notifications of updates14:55
mnaserafaik it's a full day type of thing, but no hard schedule yet14:55
*** Bhujay has quit IRC14:56
evrardjpdhellmann: thanks for the tip14:56
dhellmanngmann : ok, that's important, if we need to be giving the feedback today14:56
gmanni will remind moderators (or ask for moderators if any topic missing ) to do that tomorrow.14:56
dhellmann#action tc-members review forum proposals today/tomorrow in time to meet the selection deadline14:57
mnasersmall note14:57
mnaserhas anyone booked travel yet, by the way?  would people be open to coming a day before (say, saturday) to have something similar to what we did last time in denver?14:57
gmannone topic is "U goal discussion" as PTG and summit merged so we should discuss in this summit ?14:57
gmannotherwise next physical meetup will be around start of U cycle14:57
dhellmannmnaser : I've booked my flight, but could probably change it14:57
smcginnisI plan on arriving Saturday.14:57
evrardjpmnaser: booked my flight, can't change it.14:57
dhellmannalthough that's going to make for a *very* long week14:57
mugsiemnaser: I would be14:57
lbragstadmnaser i'll be in sometime on saturday14:57
evrardjpI arrive Saturday afternoon14:58
gmannmnaser: i will be there on sat but for OUI training14:58
TheJuliamnaser: I booked my flight and could also possibly change if needed, I think I'm already arriving on saturday and I'm also in boston the week following :\14:58
fungii haven't booked yet but intend to get in on saturday14:58
zanebI'll be there early and likely have time on Sat afternoon/evening14:58
mnaseralright, well, i'll bring up an ML thread and we can discuss options, we would need to involve foundation staff for logistics14:58
mnasersat might not even be possibly logistically14:58
asettlemnaser, haven't booked but would do the Saturday anyway I'd say. Jet lag + Alex = No14:58
mnaserbut i assume folks are interested in something like that, right?14:58
mugsieyeah, I think the last one in DEN was useful14:58
TheJuliathere is no rule saying we can't concur someplace with enough room to chat, it just might not be a meeting roomm.14:58
dhellmannperhaps we could at least meet for a long dinner on saturday?14:59
mugsieTheJulia: ++14:59
dhellmanna dinner worked well in barcelona14:59
evrardjpsounds like a good idea.14:59
asettle+1 to that14:59
zaneb+114:59
TheJuliaA dinner oriented meeting does seem like a much better idea14:59
* dhellmann lands at 7:00 PM local time and will be hungry14:59
mnasercool.  i'll bring this to ml / office hours14:59
ricolin+114:59
* dhellmann may already be hungry14:59
mugsieyeah, depending on how flights work out going west14:59
dhellmannok, one more quick item15:00
mnaserbunch of hangry TC members15:00
mnaserwhat could go wrong15:00
mnaserbut go on15:00
ricolinI will do the aquarium diving thing on saturday, but that's not conflict with dinner for sure15:00
dhellmann#topic OIP review process15:00
*** openstack changes topic to "OIP review process (Meeting topic: tc)"15:00
dhellmann2 days ago the board approved the Open Infrastructure Project acceptance criteria/process15:00
dhellmannpart of the process includes consulting with leadership of existing projects, including the TC15:00
dhellmannjbryce has asked us to think about how we would want that consultation step to work15:00
dhellmannI don't think we need to give an answer right this second, but please spend some time thinking about it15:00
dhellmann#action tc-members think about a process for handling consultations on OIP applications15:00
* mnaser will engage with osf staff to how we can do this best15:00
dhellmannI know many people have many opinions on this one, so I look forward to the future discussion15:01
dhellmann#topic next meeting15:01
*** openstack changes topic to "next meeting (Meeting topic: tc)"15:01
dhellmann#info the next TC meeting will be 4 April 2019 1400 UTC in #openstack-tc15:01
dhellmannIf you have suggestions for topics for the next meeting, please add them to the wiki at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions15:01
mugsiewe also need to look out for the OIP execustive session review thread15:01
mugsieexecutive*15:01
dhellmannThank you, everyone! I have enjoyed serving as chair for the last 2 terms and I look forward to continuing to serve as a TC member through Train.15:01
lbragstaddhellmann  i'd like to say thanks for the outstanding job you've done as the TC chair15:02
mugsiedhellmann: thanks for serving15:02
mnaserindeed, thanks once again15:02
ttxbest chair ever!15:02
jroll++15:02
fungithanks dhellmann!15:02
bauzasthanks dhellmann15:02
zanebmuch appreciated dhellmann15:02
asettleThank you dhellmann !!!15:02
TheJuliathanks dhellmann15:02
evrardjpthanks dhellmann15:02
gmanndhellmann: thanks. great serve as chair with great leadership.15:02
ricolinthanks dhellmann! I think you doing a super great job15:02
dhellmannthank you all very much, that means a lot15:03
dhellmannand we're just a tiny bit over time here, so let's...15:03
dhellmann#endmeeting15:03
*** openstack changes topic to "OpenStack Technical Committee office hours: Tuesdays at 09:00 UTC, Wednesdays at 01:00 UTC, and Thursdays at 15:00 UTC | https://governance.openstack.org/tc/ | channel logs http://eavesdrop.openstack.org/irclogs/%23openstack-tc/"15:03
openstackMeeting ended Thu Mar  7 15:03:17 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:03
openstackMinutes:        http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-03-07-14.04.html15:03
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-03-07-14.04.txt15:03
openstackLog:            http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-03-07-14.04.log.html15:03
fungiand now we take you to our office hour, already in progress15:03
ttxI have an extra topic but can discuss in office hour15:04
fungidhellmann: on the openstack vision project reviews, i'm worried that sticking links for them somewhere other than reference/projects.yaml will mean yet one more place we have a partial duplicate list of projects15:04
ttxWe have a "Meta SIG" that is tasked with doing adminsitrative approval of SIGs and furthering their adoption15:05
ttxThe governance of that is that we have one TC and one UC member as co-chairs15:05
ttxIf they ever disagree, we ask the Executive director of the Foundation to cast the deciding vote15:05
ttx(but then, we never disagree)15:06
fungihas the uc delegate been updated since the turnover there?15:06
ttxI did fill at role until now. I'm happy to continue if we have no volunteer, but I'am also happy to rotate if anyone else is interested!15:06
ttxfungi: in progress15:06
mugsieI saw something in the uc meeting logs ... let me look15:06
ttxThey should decide it at their next meeting15:06
ttxif not done already15:06
ttxI know ricolin feels strongly about SIGs for example15:07
ricolinI am!15:07
ttxso if you want the role, or have questions about it, just let me know15:07
ttxReference: https://governance.openstack.org/tc/resolutions/20180319-sig-governance.html15:08
ricolinttx I'm more than happy to help on this task for sure15:08
mugsieI think Matt stepped into the meta sig role from the UC (looking at logs)15:10
ttxmnaser: how do you want to proceed for that decision ? Just switch to ricolin and be done with it, or anything more formal?15:10
mugsiehttp://eavesdrop.openstack.org/meetings/uc/2019/uc.2019-03-04-16.00.log.html#l-45 was how the UC did it :)15:11
fungion the topic of the default node switch to ubuntu-bionic, i've posted http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003584.html to get feedback on doing it the middle of next week15:11
ttxmnaser: oh, I'll just propose a change to governance-sig updating co-chairs and ask that TC members +1 it.15:13
dhellmannfungi : that's a good point15:15
dhellmann(about the linking thing)15:15
gmannfungi: to be clrear- default node switch will 1. move all base functional job on bionic 2. infra own job ?15:15
fungigmann: apologies, i'm unable to parse your question(s)15:16
* mnaser is just about to get off a call and review buffer15:16
lbragstadmnaser dhellmann http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003587.html15:17
dhellmannlbragstad : thanks!15:17
*** cdent has left #openstack-tc15:17
fungigmann: i'm proposing that "we" switch any jobs which aren't specifying a node type explicitly to from ubuntu-xenial to ubuntu-bionic, who will write that change isn't yet decided15:18
gmannfungi: i mean currently we have tox functional jobs and legacy jobs running on xenial . what all these jobs are migrated by default node switch15:18
fungigmann: if they don't explicitly list ubuntu-xenial as their node type then they would switch. one way to avoid that is to update them to specify ubuntu-xenial if they can't support running on ubuntu-bionic15:19
gmannfungi: does that include legacy base job also? - legacy-dsvm-base15:19
fungii don't personally think it should include legacy-dsvm-base but it's worth debating15:19
gmannyeah, because I am doing it as part of legacy job migration and with testing patch to projetcs - https://review.openstack.org/#/c/639096/15:20
gmannmost of the legacy jobs are derived from it15:20
fungifor me anything called "legacy" in our job configs is a sign it's a frozen result of migration from zuul v2, unmaintainable and not to be altered further15:20
mnaserttx: looks like the governance-sig change option seems to make sene15:21
gmannfungi: ok, make sense.15:21
mnasertc-members: we would like to schedule an ad-hoc meeting regarding python3 to come up with a final decision.  how's everyone's schedules looking like, and hopefully involving gmann fungi and TheJulia as they've worked on it a lot15:22
fungigmann: but as i said, i'm open to discussing it, the infra team just can't offer a lot of help troubleshooting alterations to legacy job definitions15:22
fungiand altering them is at least as likely to result in unintended side-effects owing to their inscrutability15:23
mnaseri think it would be good to have a more structured meeting around an intro of the current state of things, and then a discussion with an end goal and actionable items to follow up on15:23
gmannok. let's do legacy-dsvm-base as part of https://etherpad.openstack.org/p/legacy-job-bionic and rest all without-nodeset-define job goes into your change15:23
mnaseri think the reason we're not getting a lot of people volunteering to help on this is because maybe they haven't been able to follow it as much15:23
asettlemnaser, unfortunately not great. Sunday I'm off to Nuremberg for teaming for a week and not back until the 18th. I'll be a bit MIA next week, now I mention it out loud. But I can't imgaine my input regarding Python 3 is invaluable. I will read the logs after if we're on IRC.15:23
zanebmnaser: I am flexible within EST zone15:23
fungimnaser: i've got a call at 1800-1900z today but am open otherwise15:23
mugsieI am out tmorrow -> tuesday UTC morning, but good other than that15:24
openstackgerritDoug Hellmann proposed openstack/governance master: add a note to notify the community when the TC chair changes  https://review.openstack.org/64169515:24
evrardjpout next week15:24
mnaserfor those who aren't available soon, do you feel strongly about the topic that you'd like us to cater for your schedule or you're okay delegating the rest of our tc to conclude this? :)15:24
mnasertotally okay if you absolutely need to be there15:24
gmannmnaser: anytime during CST work for me. tough weekend also ok for me :)15:25
jrollmnaser: I don't have strong opinions on the topic, and am fairly open after march 18 to discuss15:25
dhellmannmnaser : I am happy to advise but trust others to resolve this15:25
gmann*though15:25
mugsieI would like to be there, but if I have to read logs, and follow up on the ML thats fine15:25
mnaseryeah, python3 isn't my expertise, so i'll just mostly defer and coordinate.  but i think this has to be done sooner than later15:25
evrardjplike mugsie15:25
mnaserit's stalled a little while :<15:25
dhellmannwe might also say that we just didn't get this done in time for stein and decide what makes sense for train15:27
mugsiedhellmann: +115:28
zanebdhellmann: I think that's what we've been saying, but it has led to confusion (although deciding what we're doing for Train may alleviate that somewhat)15:28
mnaserwell we need to say "something" at the end of the day :)15:29
bauzashonestly, I said this morning we shouldn't be afraid of having a goal needing more than one cycle15:29
bauzasand py3 is super important15:29
dhellmannzaneb : ok, well, we did clarify the thing about 3.5 and 3.7, right?15:29
mnasernow that i think of it15:30
dhellmannbauzas : this specific topic is about ensuring that we clearly declare which version of python we will use for testing for a given cycle.15:30
mnaseri think having timezones in the list of TC members might be very useful.15:30
bauzasdhellmann: gotcha15:30
fungimnaser: i dunno, my timezone isn't a clear indicator of my availability. but maybe i just keep strange hours15:30
zanebdhellmann: sort of. we clarified that 3.5 wouldn't be needed for RHEL 8. but it's still needed until we get off Ubuntu Xenial. and we don't know for sure when that will be15:31
dhellmannmnaser : good idea. we could take that opportunity to turn that file into a yaml file, too, now that we have a library in the repo to serve as a public API for reading the data15:31
gmanni think if we finish the majority of  the things it is good. for example: we move all base and most of the jobs to bionic and if something is rally breaking then project can adopt to run that job on xenial as exception. that should not stop us to mark our tasks as complete.15:31
mnaserfungi: we can just mark your timezone as utc :)15:31
fungihah15:31
dhellmannbauzas : so you're right, but I think it's likely to be easier to settle this question, even though we have to discuss it each cycle. We got away with not doing it for a long time while 2.7 was the only real answer.15:31
bauzaswhich versions are run for most of the projects jobs ?15:32
dhellmannsome mix of 3.5, 3.6, and 3.715:32
fungibauzas: it probably depends on how you want to measure that15:32
bauzasfor Nova, it's 3.615:32
bauzas(and 3.5 IIRC)15:32
gmannbauzas: yeah and 3.7 in-progress15:32
dhellmannwe said stein needed to be 2.7 and 3.615:33
dhellmannhttps://governance.openstack.org/tc/reference/runtimes/stein.html15:33
dhellmannI guess there was a question about 3.5 because not everyone was on 3.6 yet? and that has something to do with the bionic transition?15:33
bauzaswhat I mean is that what's not tested is not supported15:33
dhellmannyeah, this isn't about support, it's about setting direction to decide what should be tested in the first place15:33
fungito me it has less to do with the python release and more to do with the platform on which we're testing. the default python3 on our ubuntu-bionic images is 3.6 but it's really "ubuntu bionic python3" not "python 3.6"15:34
bauzasI see15:34
dhellmannso we've said to teams they should be testing 3.6. zaneb pointed out why we might also need to include 3.5, but we have the necessary transition in place, too so maybe not?15:34
gmannmnaser: you want to do quick doodle for checking TZ for py3 ad-hoc meeting ?15:34
dhellmannfungi : that's fair, too, although I'm not sure we want to be trying to track the differences on individual platforms :-/15:35
mnasergmann: if you have a few spare secs, wanna do that? i'm just gonna get the TZ info in so we can more easily find times to propose15:35
*** Luzi has quit IRC15:35
gmannmnaser: sure. will do15:35
*** AlanClark has joined #openstack-tc15:35
fungiin much the same way the default python2 on bionic is 2.7.15 (vs xenial's 2.7.12)15:35
mnaseri don't know if folks would even be available today :)15:35
gmanni will include today and tomorrow both15:35
zanebdhellmann: retrospectively applying the resolution, we need to keep py35 until everybody migrates to Bionic (can remove it for stable/stein if that happens by the release)15:36
mnasergmann: ++15:36
dhellmannzaneb : yeah, ok, that seems like a simple enough solution for stein15:36
fungizaneb: problem is "everybody migrates to bionic" doesn't have a clear definition either15:36
zanebwe also said that py37 is coming and this it wouldn't hurt to add py37 jobs15:37
dhellmannit really seems to me that these transitions, when they happen, need to be treated as a goal and tracked that way15:37
dhellmannor at least tracked, if we use some other process15:37
fungiwhen do we consider that migration actually done? when all official deliverables' "standard" jobs (and what jobs are "standard" for that matter?) are at least run on bionic? or only run on bionic?15:37
dhellmannzaneb : let's focus on saying "should" (or "must") for now and get to "may" later15:38
zanebfungi: yeah. in future we'll ideally have a goal spelled out at the beginning of the cycle and tracked, with a definition of done and what will happen to you if you don't get it done15:38
dhellmannwe're doing goal planning right now, so do we want one for this for train?15:38
dhellmannfungi : at least seems reasonable15:38
zanebyes. for every release from now on really.15:38
fungiin the past at least, we just said "we're switching" and expected everyone to test what they could reasonably in advance and fix what they couldn't test in advance afterward15:38
dhellmannI feel like a flag day change is really the only way to do it for standard jobs.15:39
dhellmannif teams have custom jobs, updating those would be up to them15:39
fungiand if teams pin certain jobs to older images, we don't really know unless they tell us15:39
dhellmannI wonder if we could do something to make master jobs on older images fail automatically15:40
dhellmann"after the 2nd milestone, any job using xenial to test master will fail"15:40
dhellmannthe alternative, I guess, would be to not use versioned image names at all. then if something is pinned to "ubuntu" or "centos" it gets updated automatically. although that breaks stable branches.15:41
fungiif all official openstack projects moved to a dedicated zuul tenant we could maube enforce that in the base job for that tenant15:42
fungibut short of that, projects are able to define their own jobs to include or exclude whatever roles they like15:42
gmannmnaser: https://doodle.com/poll/9dpc9zxek5mdsg8p15:42
gmanntc-members please vote for timing of python3 ad-hoc meeting: https://doodle.com/poll/9dpc9zxek5mdsg8p15:43
openstackgerritMohammed Naser proposed openstack/governance master: members: convert to yaml  https://review.openstack.org/64170015:47
mnasergmann: thats such a neat service15:49
mnaserthanks for putting it together15:49
mnaserlooks like we have 6 people in at 4pm est ~5 hours, i'll give it an hour or two more and lock it in unless we have a drastic change15:54
gmann+115:54
mugsie9pm UTC?15:54
mnaseraccording to my math yes15:55
mnasergmann: do you want to push out a quick email with the needed tags to the ml?15:55
fungithanks, adding myself a reminder for 2100z15:56
gmannmnaser: sure.15:56
mnaseri'll confirm the time in an hour or so if we don't have any more changes15:56
* mnaser runs off to run errands15:57
* zaneb updates calendar15:57
*** marst has quit IRC15:59
*** marst has joined #openstack-tc16:00
gmannhttp://lists.openstack.org/pipermail/openstack-discuss/2019-March/003594.html16:08
*** jamesmcarthur has joined #openstack-tc16:08
mnaserthanks gmann16:18
gmannnp!16:19
*** AlanClark has quit IRC16:26
*** AlanClark has joined #openstack-tc16:27
*** AlanClark has quit IRC16:54
lbragstadmugsie if i take an initial crack at rewriting #3 on the help most needed list to fit this format (https://review.openstack.org/#/c/637025/) would you be willing to review or correct me?16:59
*** dtruong has joined #openstack-tc17:03
*** e0ne has quit IRC17:07
mriedemjamesmcarthur: what does it take to get a project mentioned in the forum submission tools list of "OpenStack Projects Mentioned"?17:08
mriedemb/c placement isn't in there but it's a separate project now https://governance.openstack.org/tc/reference/projects/placement.html17:08
ttxin the spirit of using free tools, I'll point out that framadate.org is an open source and openly-hosted Doodle equivalent :)17:08
jamesmcarthurYou've come to the right place :)17:08
jamesmcarthurmriedem: I'll take care of adding it for you.17:08
mriedemjamesmcarthur: great thanks17:08
jamesmcarthurmriedem: Happy to help!17:09
lbragstadmnaser feel free to ping me prior to the python3 meeting today17:14
*** dtroyer has left #openstack-tc17:19
*** ricolin has quit IRC17:22
mriedemhmm, so thinking out loud about this proposed goal for OSC CLI thingies,17:23
mriedemi'm not sure if it would be useful to have a nova-specific forum session about actually getting some of that work done, or maybe that's just ptg fodder, although we talked about it in denver and nothing came out of it17:23
mriedemi'm sure the forum session would be, "should we do this? yes. who is going to work on it? crickets."17:24
bauzasthe problem is about resources17:24
bauzasagain and again17:24
bauzasif we have owners, cool cool17:24
mriedemwell, part of the problem there is we have no plan17:24
bauzasbut maybe a TC goal is a good signal for companies17:24
mriedemcompanies schmumpanies17:24
mriedemthey don't care17:25
bauzaswell, https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc already has notes17:25
mriedemso maybe a session could be, target closing the gaps to 2.25 and assign owners17:26
mriedemand talk through them to see if there are some we actually don't need to do17:26
* bauzas nods17:28
fungistrikes me as more ptg than forum, but i could see it being a little of both17:32
*** dtantsur is now known as dtantsur|afk17:34
mriedemi think i'm looking for people that don't normally show up in the nova room at the ptg17:35
mriedemand i don't want to slot time for it at the ptg again honestly17:35
jamesmcarthurmriedem: Placement is now up on the list of tags17:35
mriedemjamesmcarthur: thanks again17:35
jamesmcarthurnp17:35
bauzasfungi: we can discuss on the PTG about what or how work for having OSC supporting some nova microversions, but we also need users at the forum that we don't usually get at the PTG for at least knowing their own PITAs they have when they use OSC17:37
bauzassorry for PITA, let's say pain points17:37
mriedemi think i'm basically looking for like a slotted time with mordred in the room to just bounce this off of17:39
jrollpita is delicious, no need to apologize for it17:39
mriedemsince i know he's dealt with this in shade and the sdk17:39
*** marst has quit IRC17:41
fungiahh, yes, user feedback on what to prioritize in closing the feature parity gap does strike me as squarely forum material17:42
fungigetting mordred to wander into an arbitrary room at the ptg, on the other hand, is also not too hard17:43
fungijust have to bait the lure appropriately17:43
bauzasah, dtroyer isn't in the room now17:43
bauzasmriedem: do you remember what dean was telling about some OSC changes for supporting microversion discovery when we had the sydney forum session ?17:43
mugsielbragstad: definitly, that would be great - thanks17:43
clarkbfwiw I really like the way shade (or that subset of the sdk now) handles microversions17:43
bauzasno notes were taken from it https://etherpad.openstack.org/p/SYD-forum-nova-osc17:44
* bauzas won't provide a sad panda gif17:44
clarkbI think it maps onto the user facing cli well too. Basically don't make the user think about them. Use microversions when the user requests a feature that requires a microversion17:44
mriedemdamn where is the openstack-dev archive again?17:45
mriedemgoogle continues to fail me17:45
bauzasyup, users shouldn't care of microversions unless they explicitely ask for it17:45
clarkbmriedem: http://lists.openstack.org/pipermail/openstack-dev/17:45
*** marst has joined #openstack-tc17:45
mriedemthanks17:46
bauzashuhu site:http://lists.openstack.org/pipermail/openstack-dev/ works with google17:46
fungiyeah, the main downside we've noted with list deletions is that the archives are no longer included in the normal list index. i suggested we could programmatically generate an index of retired list archives by comparing what we have on disk with what's configured in mailman17:55
*** mriedem is now known as mriedem_afk17:58
*** irclogbot_3 has joined #openstack-tc18:01
openstackgerritMohammed Naser proposed openstack/governance master: members: convert to yaml  https://review.openstack.org/64170018:06
*** zbr|ssbarnea has joined #openstack-tc18:11
*** zbr has quit IRC18:13
*** e0ne has joined #openstack-tc18:19
*** jpich has quit IRC18:20
*** e0ne has quit IRC18:24
*** e0ne has joined #openstack-tc18:29
openstackgerritLance Bragstad proposed openstack/governance master: Elaborate on the business value of documentation owners  https://review.openstack.org/64175018:32
*** e0ne has quit IRC18:33
openstackgerritLance Bragstad proposed openstack/governance master: Elaborate on the business value of documentation owners  https://review.openstack.org/64175018:37
*** mriedem_afk is now known as mriedem18:40
openstackgerritLance Bragstad proposed openstack/governance master: Elaborate on the business value of goal champions  https://review.openstack.org/64177319:40
openstackgerritLance Bragstad proposed openstack/governance master: Elaborate on the business value of documentation owners  https://review.openstack.org/64178420:03
openstackgerritLance Bragstad proposed openstack/governance master: Elaborate on the business value of Glance  https://review.openstack.org/64178420:03
*** dtroyer has joined #openstack-tc20:07
*** jamesmcarthur has quit IRC20:23
*** jamesmcarthur_ has joined #openstack-tc20:23
fungiptl election update: we've got candidates for 16 out of 63 teams so far (25%)20:23
openstackgerritLance Bragstad proposed openstack/governance master: Elaborate on the business value of Designate  https://review.openstack.org/64179020:26
lbragstadmugsie ^ i shuffled a bunch of bits around and attempted to keep things relatively bite-sized... i likely missed a bunch20:26
openstackgerritLance Bragstad proposed openstack/governance master: Elaborate on the business value of Glance  https://review.openstack.org/64178420:28
jrollbusiness value: users hate remembering IP addresses. operators hate manually updating DNS. :P20:28
lbragstadwfm20:28
*** marst has quit IRC20:32
*** e0ne has joined #openstack-tc20:35
*** marst has joined #openstack-tc20:42
fungijroll: technically speaking, dns came about so we could stop copying massive /etc/hosts files over uucp nightly20:44
fungiso we *did* have a solution to the remembering ip addresses problem ;)20:45
zanebbusiness value of designate is that OpenStack can actually address a market where real apps are deployed, and they can be updated with cloud deployment patterns. without it you're deploying toy applications that nobody uses, or you're calling up the IT department every time something changes, or you're not able to make major changes to its infrastructure at all despite running on a 'cloud' platform20:46
jrollheh, fair enough :)20:46
mriedemlbragstad: comment on https://review.openstack.org/#/c/641773/ but lgtm20:46
fungijroll: rfc 952 and 953 are fun reading20:47
fungialso i was exaggerating with uucp, by then most sites were relying on ftp anyway20:47
fungiand i guess rfc 606 and 608 were the earliest official references but lacked sufficient standardization20:50
fungi"Now that we finally have an official list of host names, it seems about time to put an end to the absurd situation where each site on the network must maintain a different, generally out-of-date, host list for the use of its own operating system or user programs."20:51
fungithough rfc 597 is where an official list of host names is first formally proposed20:53
fungias distributed in the periodic arpanews publication20:54
smcginnisToo bad there was never a hostfilev6 where everyone could send yearly reminders about how the available unique names would soon be depleted.20:55
mnasertc-members: our small ad-hoc python3 meeting is happening in 2 minutes (cc lbragstad gmann mugsie zaneb fungi dhellmann -- those who put down times they are available) -- i setup https://etherpad.openstack.org/p/python3-meeting with a quick small agenda20:58
mnaserplease feel free to add/remove if necessary20:58
fungii'm around, thanks for organizing!20:58
lbragstado/20:59
fungismcginnis: i think they had room for 38^24 names, so probably nowhere near running out before dns was invented21:00
mnaser#startmeeting tc-python321:00
openstackMeeting started Thu Mar  7 21:00:04 2019 UTC and is due to finish in 60 minutes.  The chair is mnaser. Information about MeetBot at http://wiki.debian.org/MeetBot.21:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.21:00
*** openstack changes topic to " (Meeting topic: tc-python3)"21:00
openstackThe meeting name has been set to 'tc_python3'21:00
mnaser#topic rollcall21:00
mnasero/21:00
*** openstack changes topic to "rollcall (Meeting topic: tc-python3)"21:00
mnaserpeople are excited about python321:00
mnasersweet21:00
fungii have a feeling the excitement is more about !python321:01
fungier, !python221:01
mnaser#topic introduction21:01
*** openstack changes topic to "introduction (Meeting topic: tc-python3)"21:01
mnasercan someone give us a brief about what's been happening? we all know python3 is going away, but just how far we've gotten, what's gotten done,?21:01
zanebo/21:02
smcginnisSomeone have the link to dhellmann's tracking page?21:02
gmanno/21:02
mnaser(and really, why we've needed to have this meeting too, considering i think a lot of tc and community members maybe hasn't been able to follow up as much with this21:02
dhellmannsmcginnis : do you mean this? https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects21:02
smcginnisdhellmann: Yep, thanks.21:02
mnaser#link https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects21:03
zanebso I understand it this meeting is about which versions of Python3 to test in Train/Stein21:03
dhellmannthat really only tracks test jobs for any version of python 321:03
mugsieo/21:03
zanebnot about which projects have migrated to python 321:03
mnaseri'm just trying to make our meeting notes somewhat consumable by a our community21:03
zanebso, as a reminder we passed a resolution on how we'll make these decisions starting with Train21:03
zaneb#link https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html21:04
zanebthe answers should fall out of that without us having to apply too many judgement calls21:04
fungipretty sure we need to test python 2.7.15 and 3.6.something in stein at a minimum. depending on what rhel 8 releases with and what opensuse leap have that may need extending further?21:04
fungier, s/stein/train/21:04
zanebbut it does rely on us doing it at the beginning of a cycle and setting up goals and expectations21:04
zanebwe were too late to do that for Stein21:05
zanebI think in this meeting we should get to the point where we know what we're doing for Train21:05
fungiyeah, basically whatever minor python versions are the default python and python3 for the three platforms we list there21:05
gmannyea, but we at least start from Stein what and how much we can do like latetst distro thing21:05
zaneband that will help us to provide guidance for what projects should do right now in Stein21:05
mnasermakes sense, so zaneb you're suggesting we come up with something for train, but start working on it in now21:06
mnaserso we don't necessarily ship with that goal, but at least we'll be ready for it by then21:06
mugsiethat gives us the time to get things in place, so seems like a solid route forward21:07
fungiretroactively applying stein we need to test 2.7 because that's what ubuntu 18.04 and centos 7 have for default python2, and python 3.6 because that's the default python3 on ubuntu 18.04 (those platforms chosen because they were the latest lts for each distro at the start of the stein cycle)21:07
zanebwe need to start preparing the Train goal now. but also we need to know what it's going to say so that we know what makes sense to do in the meantime before this process kicks in21:07
zanebfungi: can we please deal with Train first?21:07
fungisorry, gmann asked to start with stein21:07
dhellmannare we changing distros for train?21:08
fungiafter i started with train21:08
mnaserwe still need to figure out stein, otherwise, we'll ship something that will be problematic for deployers21:08
fungibut i'm happy to be quiet and let you all decide which you want to talk about first21:08
mnasergmann: is this why you put the idea of porting legacy jobs to bionic?21:08
gmannyeah, we have half of the jobs testing bionic and half xenial.21:08
gmannyeah21:09
zanebso there are 3 bullet points in the resolution. let's go through them one at a time for Train21:09
zaneb1) The latest released version of Python 3 that is available in any distribution21:09
zanebI submit that this is py37 for Train21:09
zanebany disagreement?21:09
mugsienot from me21:09
fungisounds likely unless centos 8 comes about before then and has python 3.8. doubtful21:09
zaneb2) Each Python 3 version that is the default in any of the PTI distros21:10
mnaserwe don't know what distros will be in train21:10
mnaseri don't think we have a centos 8 release date21:10
*** marst has quit IRC21:10
zaneblet's assume centos 721:10
mnaserpython3 doesn't exist on centos 7.21:11
mugsiemnaser: we pick them in advance, so if centos 8 is  not released before the start of train, we stick to 7.521:11
fungiright, i think the point is we don't know *now* what will be available at the start of the train cycle21:11
zanebI don't think it actually makes any difference, because we've said we support py27 until U, and py36 is the default on both centos8 and ubuntu bionic21:11
mugsiethats easy then21:11
mugsieunless leap is different?21:12
zanebSo I believe this is py27 and py3621:12
fungigood point, we can deduce since we know it won't be 3.5 in centos 8 and 3.8 isn't due to release until october21:12
zanebdon't know about leap, but I assume it's py3621:12
zanebif it's 37, well, we already put that on the list from (1)21:12
mnaseri think rhel 8 preview had a python version21:12
mnaser" In Red Hat Enterprise Linux 8, Python 3.6 is the default."21:13
mugsieit is 36 for leap 1521:13
mnasercentos 8 being a rebuild, will have 3.621:13
mugsieso 36 it is21:13
fungiproblem solved then21:13
mugsie3.6*21:13
zanebok, so the list so far is py27, py36, py37 (incorporating both (1) & (2))21:13
zanebnow for the fun one21:13
fungitrain=2.7,3.6,3.721:13
zaneb3) Each Python 3 version that was still used in any integration tests at the beginning of the development cycle.21:13
zanebsoooo21:13
fungithis is up for interpretation as i mentioned before21:14
zanebthe plan is to switch everyone to bionic before Train21:14
zanebin which case it's only py36, and no changes here21:14
fungii take it to mean any version that can't be updated in integration tests early in the cycle21:14
zanebif we didn't manage to get everyone to switch then we'd have to add py35 to the list21:14
*** e0ne has quit IRC21:14
zanebfungi: "Testing for these versions can be dropped once all integration tests have migrated."21:15
mnaserjust to recap so far, does that mean train will have 2.7, 3.6 and 3.7 so far (and potentially 3.5 if we don't get rid of it this cycle?)21:15
zanebbut at the beginning of a cycle, it's based on the status at the beginning of the cycle21:15
fungiyeah, i'm less and less sure it actually specifies a unique limitation on its own21:15
zanebmnaser: correct21:15
mnaser#topic Decide on py3 targets for Train + Discuss recommendations for Stein21:16
*** openstack changes topic to "Decide on py3 targets for Train + Discuss recommendations for Stein (Meeting topic: tc-python3)"21:16
mnaser(for my sakes later, let's keep going)21:16
mugsiefor unit testing21:16
mnaserdoes this lead us to discussing the potential idea of porting legacy jobs to bionic?21:16
fungiif it can be dropped later in the cycle then it's unclear to me why it matters that we know it was used at the beginning of the cycle21:16
zanebmnaser: yes, this would be a good point to discuss that21:16
mugsiefungi: i think it is so we have a clear leist21:17
*** whoami-rajat has quit IRC21:17
mugsielist*21:17
mugsiethat we then edit when the migration happens21:17
mnaser#topic porting legacy jobs to bionic <gmann>21:17
*** openstack changes topic to "porting legacy jobs to bionic <gmann> (Meeting topic: tc-python3)"21:17
mnaserthis seems like a really big leap21:17
mnaserhow much do we risk breaking by this21:17
mnaserhow different is 3.5 from 3.6 ?21:18
fungiso rephrasing for my benefit, as i'm still quite confused, "if we can't get all official projects integration tested with the versions we said we require in #1 and #2, then we require that all projects also remain tested on the earlier version"21:18
gmannmostly it should be internal script used21:18
mnaser(fwiw, i think consuming less test resources is always nice, rather than us testing a ton of targets)21:18
mnaserso there's value in that.21:19
mnaserare we more concerned that stuff that's not python wuld break under bionic?21:19
zanebfungi: yes, as long as there are gates running on py35, another project dropping support for py35 could break that gate21:19
mugsiefor the start of train, we will unit test with 2.7, 3.6, 3.7 (and 3.5 if the move to nbionic does not happen)21:19
gmannmnaser: yes that is going to be main blocker.21:19
fungii guess this is to avoid "the trove effect" we saw at the trusty to xenial transition where all other projects had switched to running jobs on xenial and started merging changes which broke trove because it was still testing on trusty (even months after the release)21:20
dhellmannI think we should clarify that "all projects" statement, though21:20
dhellmannI wouldn't want cloudkitty to require nova to keep py35 tests, for example21:20
mugsieyea. the "integration tests" line makes me think of the integrated gate21:21
fungiin effect, at the trusty to xenial switch we accepted that the trove team's lack of resources to get their jobs updated would not hold up other projects dropping support for trusty21:21
dhellmannmugsie : yeah21:21
gmannand we do not have all project cross integration testing so i cannot think of more than 7-8 projects combination21:21
zanebyeah. we left it up to the goal champions to define if there would be a hard cutover for laggards21:21
dhellmannthe integrated gate is 1 job, right? that's the whole point?21:21
dhellmannor at least 1 set of all the same jobs21:22
dhellmannso those projects would all move at one time21:22
mugsiegmann: well -  there is more than that if you take jobs outside of the integrated gate21:22
gmanndhellmann: two, tempest-full and grenade but those are used in small number of projects21:22
dhellmannand other projects could lag but we could say that support for the older images would be dropped at some point21:22
zanebthe problem is, we could organise an orderly transition in Train with lots of advance publicity of when things will break and plenty of time to fix. but if we do we have to unit test py35 in Train21:22
mugsiemost of the "non core" projects rely on some of the core services21:22
fungialso i think this is once again conflating platforms and python versions. in the trusty-xenial switch it was still python 2.7 on both sides. what changed was the platform not the python version we were running, and what broke trove was other projects dropping support for features of the old platform or starting to rely on features of the new platform21:23
zanebalternatively, we can try to ram through the change in Stein at the last minute, in which case we get to drop py35 for Train21:23
dhellmannzaneb : I don't think we want to interpret that rule as meaning that if we start out with something we're not allowed to drop it.21:23
dhellmannI think we want to focus on the end state we want for each cycle, not the start state21:23
zanebI'm actually in favour of the latter fwiw21:23
mugsiewe can drop 3.5 unit testing later in the cycle when it is less likey to break prpjects21:24
zanebdhellmann: we could drop it once the goal was complete (and we did explicitly say that in the resolution)21:24
dhellmannright21:24
dhellmannso if we don't drop 35 during stein, that doesn't mean we can't drop it during train21:24
fungii think where the start state matters is that we need to be able to give projects fair warning of what we expect them to be running and so we have to decide at the start of the cycle what the target is and thus can't realistically choose a target which won't be available for use until later in te cycle21:24
dhellmannwe should just need to declare the intent21:24
zanebagreed21:25
dhellmannfungi : yes, good point. we can't *add* something late, but we can drop something21:25
fungiprecisely21:25
dhellmannif that's not clear in the "rules" we should fix that21:25
*** mtreinish has quit IRC21:25
mnaserfungi: makes a really good point about mixing things21:25
zanebwe couldn't drop it *from the beginning* but we could announce that we had a plan to drop it during the cycle21:25
dhellmannzaneb : sure. we would want to set a reasonable date for it21:25
mnasergive me a break on this, how hard would it be to run a 16.04 image with py36 ..21:25
fungiso for example, if centos 8 is not available officially at the start of the train cycle, we tell them centos 7 is the target for the train release21:25
dhellmannM1, M2, whatever21:26
fungieven if we expect centos 8 to be available later in train21:26
mugsiefungi: yes, thats how I see it21:26
*** mtreinish has joined #openstack-tc21:26
dhellmannfungi : I think that's fair. And we can say that projects could optionally add centos 8 jobs but we wouldn't require it.21:26
mugsiesure, if people want to be proactive, thats great :)21:26
mnaserthat way we can split the python version <=> ubuntu platform problem21:26
fungimnaser: again, what we're testing is not actually "python 3.6 on bionic" it's "the python3 which ships with bionic" so compiling our own or using backports isn't really the same thing21:27
* mnaser wishes we lived in a world where "python3.6" and "python3.6 that ships with bionic" was the same thing21:27
mnaserbuuut anyways, we've come up with a lot of ideas.  does this mean that for stein we'll try to push projects to drop py36, but not aim to drop it in this cycle?21:28
fungimnaser: or at least, in the past we made the conscious decision that what we test against is the python interpreter provided by each platform we're targeting, not some ideal python x.y interpreter21:28
zanebmnaser: I think you mistyped that :)21:28
dhellmannmnaser : not drop 3.6, drop 3.521:28
fungimnaser: for stein i think we push to drop 3.521:28
mnaseroh yes21:28
mnasersorry21:28
gmannyeah 3.521:28
zanebso IMHO, no21:28
dhellmannwe could do that, but I'm also content to just say they need to include 3.621:29
zanebat the start of the cycle, all tests were on Xenial, so I think 3.5 was a reasonable target for Stein21:29
fungibullet #3 if i'm interpreting it correctly is that if we can get projects testing 3.6 (that is, bionic) in time for the stein release then they don't need to be running 3.5 (xenial) come release time and we don't need to support both for stable branch testing21:29
fungiwhich gets dicey if we want to continue maintaining stable/stein after xenial reaches eol21:30
zanebif we do manage to move completely to Bionic it would be a close-run thing21:30
mnaserbionic ships 3.6, we listed bionic as a platform, does that mean we need to get projects to add py36 as a target in stein?21:30
zanebbut if we manage it then we could tell projects to drop py35 on stable/stein21:30
fungiat the start of the cycle, bionic was available (well before the start of the cycle even) so mograting to xenial was a given based on our past transitions21:30
zanebmnaser: we do, and we actually *did* make that a goal for Stein21:30
zanebso, yay for us :)21:31
mnasersweet.21:31
dhellmannhow close did we come to accomplishing it? that's still in progress, right?21:31
fungiwe decided to design-by-committee the transition until it's now nearly too late to pull the trigger and be able to drop xenial testing when we drop stable/rocky21:31
zanebdhellmann: aren't you the goal champion? ;)21:31
*** corvus has joined #openstack-tc21:31
dhellmannnot for this, no21:31
gmannyeah, not all projects has started the legacy jobs - https://etherpad.openstack.org/p/legacy-job-bionic21:31
dhellmannoh, well, I guess sort of21:31
dhellmannI wasn't worried about the OS,  just the python version21:32
zaneb#link https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs21:32
zanebdhellmann: ahem https://governance.openstack.org/tc/goals/stein/python3-first.html#champions21:32
dhellmannI like the idea of dealing with the python version unit tests by having a series-specific name template for those21:32
fungithe "python version" is still a red herring here, but i've just about given up convincing anyone of that21:32
dhellmannzaneb : yeah, like I said, just the python version, not the OS version21:33
dhellmannfungi : I understand, but I'm trying to make the point that I didn't do any work to deal with updating the OS version21:33
zanebright, that was *not* a goal that we set21:33
zanebalthough in retrospect we should have21:33
fungiat least from the "what can we reasonably test" end of things, we lose the ability to test what we intended when the platforms which shipped them cease to receive security updates and bug fixes21:34
fungiso the choice we make here has far more bearing on stable branch lifetimes21:34
zanebfungi: you're bringing this up w.r.t. the issue of continuing to unit test py35 (on Xenial) in stable/stein?21:35
dhellmannso for train, we need to say "3.6 on bionic" right? and 3.7 somewhere?21:35
fungizaneb: yes, exactly21:35
zanebfungi: I think that's fair, but also if it turns out we're still running integration tests on xenial by the time Stein releases, then the unit tests are the least of our problems21:36
zaneband if we're not we can drop the py35 unit tests21:36
fungias of the rocky release there was already a newer lts distro available so our maintaining use of the old distro in our ci should die with that stable branch, essentially21:36
mnaserwe have a lot of similar colors, but it looks like someone has written some conclusions21:38
mnaserhow do we feel about those?21:38
zanebmnaser: that's me21:38
fungiwe're running most integration testing on bionic at this stage, right? it's the "legacy" jobs which are still relying on xenial at this point?21:38
gmannL27 on etherpad-  we should be conclusive there. either to complete the migration or  keep testing all for old ditro21:39
mnasergmann: might be the best person to answer that21:39
gmannfungi: correct. only legacy jobs on xenial21:39
zanebfungi: so I think what you're saying is we should force everyone to migrate from xenial->bionic in stein, even though it's at short notice21:39
fungiwhere short notice is since the beginning of this cycle, yes21:39
mnaseri hate to say it, but i think it might be a very necessary evil, also, i don't think a lot of projects are going to be much suffering out of it21:39
gmannzaneb: yes. but leaving thing tested in mixed way might cause issue on stein deployment21:40
mnasermost apt packages are still there, and i doubt ubuntu 16 => 18 has had a ton of fundamental cahnges for example21:40
zanebfungi: not disagreeing with you about the solution, but we didn't give them notice21:40
mugsiemnaser: it depends on the projects21:40
fungibefore this go-round, the infra team told everyone "okay there's a new lts, everybody get your stuff in order and move" but this time around we (the tc) got to take responsibility for sending that message21:40
mugsiee.g. trusty -> xenial had a completly new powerdns which broke us badly21:40
mnasergmann: do we know which projects have not yet migrated?21:41
mugsiebut we did warn at the start of the cycle21:41
mnasermugsie: yeah i can imagine that's a scenario where it might happen21:41
zanebfungi: right, and we didn't send the message until very recently AFAIK21:41
mnaserthe thing is, most people will be doing new deploys on 18.0421:41
* mnaser has done plenty of 18.04 rocky deploys and we do it in OSA CI21:41
gmannmnaser: almost all the projects use 50% of their gate job as legacy job which means xenial21:41
gmannthose jobs are either owned by projects or in infra21:41
mnaserbut most projects aren't like designate for example, where there is   very strong fundamental base on a system service21:42
fungizaneb: depends on which message. some of us did say well early and repeatedly over the course of the cycle to get it done21:42
fungithe tc didn't make an official proclamation from on high to get it done because we couldn't agree on the words we wanted to use to plan similar transitions which won't happen for a couple more years21:43
mnasercan we try an experimental job across a few major projects with legacy job running?21:43
gmannfor example neutron stadium has lot of testing and seems good there - L64 on https://etherpad.openstack.org/p/legacy-job-bionic21:43
gmannmnaser:  you mean legacy job running with xenial or bionic ?21:43
mnaserlegacy job running bionic21:43
fungimnaser: the problem there is the "legacy" jobs are basically the one-off project-specific stragglers those various teams haven't gotten around to converting21:44
zanebfungi: we have a mechanism for co-ordinating changes across the whole project and we didn't use it. you can argue that people shouldn't be surprised, but people *will* be surprised21:44
zaneb(I think we should do it anyway)21:44
gmannyeah so converting legacy  base jobs on bionic move most of projects gate to bionic21:45
fungimnaser: so running one or even a few doesn't tell us much, nor does running them on other projects than the ones for which they were specifically written21:45
mugsieand the people who helped create some of these one of jobs are not always around, which makes migrations harder21:45
fungiyes, i would argue that if your team doesn't understand the jobs it's running, those jobs are a liability and better dropped21:45
mugsieyeap21:45
dhellmannat least if no one is willing to figure them out21:45
gmanntoday i am trying to move the infra owned legacy job to bionic which run on many projests gate21:46
gmannfungi: +10.21:46
mnaseri'd like to propose and ask if there is anyone opposed to removing xenial this cycle (it's painful yes, but anyone who deson't feel its not the right thing)21:46
mnasererr rather who feels it's not the right thing to do, painful or not21:46
dhellmannwhat does "remove xenial" mean exactly?21:47
fungigmann: when yuo say "the infra owned legacy job" you specifically mean the legacy devstack-gate job which other projects are inheriting from? that job itself isn't run directly by any project right?21:47
mnaserchange the legacy jobs to use bionic21:47
gmannfungi: these - http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/zuul-legacy-jobs.yaml21:48
dhellmannare the legacy jobs the only ones using xenial still?21:48
fungigmann: oh, jobs plural. you said "legacy job" so i wasn't sure which one you were referring to21:48
mnaserdhellmann: i think converting those legacy jobs will move a huge portion of our jobs21:49
fungithe infra team has also considered those legacy jobs to be basically frozen in time, as they're nigh inscrutable and so not easy to troubleshoot if something goes sideways21:49
gmannin integration testing yes, legacy jobs are the only one using xenial.21:49
gmannfungi:  ohk, sorry for typo .21:49
gmannfungi: yeah I am going to give try and see how they behave. most of them are experimental jobs so should give projects times to fix21:50
dhellmannmnaser : I think it will. I'm trying to understand whether it's important to do it. If those are all 1-off jobs for each project, do they affect our ability to say the projects run on bionic?21:50
mnaserdhellmann: well i'm assuming most of those 1 off jobs inherit some sort of base from 'legacy' jobs21:50
fungiwhich is why for over a year the infra team has urged other teams to stop running legacy jobs in favor of writing newer jobs, because the time would come when they need to make changes (such as, say, running them on a newer platform)21:50
dhellmannmnaser : ok, I don't know how that works so I don't know if that's a safe assumption21:51
mnaserso i'm operating under the assumption that if we change the 'base' job, projects will just start using a different nodeset21:51
mnasercorrect me if im wrong gmann21:51
dhellmannwhat happens if we ignore the legacy jobs?21:51
gmannmnaser: dhellmann yes, majority of them are inherit from 'legacy-base' and 'legacy-dsvm-base'21:51
gmannand i will say 70%21:52
gmannor even more21:52
fungithere is a legacy-dsvm-base job the inherit from, yes21:52
dhellmannwould we have any projects with no testing on bionic at all if we did that?21:52
dhellmann(ignored them)21:52
corvuslegacy base is pinned to xenial now: https://opendev.org/openstack-infra/openstack-zuul-jobs/src/branch/master/zuul.d/jobs.yaml#L917-L92221:52
zaneball Heat jobs are legacy afaik21:52
gmanndhellmann: they do test bionic also which with all new devstack based jobs zuulv3. integrated-gate21:52
dhellmannthose 2 statements from zaneb and gmann are contradictary21:53
fungicorvus: thanks! i was still hunting for that line21:53
corvusoh this is a nice url too: http://zuul.opendev.org/t/openstack/job/legacy-base21:53
gmanni am not sure if heat run integrated-gate or not.21:53
zanebdhellmann: 'that' in your question was ambiguous21:53
*** edleafe_ has joined #openstack-tc21:53
dhellmannzaneb : sorry, I followed up with ()21:53
mnaserforgive me21:54
mnaserhttps://review.openstack.org/#/c/573228/21:54
mnaseri don't see any legacy jobs here?21:54
mnaserunless they've just been renamed21:54
zanebdhellmann: ah, so you did21:54
dhellmannso if we change the base legacy setting, does that just kick this can further down the road? don't we still have to have teams update those jobs? and don't those jobs also run on stable branches that may not work on bionic?21:54
corvushttp://zuul.opendev.org/t/openstack/job/heat-functional-orig-mysql-lbaasv2 -> http://zuul.opendev.org/t/openstack/job/heat-functional-devstack-base -> http://zuul.opendev.org/t/openstack/job/legacy-dsvm-base21:55
zanebmnaser: renamed https://git.openstack.org/cgit/openstack/heat/tree/.zuul.yaml#n221:55
gmannmnaser: many of the legacy jobs are renamed so it is hard to judge by name21:55
mnaserah tricky, okay, yeah, i just saw the zuul inventory file too21:55
dhellmannIOW, maybe the best long term thing is to say that those legacy jobs "don't count" towards testing and ignore them, upgrade all of the non-legacy jobs ("modern"?) and move on21:55
mnaserso what if we moved legacy jobs to non-voting and set nodeset to bionic21:55
gmanndhellmann: good question. the way i am modifyng the legcy base job is 1. they run on bionic in stein onwards adn 2. keep running on xenial < stei21:56
fungiwe do have the job inheritance tree we could use to root them all out, but i favor letting teams be responsible for identifying what jobs they need to deal with whether or not they've chosen to rename them21:56
gmannstein21:56
dhellmannmnaser : what impact will changing those jobs have on stable branches?21:56
mnaserdhellmann: it won't, according to the way gmann has had it setup21:56
dhellmannfungi : indeed21:56
gmannmnaser: what ever fail, move it to n-v is the good idea and project fix then make it v21:56
dhellmannah, sorry, I missed gmann's response there21:56
mnaserso if a project _desparately_ wants  to run legacy jobs, they have to mark it voting explicitly21:57
gmanndhellmann: yeah, stable testing is on xenial21:57
mnaserand if it breaks.. well they have to fix the legacy jobs but at least it won't block their current work21:57
dhellmannok, so my long-term question still applies. Should we try to fix this, or make them painful and encourage teams to deal with that?21:57
mnasermy opinion is that we should just change the legacy nodeset to bionic and have them all run bionic, if they break, they probably weren't good jobs in the first place21:58
mnaserand the teams can just move those jobs to non voting21:58
gmanndhellmann: it depends . either they migrate that job to zuulv3 which make it on bionic or fix with legacy definition if job is critical21:58
zanebI'm inclined to agree with mnaser, but I'm not an expert in this area21:58
fungianother alternative to making them non-voting is we let teams decide whether they pin them to xenial on their own if they want to continue running them, and understand that odds are other projects they're testing against may drop xenial support at some point (like what trove experienced when they clung to trusty for months after other projects switched to xenial)21:59
mnaseri'm starting to be more inclined to "you either have to set your jobs to non-voting (why are you running them?) or fix them (might as well as convert to new jobs)"21:59
zanebfungi: and also that stable/stein will eventually break when infra stops supporting Xenial, right?21:59
fungilegacy-base sets the default node type, but jobs inheriting from it can still override that21:59
fungizaneb: correct22:00
zanebthat needs to be in the warning22:00
gmannfungi: right so that will be done via audit of project team22:00
dhellmannok, what's the timing for making that change, given where we are in the cycle?22:00
mnaserbtw, xenial doesn't even have packaging for rocky.22:00
gmanni agree with the mnaser idea of making n-v on failed one and leave up to projects22:00
*** e0ne has joined #openstack-tc22:01
gmannfungi: how i do is check the job definition and find any overridden nodeset all the way till base job22:01
mnaserdoes anyone disagree on us changing default nodeset to bionic?22:01
dhellmannI support changing it22:01
lbragstadsame22:01
zaneb+122:02
* mnaser apologies for infra in advance and hopes that we can help them out with this22:02
gmann+122:02
mugsie+122:02
mnasernow the second argument: should we transition jobs to non-voting or voting for legay?22:02
*** jamesmcarthur_ has quit IRC22:03
mnaserif we move them to non-voting, they won't fail the gates of downstream users, but they risk merging broken code22:03
zanebmnaser: I thought we were saying we are leaving that up to projects22:03
mnaserjust wanted to get some sort of agreement22:03
fungigmann: i'm not sure which direction you're talking about. you can check the job browser in zuul to see what nodeset parent jobs of specific jobs set22:03
mnaserwe are leaving it to projects = we keep them voing in the base job?22:03
mnasers/voing/voting/22:03
gmannif they fail then tell projects that make it n-v to unblock gate of your project or other and fix or leave based on their decision22:04
dhellmannyeah, warn everyone, change the job, let them fix or set to non-voting22:04
zanebmnaser: yes, and if a project's gate breaks, they can make a job non-voting in their local Zuul config22:04
gmannyeah22:04
dhellmannnon-voting or just remove it22:04
fungiwe can do it the same day i proposed changing the base default nodeset as well22:04
gmannfungi: yes. that way and checkign job definition if changes are required.22:05
mnaserok, so legacy jobs will be moved to bionic nodeset and remain voting for master22:05
zanebfungi: if we put up a test patch for the nodeset change, can projects test it out using Depends-On? they can, right?22:05
mnaseris that accurate?22:05
gmannyeah, initial dadline i set little late (april 1st) but with new way of making n-v it can be early22:05
gmannzaneb: yes, that is how we have started till no22:05
gmannzaneb: project testing that way - https://etherpad.openstack.org/p/legacy-job-bionic22:06
mnaserand by doing this, we don't have py35 in train, right?22:06
fungizaneb: yes, depends-on changes to the openstack-zuul-jobs repository will work22:06
mnaserhttps://etherpad.openstack.org/p/python3-meeting22:07
zanebgmann: awesome. so we can give projects a little time to find out the impact (if any) and report back before we break them22:07
mnaserdo we agree whats under 'conclusions'22:07
fungi(the change i need to make to the project-config non-legacy base job on the other hand, depends-on doesn't help us)22:07
gmannyeah22:07
gmannmnaser: whats the deadline we should give to projects for legacy job moving ?22:07
mnaserfungi / clarkb might have useful input on that22:08
fungii vote for wednesday to coincide with the base job change i've proposed22:08
mnaserwe don't want to make it too late either22:08
gmann13th.22:09
mnaserdoes that date seem to make sense for most?22:09
mnaserwe can start sending warnings and give advice on how to test with depends-on22:10
fungii picked next week because the following week is rc target so would be a bad choice, and after rc is worse because some projects will be branching from rc122:10
mnaseranyone opposed or we're okay on that?22:10
gmannall ok seems :)22:11
zanebit seems very early given that projects _could_ be testing and fixing using Depends-On before we go ahead and possibly break them22:11
zanebthat said, timing argument from fungi is also compelling22:11
gmannbut testing effort has been started on Feb 25th22:11
mnaserok.  action items because i'm sure y'all are getting tired22:12
gmann#link http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003129.html22:12
mnaserPropose openstack-python3-train-jobs Zuul template22:12
fungiwell, true, we could push the legacy-base default nodeset change to later if we wanted to give teams longer to depends-on test against it, as i said that isn't the case for the project-config change to the non-legacy base job22:12
fungisince depends-on won't work there22:13
mnaseris openstack-python3-train-jobs necessary?22:13
zanebfungi: is there an advantage to doing them together?22:13
mnaseror can we tweak the job defn' so py35 doesnt run on master anymore?22:13
gmannfungi: 13th ok as first. giving lot of time to projects end up no action from them :)22:13
fungizaneb: reducing confusion is the main advantage i foresee22:13
mugsiemnaser: we said that we wouold did it in the resolution22:13
zanebmnaser: train not stein22:13
dhellmannmnaser : I think we want to get projects used to the idea of updating these settings regularly22:14
mnaserok cool22:14
mnaserso does anyone wanna pick that up?22:14
zanebI can take that one22:14
mnaser#action zaneb Propose openstack-python3-train-jobs Zuul template22:14
mnaserEmail ML with recommendations for projects in Stein22:14
mnaseri don't wanna throw more work at gmann but i feel he'd be best at taking care of this :)22:15
zanebI can also take that one if we are agreed on the stuff in the conclusions22:15
gmannthis is for py versions ?22:15
mnaseryes, what we have under 'conclusions'22:15
mnaserif zaneb wants to get this, then sure22:16
mnaser#action zaneb Email ML with recommendations for projects in Stein22:16
zanebI'll take it and let gmann have the next one :)22:16
gmannyeah, that why i did not opt :)22:16
mnasercool22:16
mnaser#action gmann Notify ML with nodeset base change22:16
mnaserzaneb: i guess your email will put context of todays meeting22:17
mnaserso we probably don't really need an extra update?22:17
mnaserwe can just link to the logs here22:17
mugsiei dont think so22:17
zanebyeah, I can do that22:17
mnaseri think we probably need to update our docs to reflect PTI for train22:17
openstackgerritLance Bragstad proposed openstack/governance master: Elaborate on the business value of Glance  https://review.openstack.org/64178422:17
mnaserwhich is creating a page similar to https://governance.openstack.org/tc/reference/runtimes/stein.html22:18
mnaserdo we want to hold off on that fro now?22:18
mnasers/fro/for/22:18
fungithe contents might even be basically identical22:18
zanebit's missing Leap22:19
mnaseryep, we added that22:19
zanebbut yeah, I see no reason not to go ahead and copy it now for Train22:19
mnaseranyone want to take up that action with the info from the etherpad?22:19
mugsieo/22:19
mnasercool22:19
mnaserthanks mugsie22:19
fungioh, right leap is new for train22:19
mnaser#action mugsie Update governance repo for Train PTI22:20
mnaseri'm really happy we flushed all this stuff out, took way longer than i thought :)22:20
mnaserbut i think it's the best outcome22:20
mnaserthanks for everyone's patience <322:20
lbragstado/22:20
fungithanks for putting this together mnaser!22:20
mugsieo/22:20
mnasernow buy flamesuits when everyone finds out they're switching to bionic22:21
mnaserSURPRISE22:21
mnaser#endmeeting22:21
*** openstack changes topic to "OpenStack Technical Committee office hours: Tuesdays at 09:00 UTC, Wednesdays at 01:00 UTC, and Thursdays at 15:00 UTC | https://governance.openstack.org/tc/ | channel logs http://eavesdrop.openstack.org/irclogs/%23openstack-tc/"22:21
openstackMeeting ended Thu Mar  7 22:21:07 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:21
openstackMinutes:        http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-07-21.00.html22:21
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-07-21.00.txt22:21
openstackLog:            http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-07-21.00.log.html22:21
zanebmnaser: good idea to have a separate meeting for this :)22:21
gmannthanks everyone and mnaser !22:21
mugsiegood night all o/22:22
corvusmnaser and the rest of the tc: i wanted to bring your attention to this message: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html22:22
gmannmugsie: have good sleep.22:22
*** tosky has quit IRC22:22
fungicorvus: yay! progress22:22
mnaser"we will automatically merge appropriate changes to all branches of all repositories updating .gitreview and Zuul configuration files." i hope this is some sort of hardwire-skip-ci change ;p22:22
fungiyes22:23
fungiit's on me to work that part out22:23
corvusi think there are some decisions the tc can make about project identity and namespace, etc, so good to start thinking about it now22:23
mnaser"* Integrated code searching"22:23
fungibut my plan is the commits will be pushed directly into the backend git repositories on the gerrit server while it's offline22:23
mnaserneat, one of the biggest reasons why i checked github often22:23
corvusmnaser: yeah, we're pretty excited about that.  codesearch (hound) is great, but it's even better to have it integrated: https://opendev.org/explore/code22:24
fungialso hound has a few unfortunate shortcomings like not searching branches besides master, lengthy downtime to reindex everything any time we change the list of repos, inexplicable max-files limit issues22:26
fungigranted, we don't necessarily know what shortcomings the search in gitea may have without people trying stuff in it22:26
corvuszaneb: and i think we got all the rewrite rules so that all deep cgit links will redirect properly :)22:27
fungiall we really know is it's not the _same_ shortcomings as hound ;)22:27
fungicorvus: and if we discover any new ones we can always adjust the set of redirect rules22:28
fungi(hopefully whatever else we might have missed doesn't mean more feature patches to gitea upstream)22:28
corvusthey merge them quickly :)22:29
fungithat's fore sure true22:29
fungiway faster than openstack's average review time! ;)22:29
*** tosky has joined #openstack-tc22:29
mnaserdoes this change mean that openstack infra team is no longer a thing?  puts openstack as just another 'tenant' as other projects?22:30
fungithe openstack infra team is, at least for the foreseeable future, an overlapping thing with the opendev team22:30
mnaserand i guess the question regarding the resource access, afaik nodepool isnt tenanted in this sense22:31
fungithere are at least a few services we're going to continue maintaining for the openstack project which we wouldn't include as a part of the opendev suite (at least not in present form)22:31
mnaserso say, if the linux kernel decides to join opendev (yay!) but starts using up all the openstack donated infrastructure22:31
mnaseror at least they were planned to be openstack at least22:31
corvusagree with fungi -- i think there will be a group of people interested in supporting openstack's use of opendev.  and there will be people interested in supporting zuul's use of opendev.  and starlingx.  and airship.  and hopefully all those people will work together on opendev, and be the opendev team.22:32
fungimnaser: those are situations where i expect we'd have lengthy discussions about having them get us a lot of additional resource donations22:32
mnaserheck they can even pay a public openstack cloud to donate resources through, ha22:33
mnaser:P22:33
fungiclarkb's most recent analysis says testing of official openstack deliverables still accounts for 98% of our node utilization22:33
*** e0ne has quit IRC22:34
fungiso i have a feeling we'll know if we're talking to a project which is going to significantly shift the needle on that22:34
*** e0ne has joined #openstack-tc22:35
fungi(note that official openstack deliverables only account for some 50% of our total repository count)22:35
*** e0ne has quit IRC22:36
clarkbya I'd really like to avoid treating that as a bogeyman22:37
clarkball of our data shows that running an extra python3 version job is tiny use of resources as is adding new top level projects in comparison to the existing heavy hitters22:37
openstackgerritLance Bragstad proposed openstack/governance master: Elaborate on the business value of goal champions  https://review.openstack.org/64177322:49
clarkbhttp://paste.openstack.org/show/747422/ was today's monthyl breakdown if you want the numbers22:51
openstackgerritLance Bragstad proposed openstack/governance master: Elaborate on the business value of goal champions  https://review.openstack.org/64177322:51
lbragstadfungi the only help needed item i have left is the one you've written it looks like22:52
fungilbragstad: lovely!22:58
*** mriedem is now known as mriedem_away23:02
*** purplerbot has quit IRC23:26
*** purplerbot has joined #openstack-tc23:26
*** tosky has quit IRC23:34

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!