| *** ykarel|away is now known as ykarel | 05:39 | |
| *** amoralej|off is now known as amoralej | 06:54 | |
| *** ysandeep|out is now known as ysandeep | 07:20 | |
| iurygregory | elodilles, can you update https://review.opendev.org/c/openstack/releases/+/808793 to include the latest commit in ipa-builder? I will be happy to +1 | 07:30 |
|---|---|---|
| opendevreview | Hervé Beraud proposed openstack/releases master: Release ironic-python-agent-builder for xena https://review.opendev.org/c/openstack/releases/+/808793 | 07:38 |
| hberaud | iurygregory: done ^ | 07:38 |
| iurygregory | done =) | 07:40 |
| hberaud | thanks | 07:41 |
| iurygregory | np | 07:48 |
| iurygregory | hberaud, for ironic/inspector we can do a final release to create stable/xena during Sep 27 - Oct 01 ? | 07:52 |
| iurygregory | I was looking at https://releases.openstack.org/xena/schedule.html | 07:52 |
| hberaud | iurygregory: I don't think it will be possible because new feature have been added (d7400b5). At least if it is possible it will require a FFE and a RFE | 07:56 |
| hberaud | iurygregory: I mean, I'm not against but it should be discussed first because CWI deliverables are now frozen | 07:58 |
| iurygregory | hberaud, got it, so we should try to at least cut a new release without creating the stable branch now? | 07:59 |
| hberaud | and you should notice that its stable branch will be proposed ASAP (I was thinking to propose missing stable branches today, if our gates are repaired) | 08:00 |
| iurygregory | oh ok =) | 08:00 |
| iurygregory | I will look at things in the ironic side | 08:00 |
| hberaud | ok | 08:00 |
| hberaud | let me know your decision ASAP | 08:01 |
| iurygregory | ack | 08:01 |
| hberaud | ttx, elodilles: FYI ^ | 08:02 |
| iurygregory | Ironic CI is a bit weird due to some neutron failures we are trying to fix, no luck yet, but let's see how it goes (other projects we should be fine to create the stable/branches) | 08:02 |
| hberaud | ack | 08:02 |
| hberaud | anyway our gates are broken too | 08:03 |
| iurygregory | well, it's friday :D | 08:03 |
| hberaud | elodilles, ttx: o/ almost all our jobs don't seems triggered. Only check-release-approval seems to work. Yesterday a bunch of patch timed out and `recheck` them don't seems to trigger the jobs | 08:05 |
| hberaud | fungi, clarkb: FYI ^ | 08:06 |
| hberaud | fungi, clarkb: I seen your discussion of yesterday, I think it's more or less related, however, the weird thing is that now almost nothing job seems triggered | 08:08 |
| hberaud | fungi, clarkb: #update: jobs seems queued since a while | 08:10 |
| hberaud | since almost 1 hour for some of them | 08:11 |
| elodilles | i guess zuul is overloaded because of the massive amount of failing jobs / timeouts | 08:12 |
| elodilles | however the queues are not that long. hmmm | 08:13 |
| hberaud | some are elapsed | 08:13 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release barbican-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809541 | 08:31 |
| obondarev | Hi everyone! Could someone please advise when yoga dir will be created here: https://github.com/openstack/releases/tree/master/deliverables? Thanks in advance! | 08:32 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release cloudkitty-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809542 | 08:32 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release freezer-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809543 | 08:33 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release glance-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809544 | 08:33 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release heat-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809545 | 08:34 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release ironic-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809546 | 08:35 |
| hberaud | obondarev: it will be created 1 weeks after Xena's final release | 08:36 |
| obondarev | hberaud: got it, thanks! | 08:37 |
| hberaud | obondarev: so around October 11 | 08:37 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release kuryr-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809547 | 08:37 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release magnum-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809548 | 08:38 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release manila-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809549 | 08:38 |
| elodilles | hberaud: hmmm, did I miss something regarding the tempest-plugin release patches? ^^^ | 08:39 |
| hberaud | elodilles: what? | 08:39 |
| elodilles | now that I see that you are proposing those | 08:39 |
| hberaud | yes this is a task for the next week | 08:40 |
| hberaud | but next week I'll be AFK on monday | 08:40 |
| elodilles | ohh, i see | 08:40 |
| hberaud | So I prefer anticipate a bit to let's time to the team to react | 08:40 |
| elodilles | I thought this is something that I've missed with my task from this week o:) | 08:41 |
| elodilles | but those projects were not listed by the tox command :) | 08:41 |
| elodilles | so now i get it, if these are for next week tasks :) | 08:42 |
| hberaud | elodilles: One tips for you during Yoga, if you seach for examples of patches of the previous cycles, during wallaby I added topics to use in our process, so you can easily retrieve this kind of series for each cycle | 08:42 |
| hberaud | elodilles: by example the topic of those is 'xena-tp-latest' (https://review.opendev.org/c/openstack/releases/+/809546) | 08:43 |
| hberaud | this help to look up in a standardized way | 08:44 |
| elodilles | hberaud: thanks, I've started to search for these topics :) thanks for introducing this way of working, it really makes one's life easier | 08:44 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release murano-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809570 | 08:44 |
| hberaud | np | 08:45 |
| hberaud | One good addition would be to add the existing version for the given cycle in process-auto-release | 08:45 |
| hberaud | it would help us to see if a first version already exit | 08:46 |
| hberaud | exist | 08:46 |
| hberaud | I'll try to add this feature soon | 08:46 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release neutron-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809571 | 08:47 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release octavia-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809573 | 08:48 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release telemetry-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809574 | 08:50 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release zaqar-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809575 | 08:51 |
| elodilles | you mean in the commit message? or how? | 08:52 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Release zun-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809576 | 08:52 |
| hberaud | elodilles: nope in gerrit, to retrieve all those patches | 08:53 |
| hberaud | Ah sorry | 08:53 |
| hberaud | I mean during the use of process-auto-release | 08:53 |
| hberaud | when we are asked to decide if we want to generate a bugfix version, a feature version etc... | 08:54 |
| hberaud | we don't have the info about the previous existing versions so we need to look at them first | 08:55 |
| hberaud | and then decide | 08:55 |
| hberaud | that's time consuming | 08:56 |
| hberaud | else we shoots in the dark and then the validation could fail | 08:56 |
| elodilles | i see, yes, the previous existing version needs to be searched for, true | 08:56 |
| elodilles | btw, for me it seems that setuptools latest release causes our trouble during pip install (i saw somewhere some discussion around it and the sympthoms tends to show the error in that direction...) | 09:00 |
| elodilles | "error in pydot2 setup command: use_2to3 is invalid." | 09:01 |
| elodilles | vs https://github.com/pypa/setuptools/issues | 09:01 |
| hberaud | elodilles: yes yoctozepto, fungi, and clarkb discussed about this yesterday evening here | 09:02 |
| * bauzas grabs popcorn | 09:05 | |
| elodilles | bauzas: the hungarian vs french language comparison in nova channel is much more exciting than this error hunting :] | 09:09 |
| gibi | elodilles: do you think that I cannot reproduce the pip issue locally as I have old python-venv and therefore old setuptools locally? | 09:10 |
| elodilles | gibi: definitely | 09:11 |
| elodilles | I'm trying to pull in the latest setuptools to at least reproduce the error | 09:11 |
| elodilles | gibi: maybe the latest virtualenv uses the new setuptools | 09:14 |
| *** ykarel_ is now known as ykarel | 09:14 | |
| gibi | afaik python-venv boundles setuptools | 09:15 |
| gibi | bundles | 09:15 |
| elodilles | tomato tomato :) | 09:16 |
| bauzas | gibi: it does | 09:17 |
| bauzas | gibi: but you can ask for not | 09:18 |
| bauzas | sec | 09:18 |
| bauzas | gibi: elodilles: https://docs.python.org/3/library/venv.html | 09:20 |
| bauzas | --upgrade-deps | 09:20 |
| bauzas | and IIRC there is something like "--no-setuptools" option | 09:22 |
| bauzas | yep, there is one | 09:22 |
| bauzas | --no-setuptools do not install setuptools (default: False) | 09:22 |
| elodilles | (with upgraded virtualenv i can reproduce the error at least) | 09:23 |
| bauzas | so you can pip it later | 09:23 |
| elodilles | fun that this use_2to3 error comes from pydot2 (due to latest setuptools), which has the last release from 2014 and the homepage says 503... | 09:28 |
| gibi | do we really depend on pydot2? what breaks if we drop it? | 09:29 |
| bauzas | what uses use_2to3 ? | 09:32 |
| bauzas | nova ? | 09:33 |
| elodilles | no, pydot2 uses it | 09:33 |
| elodilles | and good question what package depends on pydot2 | 09:33 |
| elodilles | I'll try to check it in deptree | 09:34 |
| bauzas | yeah, can't find it in our reqs | 09:34 |
| bauzas | actually, I need to bail out for lunch and gym, back around 2pm our time | 09:35 |
| elodilles | openstack-governance | 09:36 |
| elodilles | and here is the fix: https://review.opendev.org/c/openstack/governance/+/809430 | 09:38 |
| elodilles | (at least this should be valid for releases repo) | 09:39 |
| elodilles | so I guess we need to release governance to be able to release other things (hope it's not a catch-22 :X) | 09:40 |
| elodilles | gibi bauzas : in nova I see the same issue with 'decorator' | 09:42 |
| yoctozepto | you have pydot2? | 09:46 |
| yoctozepto | codesearch did not bring it up | 09:46 |
| yoctozepto | I fixed it for governance | 09:46 |
| yoctozepto | I can't see pydot2 | 09:47 |
| yoctozepto | ah, I see you are wondering which package depended on it | 09:47 |
| yoctozepto | ack | 09:47 |
| yoctozepto | are you then planning to release governance? | 09:48 |
| hberaud | a lot of deliverables seems to rely on pydot https://codesearch.opendev.org/?q=pydot&i=nope&literal=nope&files=&excludeFiles=&repos= | 09:54 |
| hberaud | yoctozepto: if it help to fix the thing then yes | 09:54 |
| opendevreview | Hervé Beraud proposed openstack/releases master: List cycle's releases with process_auto_release https://review.opendev.org/c/openstack/releases/+/809623 | 09:55 |
| hberaud | elodilles: ^ | 09:55 |
| opendevreview | Hervé Beraud proposed openstack/releases master: List cycle's releases with process_auto_release https://review.opendev.org/c/openstack/releases/+/809623 | 09:56 |
| elodilles | hberaud: will review it, thanks :) | 09:57 |
| hberaud | no rush | 09:57 |
| hberaud | thanks | 09:57 |
| elodilles | hberaud: pydot is maintained, the problem is (for us) pydot2 | 09:57 |
| yoctozepto | pydot works fine | 09:58 |
| yoctozepto | pydot2 is what broke | 09:58 |
| elodilles | hberaud yoctozepto : for me it seems a catch-22 we cannot release until we have a working openstack-governance. so we cannot even release openstack-governance :S | 09:58 |
| hberaud | I see | 09:58 |
| hberaud | ah indeed | 09:59 |
| hberaud | sigh | 09:59 |
| yoctozepto | elodilles: nice; can we just workaround/disable the code that tries to install it? | 09:59 |
| hberaud | yoctozepto: the code who install openstack-governance? | 10:00 |
| hberaud | or pydot2? | 10:00 |
| elodilles | sure, there could be multiple solutions. | 10:00 |
| elodilles | "force" approve openstack-governance? (which means "force" release of openstack-governance), or some other ugly way of releasing? :S | 10:02 |
| hberaud | we can't disable governance in our release repo, it is everywhere | 10:04 |
| hberaud | however, we could release it manually | 10:04 |
| hberaud | without using openstack/release | 10:04 |
| hberaud | I think we need the infra team do to that | 10:05 |
| *** ykarel is now known as ykarel|lunch | 10:05 | |
| yoctozepto | hberaud: governance | 10:05 |
| hberaud | I don't think it is possible | 10:06 |
| yoctozepto | I meant, you can simplify the jobs, do the obvious release, and restore the logic (revert the first patch) | 10:06 |
| yoctozepto | let me have a quick look | 10:06 |
| hberaud | it will broken all our validation and tag generation | 10:07 |
| hberaud | (I think) | 10:07 |
| hberaud | I think that if we are able to trigger the code of this file after merging a release patch then we are ok https://opendev.org/openstack/project-config/src/branch/master/roles/copy-release-tools-scripts/files/release-tools/process_release_requests.py | 10:12 |
| opendevreview | Elod Illes proposed openstack/releases master: Release openstack-governance 0.11.0 https://review.opendev.org/c/openstack/releases/+/809625 | 10:13 |
| hberaud | so, we could disable our validation, and simply merge the patch, trigger these actions, and then reenable our validation | 10:13 |
| ttx | We should see what's the best option with fungi | 10:13 |
| elodilles | hberaud: I've proposed the patch just in case... (though it will break) ^^^ | 10:13 |
| yoctozepto | I'm proposing something in a moment | 10:13 |
| hberaud | elodilles: +1 thanks | 10:13 |
| ttx | In the mean time I suspect we should stop approving anything? | 10:14 |
| hberaud | yes | 10:14 |
| hberaud | anyway we can't merge things | 10:14 |
| ttx | IIRC opendev admins can forcemerge things | 10:15 |
| opendevreview | Radosław Piliszek proposed openstack/releases master: Fix gate https://review.opendev.org/c/openstack/releases/+/809626 | 10:15 |
| ttx | to avoid that catch-22 | 10:15 |
| hberaud | that what I was thinking | 10:15 |
| ttx | unless the post-processing also requires governance, but I think it does not | 10:15 |
| yoctozepto | yeah, but it will try to install it | 10:16 |
| hberaud | I checked and it doesn't seems to need it | 10:16 |
| yoctozepto | and this is what breaks | 10:16 |
| yoctozepto | so I've just "fixed" the requirements.txt | 10:16 |
| yoctozepto | mayhaps you even want them to be this way rather than via release | 10:16 |
| hberaud | not much opinion... can't see the possible side effects for now | 10:19 |
| yoctozepto | btw, I meant https://review.opendev.org/c/openstack/releases/+/809626 if it was not clear from opendevreview :-) | 10:19 |
| hberaud | at least this patch is needed if we want to unlock the things | 10:21 |
| hberaud | I think we need 1) to manually release governance 2) merge this patch 3) try to merge another patch to see if it repaired our gates | 10:23 |
| yoctozepto | I suggest we 1) merge this patch, 2) release all that we need, 3) discuss if we want it to follow repo or revert to releases | 10:23 |
| hberaud | ah indeed release governance isn't needed with this patch, sorry | 10:24 |
| hberaud | this is a good shortcut | 10:25 |
| hberaud | I'll socialize the situation on the ML | 10:29 |
| yoctozepto | ++ | 10:37 |
| yoctozepto | meh, zuul seemingly down | 10:42 |
| yoctozepto | or just verrrry slow | 10:42 |
| hberaud | same here with zuul | 10:43 |
| hberaud | yoctozepto: Well, I summarized the situation, and by thinking about that I think that you are right about pulling governance from git rather than from pypi | 10:44 |
| hberaud | this is a cross dependency | 10:45 |
| hberaud | the same thing could appear from pbr, reno and all the deliverables that we own and that are in our req.txt | 10:46 |
| hberaud | openstack/release should not have cross dependency even from a process viewpoint | 10:47 |
| *** ykarel|lunch is now known as ykarel | 10:49 | |
| yoctozepto | yeah, as it's doing the releases | 10:49 |
| hberaud | cross dependencies are more or less the root cause of this situation. | 10:49 |
| yoctozepto | mhm | 10:49 |
| hberaud | (from a release viewpoint) | 10:49 |
| yoctozepto | still timing out on tox's with test-requirements installed - need to find another guilty dep | 11:12 |
| yoctozepto | no, found the culprit | 11:19 |
| opendevreview | Radosław Piliszek proposed openstack/releases master: Fix gate https://review.opendev.org/c/openstack/releases/+/809626 | 11:20 |
| yoctozepto | quirks, quirks everywhere | 11:20 |
| hberaud | thumbs up! | 11:23 |
| hberaud | ttx, elodilles: FYI I need to go to an appointment I'll be AFK during a while. See you at our meeting | 11:24 |
| elodilles | hberaud: ack | 11:42 |
| elodilles | thanks yoctozepto , zuul is happy so we can use your patch to unblock the gate! \o/ | 11:55 |
| ttx | nice | 11:56 |
| ttx | +2a | 11:56 |
| elodilles | \o/ | 11:56 |
| *** ykarel is now known as ykarel|afk | 12:00 | |
| opendevreview | Merged openstack/releases master: Fix gate https://review.opendev.org/c/openstack/releases/+/809626 | 12:07 |
| yoctozepto | now that the gate is green, please release my deliverable :-) https://review.opendev.org/c/openstack/releases/+/808949 | 12:27 |
| fungi | elodilles: hberaud: pydot2 has been unmaintained since 2014 and doesn't work with current setuptools. the fix that worked in governance was to replace it with pydot (which is actively maintained and seems to be compatible with pydot2 usage) | 12:29 |
| fungi | still catching up | 12:32 |
| fungi | ahh, looks like you hit on a workaround which didn't involve bypassing anything | 12:34 |
| elodilles | partly. pydot2 replacement needed for openstack-governance, but it had the fix already so we "just" needed a release (catch-22). Finally the fixing patch | 12:37 |
| elodilles | replaced to consume openstack-governance from repo instead of pypi | 12:37 |
| elodilles | thanks to yoctozepto | 12:38 |
| elodilles | so now the gate is unblocked | 12:38 |
| elodilles | \o/ | 12:38 |
| yoctozepto | \o/ | 12:46 |
| *** amoralej is now known as amoralej|lunch | 12:48 | |
| elodilles | i've initiated rechecks towards the approved release patches (8 patches) | 12:50 |
| bauzas | elodilles: thanks | 12:53 |
| bauzas | I was wondering whether I should recheck | 12:53 |
| opendevreview | Douglas Mendizábal proposed openstack/releases master: Release barbican-tempest-plugin for xena https://review.opendev.org/c/openstack/releases/+/809541 | 12:56 |
| opendevreview | Merged openstack/releases master: Release final python-masakariclient for Xena https://review.opendev.org/c/openstack/releases/+/808949 | 12:58 |
| elodilles | bauzas: no problem :) | 13:07 |
| *** ykarel|afk is now known as ykarel | 13:20 | |
| opendevreview | Merged openstack/releases master: Release ironic-python-agent-builder for xena https://review.opendev.org/c/openstack/releases/+/808793 | 13:24 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for networking-baremetal https://review.opendev.org/c/openstack/releases/+/808682 | 13:24 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for cloudkitty https://review.opendev.org/c/openstack/releases/+/808610 | 13:28 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for blazar https://review.opendev.org/c/openstack/releases/+/808604 | 13:28 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for networking-generic-switch https://review.opendev.org/c/openstack/releases/+/808685 | 13:32 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for cloudkitty-dashboard https://review.opendev.org/c/openstack/releases/+/808609 | 13:32 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for blazar-dashboard https://review.opendev.org/c/openstack/releases/+/808602 | 13:32 |
| *** amoralej|lunch is now known as amoralej | 13:34 | |
| hberaud | yoctozepto: kudos and congrat! | 13:35 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for networking-sfc https://review.opendev.org/c/openstack/releases/+/808689 | 13:39 |
| yoctozepto | hberaud: merci ! :-) | 13:43 |
| hberaud | :) | 13:43 |
| fungi | once you get a new governance release processed, make sure to revert the requirements change | 13:46 |
| hberaud | will do that one now | 13:46 |
| fungi | though in your e-mail you suggested continuing to consume governance from git, that also makes sense but would be better accomplished with a bit of improvement in the jobs themselves to make the governance repo a required project | 13:48 |
| hberaud | I would prefer to keep the fix | 13:49 |
| hberaud | I'll bring that point to our topic | 13:49 |
| hberaud | I'll update it once it will be discussed and when we will almost aligned | 13:50 |
| fungi | yeah, i think you ultimately want a different fix though, i replied on the ml | 13:52 |
| fungi | there is a better way to consume other projects from source than by using git references in requirements files | 13:53 |
| hberaud | I didn't get your response yet | 13:53 |
| hberaud | will check | 13:53 |
| fungi | it was only in the last few minutes, so it may not have arrived in your inbox yet | 13:55 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for tacker https://review.opendev.org/c/openstack/releases/+/808733 | 13:57 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for solum https://review.opendev.org/c/openstack/releases/+/808730 | 13:58 |
| hberaud | #startmeeting releaseteam | 14:00 |
| opendevmeet | Meeting started Fri Sep 17 14:00:06 2021 UTC and is due to finish in 60 minutes. The chair is hberaud. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'releaseteam' | 14:00 |
| hberaud | Ping list: elodilles armstrong | 14:00 |
| ttx | o/ | 14:00 |
| hberaud | #link https://etherpad.opendev.org/p/xena-relmgt-tracking | 14:00 |
| hberaud | We're way down on line 349 now. | 14:00 |
| hberaud | Will just wait a couple minutes for folks. | 14:00 |
| yoctozepto | o/ | 14:01 |
| elodilles | o/ | 14:01 |
| hberaud | ok let's go | 14:02 |
| hberaud | #topic Review task completion | 14:02 |
| hberaud | The first task was "Process any remaining library branching exception". IIRC I didn't see exception | 14:03 |
| hberaud | 2) On the Monday, generate release requests for all deliverables that have do not have a suitable candidate yet. | 14:03 |
| hberaud | this was done with 2 series of patches | 14:04 |
| hberaud | the first one was for CWI projects => https://review.opendev.org/c/openstack/releases/+/808782 | 14:04 |
| hberaud | sorry wrong link https://review.opendev.org/q/topic:%22xena-c-a%22+(status:open%20OR%20status:merged) | 14:05 |
| hberaud | only one patch remain unmerged yet, I'll approve it now | 14:05 |
| elodilles | thanks! | 14:06 |
| hberaud | Thanks to you elodilles | 14:06 |
| hberaud | and the second series was for RC deliverables => https://review.opendev.org/q/topic:%22xena-rc1-deadline%22 | 14:06 |
| hberaud | deadline is over and almost all PTLs approved their part so I think that we are good to go with the patches which remain opened | 14:07 |
| hberaud | ttx, elodilles feel free to validate these ones | 14:08 |
| elodilles | I'll continue to review these patches after the meeting, | 14:08 |
| hberaud | +1 thanks | 14:08 |
| elodilles | now that the gate is working :) | 14:08 |
| hberaud | We should only notice that even if the PTL validation badge is not present those patch are almost validated by current PTL | 14:09 |
| hberaud | s/are all almost/ | 14:09 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for freezer-web-ui https://review.opendev.org/c/openstack/releases/+/808618 | 14:10 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for adjutant https://review.opendev.org/c/openstack/releases/+/808593 | 14:10 |
| hberaud | And that's all for task completion | 14:10 |
| ttx | will also do reviews after meeting | 14:10 |
| hberaud | thanks | 14:10 |
| hberaud | #topic Assign R-2 tasks | 14:10 |
| hberaud | Any volunteer for "After all the projects enabled in devstack by default have been branched, we can engage with the QA, I18n and Requirements PTLs to finalize the stable branch setup" ? | 14:11 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for freezer https://review.opendev.org/c/openstack/releases/+/808619 | 14:11 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for murano-agent https://review.opendev.org/c/openstack/releases/+/808674 | 14:11 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for murano-dashboard https://review.opendev.org/c/openstack/releases/+/808677 | 14:11 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for murano https://review.opendev.org/c/openstack/releases/+/808680 | 14:11 |
| hberaud | and "Ensure that all projects that are publishing release notes have the notes link included in their deliverable file." | 14:11 |
| elodilles | i can help with those though i might need help | 14:12 |
| hberaud | I took that one | 14:12 |
| gmann | ping me once branches are ready and QA will take care of devstack/grenade things | 14:12 |
| hberaud | then let me put your name on engaging QA, i18n etc... | 14:12 |
| gmann | sure, +1 | 14:12 |
| hberaud | gmann: I mean elodilles's name :) | 14:13 |
| gmann | ok :) either is ok | 14:13 |
| hberaud | elodilles: this one is easy | 14:13 |
| elodilles | and I'll let you know gmann when we are there :) | 14:13 |
| hberaud | do not hesitate to ping me if needed | 14:13 |
| gmann | elodilles: ack. | 14:13 |
| elodilles | hberaud: +1 | 14:13 |
| hberaud | excelllent | 14:13 |
| hberaud | and that's all | 14:14 |
| hberaud | #topic Review countdown email contents | 14:14 |
| hberaud | #link https://etherpad.opendev.org/p/relmgmt-weekly-emails#L10 | 14:14 |
| hberaud | let me know if it LGTY | 14:14 |
| ttx | lgtm | 14:16 |
| ttx | only fixed a Xena capitalization | 14:16 |
| hberaud | we all use the same color :) | 14:17 |
| hberaud | thanks | 14:17 |
| ttx | boom | 14:17 |
| hberaud | ahah | 14:17 |
| * yoctozepto has to go, will read later the discussion on patching the relationship with governance repo | 14:18 | |
| hberaud | yoctozepto: o/ | 14:18 |
| fungi | yoctozepto: i've followed up about it on the ml anyway, we can summarize further there | 14:18 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for nova https://review.opendev.org/c/openstack/releases/+/808706 | 14:19 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for senlin-dashboard https://review.opendev.org/c/openstack/releases/+/808727 | 14:19 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for solum-dashboard https://review.opendev.org/c/openstack/releases/+/808729 | 14:20 |
| elodilles | (email lgtm, too) | 14:20 |
| hberaud | thanks | 14:20 |
| hberaud | #topic PTG time slot | 14:20 |
| hberaud | We need to schedule our TZ for the PTG, so which will fit well for you? | 14:20 |
| hberaud | As it will be a 1 hour PTG for us, I was thinking reusing our meeting time, is it ok for you all? | 14:21 |
| elodilles | it could work :) | 14:21 |
| ttx | hmmm sure | 14:22 |
| ttx | Ideally we should avoid conficting with TC sessions | 14:22 |
| ttx | since that gets horizontal attention | 14:22 |
| elodilles | oh and that's also usually friday | 14:22 |
| ttx | how about we wait to see where they place themselves | 14:22 |
| elodilles | usually relmgmt was on Tuesdays, wasn't it? | 14:23 |
| ttx | i would not say that was a tradition | 14:23 |
| hberaud | ttx: Ashlee and diablo_rojo_phone wait for our reply today (and of the week) | 14:23 |
| hberaud | elodilles: yes it was | 14:23 |
| ttx | maybe we can answer that we are flexible and want to avoid TC slots | 14:24 |
| elodilles | actually I didn't give any project that we shouldn't collide in the survey :X | 14:24 |
| hberaud | Concerning myself I don't have a great preference | 14:24 |
| elodilles | if i remember well | 14:24 |
| hberaud | elodilles: do you want to handle that point? | 14:24 |
| hberaud | and reply about our flexibility as suggest by ttx | 14:25 |
| clarkb | fungi: thank you for that followup email I was very confused as to why siblings wasn't doign that already | 14:25 |
| clarkb | ok /me needs to do morning errands now | 14:25 |
| elodilles | ok, sure, then i will propose preferably Tuesday but avoid TC | 14:26 |
| hberaud | sold | 14:26 |
| hberaud | thanks | 14:26 |
| hberaud | #topic PTG etherpad | 14:26 |
| hberaud | #link https://etherpad.opendev.org/p/relmgmt-yoga-ptg | 14:27 |
| elodilles | i've just added a draft | 14:27 |
| elodilles | no content yet | 14:27 |
| elodilles | but feel free to add any topic | 14:27 |
| hberaud | thanks I'll | 14:27 |
| elodilles | maybe the "things to change" from the end of the tracking etherpad? | 14:27 |
| hberaud | yes it's a starting point | 14:28 |
| hberaud | Usually we did that | 14:28 |
| opendevreview | Merged openstack/releases master: Release glance-tempest-plugin for Xena https://review.opendev.org/c/openstack/releases/+/808782 | 14:28 |
| hberaud | #topic double check unreleased client-libraries | 14:29 |
| hberaud | #link https://review.opendev.org/q/topic:%22xena-mileston-3%22 | 14:29 |
| hberaud | So I missed to propose these patch during R-5 | 14:29 |
| hberaud | These projects are quiet | 14:30 |
| fungi | is that change topic intentionally misspelled? | 14:30 |
| hberaud | nope | 14:30 |
| hberaud | It's a nit | 14:30 |
| hberaud | good catch | 14:30 |
| fungi | no worries, i was trying to work out if the url was wrong or the topic was just set with a typo | 14:31 |
| hberaud | I'll update it all over the patches | 14:31 |
| hberaud | typo only :) | 14:31 |
| fungi | pro tip: gertty can batch set change topics | 14:31 |
| hberaud | Oh!?!? How to do that? | 14:31 |
| fungi | query it for a list of changes with the old topic, then process mark the changes listed (% key by default) and then set the topic while you're on the change list | 14:32 |
| hberaud | ah sorry I misread gertty | 14:32 |
| hberaud | I see, thanks for the tips | 14:33 |
| hberaud | so these deliverables don't have a lot of changes to publish but it could worth to reserve a range of version for them for stable xena | 14:34 |
| hberaud | this is the reason behind this batch | 14:34 |
| hberaud | I don't think that we will receive validations from PTL/liaison for these deliverables and the opened patches, so I'll force them after the meeting, is it ok for you? | 14:35 |
| elodilles | these are what you discussed with ttx, that despite they don't have release content we should release to avoid confusions? | 14:35 |
| hberaud | yes | 14:35 |
| elodilles | ok | 14:36 |
| elodilles | I can help with the review here as well | 14:36 |
| hberaud | if they need to fix something at some point during Xena it will be possible | 14:36 |
| hberaud | elodilles: thanks | 14:36 |
| elodilles | np | 14:36 |
| hberaud | much appreciated | 14:36 |
| hberaud | #topic pydot2 and the governance repo | 14:37 |
| hberaud | So now we are here :) | 14:37 |
| fungi | updated the topic on those 11 changes to xena-milestone-3 (with an e) now | 14:38 |
| hberaud | As I said in my email I would avoid to rely on pypi for our own deliverables in the requirements of openstack/release to avoid future catch-22 situations | 14:38 |
| hberaud | fungi: thanks | 14:38 |
| hberaud | for now we fixed the problem but fungi proposed a solution which seems to be better | 14:39 |
| gmann | +1, I think we should stop releasing governance itself | 14:39 |
| gmann | I will check election scripts/deps which i know use it | 14:39 |
| gmann | ttx: fungi do you know if any one else, foundation site etc need governance in PyPI ? | 14:40 |
| hberaud | +1 | 14:40 |
| fungi | the only reason we tagged the governance repo originally was to mark the point in time where the state of the projects list was used in determining contributors for the electorate, yes | 14:40 |
| gmann | fungi: ok, and we can use hash for that also | 14:41 |
| fungi | it could be done with an arbitrary commit id instead (and i've even done it that way for special elections) | 14:41 |
| elodilles | for local use/run pypi is more convenient, isn't it? | 14:41 |
| gmann | but anyways do not want to hijack this meeting on this, will discuss in TC meeting or so | 14:41 |
| gmann | fungi: +1 | 14:41 |
| elodilles | my point is if we just run 'tox -e validate' for example, locally, then it will use the old openstack-governance 0.10.0 from pypi and similarly could fail | 14:43 |
| elodilles | or do i miss something? | 14:43 |
| fungi | elodilles: i suppose you could include some helper which grabs the necessary content from governance if it's not available already | 14:44 |
| hberaud | Do we have any volunteer to handle that point and propose the changes? yoctozepto maybe? | 14:44 |
| gmann | hberaud: what we need now? | 14:44 |
| fungi | the way projects handle obtaining constraints files from the requirements repo for local tox invocation is an example | 14:45 |
| hberaud | gmann: at least "declare openstack/governance in" | 14:45 |
| hberaud | the required-projects lists for the jobs which are using it, and | 14:45 |
| hberaud | then the tox role from zuul-jobs will know to consume it from | 14:45 |
| hberaud | locally supplied source instead of fetching it from PyPI | 14:45 |
| hberaud | I suppose it will require update in project-config | 14:45 |
| hberaud | at least | 14:46 |
| gmann | ah, I thought that is done. I can help | 14:46 |
| fungi | yes, i think the key release jobs which use the files from governance are probably defined in project-config | 14:46 |
| hberaud | gmann: much appreciated | 14:46 |
| fungi | best to scope that addition just to the jobs which actually use the governance files though | 14:46 |
| hberaud | I added this topic to our PTG agenda to ensure that we don't forget it too | 14:47 |
| fungi | so that we're not unnecessarily installing openstack/governance in every single release-related job whether it's needed or not | 14:47 |
| gmann | yeah | 14:47 |
| fungi | i have a feeling only the reference/projects.yaml file from governance is used, right? | 14:48 |
| hberaud | yes | 14:48 |
| hberaud | at least | 14:48 |
| fungi | so just jobs which iterate over or do lookups in that file should need governance listed as a required project for the job | 14:48 |
| fungi | and then it can be removed from the (test-?)requirements.txt file | 14:49 |
| hberaud | gmann: ^ | 14:49 |
| gmann | ack. thanks | 14:49 |
| hberaud | let us know if you need help | 14:50 |
| hberaud | #topic Open Discussion | 14:51 |
| hberaud | Anything else to discuss today? | 14:51 |
| fungi | looks like we import from governance in doc/source/_exts/deliverables.py so it might still need to be included in doc/requirements.txt | 14:51 |
| hberaud | ack | 14:53 |
| fungi | also anything which uses find_gerrit_acl_issues.py, get_contacts.py, list_changes.py, validate.py, deliverable.py, aclissues.py... | 14:54 |
| hberaud | Yeah I was thinking about acl | 14:54 |
| fungi | so it's not consuming/parsing the projects.yaml directly, it's using the public api provided by the openstack_governance python module | 14:54 |
| hberaud | yep | 14:54 |
| fungi | continuing to release openstack_governance would therefore make sense, so if the concern is just with tagging releases of the governance repo itself i suppose that module could be split into its own separate governance-tools repo or something | 14:55 |
| * yoctozepto is back | 14:56 | |
| yoctozepto | so, what's the consensus on governance-in-releases fix? | 14:56 |
| fungi | gmann: in summary, openstack/governance currently contains a public api in the form of a python package, which is consumed by other projects. treating it as a proper library would make sense because that's how it's already consumed | 14:56 |
| hberaud | for now follow fungi's proposition on the ML thread | 14:57 |
| yoctozepto | I must say I'm unsure we can easily patch the tox jobs as they rely on global definitions | 14:57 |
| yoctozepto | so we would switch it for all the projects | 14:57 |
| yoctozepto | and also ignore local git checkouts | 14:57 |
| gmann | fungi: humm, if those are used in release or election then we can ask to use directly from source otherwise lib make sense | 14:57 |
| yoctozepto | as far as I understand both, governance and releases repos only really make sense when considered from the very tip | 14:58 |
| fungi | yoctozepto: which tox jobs specifically are you concerned about? you can add required-projects similar to how we do for, e.g., tox jobs run by horizon plugins which need horizon installed from source | 14:58 |
| yoctozepto | fungi: all jobs were tox and all were failing, so e.g. pep8, py36, py38, cover, whatever | 14:58 |
| yoctozepto | we would need to inherit all | 14:59 |
| yoctozepto | and control which python vers to test | 14:59 |
| gmann | in project-config, I only find this job using the releases/tools/check_approval.py (which is governance/project.yaml) and it has governance in required_projects - / https://opendev.org/openstack/project-config/src/branch/master/zuul.d/jobs.yaml#L1078 | 14:59 |
| yoctozepto | which might not be *that* bad considering the repo's purpose | 14:59 |
| yoctozepto | mayhaps it's just an overkill that it's included in requirements.txt and should be moved to tox's definition - for endusers rely on git path and zuul could substitute its own one? wdyt? | 15:00 |
| hberaud | gmann: this one was the only one who works previously, I think because "required-project" is used | 15:01 |
| fungi | gmann: the problem comes from things which call modules in the openstack_releases package or scripts in openstack/releases tools directory, since they import from the openstack_governance package which must be installed | 15:01 |
| yoctozepto | I see many files use openstack_governance | 15:01 |
| gmann | yeah | 15:01 |
| *** ykarel is now known as ykarel|away | 15:02 | |
| fungi | so openstack_releases has numerous places where openstack_governance is treated as a python library and needs it installed via pip from somewhere | 15:02 |
| yoctozepto | mhm, precisely | 15:02 |
| hberaud | agreed, the problem was that we use governance as an API ans so we need to install and pull its dependencies and this is where we faced the pydot2 problem | 15:02 |
| yoctozepto | and we want that to be direct from git | 15:02 |
| yoctozepto | the current solution is only incapable to do depends-on | 15:03 |
| yoctozepto | and slightly less efficient | 15:03 |
| yoctozepto | than with required-projects | 15:03 |
| fungi | yoctozepto: well, also it results in running git clone from opendev every time the project is installed, that's inefficient and fragile, so will lead to a lot of new random job failures | 15:03 |
| yoctozepto | fungi: yeah, that was included in "slightly less efficient" | 15:04 |
| yoctozepto | I do wonder how bad that would be but yeah | 15:04 |
| yoctozepto | for releases we should strive for best stability | 15:04 |
| yoctozepto | so perhaps really control all the jobs locally? | 15:04 |
| yoctozepto | releases-tox etc. | 15:04 |
| hberaud | fungi: however I'm not sure to see how splitting the python module part of the governance repo will protect us from similar situation? | 15:04 |
| yoctozepto | releases don't have to gate on the same python versions tbh | 15:04 |
| fungi | unfortunately, even a modest increase in random failures for release jobs means me or another opendev admin getting involved to reenqueue failures because many of these jobs aren't idempotent | 15:05 |
| yoctozepto | fungi: yeah, I feel you totally | 15:05 |
| gmann | hberaud: yeah not sure that will solve these kind of issues | 15:05 |
| yoctozepto | ok, so how about this | 15:05 |
| fungi | hberaud: splitting the python module part of the governance repo to a separate repo means that the tc can stop worring about releasing the governance repo and can only have to release the governance-tools repo | 15:05 |
| fungi | separating the software from the data | 15:06 |
| yoctozepto | 1) releases control their jobs by themselves | 15:06 |
| yoctozepto | 2) they add required-projects to the base tox job | 15:06 |
| gmann | fungi: yeah but those tools still face same issue as currently we are facing, its tool broke us not data | 15:06 |
| yoctozepto | 3) governance also adds gating on a relevant test job | 15:06 |
| hberaud | yes | 15:06 |
| hberaud | the problem come from the env | 15:07 |
| yoctozepto | then we have more control AND more reliability | 15:07 |
| fungi | hberaud: gmann: i suggested splitting the library out of the governance repo as an alternative so that people can still continue to consume it from pypi for running locally | 15:07 |
| gmann | yoctozepto: on 2nd, base tox job you mean install gov for everyone ? | 15:07 |
| yoctozepto | gmann: no, I mean custom base tox job for releases | 15:07 |
| gmann | +1 | 15:07 |
| fungi | how do horizon plugins do things like pep8 since they need horizon installed from source? | 15:08 |
| gmann | yoctozepto: and thing is if governance ship any tool, it should test in their gate which is missing key here | 15:08 |
| hberaud | yoctozepto: seems a good idea | 15:08 |
| gmann | and if no one use those tool like universal* then just delete | 15:08 |
| yoctozepto | gmann: we test it; we had our gate broken | 15:08 |
| yoctozepto | fungi: good question | 15:08 |
| yoctozepto | fungi: I bet they just use release lol | 15:08 |
| yoctozepto | but let me check something sensible | 15:09 |
| yoctozepto | yeah, they seem to be installing latest release | 15:11 |
| yoctozepto | which is clumsy | 15:11 |
| yoctozepto | (to avoid saying it's utterly wrong in general) | 15:11 |
| yoctozepto | but it seems we just lost track of the needs of tox jobs | 15:11 |
| yoctozepto | I am unsure if we want to try to develop a generic approach | 15:12 |
| fungi | clarkb: ^ do you know of a general approach to adding required-projects for every single job run for a particular project? | 15:12 |
| yoctozepto | anyhow, releases have an outdated set of template jobs: "openstack-python3-victoria-jobs" | 15:13 |
| fungi | the idea is that any time openstack_releases is installed, openstack_governance needs to be installed but from source not from a release on pypi | 15:13 |
| yoctozepto | thus it makes sense to change the process | 15:13 |
| fungi | it looks like we would probably have to use child jobs of all the generic ones and then add required-projects to each one that way | 15:14 |
| yoctozepto | meh, and the jobs are overridden in the pipeline already lol | 15:14 |
| yoctozepto | so it can just be added to these overrides | 15:14 |
| yoctozepto | there is a lot of duplication, ok | 15:14 |
| fungi | it's possible we can set required-projects on variants instead of using job inheritance | 15:15 |
| fungi | yeah | 15:15 |
| gmann | how many jobs we have ? may be let's go with like check-release-approval | 15:16 |
| gmann | simple way | 15:16 |
| fungi | it just means the project-templates are no longer useful | 15:16 |
| hberaud | gmann's proposition could be a first step | 15:17 |
| gmann | and continue releasing governance for its public APIs for local use or so | 15:17 |
| hberaud | nothing prevents us from improving it behind | 15:18 |
| hberaud | WFY? | 15:19 |
| yoctozepto | loving that keystone also stayed on testing victoria https://opendev.org/openstack/keystone/src/branch/master/.zuul.yaml | 15:20 |
| yoctozepto | meh | 15:20 |
| hberaud | I'll have to grab kids at school | 15:20 |
| yoctozepto | hberaud: make sure to take only yours | 15:20 |
| hberaud | will try :) | 15:21 |
| yoctozepto | otherwise they may report a KIDnapping | 15:21 |
| gmann | :) | 15:21 |
| yoctozepto | I'll propose something and let's see how it's going to work | 15:21 |
| hberaud | +1 | 15:22 |
| hberaud | We could continue the discussion on the thread | 15:22 |
| hberaud | I'll close the meeting | 15:22 |
| yoctozepto | or just in this channel ;-) | 15:22 |
| hberaud | As you want :) | 15:22 |
| hberaud | Thank you everyone for joining. I added a record of this discussion to our PTG etherpad | 15:23 |
| hberaud | #closemeeting | 15:24 |
| hberaud | #endmeeting | 15:24 |
| opendevmeet | Meeting ended Fri Sep 17 15:24:19 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:24 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/releaseteam/2021/releaseteam.2021-09-17-14.00.html | 15:24 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2021/releaseteam.2021-09-17-14.00.txt | 15:24 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2021/releaseteam.2021-09-17-14.00.log.html | 15:24 |
| hberaud | work better :) | 15:24 |
| elodilles | thanks o/ | 15:24 |
| gmann | yoctozepto: for keystone, this did not merge https://review.opendev.org/c/openstack/keystone/+/754297 | 15:27 |
| fungi | gmann: yes, another sign that keystone has been hurting | 15:30 |
| gmann | yeah | 15:30 |
| opendevreview | Radosław Piliszek proposed openstack/releases master: [WIP] Optimise jobs to use required-projects https://review.opendev.org/c/openstack/releases/+/809771 | 15:31 |
| yoctozepto | gmann: yeah, wallaby and now xena | 15:31 |
| yoctozepto | meh, it's too sad for a project of this maturity | 15:32 |
| yoctozepto | anyhow, I proposed a WIP change to check if it even works like we imagine it to | 15:32 |
| gmann | let's wait for keystone wallaby to cut and then we can fix it in stable/wallaby | 15:32 |
| yoctozepto | will need 2 more jobs fixed elsewhere | 15:32 |
| ttx | won;t be able to review today, but i can pick up the leftover pieces on Monday morning | 15:33 |
| gmann | yoctozepto: I think we should keep openstack-python3-victoria(new one)-jobs template in case we make py39 as voting or new jobs | 15:34 |
| yoctozepto | gmann: what do you mean? | 15:34 |
| gmann | yoctozepto: you removed the template here https://review.opendev.org/c/openstack/releases/+/809771/1/.zuul.yaml#13 | 15:35 |
| elodilles | ttx: ack | 15:35 |
| yoctozepto | gmann: I had to, cannot use it | 15:36 |
| yoctozepto | need to set required-projects | 15:37 |
| yoctozepto | releases can control their jobs independently anyway | 15:37 |
| yoctozepto | they don't gate with the ecosystem | 15:37 |
| gmann | yoctozepto: humm, voting var works by keeping template and then extend it in job but not sure about required_projects | 15:37 |
| yoctozepto | gmann: hmm, interesting, then perhaps this should work | 15:38 |
| yoctozepto | I just understood fungi confirming my worries that it will not work like this | 15:38 |
| yoctozepto | if it does, then we can really reduce the amount of duplication there | 15:38 |
| clarkb | fungi: no I am not aware of that other than using a parent job for all jobs in a project | 15:39 |
| opendevreview | Hervé Beraud proposed openstack/releases master: Proposing Xena RC1 for heat-dashboard https://review.opendev.org/c/openstack/releases/+/808627 | 15:39 |
| fungi | gmann: yoctozepto: technically you can keep the templates yes, but if you define variants of every job from the template then the template becomes completely redundant | 15:40 |
| gmann | fungi: just to keep all jobs in sych with what we define template at least when we update template at later stage, like most probably in Yoga we might include py39 as voting | 15:40 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for keystone https://review.opendev.org/c/openstack/releases/+/808632 | 15:41 |
| opendevreview | Radosław Piliszek proposed openstack/releases master: [DNM] Templates override concept https://review.opendev.org/c/openstack/releases/+/809772 | 15:41 |
| yoctozepto | gmann, fungi: ^ I understood gmann to mean this | 15:41 |
| yoctozepto | otherwise I removed templates as they were useless after having all jobs copied to override | 15:41 |
| yoctozepto | indeed | 15:41 |
| *** ysandeep is now known as ysandeep|mtg | 15:42 | |
| yoctozepto | yeah, Zuul already complained | 15:42 |
| gmann | yoctozepto: i mean keeping openstack-python3-wallaby-jobs as it is and then add r-p in jobs too where they are already extended for irrelevant files | 15:42 |
| yoctozepto | gmann: imho, confusing and not useful at all | 15:42 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for designate-dashboard https://review.opendev.org/c/openstack/releases/+/808614 | 15:43 |
| gmann | yoctozepto: when we extend tempalate at least then it is useful, I just got it when i saw no py39 job | 15:43 |
| gmann | if you have openstack-python3-xena|yoga-jobs template then you will be forced to do for py39 also and do nto miss to test it | 15:43 |
| gmann | otherwise we need to manually keep it up to date every cycle as per what we defined in template | 15:44 |
| yoctozepto | gmann: I say it's better to let releases team manage their jobs anyway as they need customisation and the template does not help with that; let's focus on keeping the gate as green as it can be; releases themselves are series-independent ;-) | 15:44 |
| yoctozepto | there is also no automation to update the template, mind you | 15:45 |
| yoctozepto | so it's manual no matter what | 15:45 |
| yoctozepto | thus I don't see the point | 15:45 |
| gmann | yeah that is why it is victoria still.. | 15:45 |
| yoctozepto | meh, the idea with required-projects does not work in tox | 15:47 |
| yoctozepto | 2021-09-17 15:39:24.003608 | ubuntu-bionic | Uninstalling openstack-governance | 15:47 |
| yoctozepto | fungi, clarkb: ^ | 15:47 |
| clarkb | yoctozepto: it removes it then reinstalls it from source | 15:48 |
| clarkb | yoctozepto: the process is basically install everythign with tox, then scan through that list and see if any of those projects are present locally as git repos. If so uninstall then reinstall | 15:48 |
| clarkb | pip may do the uninstall then reinstall for us. Or we may do it explicitly I don't recall | 15:48 |
| fungi | right, however if the problem is that installing openstack-governance is what's broken, then we're not going to work around that by first installing the broken package and then upgrading it to the fixed source version | 15:49 |
| yoctozepto | exactly ^ | 15:49 |
| clarkb | ah right. | 15:49 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for designate https://review.opendev.org/c/openstack/releases/+/808616 | 15:50 |
| yoctozepto | so there really is no better machinery than what we merged already with my proposal | 15:50 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for manila-ui https://review.opendev.org/c/openstack/releases/+/808637 | 15:50 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for sahara-plugin-spark https://review.opendev.org/c/openstack/releases/+/808720 | 15:50 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for sahara-plugin-ambari https://review.opendev.org/c/openstack/releases/+/808717 | 15:50 |
| clarkb | why does releases consume governance? | 15:50 |
| yoctozepto | for both data and tooling | 15:50 |
| clarkb | I think this is pointing out that you shouldn't have dep cycles | 15:50 |
| fungi | clarkb: to use the modules for parsing and looking up projects.yaml entries | 15:50 |
| clarkb | the data can be used in raw form | 15:50 |
| yoctozepto | yeah, it's a metacycle I'd say :D | 15:50 |
| hberaud | clarkb: for a bunch of verifications (acl, team, etc...) | 15:50 |
| clarkb | and the tools should probably live in releases | 15:50 |
| fungi | except those tools are also used by the governance repo | 15:51 |
| yoctozepto | they need to live in governance as well | 15:51 |
| clarkb | anyway I think the actual bug here is releases should not depend on anything it releases | 15:51 |
| clarkb | fungi: right governance should consume it from releases to break the cycle | 15:51 |
| yoctozepto | yeah, that's a logical bug | 15:51 |
| yoctozepto | logic* bug | 15:51 |
| clarkb | they don't need to live in governance is my point | 15:51 |
| yoctozepto | but remember this is generalised | 15:51 |
| clarkb | they can live in releases and be consumed the other direction and then you avoid this cycle | 15:51 |
| yoctozepto | in e.g. projects wanting to test in tox with other projects | 15:51 |
| yoctozepto | like horizon fungi mentioned | 15:51 |
| clarkb | yoctozepto: I disagree, in the general case you'd kust make a new release and move on the tox stuff isn't an issue there | 15:52 |
| yoctozepto | so there is a shortcoming in tooling as well | 15:52 |
| clarkb | it is only an issue here because releases shold not depend on anything it releases but it does | 15:52 |
| yoctozepto | clarkb: at the moment master horizon plugins test with released horizon - this is wrong | 15:52 |
| fungi | clarkb: to extend your argument, because releases also relies on the data in the governance repo, that data should be moved into the releases repo? | 15:52 |
| clarkb | fungi: no the data can be consumed in raw form | 15:52 |
| yoctozepto | anyhow, I'm out for today | 15:52 |
| yoctozepto | the fire was extinguished | 15:53 |
| fungi | or some other means than installing the governance repo should be used to obtain the data? | 15:53 |
| yoctozepto | we will see how stable these git clones are | 15:53 |
| clarkb | or remove governance from release management | 15:53 |
| gmann | same it was for tempest plugins, tested with released tempest which we solved by removing tempest from requirements and everyone test with tempest master | 15:53 |
| yoctozepto | gmann: clumsy, eh? :D | 15:53 |
| * yoctozepto off | 15:54 | |
| fungi | gmann: except tempest plugins don't control the releasing of tempest | 15:54 |
| clarkb | fungi: gmann right this is a super special case because one dependes on the other and vice versa | 15:54 |
| gmann | yeah | 15:54 |
| fungi | so if there's a problem with the latest released tempest, you don't need working tempest plugin tests to push a new release of tempest to pypi | 15:54 |
| clarkb | I'm saying the correct thing to do here is to break that cycle one way or another | 15:54 |
| gmann | back to original thought. is it too hard if we stop releasing governance ? for local usage of governance tools/API | 15:55 |
| clarkb | stop managing governance with releases. Stop releases from depending on governance. combine the two. etc | 15:55 |
| fungi | yeah, the only clean way to break that dependency cycle is to reengineer the release automation to no longer rely on pip in order to get things from governance | 15:55 |
| clarkb | note that we already removed a number of projects from releases for this very reason | 15:55 |
| clarkb | disk image builder is one that I know of off the top of my head | 15:56 |
| clarkb | basically the infra teams said early on that none of the infra stuff should be managed by releases | 15:56 |
| clarkb | because if the infra stuff breaks due to external factors we need to update it without working relases | 15:56 |
| gmann | yeah, and if needed (which i do not think it is ) then we can directly release governance in pypi. otherwise best way is just say 'install governance from source and use its tool' | 15:57 |
| fungi | the other bypass option i was originally going to suggest, before i saw yoctozepto's fix already merged, was for a release manager to manually push a signed tag of governance and then merge the metadata around it afterward | 15:57 |
| fungi | members of the release managers team in gerrit already have the perms necessary to push tags themselves | 15:58 |
| clarkb | fungi: if that works (not sure what merging the metadata afterwards will do) then that seems a reasonable escape hatch too | 15:58 |
| fungi | it's the automation around having zuul push tags which relies on installing the openstack-governance package | 15:59 |
| fungi | the metadata tracked in the releases repo is a no-op if the release already exists, so it just becomes bookkeeping | 15:59 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for mistral https://review.opendev.org/c/openstack/releases/+/808645 | 16:02 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for mistral-dashboard https://review.opendev.org/c/openstack/releases/+/808643 | 16:02 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for octavia https://review.opendev.org/c/openstack/releases/+/808710 | 16:02 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for cinder https://review.opendev.org/c/openstack/releases/+/808608 | 16:02 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for manila https://review.opendev.org/c/openstack/releases/+/808639 | 16:02 |
| opendevreview | Merged openstack/releases master: Release final keystoneauth for Xena https://review.opendev.org/c/openstack/releases/+/808941 | 16:02 |
| opendevreview | Merged openstack/releases master: Release final python-keystoneclient for Xena https://review.opendev.org/c/openstack/releases/+/808948 | 16:02 |
| opendevreview | Merged openstack/releases master: Release final python-saharaclient for Xena https://review.opendev.org/c/openstack/releases/+/808951 | 16:02 |
| opendevreview | Merged openstack/releases master: Release final python-adjutantclient for Xena https://review.opendev.org/c/openstack/releases/+/808942 | 16:02 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for neutron-vpnaas https://review.opendev.org/c/openstack/releases/+/808691 | 16:02 |
| elodilles | we had a release job auth timeout (the other jobs have passed): https://zuul.opendev.org/t/openstack/build/bb318be014814502aab739507ec2529d | 16:07 |
| elodilles | fungi: this seems some connection issue ^^^ is it worth reenqueueing? | 16:09 |
| hberaud | this is on "propose-update-constraints" and this is a RC deliverables, so I don't think we need to reenqeue it | 16:10 |
| *** marios is now known as marios|out | 16:11 | |
| hberaud | Ah wait this is a CWI deliverable | 16:12 |
| hberaud | ah nope a cycle-with-rc deliverable | 16:12 |
| * hberaud need more powerful glasses | 16:13 | |
| opendevreview | Merged openstack/releases master: Release final python-solumclient for Xena https://review.opendev.org/c/openstack/releases/+/808952 | 16:15 |
| hberaud | I would argue that it would have been skipped as with the other c-w-rc deliverables who didn't generated those reqs patches (https://zuul.opendev.org/t/openstack/builds?job_name=propose-update-constraints&project=openstack/senlin-dashboard) | 16:15 |
| opendevreview | Merged openstack/releases master: Release final python-barbicanclient for Xena https://review.opendev.org/c/openstack/releases/+/808946 | 16:15 |
| opendevreview | Merged openstack/releases master: Release final python-freezerclient for Xena https://review.opendev.org/c/openstack/releases/+/808947 | 16:15 |
| opendevreview | Merged openstack/releases master: Release final python-zaqarclient for Xena https://review.opendev.org/c/openstack/releases/+/808954 | 16:15 |
| elodilles | hberaud: oh, if that is the case then we just need to ignore it. cool :) | 16:16 |
| hberaud | yes | 16:17 |
| elodilles | fungi: forget my last request about the reenqueueing please :) | 16:17 |
| hberaud | Well... I think | 16:18 |
| hberaud | I didn't see req updates from the other RC deliverables already merged | 16:18 |
| opendevreview | Merged openstack/releases master: Release final python-aodhclient for Xena https://review.opendev.org/c/openstack/releases/+/808944 | 16:23 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for sahara https://review.opendev.org/c/openstack/releases/+/808725 | 16:23 |
| opendevreview | Merged openstack/releases master: Release final python-muranoclient for Xena https://review.opendev.org/c/openstack/releases/+/808950 | 16:23 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for sahara-dashboard https://review.opendev.org/c/openstack/releases/+/808714 | 16:23 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for sahara-plugin-storm https://review.opendev.org/c/openstack/releases/+/808721 | 16:23 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for sahara-plugin-vanilla https://review.opendev.org/c/openstack/releases/+/808722 | 16:23 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for sahara-plugin-cdh https://review.opendev.org/c/openstack/releases/+/808718 | 16:23 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for sahara-plugin-mapr https://review.opendev.org/c/openstack/releases/+/808719 | 16:24 |
| elodilles | what you say makes sense (and I've doublechecked and senlin-dashboard is not listed in upper-constrains.txt ;)) | 16:24 |
| hberaud | anyway this job failure isn't an earthquake | 16:25 |
| hberaud | :) | 16:25 |
| elodilles | hberaud: nope, not at all, it seems :] | 16:25 |
| elodilles | hberaud: the last remaining xena-rc1 patch, I let you approve it: https://review.opendev.org/c/openstack/releases/+/808627 | 16:25 |
| elodilles | :) | 16:26 |
| elodilles | (so it will have the two +2 o:)) | 16:26 |
| hberaud | elodilles: thank you | 16:26 |
| elodilles | just for the record: I've added the Release Mgmt PTG session to Tuesday (Oct 19), 14:00-15:00 UTC, as there is no TC session at that time (if I saw that correctly) | 16:40 |
| hberaud | excellent thank you | 16:43 |
| opendevreview | Merged openstack/releases master: Proposing Xena RC1 for heat-dashboard https://review.opendev.org/c/openstack/releases/+/808627 | 16:49 |
| *** ysandeep|mtg is now known as ysandeep | 16:54 | |
| *** ysandeep is now known as ysandeep|dinner | 16:54 | |
| *** amoralej is now known as amoralej|off | 16:56 | |
| *** ysandeep|dinner is now known as ysandeep | 17:08 | |
| opendevreview | Goutham Pacha Ravi proposed openstack/releases master: Create Xena branch for devstack-plugin-ceph https://review.opendev.org/c/openstack/releases/+/809888 | 17:51 |
| gouthamr | gmann kopecmartin: o/ unsure if you planned to do this or you have a set date when this branching should occur ^ please feel free to -1 and let me know | 17:52 |
| *** ysandeep is now known as ysandeep|away | 18:03 | |
| gmann | gouthamr: we need to wait for devstack to branched first. I have added -1 for that. | 18:20 |
| gouthamr | gmann: ah! makes sense; thanks.. no rush on this; we were looking to break the plugin a bit with some ceph setup changes - but we're still toying with those manually | 18:21 |
| gmann | gouthamr: yeah, I will update you once devstack is ready | 18:24 |
| gouthamr | thanks gmann! | 18:24 |
| opendevreview | Rajat Dhasmana proposed openstack/releases master: Cinder team releases for stable/victoria https://review.opendev.org/c/openstack/releases/+/809892 | 18:31 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!