| *** jamesmcarthur has joined #openstack-tc | 00:00 | |
| *** jamesmcarthur has quit IRC | 00:16 | |
| *** jamesmcarthur has joined #openstack-tc | 00:17 | |
| *** markvoelker has joined #openstack-tc | 00:21 | |
| *** jamesmcarthur_ has joined #openstack-tc | 00:26 | |
| *** jamesmcarthur has quit IRC | 00:26 | |
| *** jamesmcarthur_ has quit IRC | 00:29 | |
| *** jamesmcarthur has joined #openstack-tc | 00:30 | |
| *** jamesmcarthur has quit IRC | 00:30 | |
| *** jamesmcarthur has joined #openstack-tc | 00:32 | |
| zaneb | coreycb: 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 gate | 00:33 |
|---|---|---|
| *** zhurong has quit IRC | 00:36 | |
| *** jamesmcarthur has quit IRC | 00:40 | |
| *** jamesmcarthur has joined #openstack-tc | 00:40 | |
| *** mriedem_afk is now known as mriedem | 01:02 | |
| *** mriedem has quit IRC | 01:02 | |
| *** markvoelker has quit IRC | 01:28 | |
| *** spsurya has joined #openstack-tc | 01:59 | |
| *** markvoelker has joined #openstack-tc | 02:00 | |
| *** markvoelker has quit IRC | 02:05 | |
| *** ricolin has joined #openstack-tc | 02:12 | |
| *** nicolasbock has quit IRC | 02:23 | |
| *** jamesmcarthur has quit IRC | 02:25 | |
| *** jamesmcarthur has joined #openstack-tc | 02:30 | |
| *** jamesmcarthur has quit IRC | 03:10 | |
| *** jamesmcarthur has joined #openstack-tc | 03:11 | |
| njohnston | zaneb++ | 03:12 |
| *** jamesmcarthur has quit IRC | 03:15 | |
| *** diablo_rojo has quit IRC | 03:18 | |
| *** jamesmcarthur has joined #openstack-tc | 03:42 | |
| *** jamesmcarthur has quit IRC | 04:27 | |
| *** jamesmcarthur has joined #openstack-tc | 04:31 | |
| *** jamesmcarthur has quit IRC | 04:39 | |
| *** jamesmcarthur has joined #openstack-tc | 04:52 | |
| ricolin | o/ | 05:11 |
| *** slaweq has joined #openstack-tc | 05:12 | |
| *** jamesmcarthur has quit IRC | 05:13 | |
| *** jamesmcarthur has joined #openstack-tc | 05:20 | |
| *** slaweq has quit IRC | 05:29 | |
| *** jamesmcarthur has quit IRC | 05:30 | |
| *** markvoelker has joined #openstack-tc | 06:02 | |
| *** markvoelker has quit IRC | 06:06 | |
| *** slaweq has joined #openstack-tc | 06:25 | |
| *** iurygregory has joined #openstack-tc | 06:34 | |
| njohnston | o/ | 06:41 |
| *** tosky has joined #openstack-tc | 07:12 | |
| asettle | o/ | 08:20 |
| njohnston | asettle: 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 of | 08:32 |
| njohnston | https://docs.openstack.org/train/ | 08:32 |
| njohnston | I was not sure if that was by policy or if it is something that I could suggest as a contribution | 08: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 idea | 08:34 |
| evrardjp_ | :) | 08:34 |
| njohnston | evrardjp_: 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 |
| njohnston | evrardjp_: 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 not | 08:38 |
| njohnston | sure | 08:38 |
| evrardjp_ | I am just playing devil's advocate in the meantime that the docs people can answer :p | 08:38 |
| * asettle swans in with a cat | 08:46 | |
| asettle | njohnston, 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 |
| asettle | Btw njohnston feel free to bring this convo over to openstack-doc | 08:57 |
| asettle | Andreas might know why we do what we do ther | 08:57 |
| asettle | e | 08:57 |
| njohnston | asettle: you got it | 09:08 |
| *** jaosorior has joined #openstack-tc | 09:15 | |
| *** e0ne has joined #openstack-tc | 09:33 | |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: New charms & interfaces for MySQL8 https://review.opendev.org/688211 | 09:44 |
| *** markvoelker has joined #openstack-tc | 10:04 | |
| *** markvoelker has quit IRC | 10:09 | |
| ricolin | ttx tc dinner scheduled on Wednesday 11/6 | 10:24 |
| ttx | woohoo! Thanks | 10:45 |
| *** nicolasbock has joined #openstack-tc | 11:58 | |
| *** jamesmcarthur has joined #openstack-tc | 12:11 | |
| *** jamesmcarthur has quit IRC | 12:28 | |
| *** markvoelker has joined #openstack-tc | 12:31 | |
| evrardjp_ | thanks ricolin | 12:35 |
| evrardjp_ | ricolin: I think we should sync over the board meeting presentation during the summit | 12:37 |
| evrardjp_ | mnaser: do you have the previous OpenStack foundation board meeting TC update handy? I thought to use it as a base | 12:38 |
| *** jaosorior has quit IRC | 12:42 | |
| ricolin | evrardjp_, yes, right now I only got the slides from Berlin | 12:48 |
| *** jamesmcarthur has joined #openstack-tc | 12:48 | |
| *** adriant has quit IRC | 12:51 | |
| *** adriant has joined #openstack-tc | 12:53 | |
| *** jeremy__bouncer has quit IRC | 13:11 | |
| *** jeremy__bouncer has joined #openstack-tc | 13:12 | |
| *** jeremy__bouncer has quit IRC | 13:12 | |
| *** jamesmcarthur has quit IRC | 13:13 | |
| *** jeremy__bouncer has joined #openstack-tc | 13:14 | |
| *** jamesmcarthur has joined #openstack-tc | 13:20 | |
| *** mriedem has joined #openstack-tc | 13:23 | |
| *** spsurya has quit IRC | 13:29 | |
| *** slaweq has quit IRC | 13:32 | |
| *** e0ne has quit IRC | 13:35 | |
| *** e0ne has joined #openstack-tc | 13:36 | |
| *** nicolasbock has quit IRC | 14:01 | |
| zaneb | evrardjp_, njohnston: if you move a doc then you should add a redirect, otherwise people linking to /latest will also get a 404 | 14:03 |
| coreycb | zaneb: thanks for the input. i'll look into a non-voting py38 job once it's available on bionic. | 14:03 |
| zaneb | coreycb: awesome, thanks | 14:06 |
| *** jamesmcarthur has quit IRC | 14:06 | |
| ttx | evrardjp_: 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 |
| ttx | smcginnis: same question for the "Operations Docs" SIG -- did that one go anywhere? | 14:09 |
| smcginnis | ttx: It's still "active", just not a lot of focus. | 14:09 |
| smcginnis | Its 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 |
| ttx | Does it still make sense in the new "docs is a SIG" world? | 14:10 |
| ttx | ok | 14:10 |
| smcginnis | It 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 |
| ttx | I wonder if we should not have a status for SIGs that are not "active" but are still around to maintain stuff. | 14:10 |
| ttx | Like if a problem is raised those people would jump in | 14:11 |
| ttx | but there is no weekly meeting needed | 14:11 |
| ttx | at best office hours | 14:11 |
| smcginnis | There's probably work that could be done there. It just needs someone with the motivation to do it. | 14:11 |
| fungi | though also if they're not active, it's hard to tell whether anyone's around to jump into action when needed | 14:11 |
| ttx | ok, thanks for the update | 14:11 |
| smcginnis | We'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 |
| smcginnis | Or just ad hoc in the ops channel. | 14:12 |
| fungi | so you won't really discover the difference between latent and defunct without some triggering event | 14:12 |
| smcginnis | True | 14:12 |
| fungi | it's a bit of a schrödinger's cat situation | 14:12 |
| fungi | just without the cesium atom | 14:12 |
| smcginnis | Maybe every cycle - have a process of emailing the chairs and asking if a SIG is still active and/or needed? | 14:13 |
| smcginnis | Sounds maybe like what ttx is doing now. | 14:14 |
| ttx | yeah, I'm doing it a bit informally | 14:16 |
| jungleboyj | Just needs formalization then? | 14:16 |
| *** jamesmcarthur has joined #openstack-tc | 14:17 | |
| ttx | somewhere between my TC hat, my Meta SIG hat and my OSF hat | 14:17 |
| jungleboyj | And we are back to needing a hat switching API. | 14:17 |
| ttx | jungleboyj, smcginnis: I think it's the job of the Meta SIG | 14:18 |
| ttx | Keep track of SIGs in general | 14:19 |
| smcginnis | Makes sense. Anyway, thanks for doing it. Glad someone is checking. | 14:19 |
| gmann | o/ | 14:20 |
| ttx | just started a thread on the resource management one | 14:20 |
| *** bnemec has quit IRC | 14:35 | |
| *** bnemec has joined #openstack-tc | 14: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 evrardjp | 14:48 | |
| ttx | evrardjp: if it's still in the cards, there is no issue... just want the page to reflect current state | 14:49 |
| evrardjp | yeah there is no reason to drop it afaik | 14:49 |
| gmann | TC office hour time.. | 15:00 |
| *** jcapitao has joined #openstack-tc | 15:00 | |
| njohnston | o/ | 15:00 |
| gmann | as planned I would like to start the discussion on py2.7 drop | 15:00 |
| gmann | i think most of the tc are here | 15:01 |
| gmann | tc-members ^^ | 15:01 |
| asettle | o/ | 15:01 |
| jroll | oh boy | 15:01 |
| jungleboyj | o/ | 15:01 |
| jungleboyj | Wheeeee | 15:01 |
| *** gouthamr_ is now known as gouthamr | 15:01 | |
| * fungi wonders if jroll just experienced a quantum leap | 15:01 | |
| gmann | :) | 15:02 |
| jroll | heh | 15:02 |
| jroll | I 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 |
| gmann | let's wait for few min in case more members show up | 15:04 |
| *** mnasiadka has joined #openstack-tc | 15:05 | |
| njohnston | cloudnull is travelling IIRC | 15:05 |
| gmann | ok | 15:06 |
| * mugsie is here, but not really here - trying to write slides + workshop for shangai before I start travel next week | 15:07 | |
| evrardjp | I am here but technically on holidays. I will pay attention to this though | 15:09 |
| * evrardjp should take example on mugsie :) | 15:09 | |
| *** slaweq has joined #openstack-tc | 15:10 | |
| jroll | I think we can go ahead, if anyone cares deeply they'd be here already, the others can catch up | 15:10 |
| gmann | ok. let's start | 15:10 |
| gmann | yeah | 15:10 |
| gmann | etherpad link https://etherpad.openstack.org/p/drop-python2-support | 15:10 |
| gmann | this etherpad is collecting the key points, projects want to keep py2.7 support and draft schedule | 15:10 |
| gmann | we can start from starting of etherpad | 15:11 |
| gmann | L19 - 'Projects want to keep python 2 support and need oslo, QA or any other dependent projects/lib support' | 15:11 |
| gmann | swift is in the list to keep the support | 15:12 |
| e0ne | :( | 15:12 |
| gmann | i wrote the two options for them | 15:12 |
| gmann | timburke can tell us the exact plan for swift | 15:12 |
| njohnston | I 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-tc | 15:13 | |
| jungleboyj | njohnston: That is a good point. | 15:13 |
| gmann | njohnston: +1. i will write that on etherpad | 15:13 |
| mwhahaha | but doesn't that mean basically it can't be tested under py27 anymore? | 15:13 |
| gmann | both are same. if you are not testing it means it might be broken anytime | 15:14 |
| gmann | and if not supporting then you cannot keep testing | 15:14 |
| jroll | is there a problem with swift wanting to keep support? | 15:14 |
| bnemec | FWIW, swift doesn't use Oslo so that doesn't necessarily affect us. | 15:14 |
| bnemec | Unless they have a transitive dep that I'm not aware of. | 15:14 |
| jroll | right | 15:14 |
| gmann | etherpad mentioned that they need one release with py3 and also want to keep xenial support | 15:14 |
| jroll | their dependency list is very small: https://github.com/openstack/swift/blob/master/requirements.txt | 15:14 |
| gmann | bnemec: is it | 15:15 |
| jroll | I don't have a problem with them keeping 2.7 if they can handle the work | 15:15 |
| njohnston | I like the elegance of the version cap proposal; it really captures the spirit of "this is the end of the road". | 15:15 |
| gmann | opohk these are their dep- https://opendev.org/openstack/swift/src/branch/master/requirements.txt | 15:15 |
| fungi | yeah, 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 software | 15:16 |
| gmann | ok, we should be ok as long as it is not extra burdon on openstack maintained projects/lib | 15:16 |
| *** jaosorior has quit IRC | 15:16 | |
| fungi | their independence from openstack shared libs should make it not too much of a problem, i hope | 15:17 |
| gmann | yeah | 15:17 |
| njohnston | +1 | 15:17 |
| gmann | so 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 plugin | 15:17 |
| fungi | and 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 |
| jungleboyj | I think the cap makes sense as well. | 15:17 |
| jroll | ++ | 15:17 |
| evrardjp | fungi: agreed | 15:18 |
| fungi | i expect they can perform stand-alone swift functional testing without devstack (perhaps they already do, i haven't looked at their jobs) | 15:18 |
| gmann | make sense | 15:18 |
| gmann | fungi: 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 fine | 15:19 |
| clarkb | fungi: they are using containers in saio now (swift all in one) no devstack | 15:20 |
| clarkb | fungi: I don't think we should continue to carry devstack python2 support for testing swift given they have tools that can do it for them | 15:20 |
| jungleboyj | clarkb: ++ | 15:20 |
| gmann | agree. | 15:20 |
| fungi | clarkb: absolutely, i did not mean to suggest devstack needs to retain 2.7 support, quite the reverse in fact | 15:21 |
| gmann | i 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 etc | 15:22 |
| gmann | next is Tempest in that list. which i added and started the ML also if any strong opposition to drop the support | 15:23 |
| gmann | as QA team we are ok to drop and i did not get any users saying not to do that. | 15:23 |
| gmann | only tripleo want it till centos8 | 15:23 |
| evrardjp | as leader of said team, we trust you too :) | 15:23 |
| mwhahaha | it would be nice if we could hold off until we have rdo in place | 15:24 |
| gmann | so tempest will drop support in m-2 which is mid of feb | 15:24 |
| mwhahaha | which hopefully won't be long | 15:24 |
| evrardjp | we have to think the best for OpenStack as a whole not only a single project. | 15:24 |
| gmann | mwhahaha: ^^ is that fine for you | 15:24 |
| mwhahaha | yes | 15:24 |
| mwhahaha | if it's in feb that should be fine | 15:24 |
| evrardjp | But I understand that position, and it would be good to have RDO approval | 15:24 |
| mwhahaha | if we don't have rdo+centos8 by then we have other problems | 15:24 |
| gmann | mwhahaha: perfect. | 15:24 |
| evrardjp | I am typing too slow | 15:24 |
| evrardjp | thanks mwhahaha | 15:25 |
| gmann | we have testing tools planned for phase-2 which is m-2 | 15:25 |
| evrardjp | gmann: should we add those steps into the release schedule ? | 15:25 |
| *** slaweq has quit IRC | 15:25 | |
| gmann | evrardjp: +1 nice idea. once we finalized the schedule then it is good idea to put on release schedule too | 15:26 |
| gmann | any other project want to keep support anyone aware and not listed in etherpad ? otherwise we move to discuss the other points | 15:28 |
| evrardjp | I think we can move | 15:28 |
| mugsie | did the quieter projects respond? | 15:28 |
| mugsie | (trove / searchlight etc spring to mind) | 15:29 |
| gmann | not yet. hope they read the email | 15:29 |
| * evrardjp has high hopes | 15:29 | |
| njohnston | noone I am aware of. Even networking-midonet is getting behind it, and we had concerns that project was unmanned. | 15:29 |
| mugsie | I would just be concerned about them completely breaking, and seen both are basically single person projects I would worry about them recovering | 15:30 |
| mugsie | but that may be "not bad" thing I suppose | 15:30 |
| gmann | njohnston: ah ok. they are not yet migrated to bionic also if i remember. do you know they want to keep py2.7 | 15:30 |
| njohnston | gmann: No, they are working on converting their jobs to accomodate py3 testing | 15:30 |
| gmann | ok. hope you can bring this to all neutron stadium projects in neutron meeting or so | 15:31 |
| gmann | in case we miss anyone. | 15:31 |
| njohnston | gmann: we've been harping on it for almost a year now | 15:32 |
| gmann | mugsie: yeah. should we approach to them individually ? i do not know how many we can though | 15:32 |
| gmann | njohnston: perfect. | 15:32 |
| mugsie | could the liasons reach out gmann? | 15:33 |
| mugsie | trove is zaneb, evrardjp | 15:33 |
| gmann | ah nice idea. | 15:33 |
| mugsie | searhclight is gmann, jungleboyj | 15:33 |
| zaneb | what are we supposed to be asking them? | 15:33 |
| gmann | i 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 |
| evrardjp | zaneb: if they read the ML I guess? | 15:34 |
| zaneb | lol | 15:34 |
| gmann | zaneb: if py2.7 support dropping is fine for them and yes they are aware of this (ML) | 15:34 |
| evrardjp | zaneb: ofc let's do that through email | 15:34 |
| evrardjp | joke aside, this is good to highlight. | 15:34 |
| gmann | added in etherpad ac a action item for all of us | 15:35 |
| njohnston | +1 | 15:35 |
| zaneb | they support python3 already afaik. that's the hard part. | 15:35 |
| evrardjp | I suppose many have for a while, else they would not be compliant with PTI | 15:36 |
| jungleboyj | So is there an action item for me there or not? | 15:37 |
| evrardjp | yet, removing 2 is not the same as supporting 3 :) | 15:37 |
| gmann | py3 is ok but they might want to keep py2.7 for their customer or so ? | 15:37 |
| jungleboyj | Also, where is the liaison list? | 15:37 |
| evrardjp | exactly :) | 15:37 |
| evrardjp | jungleboyj: it's in governance | 15:37 |
| gmann | jungleboyj: yes, please check your liaison projects | 15:37 |
| mugsie | jungleboyj: https://governance.openstack.org/tc/reference/tc-liaisons.html | 15:37 |
| jungleboyj | mugsie: Ah, thank you. New guy didn't know about that. | 15:38 |
| mugsie | and then on the project pages, it has them as well (e.g.: https://governance.openstack.org/tc/reference/projects/heat.html ) | 15:38 |
| evrardjp | jungleboyj: for code: https://github.com/openstack/governance/blob/master/reference/members.yaml | 15:38 |
| mugsie | it merged a few weeks before you joined, so not something everyone would know yet :) | 15:38 |
| gmann | added the link on etherpad too | 15:38 |
| gmann | or new member should get the checklist or welcome todo things from chair :). i got from dhellmann and that was helpful . | 15:39 |
| gmann | let's move next | 15:39 |
| jungleboyj | :-) Ok, good to know. | 15:40 |
| gmann | before schedule discussion, which can be the last thing. let's check 'Questions/Key Points to take care:' | 15:40 |
| gmann | L57 on etherpad | 15:40 |
| gmann | 'How to test the upgrade from python2 -> python3' | 15:40 |
| jungleboyj | So, I will reach out to searchlight on the ML. | 15:41 |
| gmann | grenade is option to test this in upstream but there were failure on devstack patch from mriedem | 15:41 |
| gmann | jungleboyj: thanks | 15:41 |
| gmann | https://zuul.opendev.org/t/openstack/build/cbb25dbf44474a1ca24dc3b0d2b1e455 | 15:41 |
| gmann | we said we can do that if we find volunteer otherwise we can drop this idea at least to test in upstream CI/CD | 15:42 |
| gmann | I do not know if mriedem has plan to fix those failure and want to make job for such testing | 15:43 |
| mriedem | py2->py3 grenade? | 15:43 |
| gmann | yeah | 15:43 |
| mriedem | i'm not planning on creating a job for that | 15:43 |
| gmann | ok. | 15:43 |
| njohnston | I 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 v3 | 15:43 |
| evrardjp | I think we've got our expert. Thanks njohnston ! :p | 15:43 |
| gmann | njohnston: which job | 15: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 this | 15:44 | |
| njohnston | gmann: 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-* jobs | 15:45 |
| gmann | currently train -> master is py2->p2 and py3->py3 | 15:45 |
| gmann | ohk | 15:45 |
| gmann | njohnston: currently it is failing (py2->py3) - https://zuul.opendev.org/t/openstack/build/cbb25dbf44474a1ca24dc3b0d2b1e455 | 15:46 |
| jroll | so there's an old ML thread about this where we agreed that we probably don't need to test py2->3 upgrades in services: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134592.html | 15:46 |
| *** iurygregory has quit IRC | 15:46 | |
| gmann | yeah | 15:46 |
| jroll | of course, a project could do that if they wanted | 15:47 |
| jroll | we did pick out an oslo.messaging bug around this that would have affects, but I assume that's fixed by now | 15:47 |
| gmann | yeah, we can do as part of integrated gate testing also if someone make it working | 15:47 |
| jroll | oh, not a bug, just a need for a test: https://bugs.launchpad.net/oslo.messaging/+bug/1792977 | 15:47 |
| openstack | Launchpad bug 1792977 in oslo.messaging "Need a functional test to verify py2 <-> py3 interoperability" [High,Triaged] | 15:47 |
| jroll | I'm not particularly concerned about testing it in the integrated gate, but that might just be me | 15:48 |
| evrardjp | jroll: care to explain why ? | 15:49 |
| jroll | evrardjp: because if a service works on py2 and works on py3, it should just work when the underlying python is switched | 15:50 |
| jroll | *rolling* upgrades are a concern, because you have mixed versions | 15:50 |
| jroll | but that should all be handled in o.msg | 15:50 |
| gmann | till train we have been testing both version as integrated, unit, functional testing | 15:50 |
| evrardjp | jroll: I don't disagree, but why wouldn't it deserve testing in the integrated gate? | 15:50 |
| evrardjp | I think I see what you mean now | 15:51 |
| evrardjp | nvm | 15:51 |
| ricolin | o/ | 15:51 |
| jroll | evrardjp: 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 versa | 15:51 |
| gmann | do we have plan from oslo to do so ? | 15:52 |
| gmann | bnemec ^^ | 15:52 |
| jroll | they have a bug for a work item: https://bugs.launchpad.net/oslo.messaging/+bug/1792977 | 15:52 |
| openstack | Launchpad bug 1792977 in oslo.messaging "Need a functional test to verify py2 <-> py3 interoperability" [High,Triaged] | 15:52 |
| jroll | but doesn't look like it's been touched | 15:52 |
| bnemec | Not that I know of. We have not had good luck holding on to messaging folks lately. :-/ | 15:52 |
| gmann | from 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 all | 15:53 |
| bnemec | We do have functional tests though so hopefully it wouldn't be too difficult to do. | 15:53 |
| gmann | ok | 15:53 |
| gmann | let'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 |
| njohnston | +1 | 15:54 |
| jroll | ++ | 15:55 |
| fungi | it might have been a nice-to-have when we were working on achieving python 3 support | 15:55 |
| fungi | now it's here and we're looking at dropping python 2 | 15:56 |
| evrardjp | fine for me. We'll discover things through other mechanisms, and deal with it appropriately I guess :) | 15:56 |
| fungi | and by now i expect plenty of folks who were using openstack on python 2 have upgraded to python 3 | 15:56 |
| *** diablo_rojo has joined #openstack-tc | 15:56 | |
| fungi | so if there were significant problems associated with that, someone would hopefully have told us | 15:56 |
| gmann | and if they could have faced bug while upgrading they could have reported | 15:57 |
| gmann | yeah. you typed fast | 15:57 |
| gmann | ok, i added the AGREE in etherpad | 15:57 |
| gmann | next is 'fast-forward upgrades from <=Stein to >=Ussuri need some solution to switch from Python2.7 to Python3.{6,7} in Train' | 15:57 |
| gmann | L66 | 15:58 |
| fungi | worst 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 future | 15:58 |
| jroll | fungi: ++ | 15:58 |
| gmann | yeah | 15:58 |
| gmann | fungi: ^^ fast-forward upgrade thing | 15:58 |
| gmann | stein was also doing testing for both version so should be ok right | 15:59 |
| jroll | why does a fast forward need to move to py3 in the train part of the upgrade? | 15:59 |
| *** diablo_rojo has quit IRC | 15:59 | |
| *** diablo_rojo has joined #openstack-tc | 16:00 | |
| jroll | well, I take that back | 16:00 |
| gmann | rocky->ussuri ? | 16:00 |
| jroll | but, upstream doesn't really support FFU, right? that's for vendors to handle? | 16:00 |
| gmann | +1. | 16:01 |
| fungi | yeah, it was mostly a question about how ffu works if going from a py2-only release to a py3-only release | 16:01 |
| fungi | and whether it's something we need to worry/care about | 16:02 |
| jroll | fair question, I think people writing FFU automation would insert the py3 switch in the middle somewhere | 16:02 |
| * gmann office hour time is up but i hope we can continue and finish the schedule | 16:02 | |
| fungi | because the upgrading routines (db-manage and whatnot) will need to switch interpreters at some point in the sequence | 16:02 |
| njohnston | I 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 could | 16:03 |
| fungi | sure | 16:03 |
| amotoki | all 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 |
| diablo_rojo | o/ | 16:03 |
| fungi | it'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 3 | 16:04 |
| gmann | yeah, py2->py3 might have be done before release upgrade | 16:04 |
| evrardjp | Is it really a problem we have to solve in here? | 16:05 |
| fungi | evrardjp: that's the question | 16:05 |
| gmann | let's keep those for vendors to worry if it does not work or create issue for them | 16:05 |
| amotoki | I don't think so, but it is better to mention what we expect. | 16:05 |
| fungi | right, it's about setting expectations | 16:05 |
| gmann | there used to be upgrade sig ? | 16:06 |
| fungi | we 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 upgrade | 16:06 |
| *** jcapitao is now known as jcapitao|afk | 16:07 | |
| ttx | upgrade sig called success and was disbanded | 16:07 |
| gmann | ohk | 16:07 |
| ttx | a while ago | 16:07 |
| gmann | fungi: +1. that is some thing we can highlight | 16:07 |
| gmann | let's move to next item about backport - L68 'What are our guidelines to backport fixes to stable branches?' | 16:08 |
| gmann | py3 only code backport can be issue | 16:09 |
| njohnston | that's a good point | 16:09 |
| jungleboyj | Yeah. I am worried about this for Cinder. | 16:09 |
| fungi | doesn't seem like the backport guidelines really change. stable branches will continue to be tested with python 2.7 | 16:09 |
| fungi | and dependencies can't really be altered | 16:10 |
| gmann | backport expert mriedem ^^ | 16:10 |
| fungi | there are always changes between releases which require some backports to be adapted | 16:10 |
| smcginnis | Just might require a little more tweaking to get things backported. | 16:10 |
| njohnston | If 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 on | 16:10 |
| fungi | this is just maybe a bigger/broader change than usual | 16:10 |
| jungleboyj | Yeah, we will just need to be sensitive that some changes can't be an exact cherry-pick. | 16:10 |
| gmann | this is something we can solve case by case if that happen. do not knoe what we can do in this | 16:10 |
| jungleboyj | gmann: ++ | 16:11 |
| fungi | jungleboyj: and realistically, it's already the case that some changes can't be cherry-picked directly | 16:11 |
| gmann | if that happen, then make it work for py2.7 also using six and then backport | 16:11 |
| jungleboyj | fungi: True. | 16:11 |
| njohnston | I 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 choices | 16:11 |
| gmann | but then question is we need to keep six support | 16:11 |
| amotoki | it totally depends on test coverage. we need to review backports from py2/py3 compatibility more than now. | 16:11 |
| jungleboyj | gmann: ++ | 16:11 |
| amotoki | +1 for keeping six support | 16:12 |
| jungleboyj | Is there any reason to hurry removing it? | 16:13 |
| evrardjp | I think this doesn't need to be determined today | 16:13 |
| gmann | but we have to decide if six support can be removed or not from projects if we drop py2.7 | 16:13 |
| evrardjp | I 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 |
| mriedem | what is the specific backport question? i'm not paying attention. | 16:13 |
| *** e0ne has quit IRC | 16:14 | |
| gmann | mriedem: from py3 only code from ussuri to stable | 16:14 |
| mriedem | stable branches would continue to test py27 and if you backport something that needs tweaking for py27 then you do it in the backport | 16:14 |
| evrardjp | For me, this is not a simple black or white, and projects can (as usual) decide their fate | 16:14 |
| gmann | mriedem: yeah and that need six support to keep. | 16:14 |
| mriedem | like smcginnis says "Just might require a little more tweaking to get things backported." | 16:14 |
| mriedem | sure | 16:14 |
| jungleboyj | evrardjp: That makes sense. | 16:14 |
| evrardjp | And yes, it shouldn't break the stable policy per se | 16:15 |
| *** jcapitao|afk has quit IRC | 16:15 | |
| njohnston | +1 | 16:15 |
| gmann | mriedem: oh. tweak for py2.7 in backport or on master | 16:15 |
| mriedem | backport | 16:15 |
| evrardjp | gmann: I guess it's tweak for py2 in the backport | 16:15 |
| mriedem | 99% of the time that's not going to be a problem | 16:15 |
| evrardjp | It seems we are all in agreement then? | 16:15 |
| mriedem | if it is, you fix in the backport and mention it in the commit message | 16:15 |
| gmann | yeah, it is case by case not everytime | 16:15 |
| fungi | mriedem: specifically, the question was whether the stable branch backport policy needs changing for this. i asserted that it shouldn't | 16:16 |
| *** mriedem is now known as mriedem_away | 16:16 | |
| gmann | in that case we do not have to say keep six support. it is up to projects | 16:16 |
| mriedem_away | fungi: agree, no change | 16:16 |
| evrardjp | gmann: correct | 16:16 |
| gmann | ok. | 16:16 |
| gmann | i will add the AGREE. | 16:16 |
| evrardjp | :) | 16:16 |
| gmann | next item | 16:16 |
| gmann | L71- What is the tactics of dropping openstack-tox-py27 in our gate? (amotoki) | 16:16 |
| fungi | having release-specific project-templates which apply those makes the removal somewhat straightforward | 16:17 |
| gmann | this is adding the pep8 job to ussuri template so that we can drop openstack-python-jobs https://review.opendev.org/#/c/688997/ | 16:17 |
| gmann | fungi: yeah | 16:17 |
| fungi | projects who want to retain the openstack-tox-py27 job can add it directly to their project configuration | 16:17 |
| gmann | true. please review that patch if any objection | 16:18 |
| amotoki | or they can keep openstack-python-jobs template | 16:18 |
| njohnston | To 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 |
| gmann | yes keeping py2.7 template does not harm if they want to test py2.7 | 16:19 |
| gmann | now L33 'Draft Schedule:' | 16:19 |
| * gouthamr peeks in - manila meeting coincided with this office hour | 16:20 | |
| njohnston | I have an appointment and have to run - thanks all | 16:20 |
| gmann | does mentioned schedule works fine for all ? anything missed ? | 16:20 |
| gmann | njohnston: sure, thanks | 16:20 |
| gmann | there is os-vif comment from sean-k-mooney | 16:21 |
| *** ianychoi has joined #openstack-tc | 16:21 | |
| gmann | not sure it is for keeping till m-3 or m-2 is fine | 16:21 |
| fungi | concern with m-3 is that's pretty late in the cycle when teams are getting a lot busier on other stuff | 16:22 |
| gmann | m-2 is all ok and as per draft schedule | 16:22 |
| smcginnis | I think the earlier we do things the better to make sure there aren't any late cycle surprises. | 16:22 |
| gmann | true. | 16:22 |
| evrardjp | smcginnis: ++ | 16:22 |
| fungi | yeah, any fallout gets dealt with while folks have more available bandwidth to do so | 16:23 |
| jungleboyj | I agree that M-2 is better. | 16:23 |
| evrardjp | I 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 |
| gmann | I will check with sean-k-mooney if it cannot be done from m1 -> m-2 | 16:23 |
| gmann | evrardjp: thanks for attending in ur holiday too | 16:23 |
| jungleboyj | :-) | 16:23 |
| gmann | if no objection to the mentioned schedule then let's make it final. | 16:24 |
| jungleboyj | gmann: ++ | 16:24 |
| amotoki | horizon 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 |
| amotoki | the current schedule looks fine from horizon perspective too | 16:24 |
| evrardjp | it is a big topic. I can take a few hours for this :) | 16:24 |
| gmann | amotoki: thanks | 16:25 |
| gmann | ok. it's all from etherpad. anything else to discuss | 16:25 |
| gmann | if no then last thing. | 16:26 |
| gmann | is 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 |
| jungleboyj | The py3 support? | 16:27 |
| gmann | ? you mean we can do as part of that goal | 16:28 |
| jungleboyj | gmann: I don't understand the question. :-) | 16:28 |
| smcginnis | That 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 |
| gmann | py3 support goal was there since many cycle | 16:28 |
| smcginnis | Rephrased - py2 non-support would be the new goal. | 16:29 |
| gmann | smcginnis: 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 now | 16:29 |
| gmann | yeah | 16:29 |
| gmann | till goal merge and then it means everyone else (except in list) ok to drop py2.7 | 16:30 |
| smcginnis | That 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 |
| gmann | TC liasion will check with their projects if they did not notice this | 16:30 |
| gmann | yeah | 16:31 |
| gmann | we 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 |
| jungleboyj | smcginnis: Ok. That was what had me confused. I thought we already had the goal. :-) | 16:31 |
| jungleboyj | Yeah, I think have a cycle goal for dropping py27 support makes sense. | 16:32 |
| gmann | ok, I will compose the goal. and summarize this discussion on ML | 16:32 |
| ricolin | community goal is definitely help to check the drop process bi-way, but we need to specify the action for projects | 16:32 |
| jungleboyj | gmann: ++ | 16:32 |
| smcginnis | Having 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 |
| gmann | yeah | 16:32 |
| gmann | that's all from me. thanks everyone for participating. | 16:33 |
| jungleboyj | Welcome. :-) | 16:34 |
| jungleboyj | gmann: 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 |
| gmann | jungleboyj: yeah, i am also going to do that via email to PTL and CC second TC liaison | 16:36 |
| gmann | there are two TC liaison per project, so keeping him/her in CC will help in sync and avoid duplicate email | 16:36 |
| jungleboyj | gmann: Ok, I was going to use the ML but I suppose directly contacting the PTL is probably a good idea. | 16:37 |
| jungleboyj | Hmm, some of these project pages are missing. | 16:38 |
| fungi | out of curiosity, what cross-project actions would such a cycle goal actually entail? | 16:39 |
| gmann | jungleboyj: yeah you can get response better with direct email | 16:40 |
| jungleboyj | Okie Dokie. | 16:40 |
| fungi | as 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 anything | 16:40 |
| fungi | s/v6/python 3/ | 16:40 |
| fungi | (sorry, having ipv6 discussions simultaneously in another channel) | 16:41 |
| smcginnis | I believe that summarization is correct. | 16:41 |
| fungi | s/python 3/2.7/ | 16:41 |
| * fungi sighs | 16:41 | |
| gmann | fungi: 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 immediately | 16:41 |
| amotoki | perhaps the goal is to drop py27 or declare py27 support explicitly | 16:41 |
| gmann | fungi: correct | 16:42 |
| fungi | gmann: 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 tasks | 16:42 |
| gmann | amotoki: yes, it will update setup.cfg to remove the py2.7 from there | 16:42 |
| gmann | fungi: 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 py27 | 16:43 |
| fungi | gmann: yep, but how do you track that? first you need to know that cinder is planning to do something | 16:45 |
| gmann | amotoki: 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 |
| fungi | so 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 |
| smcginnis | https://review.opendev.org/#/c/691016/1 | 16:46 |
| fungi | a cycle goal is for some set of tasks we want most projects to do by the time ussuri is released | 16:47 |
| amotoki | gmann: 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 |
| gmann | fungi: champion can coordinate on that. if 2 projects need to go together then push patch for both together | 16:47 |
| fungi | gmann: but why does it need to be a goal champion? | 16:47 |
| gmann | for co-ordination | 16:47 |
| fungi | and 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 |
| fungi | it sounds like we need a coordinator to handle communication, but i don't see how it's a cycle goal | 16:48 |
| smcginnis | I 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 |
| gmann | we 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 |
| fungi | goals are great for tracking, but first we need to know what to track | 16:49 |
| gmann | i am not sure how many cases it will be like that may be 0 | 16:49 |
| gmann | amotoki: yeah, we will add the phase wise deadline. | 16:50 |
| amotoki | from 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 |
| fungi | anyway, 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 |
| openstackgerrit | Merged openstack/governance master: Remove puppet-yum from Infra https://review.opendev.org/688761 | 16:52 |
| openstackgerrit | Merged openstack/governance master: Add a redirect for the renamed openstack-chef project https://review.opendev.org/689143 | 16:52 |
| openstackgerrit | Merged openstack/governance master: Switch to Ussuri jobs https://review.opendev.org/689978 | 16:52 |
| openstackgerrit | Merged openstack/governance master: Add openstack/barbican-ui https://review.opendev.org/688699 | 16:52 |
| fungi | so it needs a plan (we have one, awesome) and a coordinator or several to handle communication of that plan at each phase | 16:52 |
| fungi | but that's not the same thing as a cycle goal | 16:52 |
| *** tosky has quit IRC | 16:52 | |
| smcginnis | Well, the thing we want done is to have everyone to move in an orderly fashion out the py2 door. | 16:53 |
| fungi | escept, we don't | 16:53 |
| fungi | er, except | 16:53 |
| fungi | we want everyone who is moving out the py2 door to do so in an orderly fashion | 16:53 |
| gmann | there are things to be done here. removing jobs, update setup.cfg, reno to clear notification that this project not supporting py27 any more | 16:54 |
| fungi | gmann: is the work that is required to be done work that needs to be done by most projects? | 16:54 |
| smcginnis | Unless 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 |
| fungi | or is it centralized, with some optional work that projects can do on their own if they want? | 16:55 |
| gmann | i expect all projects (dropping it) to do. | 16:55 |
| fungi | that's a tautology | 16:55 |
| gmann | it should not be a silently drop the py2 in bit and pieces | 16:55 |
| fungi | okay, so the cycle goal is about cleanup then? | 16:56 |
| fungi | the "this is what teams need to do by the time ussuri is released" part of the goal | 16:56 |
| smcginnis | I 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 |
| fungi | i 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 it | 16:58 |
| gmann | projects 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 py27 | 16:58 |
| smcginnis | I 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 |
| smcginnis | Being vague isn't going to help our users. | 16:59 |
| gmann | yeah, optional is more confusing. either declare explicitly or drop. | 17:00 |
| amotoki | smcginnis: ++ | 17:00 |
| smcginnis | So the goal (to me) would be "don't be vague". | 17:00 |
| fungi | i 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 pieces | 17:00 |
| gmann | and we can maintain some user facing centralized doc or wiki saying what all keep the support | 17:01 |
| gmann | that can be good to point in various place of notification | 17:01 |
| jungleboyj | Does OpenStackSDK have a PTL? There is nothing in the PTL list. | 17:01 |
| clarkb | I want to say it is monty | 17:01 |
| gmann | Monty i think | 17:01 |
| fungi | did teh change to set monty as ptl never merge? | 17:01 |
| gmann | oh | 17:02 |
| jungleboyj | gmann: Thanks. | 17:02 |
| amotoki | jungleboyj: https://governance.openstack.org/tc/reference/projects/openstacksdk.html | 17:02 |
| fungi | jungleboyj: what is "the ptl list" then? | 17:02 |
| fungi | i assumed you meant the reference/projects.yaml in openstack governance | 17:03 |
| *** jaosorior has joined #openstack-tc | 17:03 | |
| jungleboyj | fungi: Ah, thank you. That is helpful. | 17:08 |
| * jungleboyj is feeling very new. | 17:08 | |
| fungi | is there a "ptl list" somewhere with an out of date set of ptls? | 17:11 |
| fungi | or were you looking at election results? | 17:11 |
| *** markvoelker has quit IRC | 17:12 | |
| fungi | election 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 page | 17:12 |
| jungleboyj | fungi: I was. | 17:12 |
| clarkb | https://governance.openstack.org/election/results/train/ptl.html election results show monty too fwiw | 17:14 |
| *** mriedem_away is now known as mriedem | 17:14 | |
| gmann | train is fine. but in ussuri it was pointed later - https://governance.openstack.org/election/results/ussuri/ptl.html | 17:17 |
| gmann | appointed | 17:17 |
| clarkb | ah | 17:17 |
| fungi | https://governance.openstack.org/election/results/ussuri/ptl.html | 17:18 |
| ricolin | gmann, are you plan to update ussuri release schedule too? https://opendev.org/openstack/releases/src/branch/master/doc/source/ussuri/schedule.yaml | 17:23 |
| gmann | ricolin: that is the plan. i think it is good idea (from evrardjp). | 17:25 |
| *** markvoelker has joined #openstack-tc | 17:26 | |
| *** jamesmcarthur has quit IRC | 17:29 | |
| *** jamesmcarthur has joined #openstack-tc | 17:31 | |
| ricolin | gmann, is this a correct statement to you | 17: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 |
| ricolin | [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010142.html | 17:33 |
| ricolin | [5] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-10-24.log.html | 17:33 |
| ricolin | [6] https://etherpad.openstack.org/p/drop-python2-support | 17:33 |
| mnaser | seems like i missed a fun topic | 17:37 |
| gmann | ricolin: 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 plan | 17:37 |
| openstackgerrit | Sean McGinnis proposed openstack/election master: Add Governance link to PTL results https://review.opendev.org/691030 | 17:41 |
| *** jamesmcarthur has quit IRC | 17:43 | |
| *** dhellmann_ has joined #openstack-tc | 17:43 | |
| *** dhellmann has quit IRC | 17:45 | |
| *** dhellmann_ is now known as dhellmann | 17:45 | |
| *** jaosorior has quit IRC | 17:45 | |
| ricolin | gmann, will scratch the join discussion part | 17:47 |
| * ricolin is working on weekly update ML for TCs and community | 17:49 | |
| *** jaosorior has joined #openstack-tc | 17:50 | |
| gmann | ricolin: thanks. i will be summarizing the discussion in ML today and you can link there | 17:50 |
| *** jamesmcarthur has joined #openstack-tc | 17:54 | |
| *** ricolin has quit IRC | 17:55 | |
| *** jamesmcarthur has quit IRC | 17:59 | |
| *** tosky has joined #openstack-tc | 18:03 | |
| mriedem | as 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? https://review.opendev.org/#/c/690996/2/.zuul.yaml | 18:07 |
| fungi | mriedem: it's https://review.opendev.org/688997 | 18:09 |
| gmann | mriedem: https://review.opendev.org/#/c/688997/ | 18:09 |
| gmann | yeah | 18:09 |
| *** jaosorior has quit IRC | 18:09 | |
| mriedem | ack thanks | 18:10 |
| *** jaosorior has joined #openstack-tc | 18:11 | |
| *** jaosorior has quit IRC | 18:20 | |
| *** mriedem has quit IRC | 18:20 | |
| *** mriedem has joined #openstack-tc | 18:22 | |
| openstackgerrit | Sean McGinnis proposed openstack/election master: Add Governance link to PTL results https://review.opendev.org/691030 | 18:50 |
| *** zaneb has quit IRC | 19:23 | |
| *** slaweq has joined #openstack-tc | 19:50 | |
| *** slaweq has quit IRC | 19:55 | |
| *** tosky_ has joined #openstack-tc | 20:00 | |
| *** tosky has quit IRC | 20:03 | |
| *** slaweq has joined #openstack-tc | 20:04 | |
| *** jamesmcarthur has joined #openstack-tc | 20:14 | |
| *** nicolasbock has joined #openstack-tc | 20:21 | |
| *** zaneb has joined #openstack-tc | 20:27 | |
| *** zaneb has quit IRC | 20:28 | |
| *** zaneb has joined #openstack-tc | 20:29 | |
| *** jamesmcarthur has quit IRC | 20:34 | |
| *** zaneb has quit IRC | 20:35 | |
| *** zaneb has joined #openstack-tc | 20:36 | |
| *** zbitter has joined #openstack-tc | 20:40 | |
| *** zaneb has quit IRC | 20:40 | |
| *** KeithMnemonic has quit IRC | 20:41 | |
| *** zbitter has quit IRC | 20:44 | |
| *** zbitter has joined #openstack-tc | 20:44 | |
| *** KeithMnemonic has joined #openstack-tc | 20:52 | |
| *** zbitter has quit IRC | 20:58 | |
| *** zaneb has joined #openstack-tc | 21:01 | |
| *** zaneb has quit IRC | 21:03 | |
| *** zaneb has joined #openstack-tc | 21:03 | |
| *** zaneb has quit IRC | 21:07 | |
| *** zaneb has joined #openstack-tc | 21:08 | |
| *** markvoelker has quit IRC | 21:20 | |
| fungi | gmann: 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 |
| fungi | that services/leaf projects had until milestone 1, because after m1 (but by m2) libs they depend on could drop it | 21:36 |
| *** e0ne has joined #openstack-tc | 21:37 | |
| fungi | and that dropping py27 testing between m2 and release wasn't allowed, to give the projects depending on them some stability between then and release | 21:37 |
| * fungi can follow up on the ml if needed | 21:38 | |
| fungi | the 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 2 | 21:39 |
| fungi | since libs are frozen at milestone 3 | 21:39 |
| fungi | if 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 m3 | 21:40 |
| smcginnis | ++ | 21:41 |
| *** slaweq has quit IRC | 21:44 | |
| *** e0ne has quit IRC | 21:49 | |
| *** e0ne has joined #openstack-tc | 21:49 | |
| *** zaneb has quit IRC | 21:51 | |
| *** zaneb has joined #openstack-tc | 21:51 | |
| *** zaneb has quit IRC | 21:53 | |
| *** zaneb has joined #openstack-tc | 21:54 | |
| *** slaweq has joined #openstack-tc | 21:55 | |
| *** e0ne has quit IRC | 21:56 | |
| fungi | i've followed up on the ml thread with my concerns | 21:58 |
| *** zaneb has quit IRC | 22:01 | |
| *** zaneb has joined #openstack-tc | 22:02 | |
| *** markvoelker has joined #openstack-tc | 22:03 | |
| *** zaneb has quit IRC | 22:10 | |
| *** zaneb has joined #openstack-tc | 22:11 | |
| *** slaweq has quit IRC | 22:13 | |
| *** zaneb has quit IRC | 22:14 | |
| *** zaneb has joined #openstack-tc | 22:14 | |
| *** zaneb has quit IRC | 22:17 | |
| *** zaneb has joined #openstack-tc | 22:19 | |
| *** zaneb has quit IRC | 22:21 | |
| *** zaneb has joined #openstack-tc | 22:22 | |
| *** markvoelker has quit IRC | 22:26 | |
| *** zaneb has quit IRC | 22:33 | |
| *** tosky_ is now known as tosky | 22:36 | |
| *** tosky has quit IRC | 22:36 | |
| gmann | fungi: humm, i mean those are deadline not the start point. but thanks for clarification. | 22:46 |
| fungi | yeah, your e-mail implied those milestone dates were when such things could start happening, not when they needed to be done by | 22:47 |
| fungi | at least that's how i interpreted it | 22:47 |
| fungi | so 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 surprise | 22:48 |
| gmann | ok, i updated etherad with clear duration please check | 22:48 |
| fungi | gmann: thanks! yes what's in the etherpad now is clear and matches what i intended as well | 22:49 |
| gmann | ok | 22:49 |
| *** mriedem has quit IRC | 22:54 | |
| fungi | basically 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 ussuri | 22:54 |
| gmann | yeah | 22:56 |
| fungi | the 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 like | 22:58 |
| fungi | the libs are far more constrained since they need to give leaf projects time to remove testing, and yet still release earlier than them | 22:59 |
| *** slaweq has joined #openstack-tc | 23:00 | |
| fungi | this 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 train | 23:00 |
| fungi | at 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 me | 23:01 |
| fungi | more like incentive | 23:01 |
| *** slaweq has quit IRC | 23:05 | |
| *** slaweq has joined #openstack-tc | 23:43 | |
| *** slaweq has quit IRC | 23:48 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!