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.
To avoid wiping out the caller's whole libvirt environment, regardless
of whether it was associated with our cluster or not. Using
cluster-name prefixes still makes me a bit jumpy, so I've added
warnings to both the environment-variable and asset-prompt docs
warning libvirt users to pick something sufficiently unique.
Also:
* Use {cluster-name}-master-{count} naming. We used to use
master{count}, which diverged from other usage (e.g. AWS, which has
used master-{count} since way back in ca443c5e (openstack/nova:
replace cloud-init with ignition, 2017-02-27,
coreos/tectonic-installer#7).
* Rename module.libvirt_base_volume -> module.volume. There's no
reason to diverge from the module source for that name.
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>
Keep the environment variable (with a warning about using it), but
drop the interactive prompt. The default is solid, and users
manipulating it are more likely to break something (e.g. by continuing
to use the old v1 pipeline), while the installer can update its
default to track the RHCOS folks (e.g. like 11178211, rhcos: implement
image discovery for new pipeline, 2018-10-26, #554).
Brian says [1]:
The third time I had to abort was when prompted for base domain
followed by cluster name (I included my cluster name in my base
domain because I'm using a well structure name server delegation
structure).
And I've seen a number of other cases where folks suggest including
the cluster name again in the base domain. Sometimes you might need
to do that (e.g. if you cannot create subdomains without the
additional namespacing). But in most cases, including the cluster
name in the base domain is redundant.
[1]: https://github.com/openshift/installer/issues/627#issue-378069672
To make it easier to pass this in when you don't have a shell for:
$ OPENSHIFT_INSTALL_SSH_PUB_KEY="$(cat path/to/key)" openshift-install install-config
For example, this is useful in CI where we can launch the cluster
without hitting a shell at all. And it's also a bit more compact for
folks who are reading from files anyway.
I've also added a check for "do we only have one choice?". If so, I
just pick that value instead of bothering the user when they don't
have a decision to make.
