You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[1] includes [2] pitching local update services in managed regions.
However, HyperShift currently forces ClusterVersion spec.upstream
empty [3]. This commit is part of making the upstream update service
configurable on HyperShift, so those clusters can hear about and
assess known issues with updates in environments where the default
https://api.openshift.com/api/upgrades_info update service is not
accessible, or in which an alternative update service was desired for
testing or policy reasons. This includes [2], mentioned above, but
would also include any other instance of
disconnected/restricted-network use. The alternative for folks who
want HyperShift updates in places where api.openshift.com is
inaccessible are:
* Don't use an update service and manage that aspect manually. But the
update service declares multiple new releases each week, as well as
delivering information about known risks/issues for local clusters
to evalute their exposure. That's a lot of information to manage
manually, if folks decide not to plug into the existing update
service tooling.
* Run a local update service, and fiddle with DNS and X.509 certs so
that packets aimed at api.openshift.com get routed to your local
service . This one requires less long-term effort than manually
replacing the entire update service system, but it requires your
clusters to trust an X.509 Certificate Authority that is willing to
sign certificates for your local service saying "yup, that one is
definitely api.openshift.com".
One possible data path would be:
1. HostedCluster (management cluster).
2. HostedControlPlane (management cluster).
3. ClusterVersion spec.upstream (hosted API).
4. Cluster-version operator container (managment cluster).
that pathway would only require changes to the HyperShift repo. But
to avoid URI passing through the customer-accessible hosted API, this
commit adds a new --update-service command-line option to support:
1. HostedCluster (management cluster).
2. HostedControlPlane (management cluster).
3. Cluster-version operator Deployment --update-service command line
option (management cluster).
4. Cluster-version operator container (managment cluster).
If, in the future, we grow an option to give the hosted CVO kubeconfig
access to both the management and hosted Kubernetes APIs, we could
drop --update-service and have the hosted CVO reach out and read this
configuration off HostedControlPlane or HostedCluster directly.
I'd initially gone with --upstream, but moved to --update-service and
updateService, etc. based on Petr's reasonable point that "upstream"
is pretty generic, "update service" is not much longer and is much
more specific, and diverging from the ClusterVersion spec.upstream
precedent isn't that terrible [4].
[1]: https://issues.redhat.com/browse/XCMSTRAT-513
[2]: https://issues.redhat.com/browse/OTA-1185
[3]: https://github.com/openshift/hypershift/blob/5e50e633fefd88aab9588d660c4b5daddd950d9a/control-plane-operator/hostedclusterconfigoperator/controllers/resources/resources.go#L1059
[4]: #1035 (review)
Copy file name to clipboardExpand all lines: cmd/start.go
+1Lines changed: 1 addition & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -46,5 +46,6 @@ func init() {
46
46
cmd.PersistentFlags().BoolVar(&opts.PromQLTarget.UseDNS, "use-dns-for-services", opts.PromQLTarget.UseDNS, "Configures the CVO to use DNS for resolution of services in the cluster.")
47
47
cmd.PersistentFlags().StringVar(&opts.PrometheusURLString, "metrics-url", opts.PrometheusURLString, "The URL used to access the remote PromQL query service.")
48
48
cmd.PersistentFlags().BoolVar(&opts.InjectClusterIdIntoPromQL, "hypershift", opts.InjectClusterIdIntoPromQL, "This options indicates whether the CVO is running inside a hosted control plane.")
49
+
cmd.PersistentFlags().StringVar(&opts.UpdateService, "update-service", opts.UpdateService, "The preferred update service. If set, this option overrides any upstream value configured in ClusterVersion spec.")
klog.V(2).Infof("Retrieving available updates again, because the architecture has changed from %q to %q", optrAvailableUpdates.Architecture, desiredArch)
klog.V(2).Infof("Retrieving available updates again, because the upstream has changed from %q to %q", optrAvailableUpdates.Upstream, config.Spec.Upstream)
92
+
klog.V(2).Infof("Retrieving available updates again, because the update service has changed from %q to %q from %s", optrAvailableUpdates.UpdateService, updateService, updateServiceSource)
0 commit comments