-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug 1759146: data/rhcos: fix base url to use correct baseURI #2462
Bug 1759146: data/rhcos: fix base url to use correct baseURI #2462
Conversation
The current baseURI is pointing at releases-rhcos-art.cloud.privileged.psi.redhat.com, which is an internal URL and signed by the corporate CA. This is breaking most 4.2 installs.
@stbenjam: This pull request references Bugzilla bug 1759146, which is invalid:
Comment In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/bugzilla refresh |
@stbenjam: This pull request references Bugzilla bug 1759146, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/lgtm needs an approver |
/approve |
Don't allow people to point to e.g. an RHT-internal endpoint. See: openshift#2462
#2463 |
How is that? |
@stbenjam: This pull request references Bugzilla bug 1759146, which is valid. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I updated it to be be more specific: This is breaking any 4.2 install that relies on downloading RHCOS (e.g. UPI, baremetal IPI), and the user is not on the VPN or is on the VPN and the particular server doesn't trust RH's corporate CA. Any cloud providers we upload the images to in advance wouldn't be affected, so it's not really most installs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ashcrow, patrickdillon, sdodson, stbenjam The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test e2e-azure |
@sdodson Tide is reporting that it also "Needs cherry-pick-approved label." |
/test e2e-metal |
/test e2e-vsphere-upi |
Not even that right, once https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/pre-release/latest/ is updated? |
/test e2e-openstack OpenStack uses the base URI too. |
But e2e-openstack is only in our master presubmits as well. Sigh... |
Not sure I understand, what is not right? We've always used releases-art-rhcos.svc.ci.openshift.org as baseURI in rhcos.json, even the release-4.1 branch is pointing there. In any case, releases-rhcos-art.cloud.privileged.psi.redhat.com is certainly incorrect. For releases, something else must change rhcos.json to point to the production location on openshift.com? |
That doesn't exist today; see #1399 etc.
The PR is fine. What I am trying to say is that not all UPI installs depend on the metadata here. Clearly OpenStack is scripting against it today, but e.g. one can download the Or to phrase it differently: This fixes OpenStack IPI (and possibly metalkube). |
@stbenjam: This pull request references Bugzilla bug 1759146, which is valid. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
We can trigger metal3 CI, at least. That's broken and should be fixed by this PR. |
/label platform/baremetal (Temporarily labeling this to trigger metal3 CI so we can see this fixes one of the broken platforms) |
@stbenjam: The label(s) In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Well, that didn't work. I know @sdodson kicked off a cluster-bot install with vmware, we might have to rely on that. |
Ok got it, thanks. Based on what I saw from Slack, this affected at least baremetal UPI, baremetal IPI (metalkube), openstack IPI, and vmware UPI. |
@stbenjam: This pull request references Bugzilla bug 1759146, which is valid. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/test e2e-vsphere |
Metal3 CI is kicked off, but it's going to fail shortly. It always tries to apply a PR to |
Build FAILURE, see build http://10.8.144.11:8080/job/dev-tools/1199/ |
@stbenjam: All pull requests linked via external trackers have merged. Bugzilla bug 1759146 has been moved to the MODIFIED state. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Don't allow people to point to e.g. an RHT-internal endpoint. See: openshift#2462
The current baseURI is pointing at
releases-rhcos-art.cloud.privileged.psi.redhat.com, which is an internal
URL and signed by the corporate CA. This is breaking any 4.2 install that relies on downloading RHCOS (e.g. some UPI installs, baremetal IPI, etc), and the user is not on the VPN or is on the VPN and the particular server doesn't trust RH's corporate CA.