Refresh the user documentation with the current state of deployment on
OpenStack.
Co-Authored-By: Emilio Garcia <egarcia@redhat.com>
Co-Authored-By: Ramon Acedo Rodriguez <racedoro@redhat.com>
Co-Authored-By: Martin André <m.andre@redhat.com>
current doc contains wrong info
https://github.com/openshift/installer/blob/master/pkg/asset/rhcos/image.go#L64
only support rhcos
and per test, change image name to rhcos-xxx such as rhcos-112
ERROR
ERROR Error: Your query returned no results. Please change your search criteria and try again.
ERROR
ERROR on ../../../../../../tmp/openshift-install-590981577/bootstrap/main.tf line 58, in data "openstack_images_image_v2" "bootstrap_image":
ERROR 58: data "openstack_images_image_v2" "bootstrap_image" {
The kubeadmin user should only be used to temporarily access the
console, and only until an admin configures a proper Identity Provider.
There is no reason to login as the kubeadmin user via CLI. If oauth
is broken in a cluster, an admin can still access via CLI as system:admin,
but will not be able to access via kube:admin.
The FQDN for the service VM to deploy against OpenStack changed from
`<cluster name>-api.<cluster domain>` to `api.<cluster name><cluster
domain>`. This commit reflects the change into the documentation.
Technically, network names in OpenStack are not unique. We would
expect almost every deployment to be using a unique name for its
external network, though.
In the rare case where you must disambiguate networks, it's possible
to specify the UUID via a terraform variable.
$ env TF_VAR_openstack_external_network_id="6a32627e-d98d-40d8-9324-5da7cf1452fc" \
> bin/openshift-install create cluster
The OpenStack provider now does not create any floating IP addresses.
Instead, the user is expected to create one themselves ahead of time and
pass it in.
This lets us support non-FIP deployments and it is the final step
towards a completely unattended installation.
Since the external API DNS records have to be created out-of-band and
since the floating IP address could not be determined ahead of time,
this was something the deployers had to do as the installation was
happening.
Now they can create the FIP, create the DNS records, add the IP to the
install config (under `platform.openstack.lbFloatingIP`) and have the
start the installation and let it complete on its own.
If the `lbFloatingIP` value is not specified, no floating IP will be
created. This will likely make the installer fail (unless the deployer
configured their networking and DNS such that the API is externally
accessible), but this was true even before this change.
This should still result in a successful deployment, the installer just
won't be able to tell.
Change machine-config-server port from 49500 -> 22623
to avoid conflict with local port and node port ranges.
Closes machine-config-operator issue: #166
This adds the `<cluster name>-api.<domain>` as well as the
`*.apps.<cluster name>.<domain>` entries to the DNS running on the
Service VM.
That finally closes the loop and lets us install OpenShift on
OpenStack and then open the UI in the browser (they'll need to use the
DNS we provide, but that's a hard requirement at this point).
This reverts commit ae54392948.
The proposed solution (including the exact same CoreDNS configuration)
does not work for several of our developers deployments causing a
regression (i.e. we're not able to get the etcd cluster started).
It appears that the DNS requests are getting the CNAME values for the
etcd records, but they never resolve to an IP address.
We've not figured out why that is yet, so reverting this change lets us
unblock the OpenStack deployments.
For the Openstack DNS (short-term) solution, the external DNS should be
configured with the relevant SRV and CNAME records.
This patch deletes the DNS server runs in service VM and
documents the kind of records that must be configured in the
the environment DNS prior to launching a deployment in order for the
etcd discovery and aliases to work properly. This is only for in-cluster
DNS resolution and as such does not include OCP router wildcard record
examples.
Co-authored-by: Antoni Segura Puimedon <celebdor@gmail.com>
We've documented the steps to shift to an external load balancer here.
I did not cover specifically how to configure the DNS, only that the -api
record needs to be changed. I'll leave this for the DNS folks or fix
it after they submit their documentation.
Co-Authored-By: egarcia@redhat.com
* Removed the need to add a floating IP per
d96e4c12bf
* Clarified more OSP requisites (RHCOS image, ssh key, external network
name/id)
* Provided a clouds.yaml example file
* Added using /etc/hosts instead /etc/resolv.conf to access the API
