Hi all, We are in-midst of transition from OSF to OIF and hence decided,  not  to add more add-ons for Victoria.  Note the value and  efforts involved  in Refstack & Tempest process was in question and answer is we need to identify pointers in Marketplace to confirm the claims for current Marketpalce efforts.   Here is the summary of Interop WG call today.  1. Interop Guidelines for 2020.10.json  - 2020.10.json  (https://opendev.org/osf/interop) - Arkady to try submit to osf/interop - escale to osf staff if needed ( refer https://review.opendev.org/#/c/762705/1/2020.11.json )- Need pointers to results in Markets 2. Interop add-on Guidelines  for existing - https://opendev.org/osf/interop/src/branch/master/add-ons2.a  DNS (Designate)  - dns.2020.10.json - Need pointers to results 2.b  Orchestration(Heat) -orchestration.2020.10.json - Need pointers results 3. Interop add-on guidelines for new proposals - https://www.openstack.org/marketplace/3.a  FileSystem (Manila) - No plans for Victoria3.b Metal as a Service (Ironic) - No plans for Victoria 4. What's next for Interop 2021 with containers & Kubernetes/magnum ? - Need Volunteers with go skills for new conformance test proposals - Need Board level guidelines from Foundation  Call for volunteers again to ensure we transit from OSF to OIF and please do reply your ideas by email for 1. un-linking orchestration from Heat to Mangnum or Kubernetes as baseline for containers2. Adding new program for BareMetal as a Service with Ironic , bifrost , metal3 etc.3. Putting Integrated OpenStack Integrated logo program on autopilot or terminate  the same at Victoria. ThanksPrakashFor Interop WG OSF/OIF On Friday, November 13, 2020, 11:04:48 AM PST, openstack-discuss-request@lists.openstack.org <openstack-discuss-request@lists.openstack.org> wrote: Send openstack-discuss mailing list submissions to     openstack-discuss@lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to     openstack-discuss-request@lists.openstack.org You can reach the person managing the list at     openstack-discuss-owner@lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics:   1. Re: [release][infra] Discrepancy between release jobs and the       "normal" jobs CI in terms of distro (Jeremy Stanley)   2. [OpenStack][InteropWG] Weekly Interop meeting Agenda for       Victoria Interop Guidelines  in next hr (prakash RAMCHANDRAN)   3. Re: [release][infra] Discrepancy between release jobs and the       "normal" jobs CI in terms of distro (Jeremy Stanley)   4. Re:       [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova       enforces that no DB credentials are allowed for the nova-compute       service (Oliver Walsh) ---------------------------------------------------------------------- Message: 1 Date: Fri, 13 Nov 2020 17:20:44 +0000 From: Jeremy Stanley <fungi@yuggoth.org> To: openstack-discuss@lists.openstack.org Subject: Re: [release][infra] Discrepancy between release jobs and the     "normal" jobs CI in terms of distro Message-ID: <20201113172044.c6cgt7rdy6m6mkeu@yuggoth.org> Content-Type: text/plain; charset="utf-8" On 2020-11-13 13:58:18 +0100 (+0100), Radosław Piliszek wrote: [...]

I believe it would be a rare situation but surely testing something on Bionic and trying to release on Focal might have its quirks.

Honestly, I think the real problem here is that we have a bunch of unnecessary cruft in the release-openstack-python job held over from when we used to use tox to create release artifacts. If you look through the log of a successful build you'll see that we're not actually running tox or installing the projects being released, but we're using the ensure-tox and bindep roles anyway. We may not even need ensure-pip in there. The important bits of the job are that it checks out the correct state of the repository and then runs `python3 setup.py sdist bdist_wheel` and then pulls the resulting files back to the executor to be published. That should be fairly consistent no matter what project is being built and no matter what distro it's being built on. -- Jeremy Stanley