-
Task
-
Resolution: Done
-
Major
-
None
-
None
-
False
-
None
-
False
-
-
-
-
At this moment, the Operator 3.0 build process is using the following repository names:
- git-dist:
Operator Image: https://pkgs.devel.redhat.com/git/containers/jboss-eap-7-operator/
dev branch: jb-eap-3.0-operator-dev-rhel-8
prod branch: jb-eap-3.0-operator-rhel-8
Operator bundle: https://pkgs.devel.redhat.com/git/containers/eap73-rhel-8-operator-bundle
dev branch: jb-eap-3.0-operator-dev-rhel-8
prod branch: jb-eap-3.0-operator-rhel-8
- Comet repositories:
Operator Image: jboss-eap-7/eap73-rhel8-operator https://comet.engineering.redhat.com/containers/repositories/5dc0529ebed8bd164af4cc8a#
Operator Bundle: jboss-eap-7/eap73-rhel8-operator-bundle https://comet.engineering.redhat.com/containers/repositories/5f61cf06c1f1c6934e75f88a#
Both are linked to the following product:
"JBoss Enterprise Application Platform 7" https://comet.engineering.redhat.com/containers/products/5f904c3679b4f8d046342f74
In between them, there are also brew targets that are configured to publish the images under the following repository name:
Operator Image: registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-eap73-rhel8-operator
Tasks to do for EAP Operator 3.0:
We need to review the internal repositories, image names, brew tasks, and Comet repos. These changes will also affect some labels managed internally by the Operator image and bundle docker files.
- Image name:
Our EAP Operator policy (https://access.redhat.com/articles/5702651), states that the JBoss EAP Operator is progressively released on the same container image as a new version, I don't think this is a hard requirement, but we need to verify if we can update an Operator by using a different image. This is a CSV configuration.
Propossed: registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-eap-rhel-operator
- git-dist/brew tasks:
The git-dist repositories could be the same, those are internal repositories which are not directly exposed to the customer, however, we should get the rid of version names and avoid having this issue again in the future. I understand this is also dependent on the ability to update an Operator from a completely new image repo.
My suggestion for the new git-dist would be:
Operator Image: https://pkgs.devel.redhat.com/git/containers/jboss-eap-operator/
dev branch: jb-eap-3.0-operator-dev-rhel-8
prod branch: jb-eap-3.0-operator-rhel-8
Operator bundle: https://pkgs.devel.redhat.com/git/containers/eap-rhel-operator-bundle
dev branch: jb-eap-3.0-operator-dev-rhel-8
prod branch: jb-eap-3.0-operator-rhel-8
- Comet repos:
We need to configure new comet repositories, the old ones should be deprecated since it looks like the CVP QE fails if there the git-dist is bound to different Comet repos. My suggestion:
jboss-eap/eap-rhel-operator
jboss-eap/eap-rhel-operator-bundle
The new comet repositories need to be linked to:
"JBoss Enterprise Application Platform 7" https://comet.engineering.redhat.com/containers/products/5f904c3679b4f8d046342f74
And we need to create a new product based on EAP 8: "JBoss Enterprise Application Platform 8" operator product.
I am going to create a subtask for each of the above points, once we have an agreement on the names.
- blocks
-
JBEAP-25079 EAP Operator 3.0 release
- Closed