Merge pull request openshift#72 from clnperez/add-ipi-mc

manual upstream merge

OWNERS_ALIASES

@@ -27,6 +27,7 @@ aliases:
     - mandre
     - mdbooth
     - pierreprinetti
+    - stephenfin
   openstack-reviewers:
     - EmilienM
     - adduarte

data/data/baremetal/main.tf

@@ -28,7 +28,7 @@ module "masters" {
 
   master_count   = var.master_count
   ignition       = var.ignition_master
-  hosts          = var.hosts
+  masters        = var.masters
   properties     = var.properties
   root_devices   = var.root_devices
   driver_infos   = var.driver_infos

data/data/baremetal/masters/main.tf

@@ -1,6 +1,6 @@
 resource "ironic_node_v1" "openshift-master-host" {
   count          = var.master_count
-  name           = var.hosts[count.index]["name"]
+  name           = var.masters[count.index]["name"]
   resource_class = "baremetal"
 
   inspect   = true
@@ -9,22 +9,22 @@ resource "ironic_node_v1" "openshift-master-host" {
 
   ports = [
     {
-      address     = var.hosts[count.index]["port_address"]
+      address     = var.masters[count.index]["port_address"]
       pxe_enabled = "true"
     },
   ]
 
   properties  = var.properties[count.index]
   root_device = var.root_devices[count.index]
 
-  driver      = var.hosts[count.index]["driver"]
+  driver      = var.masters[count.index]["driver"]
   driver_info = var.driver_infos[count.index]
 
-  boot_interface       = var.hosts[count.index]["boot_interface"]
-  management_interface = var.hosts[count.index]["management_interface"]
-  power_interface      = var.hosts[count.index]["power_interface"]
-  raid_interface       = var.hosts[count.index]["raid_interface"]
-  vendor_interface     = var.hosts[count.index]["vendor_interface"]
+  boot_interface       = var.masters[count.index]["boot_interface"]
+  management_interface = var.masters[count.index]["management_interface"]
+  power_interface      = var.masters[count.index]["power_interface"]
+  raid_interface       = var.masters[count.index]["raid_interface"]
+  vendor_interface     = var.masters[count.index]["vendor_interface"]
 }
 
 resource "ironic_deployment" "openshift-master-deployment" {

data/data/baremetal/masters/variables.tf

@@ -9,27 +9,27 @@ variable "ignition" {
   description = "The content of the master ignition file"
 }
 
-variable "hosts" {
+variable "masters" {
   type        = list(map(string))
-  description = "Hardware details for hosts"
+  description = "Hardware details for masters"
 }
 
 variable "properties" {
   type        = list(map(string))
-  description = "Properties for hosts"
+  description = "Properties for masters"
 }
 
 variable "root_devices" {
   type        = list(map(string))
-  description = "Root devices for hosts"
+  description = "Root devices for masters"
 }
 
 variable "driver_infos" {
   type        = list(map(string))
-  description = "BMC information for hosts"
+  description = "BMC information for masters"
 }
 
 variable "instance_infos" {
   type        = list(map(string))
-  description = "Instance information for hosts"
+  description = "Instance information for masters"
 }

data/data/baremetal/variables-baremetal.tf

@@ -28,9 +28,9 @@ variable "ironic_password" {
   description = "Password for authentication to Ironic"
 }
 
-variable "hosts" {
+variable "masters" {
   type        = list(map(string))
-  description = "Hardware details for hosts"
+  description = "Hardware details for masters"
 }
 
 variable "bridges" {
@@ -40,20 +40,20 @@ variable "bridges" {
 
 variable "properties" {
   type        = list(map(string))
-  description = "Properties for hosts"
+  description = "Properties for masters"
 }
 
 variable "root_devices" {
   type        = list(map(string))
-  description = "Root devices for hosts"
+  description = "Root devices for masters"
 }
 
 variable "driver_infos" {
   type        = list(map(string))
-  description = "BMC information for hosts"
+  description = "BMC information for masters"
 }
 
 variable "instance_infos" {
   type        = list(map(string))
-  description = "Instance information for hosts"
+  description = "Instance information for masters"
 }

data/data/install.openshift.io_installconfigs.yaml

@@ -2269,6 +2269,10 @@ spec:
                             type: integer
                         type: object
                     type: object
+                  diskType:
+                    description: Disk Type Thin specifies if thin disks should be
+                      use instead of thick
+                    type: string
                   folder:
                     description: Folder is the absolute path of the folder that will
                       be used and/or created for virtual machines. The absolute path

data/data/vsphere/pre-bootstrap/main.tf

@@ -50,6 +50,7 @@ resource "vsphereprivate_import_ova" "import" {
   network    = var.vsphere_network
   folder     = local.folder
   tag        = vsphere_tag.tag.id
+  disk_type  = var.vsphere_disk_type
 }
 
 resource "vsphere_tag_category" "category" {

data/data/vsphere/variables-vsphere.tf

@@ -76,4 +76,7 @@ variable "vsphere_control_plane_num_cpus" {
 variable "vsphere_control_plane_cores_per_socket" {
   type = number
 }
-
+variable "vsphere_disk_type" {
+  type    = string
+  default = "eagerZeroedThick"
+}

docs/design/openstack/networking-infrastructure.md

@@ -48,7 +48,7 @@ Keepalived. While the bootstrap node is up, it will have priority running the AP
 
 The Master nodes run dhcp, HAProxy, CoreDNS, and Keepalived. Haproxy loadbalances incoming requests
 to the API across all running masters. It also runs a stats and healthcheck server. Keepalived manages both VIPs on the master, where each
-master has an equal chance of being assigned one of the VIPs. Initially, the bootstrap node has the highest priority for hosting the API VIP, so they will point to addresses there at startup. Meanwhile, the master nodes will try to get the control plane, and the OpenShift API up. Keepalived implements periodic health checks for each VIP that are used to determine the weight assigned to each server. The server with the highest weight is assigned the VIP. Keepalived has two seperate healthchecks that attempt to reach the OpenShift API and CoreDNS on the localhost of each master node. When the API on a master node is reachable, Keepalived substantially increases it's weight for that VIP, making its priority higher than that of the bootstrap node and any node that does not yet have the that service running. This ensures that nodes that are incapable of serving DNS records or the OpenShift API do not get assigned the respective VIP. The Ingress VIP is also managed by a healthcheck that queries for an OCP Router HAProxy healthcheck, not the HAProxy we stand up in  static pods for the API. This makes sure that the Ingress VIP is pointing to a server that is running the necessary OpenShift Ingress Operator resources to enable external access to the node.
+master has an equal chance of being assigned one of the VIPs. Initially, the bootstrap node has the highest priority for hosting the API VIP, so they will point to addresses there at startup. Meanwhile, the master nodes will try to get the control plane, and the OpenShift API up. Keepalived implements periodic health checks for each VIP that are used to determine the weight assigned to each server. The server with the highest weight is assigned the VIP. Keepalived has two separate healthchecks that attempt to reach the OpenShift API and CoreDNS on the localhost of each master node. When the API on a master node is reachable, Keepalived substantially increases it's weight for that VIP, making its priority higher than that of the bootstrap node and any node that does not yet have the that service running. This ensures that nodes that are incapable of serving DNS records or the OpenShift API do not get assigned the respective VIP. The Ingress VIP is also managed by a healthcheck that queries for an OCP Router HAProxy healthcheck, not the HAProxy we stand up in  static pods for the API. This makes sure that the Ingress VIP is pointing to a server that is running the necessary OpenShift Ingress Operator resources to enable external access to the node.
 
 The Worker Nodes run dhcp, CoreDNS, and Keepalived. On workers, Keepalived is only responsible for managing
 the Ingress VIP. It's algorithm is the same as the one run on the masters.

docs/dev/libvirt/README.md

@@ -113,7 +113,7 @@ First, you need to start the libvirtd TCP socket, which is managed by systemd:
 sudo systemctl start libvirtd-tcp.socket
 ```
 
-To make this change persistent accross reboots you can optionally enable it:
+To make this change persistent across reboots you can optionally enable it:
 
 ```sh
 sudo systemctl enable libvirtd-tcp.socket
@@ -415,7 +415,7 @@ FATA[0019] failed to run Terraform: exit status 1
 
 it is likely that your install configuration contains three backslashes after the protocol (e.g. `qemu+tcp:///...`), when it should only be two.
 
-### Random domain creation errors due to libvirt race conditon
+### Random domain creation errors due to libvirt race condition
 
 Depending on your libvirt version you might encounter [a race condition][bugzilla_libvirt_race] leading to an error similar to:
 

docs/user/aws/limits.md

@@ -42,7 +42,7 @@ For multiple clusters, a higher limit will likely be required (and will certainl
 
 ### Example: Using North Virginia (us-east-1)
 
-North Virginia (us-east-1) has six availablity zones, so a higher limit is required unless you configure your cluster to use fewer zones.
+North Virginia (us-east-1) has six availability zones, so a higher limit is required unless you configure your cluster to use fewer zones.
 To support the default, all-zone installation, please submit a limit increase for VPC Elastic IPs similar to the following in the support dashboard (to create more than one cluster, a higher limit will be necessary):
 
 ![Increase Elastic IP limit in AWS](images/support_increase_elastic_ip.png)

docs/user/azure/install_upi.md

@@ -12,7 +12,7 @@ example.
 * the following binaries installed and in $PATH:
   * [openshift-install][openshiftinstall]
     * It is recommended that the OpenShift installer CLI version is the same of the cluster being deployed. The version used in this example is 4.3.0 GA.
-  * [az (Azure CLI)][azurecli] installed and aunthenticated
+  * [az (Azure CLI)][azurecli] installed and authenticated
     * Commands flags and structure may vary between `az` versions. The recommended version used in this example is 2.0.80.
   * python3
   * [jq][jqjson]
@@ -455,7 +455,7 @@ csr-wpvxq   19m    system:serviceaccount:openshift-machine-config-operator:node-
 csr-xpp49   19m    system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Approved,Issued
 ```
 
-You should inspect each pending CSR with the `oc describe csr <name>` command and verify that it comes from a node you recognise. If it does, they can be approved:
+You should inspect each pending CSR with the `oc describe csr <name>` command and verify that it comes from a node you recognize. If it does, they can be approved:
 
 ```console
 $ oc adm certificate approve csr-8bppf csr-dj2w4 csr-ph8s8

docs/user/azure/limits.md

@@ -32,7 +32,7 @@ A public IP address is also created for the bootstrap machine during installatio
 ## Network Security Groups
 
 Each cluster creates network security groups for every subnet within the VNet. The default install creates network
-security groups for the control plane and for the compuete node subnets. The default limit of 5000 for new accounts
+security groups for the control plane and for the compute node subnets. The default limit of 5000 for new accounts
 allows for many clusters to be created. The network security groups which exist after the default install are:
 
 1. controlplane
@@ -94,13 +94,13 @@ By default, each cluster will create 3 network load balancers. The default limit
 3. external
   * Public IP address that load balances requests to port 6443 across control-plane nodes
 
-Additional Kuberntes LoadBalancer Service objects will create additional [load balancers][load-balancing]. 
+Additional Kubernetes LoadBalancer Service objects will create additional [load balancers][load-balancing]. 
 
 
 ## Increasing limits
 
 
-To increase a limit beyond the maximum, a suppport request will need to be filed.
+To increase a limit beyond the maximum, a support request will need to be filed.
 
 First, click on "help + support". It is located on the bottom left menu.
 

docs/user/customization.md

@@ -39,7 +39,7 @@ The following `install-config.yaml` properties are available:
         The default is 10.128.0.0/14 with a host prefix of /23.
         * `cidr` (required [IP network](#ip-networks)): The IP block address pool.
         * `hostPrefix` (required integer): The prefix size to allocate to each node from the CIDR.
-        For example, 24 would allocate 2^8=256 adresses to each node. If this field is not used by the plugin, it can be left unset.
+        For example, 24 would allocate 2^8=256 addresses to each node. If this field is not used by the plugin, it can be left unset.
     * `machineNetwork` (optional array of objects): The IP address pools for machines.
         * `cidr` (required [IP network](#ip-networks)): The IP block address pool.
             The default is 10.0.0.0/16 for all platforms other than libvirt.
@@ -72,7 +72,7 @@ For example, 10.0.0.0/16 represents IP addresses 10.0.0.0 through 10.0.255.255.
 
 The following machine-pool properties are available:
 
-* `architecture` (optional string): Determines the instruction set architecture of the machines in the pool. Currently, heteregeneous clusters are not supported, so all pools must specify the same architecture.
+* `architecture` (optional string): Determines the instruction set architecture of the machines in the pool. Currently, heterogeneous clusters are not supported, so all pools must specify the same architecture.
     Valid values are `amd64` (the default).
 * `hyperthreading` (optional string): Determines the mode of hyperthreading that machines in the pool will utilize.
     Valid values are `Enabled` (the default) and `Disabled`.

docs/user/gcp/limits.md

@@ -55,7 +55,7 @@ A standard OpenShift installation creates 2 forwarding rules.
 A standard OpenShift installation creates 3 in-use global IP addresses.  
 
 ### Networks
-A standard OpenShift instlalation creates 2 networks.
+A standard OpenShift installation creates 2 networks.
 
 ### Routers
 A standard OpenShift installation creates 1 router.

docs/user/metal/README.md

@@ -2,7 +2,7 @@
 
 OpenShift has support for bare metal deployments with either [User
 provided infrastructure (UPI)](install_upi.md), or [Installer-provided
-instrastructure (IPI)](install_ipi.md).
+infrastructure (IPI)](install_ipi.md).
 
 The following is a summary of key differences:
 

docs/user/metal/customization_ipi.md

@@ -57,7 +57,7 @@ and TFTP server in the cluster to support provisioning. Much of this can
 be customized.
 
 
-* `provisioningNetorkCIDR` (optional string): Override the default provisioning network.
+* `provisioningNetworkCIDR` (optional string): Override the default provisioning network.
 * `bootstrapProvisioningIP` (optional string): Override the bootstrap
     provisioning IP. If unspecified, uses the 2nd address in the
     provisioning network's subnet.

docs/user/metal/install_upi.md

@@ -1,5 +1,7 @@
 # Install: BareMetal User Provided Infrastructure
 
+The upstream project that provides management of bare metal hosts is [metal.equinix.com][equinix-metal].
+
 The steps for performing a UPI-based install are outlined here. Several [Terraform][upi-metal-example] templates are provided as an example to help model your own.
 
 ## Table of contents
@@ -224,11 +226,11 @@ INFO Waiting up to 30m0s for the cluster to initialize...
 
 ## Example Bare-Metal UPI deployment
 
-Terraform [templates][upi-metal-example] provides an example of using OpenShift Installer to create an bare-metal UPI OpenShift cluster on Packet.net
+Terraform [templates][upi-metal-example] provides an example of using OpenShift Installer to create an bare-metal UPI OpenShift cluster on [Equinix Metal][equinix-metal].
 
 ### Overview
 
-* Compute: Uses Packet.net to deploy bare-metal machines.
+* Compute: Uses [Equinix Metal][equinix-metal] to deploy bare-metal machines.
     Uses [matchbox] to serve PXE scripts and Ignition configs for bootstrap, control plane and worker machines.
     Uses `public` IPv4 addresses for each machine, so that all the machines are accessible on the internet.
 
@@ -274,7 +276,7 @@ Use the bootstrap [monitoring](#monitor-for-bootstrap-complete) to track when cl
 terraform apply -auto-approve -var=bootstrap_dns="false"
 ```
 
-NOTE: The bootstrap resources like the bootstrap machines currently cannot be removed using terraform. You can use the Packet.net console to remove the bootstrap machine. All the resources will be cleaned up by `terraform destroy`
+NOTE: The bootstrap resources like the bootstrap machines currently cannot be removed using terraform. You can use the [Equinix Metal console][equinix-metal-console] to remove the bootstrap machine. All the resources will be cleaned up by `terraform destroy`
 
 ### Approving server certificates for nodes
 
@@ -312,6 +314,8 @@ terraform destroy -auto-approve
 [coreos-installer-args]: https://github.com/coreos/coreos-installer#kernel-command-line-options-for-coreos-installer-running-in-the-initramfs
 [coreos-installer]: https://github.com/coreos/coreos-installer#coreos-installer
 [csr-requests]: https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/#requesting-a-certificate
+[equinix-metal]: https://metal.equinix.com
+[equinix-metal-console]: https://console.equinix.com
 [etcd-ports]: https://github.com/openshift/origin/pull/21520
 [machine-config-server]: https://github.com/openshift/machine-config-operator/blob/master/docs/MachineConfigServer.md
 [matchbox]: https://github.com/coreos/matchbox

docs/user/openstack/README.md

@@ -36,9 +36,15 @@ In addition, it covers the installation with the default CNI (OpenShiftSDN), as
     - [Destroying The Cluster](#destroying-the-cluster)
   - [Post Install Operations](#post-install-operations)
     - [Adding a MachineSet](#adding-a-machineset)
+      - [Defining a MachineSet That Uses Multiple Networks](#defining-a-machineset-that-uses-multiple-networks)
       - [Using a Server Group](#using-a-server-group)
       - [Setting Nova Availability Zones](#setting-nova-availability-zones)
     - [Using a Custom External Load Balancer](#using-a-custom-external-load-balancer)
+      - [External Facing OpenShift Services](#external-facing-openshift-services)
+      - [HAProxy Example Load Balancer Config](#haproxy-example-load-balancer-config)
+      - [DNS Lookups](#dns-lookups)
+      - [Verifying that the API is Reachable](#verifying-that-the-api-is-reachable)
+      - [Verifying that Apps Reachable](#verifying-that-apps-reachable)
     - [Reconfiguring cloud provider](#reconfiguring-cloud-provider)
       - [Modifying cloud provider options](#modifying-cloud-provider-options)
       - [Refreshing a CA Certificate](#refreshing-a-ca-certificate)

docs/user/openstack/install_upi.md

@@ -63,7 +63,7 @@ of this method of installation.
 
 ## Prerequisites
 
-The file `inventory.yaml` contains the variables most likely to need customisation.
+The file `inventory.yaml` contains the variables most likely to need customization.
 **NOTE**: some of the default pods (e.g. the `openshift-router`) require at least two nodes so that is the effective minimum.
 
 The requirements for UPI are broadly similar to the [ones for OpenStack IPI][ipi-reqs]:
@@ -580,7 +580,7 @@ Possible choices include:
 * Swift (see Example 1 below);
 * Glance (see Example 2 below);
 * Amazon S3;
-* Internal web server inside your organisation;
+* Internal web server inside your organization;
 * A throwaway Nova server in `$INFRA_ID-nodes` hosting a static web server exposing the file.
 
 In this guide, we will assume the file is at the following URL:
@@ -932,7 +932,7 @@ csr-lrtlk   15m    system:serviceaccount:openshift-machine-config-operator:node-
 csr-wkm94   16m    system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Approved,Issued
 ```
 
-You should inspect each pending CSR and verify that it comes from a node you recognise:
+You should inspect each pending CSR and verify that it comes from a node you recognize:
 
 ```sh
 $ oc describe csr csr-88jp8