In 4.12, the default CNI will be OVNKubernetes.
This change will deploy ovnk by default as well
as adjust tests, docs and comments to reflect
the same.
Signed-off-by: Jamo Luhrsen <jluhrsen@gmail.com>
The cluster-version operator has been falling back to a default URI
when the ClusterVersion upstream is empty since way back [1,2], and
this behavior is enshrined in the API [3]. Drop the installer-side
opinion, so:
* There is a single location where we version-control the default
upstream (the CVO).
* Folks consuming in-cluster ClusterVersion objects have one less
property to distract them (unless they want to override the default,
in which case it's not distracting).
[1]: 2c4931dc28/pkg/cvo/availableupdates.go (L27-L31)
[2]: ab4d84a021 (diff-78f2af341fa49292dd6930f378018867R24)
[3]: 0422dc1708/config/v1/types_cluster_version.go (L56-L57)
As of OpenShift 4.4.0, the "router-ca" configmap is deprecated, and the
"default-ingress-cert" configmap should be used instead.
* cmd/openshift-install/create.go (addRouterCAToClusterCA): Replace use of
"router-ca" with use of "default-ingress-cert". Return not-found errors to
caller.
* docs/user/troubleshooting.md: Update references to "router-ca".
Make the example slightly simpler on version number to better
reflect what a human might see. Noticed this while updating the
channel to stable-4.3 - apparently we'd also found and replaced
this value before.
4.2 has branched off, so we can bump master to track stable-4.3. This
bump is like the previous 8eeb26840c
(data/data/manifests/bootkube/cvo-overrides: Move to stable-4.2,
2019-05-29, #1801).
Generated with:
$ sed -i 's/stable-4.2/stable-4.3/' $(git grep -l stable-4.2)
* Add the Network.config.openshift.io CRD
* Generate the network config from the install config
* Remove networkoperator types from install config (but use the same
schema)
* Move network CRDs to templates to match #943
This doesn't change the json/yaml serialization of the install config, but it
changes it internally.
Now that the public IPs have been removed from the masters, an
additional step may need to be followed when troubleshooting in order to
get SSH access.
This allows the user to stream logs from the bootstrap node without the
need for SSH. This read-only view into the bootstrap process is
convenient for those who wish not to use SSH in their cluster. Right
now, this requires the user to manually invoke curl to fetch the logs,
but this could be done automatically by the installer in the future.
Previously, these platform-agnostic docs left users guessing about which username to use when SSHing in.
And folks with AWS experience might be surprised that we don't use AWS key pairs, so add some wording to avoid them thinking the lack of an AWS key pair is the source of their SSH issues.
This changes the logging strategy so that it logs all output to a local
file in addition to logging at the desired level to the console.
Unfortunately, logrus doesn't have a facility for capturing all log
entries (the hooks are only fired for entries which are at or below the
specified level) so this disables the console output and sets up two
hooks: one for the console and one for the local file.
Because this is the next step beyond "my cluster didn't install,
here's the --log-level=debug output", for folks working up bug reports
that don't match one of the common failures.
This isn't shell content, so we shouldn't be highlighting it. Before
this commit, GitHub was styling 'in' (which is a shell keyword):
$ curl -s fffc477537/docs/user/troubleshooting.md (etcd-is-not-running) | grep 'Error signing'
<div class="highlight highlight-source-shell"><pre>Error signing CSR provided <span class="pl-k">in</span> request from agent: error parsing profile: invalid organization</pre></div>
