Bug 1690189

Summary: Multiple images are being built by OCP that are not part of CI
Product: OpenShift Container Platform Reporter: Clayton Coleman <ccoleman>
Component: ReleaseAssignee: Tim Bielawa <tbielawa>
Status: CLOSED ERRATA QA Contact: Wei Sun <wsun>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 4.1.0CC: aos-bugs, jokerman, mdulko, mmccomas, shurley, smunilla, sponnaga, vlaad, xtian
Target Milestone: ---   
Target Release: 4.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-04 10:46:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Clayton Coleman 2019-03-19 00:49:33 UTC
The following images are being built in OSBS and published to ocp/4.0-art-latest but have no Origin equivalent.  They need to have origin CI or to have their OSBS jobs set to disabled (everything in ose-* must have an equivalent origin Github and CI flow blocking promotion).

Each of these should probably be split into the component teams, but I need help assigning.

ansible-operator
ansible-service-broker
ansible-service-broker-operator
autoheal
cephfs-provisioner
cluster-nfd-operator
csi-provisioner
efs-provisioner
kuryr-cni, 
kuryr-controller, 
leader-elector, 
manila-provisioner, 
ovn-kubernetes
snapshot-controller
snapshot-provisioner
sriov-device-plugin
template-service-broker-operator

Teams may not be in the payload or in our OSE space without CI guarding their master branches and publishing to 4.0/ocp.  There are three possible outcomes:

1. stop building these in OCP - they are not part of 4.0
2. stop publishing these to quay.io/openshift-release-dev/4.0-art-dev (via some specific rule) because they are not going to be part of the openshift release payload
3. add origin CI that gates merges to their master branches

All of these need to be resolved.

Comment 1 Clayton Coleman 2019-03-19 01:14:25 UTC
sriov-device-plugin is sriov-network-device-plugin in origin.  We should clone and assign them based on the correct name.

leader-elector has no origin equivalent.

template-service-broker-operator is tsb-operator in origin and looks like it has never built.  Will split that off into https://bugzilla.redhat.com/show_bug.cgi?id=1690194

Storage team needs to explain their differences.

Comment 2 Clayton Coleman 2019-03-19 01:20:14 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1690195 for storage.

Comment 3 Clayton Coleman 2019-03-19 01:27:40 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1690197 is cluster-nfd-operator, they need to be disabled until they add CI gating.

Comment 4 Clayton Coleman 2019-03-19 16:25:01 UTC
sriov* is in https://bugzilla.redhat.com/show_bug.cgi?id=1690472

Comment 5 Michał Dulko 2019-03-19 16:34:11 UTC
For kuryr-cni, kuryr-controller and leader-elector option #2 seems best. We're actively working to have Kuryr support ready for 4.1 or 4.2, and part of that is obviously CI coverage. Please note that leader-elector is just a Kuryr dependency.

Comment 6 Tim Bielawa 2019-03-19 16:40:58 UTC
(In reply to Clayton Coleman from comment #0)
> The following images are being built in OSBS and published to
> ocp/4.0-art-latest but have no Origin equivalent.  They need to have origin
> CI or to have their OSBS jobs set to disabled (everything in ose-* must have
> an equivalent origin Github and CI flow blocking promotion).
> 
> ansible-operator
> ansible-service-broker
> ansible-service-broker-operator
> autoheal
> cephfs-provisioner
> cluster-nfd-operator
> csi-provisioner
> efs-provisioner
> kuryr-cni, 
> kuryr-controller, 
> leader-elector, 
> manila-provisioner, 
> ovn-kubernetes
> snapshot-controller
> snapshot-provisioner
> sriov-device-plugin
> template-service-broker-operator

I am going to use this as a blacklist for images we reject to sync or add to the image stream. I should have that coded up before COB today.

Comment 8 Tim Bielawa 2019-03-21 17:05:03 UTC
I've got the PRs merged that add the blacklists to our build data and the PR merged to read from the blacklist when mirroring/syncing/updating the image stream.

I'm waiting for the new release to show up on PyPi. Running into this recurring issue though

Uploading distributions to https://upload.pypi.org/legacy/
Uploading rh-doozer-0.3.31.tar.gz
100%|███████████████████████████████████████| 87.4k/87.4k [00:00<00:00, 245kB/s]
NOTE: Try --verbose to see response content.
HTTPError: 403 Client Error: Invalid or non-existent authentication information. for url: https://upload.pypi.org/legacy/
PyPI upload failed.
failed to deploy

It'll get there eventually!

Comment 11 Zhang Cheng 2019-04-12 03:18:48 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1690194 for service broker side.

Comment 14 errata-xmlrpc 2019-06-04 10:46:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0758