Thursday, 2019-10-24

*** jamesmcarthur has joined #openstack-tc00:00
*** jamesmcarthur has quit IRC00:16
*** jamesmcarthur has joined #openstack-tc00:17
*** markvoelker has joined #openstack-tc00:21
*** jamesmcarthur_ has joined #openstack-tc00:26
*** jamesmcarthur has quit IRC00:26
*** jamesmcarthur_ has quit IRC00:29
*** jamesmcarthur has joined #openstack-tc00:30
*** jamesmcarthur has quit IRC00:30
*** jamesmcarthur has joined #openstack-tc00:32
zanebcoreycb: I think it's a bit late to add another voting job (some projects may have switched over already) but I'd definitely be in favour of adding a non-voting job as soon as py38 is available in the images we use in the gate00:33
*** zhurong has quit IRC00:36
*** jamesmcarthur has quit IRC00:40
*** jamesmcarthur has joined #openstack-tc00:40
*** mriedem_afk is now known as mriedem01:02
*** mriedem has quit IRC01:02
*** markvoelker has quit IRC01:28
*** spsurya has joined #openstack-tc01:59
*** markvoelker has joined #openstack-tc02:00
*** markvoelker has quit IRC02:05
*** ricolin has joined #openstack-tc02:12
*** nicolasbock has quit IRC02:23
*** jamesmcarthur has quit IRC02:25
*** jamesmcarthur has joined #openstack-tc02:30
*** jamesmcarthur has quit IRC03:10
*** jamesmcarthur has joined #openstack-tc03:11
*** jamesmcarthur has quit IRC03:15
*** diablo_rojo has quit IRC03:18
*** jamesmcarthur has joined #openstack-tc03:42
*** jamesmcarthur has quit IRC04:27
*** jamesmcarthur has joined #openstack-tc04:31
*** jamesmcarthur has quit IRC04:39
*** jamesmcarthur has joined #openstack-tc04:52
*** slaweq has joined #openstack-tc05:12
*** jamesmcarthur has quit IRC05:13
*** jamesmcarthur has joined #openstack-tc05:20
*** slaweq has quit IRC05:29
*** jamesmcarthur has quit IRC05:30
*** markvoelker has joined #openstack-tc06:02
*** markvoelker has quit IRC06:06
*** slaweq has joined #openstack-tc06:25
*** iurygregory has joined #openstack-tc06:34
*** tosky has joined #openstack-tc07:12
njohnstonasettle: I got a question yesterday about docs, was not sure of the answer.  I was chatting with a chap from cinder and he asked me about the header we put on docs that are older, that says "This is maintained, but not the current release. The current supported release is Train."  He asked, could we have the link deeplink to the train version of the doc you're looking at instead of08:32
njohnstonI was not sure if that was by policy or if it is something that I could suggest as a contribution08:32
evrardjp_njohnston: what if the file was changed between old release and more recent release, pointing to a 404 ?08:33
evrardjp_don't get me wrong, I like the idea08:34
njohnstonevrardjp_: I'm fine with a 404, but I am coming at ti from a developer mentality.  I don't think we're changing the names of existing docs very often these days though, so I don't think that is the scenario to optimize for.08:34
njohnstonevrardjp_: I would also say that it would be good to suggest to project teams "if you move a document, leave a file in the old location saying 'this file has been moved to...'"08:35
evrardjp_or simply propose in the 404 to see the recent docs of the team.08:37
evrardjp_that's more clicking but why not08:38
evrardjp_I am just playing devil's advocate in the meantime that the docs people can answer :p08:38
* asettle swans in with a cat08:46
asettlenjohnston, perhaps I'm not looking at this the right way. But I'm not sure I understand the use case your mate brought up. Could you show me an example from a developers perspective?08:48
asettleBtw njohnston feel free to bring this convo over to openstack-doc08:57
asettleAndreas might know why we do what we do ther08:57
njohnstonasettle: you got it09:08
*** jaosorior has joined #openstack-tc09:15
*** e0ne has joined #openstack-tc09:33
openstackgerritThierry Carrez proposed openstack/governance master: New charms & interfaces for MySQL8
*** markvoelker has joined #openstack-tc10:04
*** markvoelker has quit IRC10:09
ricolinttx tc dinner scheduled on Wednesday 11/610:24
ttxwoohoo! Thanks10:45
*** nicolasbock has joined #openstack-tc11:58
*** jamesmcarthur has joined #openstack-tc12:11
*** jamesmcarthur has quit IRC12:28
*** markvoelker has joined #openstack-tc12:31
evrardjp_thanks ricolin12:35
evrardjp_ricolin: I think we should sync over the board meeting presentation during the summit12:37
evrardjp_mnaser: do you have the previous OpenStack foundation board meeting TC update handy? I thought to use it as a base12:38
*** jaosorior has quit IRC12:42
ricolinevrardjp_, yes, right now I only got the slides from Berlin12:48
*** jamesmcarthur has joined #openstack-tc12:48
*** adriant has quit IRC12:51
*** adriant has joined #openstack-tc12:53
*** jeremy__bouncer has quit IRC13:11
*** jeremy__bouncer has joined #openstack-tc13:12
*** jeremy__bouncer has quit IRC13:12
*** jamesmcarthur has quit IRC13:13
*** jeremy__bouncer has joined #openstack-tc13:14
*** jamesmcarthur has joined #openstack-tc13:20
*** mriedem has joined #openstack-tc13:23
*** spsurya has quit IRC13:29
*** slaweq has quit IRC13:32
*** e0ne has quit IRC13:35
*** e0ne has joined #openstack-tc13:36
*** nicolasbock has quit IRC14:01
zanebevrardjp_, njohnston: if you move a doc then you should add a redirect, otherwise people linking to /latest will also get a 40414:03
coreycbzaneb: thanks for the input. i'll look into a non-voting py38 job once it's available on bionic.14:03
zanebcoreycb: awesome, thanks14:06
*** jamesmcarthur has quit IRC14:06
ttxevrardjp_: had a question for you around the Containers SIG -- is that active and useful? Or did it not really take off and should probably be removed from SIG list?14:08
ttxsmcginnis: same question for the "Operations Docs" SIG -- did that one go anywhere?14:09
smcginnisttx: It's still "active", just not a lot of focus.14:09
smcginnisIts main benefit being that it is the owner of some of the docs repos that we do still want to have and publish.14:10
ttxDoes it still make sense in the new "docs is a SIG" world?14:10
smcginnisIt could be argued that it could be an area of focus for a docs SIG, but for now I think it makes sense standalone.14:10
ttxI wonder if we should not have a status for SIGs that are not "active" but are still around to maintain stuff.14:10
ttxLike if a problem is raised those people would jump in14:11
ttxbut there is no weekly meeting needed14:11
ttxat best office hours14:11
smcginnisThere's probably work that could be done there. It just needs someone with the motivation to do it.14:11
fungithough also if they're not active, it's hard to tell whether anyone's around to jump into action when needed14:11
ttxok, thanks for the update14:11
smcginnisWe've kind of co-opted the Ops Meetup planning meeting if/when we've needed any ops docs discussions since it's basically the same people.14:12
smcginnisOr just ad hoc in the ops channel.14:12
fungiso you won't really discover the difference between latent and defunct without some triggering event14:12
fungiit's a bit of a schrödinger's cat situation14:12
fungijust without the cesium atom14:12
smcginnisMaybe every cycle - have a process of emailing the chairs and asking if a SIG is still active and/or needed?14:13
smcginnisSounds maybe like what ttx is doing now.14:14
ttxyeah, I'm doing it a bit informally14:16
jungleboyjJust needs formalization then?14:16
*** jamesmcarthur has joined #openstack-tc14:17
ttxsomewhere between my TC hat, my Meta SIG hat and my OSF hat14:17
jungleboyjAnd we are back to needing a hat switching API.14:17
ttxjungleboyj, smcginnis: I think it's the job of the Meta SIG14:18
ttxKeep track of SIGs in general14:19
smcginnisMakes sense. Anyway, thanks for doing it. Glad someone is checking.14:19
ttxjust started a thread on the resource management one14:20
*** bnemec has quit IRC14:35
*** bnemec has joined #openstack-tc14:37
evrardjp_ttx: I just didn't put enough efforts to kickstart the work on containers sig yet. I expect it to be low activity anyway, and mostly on the ML. Is that a problem?14:48
*** evrardjp_ is now known as evrardjp14:48
ttxevrardjp: if it's still in the cards, there is no issue... just want the page to reflect current state14:49
evrardjpyeah there is no reason to drop it afaik14:49
gmannTC office hour time..15:00
*** jcapitao has joined #openstack-tc15:00
gmannas planned I would like to start the discussion on py2.7 drop15:00
gmanni think most of the tc are here15:01
gmanntc-members ^^15:01
jrolloh boy15:01
*** gouthamr_ is now known as gouthamr15:01
* fungi wonders if jroll just experienced a quantum leap15:01
jrollI have been fighting with a virtualenv bug caused by weird downstream OS/python things all morning and my brain is broken. probably as broken as a quantum leap would leave it.15:03
gmannlet's wait for few min in case more members show up15:04
*** mnasiadka has joined #openstack-tc15:05
njohnstoncloudnull is travelling IIRC15:05
* mugsie is here, but not really here - trying to write slides + workshop for shangai before I start travel next week15:07
evrardjpI am here but technically on holidays. I will pay attention to this though15:09
* evrardjp should take example on mugsie :)15:09
*** slaweq has joined #openstack-tc15:10
jrollI think we can go ahead, if anyone cares deeply they'd be here already, the others can catch up15:10
gmannok. let's start15:10
gmannetherpad link
gmannthis etherpad is collecting the key points, projects want to keep py2.7 support and draft schedule15:10
gmannwe can start from starting of etherpad15:11
gmannL19 - 'Projects want to keep python 2 support and need oslo, QA or any other dependent projects/lib support'15:11
gmannswift is in the list to keep the support15:12
gmanni wrote the two options for them15:12
gmanntimburke can tell us the exact plan for swift15:12
njohnstonI think we should make sure to explicate that "drop py27 support" does not mean that it won't be tested under py27 anymore, it means code that is incompatible will start being merged (like removal of six).  I talked to someone today that was confused about that.15:12
*** jaosorior has joined #openstack-tc15:13
jungleboyjnjohnston:  That is a good point.15:13
gmannnjohnston: +1. i will write that on etherpad15:13
mwhahahabut doesn't that mean basically it can't be tested under py27 anymore?15:13
gmannboth are same. if you are not testing it means it might be broken anytime15:14
gmannand if not supporting then you cannot keep testing15:14
jrollis there a problem with swift wanting to keep support?15:14
bnemecFWIW, swift doesn't use Oslo so that doesn't necessarily affect us.15:14
bnemecUnless they have a transitive dep that I'm not aware of.15:14
gmannetherpad mentioned that they need one release with py3 and also want to keep xenial support15:14
jrolltheir dependency list is very small:
gmannbnemec: is it15:15
jrollI don't have a problem with them keeping 2.7 if they can handle the work15:15
njohnstonI like the elegance of the version cap proposal; it really captures the spirit of "this is the end of the road".15:15
gmannopohk these are their dep-
fungiyeah, from what i understand, swift particularly wants folks with stand-alone deployments which are on older python 2.7-only platforms to be able to continue upgrading the software15:16
gmannok, we should be ok as long as it is not extra burdon on openstack maintained projects/lib15:16
*** jaosorior has quit IRC15:16
fungitheir independence from openstack shared libs should make it not too much of a problem, i hope15:17
gmannso let's ask swift that what all support they need from openstack lib.testing tools etc. devstack support might be requred but that can done via plugin15:17
fungiand yes, if there are libraries they depend on which are unable to maintain support for 2.7, i would expect the swift team to take on that work (either through collaboration or forking the library)15:17
jungleboyjI think the cap makes sense as well.15:17
evrardjpfungi: agreed15:18
fungii expect they can perform stand-alone swift functional testing without devstack (perhaps they already do, i haven't looked at their jobs)15:18
gmannmake sense15:18
gmannfungi: yeah, i added the integration testing also in last cycle so if they need those jobs on py2.7 or just function testing should be enough to verify the py2.7 working fine15:19
clarkbfungi: they are using containers in saio now (swift all in one) no devstack15:20
clarkbfungi: I don't think we should continue to carry devstack python2 support for testing swift given they have tools that can do it for them15:20
jungleboyjclarkb: ++15:20
fungiclarkb: absolutely, i did not mean to suggest devstack needs to retain 2.7 support, quite the reverse in fact15:21
gmanni have added the notes on etherpad and question to swift team about confirmation on if supporting py2.7 independently is fine for them or need any support from openstack lib/testing tool etc15:22
gmannnext is Tempest in that list. which i added and started the ML also if any strong opposition to drop the support15:23
gmannas QA team we are ok to drop and i did not get any users saying not to do that.15:23
gmannonly tripleo want it till centos815:23
evrardjpas leader of said team, we trust you too :)15:23
mwhahahait would be nice if we could hold off until we have rdo in place15:24
gmannso tempest will drop support in m-2 which is mid of feb15:24
mwhahahawhich hopefully won't be long15:24
evrardjpwe have to think the best for OpenStack as a whole not only a single project.15:24
gmannmwhahaha: ^^ is that fine for you15:24
mwhahahaif it's in feb that should be fine15:24
evrardjpBut I understand that position, and it would be good to have RDO approval15:24
mwhahahaif we don't have rdo+centos8 by then we have other problems15:24
gmannmwhahaha: perfect.15:24
evrardjpI am typing too slow15:24
evrardjpthanks mwhahaha15:25
gmannwe have testing tools planned for phase-2 which is m-215:25
evrardjpgmann: should we add those steps into the release schedule ?15:25
*** slaweq has quit IRC15:25
gmannevrardjp: +1 nice idea. once we finalized the schedule then it is good idea to put on release schedule too15:26
gmannany other project want to keep support anyone aware and not listed in etherpad ? otherwise we move to discuss the other points15:28
evrardjpI think we can move15:28
mugsiedid the quieter projects respond?15:28
mugsie(trove / searchlight etc spring to mind)15:29
gmannnot yet. hope they read the email15:29
* evrardjp has high hopes15:29
njohnstonnoone I am aware of.  Even networking-midonet is getting behind it, and we had concerns that project was unmanned.15:29
mugsieI would just be concerned about them completely breaking, and seen both are basically single person projects I would worry about them recovering15:30
mugsiebut that may be "not bad" thing I suppose15:30
gmannnjohnston: ah ok. they are not yet migrated to bionic also if i remember. do you know they want to keep py2.715:30
njohnstongmann: No, they are working on converting their jobs to accomodate py3 testing15:30
gmannok. hope you  can bring this to all neutron stadium projects in neutron meeting or so15:31
gmannin case we miss anyone.15:31
njohnstongmann: we've been harping on it for almost a year now15:32
gmannmugsie: yeah. should we approach to them individually ? i do not know how many we can though15:32
gmannnjohnston: perfect.15:32
mugsiecould the liasons reach out gmann?15:33
mugsietrove is zaneb, evrardjp15:33
gmannah nice idea.15:33
mugsiesearhclight is gmann, jungleboyj15:33
zanebwhat are we supposed to be asking them?15:33
gmanni cannot type action here but each TC liasons can reach out to their projects and make sure they are aawre of this and fine.15:33
evrardjpzaneb: if they read the ML I guess?15:34
gmannzaneb: if py2.7 support dropping is fine for them and yes they are aware of this (ML)15:34
evrardjpzaneb: ofc let's do that through email15:34
evrardjpjoke aside, this is good to highlight.15:34
gmannadded in etherpad ac a action item for all of us15:35
zanebthey support python3 already afaik. that's the hard part.15:35
evrardjpI suppose many have for a while, else they would not be compliant with PTI15:36
jungleboyjSo is there an action item for me there or not?15:37
evrardjpyet, removing 2 is not the same as supporting 3 :)15:37
gmannpy3 is ok but they might want to keep py2.7 for their customer or so ?15:37
jungleboyjAlso, where is the liaison list?15:37
evrardjpexactly :)15:37
evrardjpjungleboyj: it's in governance15:37
gmannjungleboyj: yes, please check your liaison projects15:37
jungleboyjmugsie: Ah, thank you.  New guy didn't know about that.15:38
mugsieand then on the project pages, it has them as well (e.g.: )15:38
evrardjpjungleboyj: for code:
mugsieit merged a few weeks before you joined, so not something everyone would know yet :)15:38
gmannadded the link on etherpad too15:38
gmannor new member should get the checklist or welcome todo things from chair :). i got from dhellmann and that was helpful .15:39
gmannlet's move next15:39
jungleboyj:-)  Ok, good to know.15:40
gmannbefore schedule discussion, which can be the last thing. let's check 'Questions/Key Points to take care:'15:40
gmannL57 on etherpad15:40
gmann'How to test the upgrade from python2 -> python3'15:40
jungleboyjSo, I will reach out to searchlight on the ML.15:41
gmanngrenade is option to test this in upstream but there were failure on devstack patch from mriedem15:41
gmannjungleboyj: thanks15:41
gmannwe said we can do that if we find volunteer otherwise we can drop this idea at least to test in upstream CI/CD15:42
gmannI do not know if mriedem has plan to fix those failure and want to make job for such testing15:43
mriedempy2->py3 grenade?15:43
mriedemi'm not planning on creating a job for that15:43
njohnstonI swear I have seen grenade test 2 before and 3 after; when neutron started looking at this it was one fo the first things we were interested in, and I saw grenade could do a v2.7 followed by a v315:43
evrardjpI think we've got our expert. Thanks njohnston ! :p15:43
gmannnjohnston:  which job15:44
* njohnston tries to scrape the action item off his shoe, because he just stepped in it ;-)15:44
* jroll digs up old email thread about this15:44
njohnstongmann: this was about 10 months ago I think (I'll look back to be sure) and it was a neutron grenade job, before we standardized on the grenade-* jobs15:45
gmanncurrently train -> master is py2->p2 and py3->py315:45
gmannnjohnston: currently it is failing (py2->py3) -
jrollso there's an old ML thread about this where we agreed that we probably don't need to test py2->3 upgrades in services:
*** iurygregory has quit IRC15:46
jrollof course, a project could do that if they wanted15:47
jrollwe did pick out an oslo.messaging bug around this that would have affects, but I assume that's fixed by now15:47
gmannyeah, we can do as part of integrated gate testing also if someone make it working15:47
jrolloh, not a bug, just a need for a test:
openstackLaunchpad bug 1792977 in oslo.messaging "Need a functional test to verify py2 <-> py3 interoperability" [High,Triaged]15:47
jrollI'm not particularly concerned about testing it in the integrated gate, but that might just be me15:48
evrardjpjroll: care to explain why ?15:49
jrollevrardjp: because if a service works on py2 and works on py3, it should just work when the underlying python is switched15:50
jroll*rolling* upgrades are a concern, because you have mixed versions15:50
jrollbut that should all be handled in o.msg15:50
gmanntill train we have been testing both version as integrated, unit, functional testing15:50
evrardjpjroll: I don't disagree, but why wouldn't it deserve testing in the integrated gate?15:50
evrardjpI think I see what you mean now15:51
jrollevrardjp: sorry, I should have said we don't need to have a big integrated job, just a small oslo.messaging job with a py2 client and py3 server, and vice versa15:51
gmanndo we have plan from oslo to do so ?15:52
gmannbnemec ^^15:52
jrollthey have a bug for a work item:
openstackLaunchpad bug 1792977 in oslo.messaging "Need a functional test to verify py2 <-> py3 interoperability" [High,Triaged]15:52
jrollbut doesn't look like it's been touched15:52
bnemecNot that I know of. We have not had good luck holding on to messaging folks lately. :-/15:52
gmannfrom integrated gate testing, i agree if no one want to make it testing means no one need it so we do not have to do it as part of mandatory testing for all15:53
bnemecWe do have functional tests though so hopefully it wouldn't be too difficult to do.15:53
gmannlet's drop the integrated testing for py2->py3 and oslo can check if they can do functional testing of oslo.messaging. is it fine for all ?15:54
fungiit might have been a nice-to-have when we were working on achieving python 3 support15:55
funginow it's here and we're looking at dropping python 215:56
evrardjpfine for me. We'll discover things through other mechanisms, and deal with it appropriately I guess :)15:56
fungiand by now i expect plenty of folks who were using openstack on python 2 have upgraded to python 315:56
*** diablo_rojo has joined #openstack-tc15:56
fungiso if there were significant problems associated with that, someone would hopefully have told us15:56
gmannand if they could have faced bug while upgrading they could have reported15:57
gmannyeah. you typed fast15:57
gmannok, i added the AGREE in etherpad15:57
gmannnext is 'fast-forward upgrades from <=Stein to >=Ussuri need some solution to switch from Python2.7 to Python3.{6,7} in Train'15:57
fungiworst case, people are taking train as an opportunity to do the upgrading, so if they haven't yet then we ought to hear from them in the near future15:58
jrollfungi: ++15:58
gmannfungi: ^^ fast-forward upgrade thing15:58
gmannstein was also doing testing for both version so should be ok right15:59
jrollwhy does a fast forward need to move to py3 in the train part of the upgrade?15:59
*** diablo_rojo has quit IRC15:59
*** diablo_rojo has joined #openstack-tc16:00
jrollwell, I take that back16:00
gmannrocky->ussuri ?16:00
jrollbut, upstream doesn't really support FFU, right? that's for vendors to handle?16:00
fungiyeah, it was mostly a question about how ffu works if going from a py2-only release to a py3-only release16:01
fungiand whether it's something we need to worry/care about16:02
jrollfair question, I think people writing FFU automation would insert the py3 switch in the middle somewhere16:02
* gmann office hour time is up but i hope we can continue and finish the schedule 16:02
fungibecause the upgrading routines (db-manage and whatnot) will need to switch interpreters at some point in the sequence16:02
njohnstonI don't think it's something we need to worry about because chances are they will need to contend with a xenial to bionic upgrade in there (or centos 7 to 8) and that'll force the issue better than we could16:03
amotokiall deployments need to switch py2 to py3 at some point. they can do FFU to soem release like train, upgrade py2 to py3 and then FFU to further release.16:03
fungiit's convenient that the xenial-bionic switch comes in the first release to fully support both 2 and 3, while the centos 7-8 switch comes in the first release to support only 316:04
gmannyeah, py2->py3 might have be done before release upgrade16:04
evrardjpIs it really a problem we have to solve in here?16:05
fungievrardjp: that's the question16:05
gmannlet's keep those for vendors to worry if it does not work or create issue for them16:05
amotokiI don't think so, but it is better to mention what we expect.16:05
fungiright, it's about setting expectations16:05
gmannthere used to be upgrade sig ?16:06
fungiwe say train is the last release to support python 2, and that ussuri will only officially support python 3, but we don't really go into the implications/reality of that. hopefully downstream consumers understand what needs to happen at upgrade16:06
*** jcapitao is now known as jcapitao|afk16:07
ttxupgrade sig called success and was disbanded16:07
ttxa while ago16:07
gmannfungi: +1. that is some thing we can highlight16:07
gmannlet's move to next item about backport - L68 'What are our guidelines to backport fixes to stable branches?'16:08
gmannpy3 only code backport can be issue16:09
njohnstonthat's a good point16:09
jungleboyjYeah.  I am worried about this for Cinder.16:09
fungidoesn't seem like the backport guidelines really change. stable branches will continue to be tested with python 2.716:09
fungiand dependencies can't really be altered16:10
gmannbackport expert mriedem ^^16:10
fungithere are always changes between releases which require some backports to be adapted16:10
smcginnisJust might require a little more tweaking to get things backported.16:10
njohnstonIf projects decide to throw six overboard and their backports get more conflicted as a result, that is a value proposition that various teams might come to different answers on16:10
fungithis is just maybe a bigger/broader change than usual16:10
jungleboyjYeah, we will just need to be sensitive that some changes can't be an exact cherry-pick.16:10
gmannthis is something we can solve case by case if that happen. do not knoe what we can do in this16:10
jungleboyjgmann: ++16:11
fungijungleboyj: and realistically, it's already the case that some changes can't be cherry-picked directly16:11
gmannif that happen, then make it work for py2.7 also using six and then backport16:11
jungleboyjfungi:  True.16:11
njohnstonI can see some teams finding features in py3 that justify the backport pain, while others might keep six around.  I think if we just highlight that starting into py27-incompatible code carries with it a cost so teams are aware of it, they can make their own choices16:11
gmannbut then question is we need to keep six support16:11
amotokiit totally depends on test coverage. we need to review backports from py2/py3 compatibility more than now.16:11
jungleboyjgmann:  ++16:11
amotoki+1 for keeping six support16:12
jungleboyjIs there any reason to hurry removing it?16:13
evrardjpI think this doesn't need to be determined today16:13
gmannbut we have to decide if six support can be removed or not from projects if we drop py2.716:13
evrardjpI agree with njohnston as there is a cost of incompatible code, but there is also a hidden cost of not moving forward, or slowly moving forward, for onboarding purposes.16:13
mriedemwhat is the specific backport question? i'm not paying attention.16:13
*** e0ne has quit IRC16:14
gmannmriedem: from py3 only code from ussuri to stable16:14
mriedemstable branches would continue to test py27 and if you backport something that needs tweaking for py27 then you do it in the backport16:14
evrardjpFor me, this is not a simple black or white, and projects can (as usual) decide their fate16:14
gmannmriedem: yeah and that need six support to keep.16:14
mriedemlike smcginnis says "Just might require a little more tweaking to get things backported."16:14
jungleboyjevrardjp:  That makes sense.16:14
evrardjpAnd yes, it shouldn't break the stable policy per se16:15
*** jcapitao|afk has quit IRC16:15
gmannmriedem: oh.  tweak for py2.7 in backport or on master16:15
evrardjpgmann: I guess it's tweak for py2 in the backport16:15
mriedem99% of the time that's not going to be a problem16:15
evrardjpIt seems we are all in agreement then?16:15
mriedemif it is, you fix in the backport and mention it in the commit message16:15
gmannyeah, it is case by case not everytime16:15
fungimriedem: specifically, the question was whether the stable branch backport policy needs changing for this. i asserted that it shouldn't16:16
*** mriedem is now known as mriedem_away16:16
gmannin that case we do not have to say keep six support. it is up to projects16:16
mriedem_awayfungi: agree, no change16:16
evrardjpgmann: correct16:16
gmanni will add the AGREE.16:16
gmannnext item16:16
gmannL71- What is the tactics of dropping openstack-tox-py27 in our gate? (amotoki)16:16
fungihaving release-specific project-templates which apply those makes the removal somewhat straightforward16:17
gmannthis is adding the pep8 job to ussuri template so that we can drop  openstack-python-jobs
gmannfungi: yeah16:17
fungiprojects who want to retain the openstack-tox-py27 job can add it directly to their project configuration16:17
gmanntrue. please review that patch if any objection16:18
amotokior they can keep openstack-python-jobs template16:18
njohnstonTo me that is the straightforward solution.  It also forces projects that want to keep py27 to have to do something affirmative to do so, which I think is proper at this point.16:18
gmannyes keeping py2.7 template does not harm if they want to test py2.716:19
gmannnow L33 'Draft Schedule:'16:19
* gouthamr peeks in - manila meeting coincided with this office hour 16:20
njohnstonI have an appointment and have to run - thanks all16:20
gmanndoes mentioned schedule works fine for all ? anything missed  ?16:20
gmannnjohnston: sure, thanks16:20
gmannthere is os-vif comment from sean-k-mooney16:21
*** ianychoi has joined #openstack-tc16:21
gmannnot sure it is for keeping till m-3 or m-2 is fine16:21
fungiconcern with m-3 is that's pretty late in the cycle when teams are getting a lot busier on other stuff16:22
gmannm-2 is all ok and as per draft schedule16:22
smcginnisI think the earlier we do things the better to make sure there aren't any late cycle surprises.16:22
evrardjpsmcginnis: ++16:22
fungiyeah, any fallout gets dealt with while folks have more available bandwidth to do so16:23
jungleboyjI agree that M-2 is better.16:23
evrardjpI have to go for now. I want to thank all of you for attending here, more particularily gmann for handling this dance. Thanks gmann!16:23
gmannI will check with sean-k-mooney if it cannot be done from m1 -> m-216:23
gmannevrardjp: thanks for attending in ur holiday too16:23
gmannif no objection to the mentioned schedule then let's make it final.16:24
jungleboyjgmann: ++16:24
amotokihorizon plans to follow the proposed schedule. It depends on py3 support in horizon plugins but generally speaking we can expect all plugins support py3 and we can follow them up if not.16:24
amotokithe current schedule looks fine from horizon perspective too16:24
evrardjpit is a big topic. I can take a few hours for this :)16:24
gmannamotoki: thanks16:25
gmannok. it's all from etherpad. anything else to discuss16:25
gmannif no then last thing.16:26
gmannis it fine to make it a cycle goal with all agreed point and schedule so that it can be published and executed in much planned way ?16:26
jungleboyjThe py3 support?16:27
gmann? you mean we can do as part of that goal16:28
jungleboyjgmann:  I don't understand the question.  :-)16:28
smcginnisThat may help make sure it can get done in a coordinated fashion. Doesn't hurt to make it a cycle goal. Only drawback is if some projects plan to keep py2 support, what is the definition of done for the goal?16:28
gmannpy3 support goal was there since many cycle16:28
smcginnisRephrased - py2 non-support would be the new goal.16:29
gmannsmcginnis: so those project can be listed as OK if they come up and show the plan. swift is the only one in that list as of now16:29
gmanntill goal merge and then it means everyone else (except in list) ok to drop py2.716:30
smcginnisThat would make it explicit. The goal is to drop py2. Here are the projects that have explicitly declared they want to continue to maintain that support.16:30
gmannTC liasion will check with their projects if they did not notice this16:30
gmannwe do not want to mark that invalid at runtime and say we want to keep and it is not working because our dependency not supporting 2.7.16:31
jungleboyjsmcginnis:  Ok.  That was what had me confused.  I thought we already had the goal. :-)16:31
jungleboyjYeah, I think have a cycle goal for dropping py27 support makes sense.16:32
gmannok, I will compose the goal. and summarize this discussion on ML16:32
ricolincommunity goal is definitely help to check the drop process bi-way, but we need to specify the action for projects16:32
jungleboyjgmann:  ++16:32
smcginnisHaving the goal would also define a review topic to use that could help make it easier to track what work is being done towards this.16:32
gmannthat's all from me. thanks everyone for participating.16:33
jungleboyjWelcome.  :-)16:34
jungleboyjgmann:  Just to be clear.  Should I reach out to all the projects that I am liaison for just to make sure everyone is onboard?16:35
gmannjungleboyj: yeah, i am also going to do that via email to PTL and CC second TC liaison16:36
gmannthere are two TC liaison per project, so keeping him/her in CC will help in sync and avoid duplicate email16:36
jungleboyjgmann:  Ok, I was going to use the ML but I suppose directly contacting the PTL is probably a good idea.16:37
jungleboyjHmm, some of these project pages are missing.16:38
fungiout of curiosity, what cross-project actions would such a cycle goal actually entail?16:39
gmannjungleboyj: yeah you can get response better with direct email16:40
jungleboyjOkie Dokie.16:40
fungias i understand it, the plan is that projects are allowed to drop python 2.7 jobs, and may be forced to if those jobs start failing because their dependencies no longer work with v6, but there is no requirement for them to necessarily drop anything16:40
fungis/v6/python 3/16:40
fungi(sorry, having ipv6 discussions simultaneously in another channel)16:41
smcginnisI believe that summarization is correct.16:41
fungis/python 3/2.7/16:41
* fungi sighs16:41
gmannfungi: all projects (i mean service or lib) if falling under same phase then they need to coordinate on timing if it break their jobs. and if break py27 job then it is time to drop those immediately16:41
amotokiperhaps the goal is to drop py27 or declare py27 support explicitly16:41
gmannfungi: correct16:42
fungigmann: so the actions would be "if you plan to do something then you need to do it by this date" but i'm not sure how you track that as discrete tasks16:42
gmannamotoki: yes, it will update setup.cfg to remove the py2.7 from there16:42
gmannfungi: it can be done on different date. for example, cinder can drop now and if it break nova py27 job then nova drop the job to unblock the gate and then continue removing the other support of py2716:43
fungigmann: yep, but how do you track that? first you need to know that cinder is planning to do something16:45
gmannamotoki: if project not dropping the py27 then it means they are continuing the support. dropping explicitly via setup.cfg and reno is enough i think.16:45
fungiso while i completely agree coordinated timing is needed, i don't see how that fits a cycle goal (or benefits from being one)16:46
fungia cycle goal is for some set of tasks we want most projects to do by the time ussuri is released16:47
amotokigmann: what I would like to mention is the definition of a community-wide goal. as other folks mention, a goal should describe what we should do till a specific date.16:47
gmannfungi: champion can coordinate on that. if 2 projects need to go together then push patch for both together16:47
fungigmann: but why does it need to be a goal champion?16:47
gmannfor co-ordination16:47
fungiand how do we know the predetermined set of tasks for the goal is accurate, for the tc to be able to vote on them?16:48
fungiit sounds like we need a coordinator to handle communication, but i don't see how it's a cycle goal16:48
smcginnisI was thinking a goal could help for tracking, but maybe this would be better as a short term working group / pop-up team for those interested in helping coordinate the work.16:48
gmannwe will not list each case, we can mention in goal that we are going to do this and if dependency break gate it is time to drop jobs.16:49
fungigoals are great for tracking, but first we need to know what to track16:49
gmanni am not sure how many cases it will be like that may be 016:49
gmannamotoki: yeah, we will add the phase wise deadline.16:50
amotokifrom project team perspective, goals help us know what we should do at least as openstack community. Defining a goal to drop something might be challenging and unclear though.16:51
fungianyway, just to rephrase, a cycle goal is about something we want done, but this is more about something we want to avoid (having development on some projects blocked prematurely by incompatible changes merging to their dependencies)16:52
openstackgerritMerged openstack/governance master: Remove puppet-yum from Infra
openstackgerritMerged openstack/governance master: Add a redirect for the renamed openstack-chef project
openstackgerritMerged openstack/governance master: Switch to Ussuri jobs
openstackgerritMerged openstack/governance master: Add openstack/barbican-ui
fungiso it needs a plan (we have one, awesome) and a coordinator or several to handle communication of that plan at each phase16:52
fungibut that's not the same thing as a cycle goal16:52
*** tosky has quit IRC16:52
smcginnisWell, the thing we want done is to have everyone to move in an orderly fashion out the py2 door.16:53
fungiescept, we don't16:53
fungier, except16:53
fungiwe want everyone who is moving out the py2 door to do so in an orderly fashion16:53
gmannthere are things to be done here. removing jobs, update setup.cfg, reno to clear notification that this project not supporting py27 any more16:54
fungigmann: is the work that is required to be done work that needs to be done by most projects?16:54
smcginnisUnless the team explicitly declares they plan to keep it around, I think we do. If we are no longer testing py2, then it's broken and we should make sure things are cleaned up so no one gets the false impression that they can still run with py2 because no one out right declared it not supported.16:54
fungior is it centralized, with some optional work that projects can do on their own if they want?16:55
gmanni expect all projects (dropping it) to do.16:55
fungithat's a tautology16:55
gmannit should not be a silently  drop the py2 in bit and pieces16:55
fungiokay, so the cycle goal is about cleanup then?16:56
fungithe "this is what teams need to do by the time ussuri is released" part of the goal16:56
smcginnisI think the goal needs to be 1) testing stops on py2, 2) package metadata is updated to remove py2 declaration. That's it as far as what we need to do to make it clear to our downstream consumers what the current status is. Then cleanup and removing compatibility code is bonus points that we would highly encourage. Or at least I would.16:58
fungii just feel like we've switched from saying that dropping python 2.7 support in projects is optional (modulo dependencies also dropping support for it, and teams being responsible to find their own alternative solutions if they need them) to saying that everyone needs to drop python 2.7 testing and unless you say you're going to test something with 2.7 you're required to remove it16:58
gmannprojects can do even more also like code cleanup etc to make it non-py27. but things to do here as must is remove the testing and a clear notification or no more guarantee of py2716:58
smcginnisI do think it needs to be explicit. Either you declare you are going to keep testing it and support it on your own, or you clearly declare that it is no longer supported and remove anything that might give the impression otherwise.16:59
smcginnisBeing vague isn't going to help our users.16:59
gmannyeah, optional is more confusing. either declare explicitly or drop.17:00
amotokismcginnis: ++17:00
smcginnisSo the goal (to me) would be "don't be vague".17:00
fungii seems entirely reasonable to me to say that these are the deadlines when teams are allowed to remove python 2.7 support, and if you don't remove your testing (and similarly update your metadata) within those timeframes and your testing later breaks, you get to keep both pieces17:00
gmannand we can maintain some user facing centralized doc or wiki saying what all keep the support17:01
gmannthat can be good to point in various place of notification17:01
jungleboyjDoes OpenStackSDK have a PTL?  There is nothing in the PTL list.17:01
clarkbI want to say it is monty17:01
gmannMonty i think17:01
fungidid teh change to set monty as ptl never merge?17:01
jungleboyjgmann:  Thanks.17:02
fungijungleboyj: what is "the ptl list" then?17:02
fungii assumed you meant the reference/projects.yaml in openstack governance17:03
*** jaosorior has joined #openstack-tc17:03
jungleboyjfungi:  Ah, thank you.  That is helpful.17:08
* jungleboyj is feeling very new.17:08
fungiis there a "ptl list" somewhere with an out of date set of ptls?17:11
fungior were you looking at election results?17:11
*** markvoelker has quit IRC17:12
fungielection results are not expected to necessarily have a complete set of ptls (due to the tc occasionally needing to appoint some of them for various reasons), but maybe we can make that more clear on the election page17:12
jungleboyjfungi:  I was.17:12
clarkb election results show monty too fwiw17:14
*** mriedem_away is now known as mriedem17:14
gmanntrain is fine. but in ussuri it was pointed later -
ricolingmann, are you plan to update ussuri release schedule too?
gmannricolin: that is the plan. i think it is good idea (from evrardjp).17:25
*** markvoelker has joined #openstack-tc17:26
*** jamesmcarthur has quit IRC17:29
*** jamesmcarthur has joined #openstack-tc17:31
ricolingmann, is this a correct statement to you17:33
ricolin- There is now a ML [4] and etherpad[6] to discuss about specific schedule for OpenStack Python 2 to 3 migration, please join our discussions! There's a lot of discussion happened in [5]. As we now have a schedule out in [6] for drop python 2.7, we need each teams to pay attention on their python dependency and check if that schedule works. The release schedule will be update accordingly.17:33
mnaserseems like i missed a fun topic17:37
gmannricolin:  we already said ' please join our discussions! ' so discussion is done today but people can bring the points. and draft schedule is also out for a while. next plan is i am going to 1. summarize the agreement on ML 2. compose goal 3. update release schedule and 4. TC liaison are contacting to each projects if anything they missed or not agree with the plan17:37
openstackgerritSean McGinnis proposed openstack/election master: Add Governance link to PTL results
*** jamesmcarthur has quit IRC17:43
*** dhellmann_ has joined #openstack-tc17:43
*** dhellmann has quit IRC17:45
*** dhellmann_ is now known as dhellmann17:45
*** jaosorior has quit IRC17:45
ricolingmann, will scratch the join discussion part17:47
* ricolin is working on weekly update ML for TCs and community17:49
*** jaosorior has joined #openstack-tc17:50
gmannricolin: thanks. i will be summarizing the discussion in ML today and you can link there17:50
*** jamesmcarthur has joined #openstack-tc17:54
*** ricolin has quit IRC17:55
*** jamesmcarthur has quit IRC17:59
*** tosky has joined #openstack-tc18:03
mriedemas people start removing the openstack-python-jobs job template to drop py27 they are forgetting that includes the pep8 job. is there a plan to add pep8 to openstack-python3-ussuri-jobs or just everyone has to list the pep8 job directly now?
fungimriedem: it's
*** jaosorior has quit IRC18:09
mriedemack thanks18:10
*** jaosorior has joined #openstack-tc18:11
*** jaosorior has quit IRC18:20
*** mriedem has quit IRC18:20
*** mriedem has joined #openstack-tc18:22
openstackgerritSean McGinnis proposed openstack/election master: Add Governance link to PTL results
*** zaneb has quit IRC19:23
*** slaweq has joined #openstack-tc19:50
*** slaweq has quit IRC19:55
*** tosky_ has joined #openstack-tc20:00
*** tosky has quit IRC20:03
*** slaweq has joined #openstack-tc20:04
*** jamesmcarthur has joined #openstack-tc20:14
*** nicolasbock has joined #openstack-tc20:21
*** zaneb has joined #openstack-tc20:27
*** zaneb has quit IRC20:28
*** zaneb has joined #openstack-tc20:29
*** jamesmcarthur has quit IRC20:34
*** zaneb has quit IRC20:35
*** zaneb has joined #openstack-tc20:36
*** zbitter has joined #openstack-tc20:40
*** zaneb has quit IRC20:40
*** KeithMnemonic has quit IRC20:41
*** zbitter has quit IRC20:44
*** zbitter has joined #openstack-tc20:44
*** KeithMnemonic has joined #openstack-tc20:52
*** zbitter has quit IRC20:58
*** zaneb has joined #openstack-tc21:01
*** zaneb has quit IRC21:03
*** zaneb has joined #openstack-tc21:03
*** zaneb has quit IRC21:07
*** zaneb has joined #openstack-tc21:08
*** markvoelker has quit IRC21:20
fungigmann: in your summary to the ml it looks like you're saying libs can't drop py27 testing until on or after the second milestone date. i thought what we had discussed was them being able to drop it between milestone 1 and milestone 2 but that if they were going to drop it in ussuri they had to do it prior to reaching milestone 2?21:35
fungithat services/leaf projects had until milestone 1, because after m1 (but by m2) libs they depend on could drop it21:36
*** e0ne has joined #openstack-tc21:37
fungiand that dropping py27 testing between m2 and release wasn't allowed, to give the projects depending on them some stability between then and release21:37
* fungi can follow up on the ml if needed21:38
fungithe original plan we discussed anyway was leaf projects dropping python 2.7 testing by milestone 1 to allow shared libraries to drop python 2.7 testing by milestone 221:39
fungisince libs are frozen at milestone 321:39
fungiif libs can't drop py27 until on or after m2, then they have a very limited amount of time to stabilize or decide they need to revert before they get released at m321:40
*** slaweq has quit IRC21:44
*** e0ne has quit IRC21:49
*** e0ne has joined #openstack-tc21:49
*** zaneb has quit IRC21:51
*** zaneb has joined #openstack-tc21:51
*** zaneb has quit IRC21:53
*** zaneb has joined #openstack-tc21:54
*** slaweq has joined #openstack-tc21:55
*** e0ne has quit IRC21:56
fungii've followed up on the ml thread with my concerns21:58
*** zaneb has quit IRC22:01
*** zaneb has joined #openstack-tc22:02
*** markvoelker has joined #openstack-tc22:03
*** zaneb has quit IRC22:10
*** zaneb has joined #openstack-tc22:11
*** slaweq has quit IRC22:13
*** zaneb has quit IRC22:14
*** zaneb has joined #openstack-tc22:14
*** zaneb has quit IRC22:17
*** zaneb has joined #openstack-tc22:19
*** zaneb has quit IRC22:21
*** zaneb has joined #openstack-tc22:22
*** markvoelker has quit IRC22:26
*** zaneb has quit IRC22:33
*** tosky_ is now known as tosky22:36
*** tosky has quit IRC22:36
gmannfungi: humm, i mean those are deadline not the start point. but thanks for clarification.22:46
fungiyeah, your e-mail implied those milestone dates were when such things could start happening, not when they needed to be done by22:47
fungiat least that's how i interpreted it22:47
fungiso we need to make sure everyone is on the same page there, otherwise if people think libs aren't going to start breaking py27 support at milestone 1, they're in for an unpleasant surprise22:48
gmannok, i updated etherad with clear duration please check22:48
fungigmann: thanks! yes what's in the etherpad now is clear and matches what i intended as well22:49
*** mriedem has quit IRC22:54
fungibasically we have a month and a half from now for leaf projects to finish removing whatever py27 testing they're going to remove, because starting at milestone 1 they could get broken by libraries merging non-py27-compatible changes. libraries get ~2 months between m1 and m2 to do that, and then they have a ~1.5-month stabilization period between m2 and their final releases for ussuri22:54
fungithe leaf projects actually have a lot more time to do merge non-py27-compatible changes themselves, because they can start as soon as they remove the jobs (so ~now) and continue until the start of the rc period if they like22:58
fungithe libs are far more constrained since they need to give leaf projects time to remove testing, and yet still release earlier than them22:59
*** slaweq has joined #openstack-tc23:00
fungithis is of course ignoring projects that haven't figured out py3k testing yet. but that's why we had cycle goals for it in rocky, stein, and train23:00
fungiat this point if they can't merge any other changes until they get py3k support knocked out, that doesn't actually seem like a problem to me23:01
fungimore like incentive23:01
*** slaweq has quit IRC23:05
*** slaweq has joined #openstack-tc23:43
*** slaweq has quit IRC23:48

Generated by 2.15.3 by Marius Gedminas - find it at!