Hide Forgot
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.
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1690195 for storage.
https://bugzilla.redhat.com/show_bug.cgi?id=1690197 is cluster-nfd-operator, they need to be disabled until they add CI gating.
sriov* is in https://bugzilla.redhat.com/show_bug.cgi?id=1690472
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.
(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.
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!
https://bugzilla.redhat.com/show_bug.cgi?id=1690194 for service broker side.
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