Re: [barbican][kolla][neutron][puppet-openstack][requirements] Please clean up Zuul configuration errors

Clark Boylan cboylan at sapwetik.org
Fri Jun 25 16:48:58 UTC 2021


On Fri, Jun 25, 2021, at 9:39 AM, Alex Schultz wrote:
> 
> 
> On Fri, Jun 25, 2021 at 10:19 AM Jeremy Stanley <fungi at yuggoth.org> wrote:
> > For the teams tagged in the subject, please have a look at
> > https://zuul.opendev.org/t/openstack/config-errors and merge fixes
> > to your respective repositories for the errors listed there. A
> > summary view can also be found by clicking the "bell" icon in the
> > top-right corner of https://zuul.opendev.org/t/openstack/status or
> > similar pages).
> > 
> 
> It looks like puppet-openstack-integration stable/ocata and stable/pike 
> needs to be cleaned up/removed. I don't see it as deliverables in the 
> releases repo so these might have been manually created before moving 
> under the release umbrella.  I believe we've EOL'd pike and ocata for 
> the regular modules.  What would be the best course of action to clean 
> up these branches?

For OpenStack release managed projects (I believe this is one) the OpenStack release teams has appropriate permissions in Gerrit as well as script tools to EOL branches properly. I think you can make a request to them and they can run through that for you.

For projects that are not managed by the OpenStack release team we can help you update the Gerrit ACLs so that you have appropriate permissions for this type of cleanup. https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack/meta-config.config#L2-L5 shows the set of permissions needed to abandon all open changes on a branch, tag the branch with an eol tag, then remove the branch. (The create permission isn't strictly necessary here).

> 
> Thanks,
> -Alex
>  
> > Many of these errors are new as of yesterday, due to lingering
> > ansible_python_interpreter variable assignments left over from the
> > Python 3.x default transition. Zuul no longer allows to override the
> > value of this variable, but it can be safely removed since all cases
> > seem to be setting it to the same as our current default.
> > 
> > Roughly half the errors look like they've been there for longer, and
> > seem to relate to project renames or job removals leaving stale
> > references in other projects. In most cases you should simply be
> > able to update the project names in these or remove the associated
> > jobs as they're likely no longer used. Also be aware that many of
> > these errors are on stable branches, so the cleanup will need
> > backporting in such cases.
> > 
> > Thanks for your prompt attention!
> > -- 
> > Jeremy Stanley



More information about the openstack-discuss mailing list