Bug 1686139
Summary: | Moving the API port from 6443 is currently not possible | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Erik M Jacobs <ejacobs> |
Component: | Master | Assignee: | Michal Fojtik <mfojtik> |
Status: | CLOSED WONTFIX | QA Contact: | Xingxing Xia <xxia> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 4.1.0 | CC: | aos-bugs, chernand, crawford, decarr, esauer, jmatthew, jokerman, mmccomas, nmalik, wgordon |
Target Milestone: | --- | ||
Target Release: | 4.2.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-04-11 22:21:11 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
Erik M Jacobs
2019-03-06 19:51:05 UTC
This looks like a duplicate of 1663453. Is there any new information that needs to be considered or can this be closed? This is not a dupe of 1663453 1663453 says "put the API port on 8443". This BZ is "make the API port configurable". Okay, maybe not a dup, but it shares the same conclusion:
> We've decided to stick with 6443 for the API. We'll make a point to educate customers about the port change.
Unless there is a compelling reason to do so, we should not allow the API port to be customized.
Not allowing for the customization of the API port means that there are some potential users who will not be able to access the API for whatever reason. If we don't allow for moving the API port, then we likely need to document and support some type of proxy solution in front of the API. I'm not convinced. These potential users would have to be smart enough to block access to 6443 but not smart enough to provide a proxy. That seems very unlikely and since we don't have any concrete examples, I'm going to close this. We can revisit this if it proves to be problematic in the future. Can we understand why putting the api on a non-standard SSL port is necessary or useful in the first place? In OpenShift 3.x, we used 8443 for the API because it was possible/supported to run the router on the control plane, and we needed to avoid port conflicts on the host. But in OpenShift 4, we require dedicated control plane hosts and taint the those servers so nothing else gets scheduled there. There are no port conlficts to protect against. Why wouldn't we run the api on 443 by default? There is a growing use case for edge clusters, which don't have any worker nodes. In these environments, the port conflict does exist. Adding my perspective from a hosted perspective (OpenShift Dedicated/OpenShift Online). Most of these customer's are much less technical, which is why they're investing in a hosted solution. Typically there are corporate policies put in place at a higher level, that the hosted customers (typically just developers) don't have any chance of being to change or workaround with a proxy. Because this limitation exists in the installer, we have *no way* of supporting these customers. We already have 1 concrete example of a customer being blocked by this, and OSD on v4 is still fairly small. This will absolutely be a hinderance to the expansion and adoption of our hosted offerings. |