- Create Kubernetes cluster on the top of OpenStack

This assumes you have your environement variables set correctly.

When ENABLE_PROXY is set to true, it takes the current proxy
settings and applies them to the heat configuration.

Also modified the defaults system in config-default.sh

If someone has an openrc as part of their profile, this will make kube-up work automatically.

The only things that have to be modified are in config-default.sh, either by editing the file or setting environment variables.

Making the assumption that the person running kube-up has their
Openstack environment setup, those same variables are being passed
into heat, and then into openstack.conf.

The salt codebase was modified to add openstack as well.

This makes it so that we download the OS image automatically.

Also contains other usability improvements:
- kubectl context created with heat stack name
- Bumped default minions to 3

Hard-coded the enabling of the common addons:

- logging
- kube-dashboard
- monitoring

Will make it configureable in a subsequent PR.
Also need to enable configuration of basic_auth.csv

The default pod sizes are too small for some Java apps. Also the logging/monitoring pods were taking up too many resources.

Parameter names of Heat str_replace remain unchanged

There might be several methods to deploy a Kubernetes cluster on OpenStack.
It is better to name the provider more specific.

It looks like this was left over from #23316

Fixed the order of fields for basic_auth.

This provider still needs to leverage common.sh for generating proper credentials though.

Also documented a pattern for how to get the SWIFT_SERVER_URL automatically

CentOS 7 Core nodes running on OpenStack with an SSL-enabled API
endpoint results in the following error without this patch:

F0425 19:00:58.124520       5 server.go:100] Cloud provider could not be initialized: could not init cloud provider "openstack": Post https://my.openstack.cloud:5000/v2.0/tokens: x509: failed to load system roots and no roots provided

The root cause is that the ca-bundle.crt file is actually a symlink
which points to a directory which wasn't previously exposed.

[root@kubernetesstack-master ~]# ls -l /etc/ssl/certs/ca-bundle.crt
lrwxrwxrwx. 1 root root 49 18 nov 11:02 /etc/ssl/certs/ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
[root@kubernetesstack-master ~]#

…ovider.

On reboot, minions hostname would change, causing issue querying Openstack API and registering with kube-apiserver.

This is due to a bug in cloud-init which has been patched but apparently not widely distributed.

Should be harmless on unaffected systems.
https://bugs.launchpad.net/cloud-init/+bug/1246485
http://blog.oddbit.com/2014/12/10/cloudinit-and-the-case-of-the-changing-hostname/

Expose /etc/pki from host to kube-apiserver and controller-manager

Adding workaround for hostname swapping issue in OpenStack kube-up provider

Automatically detect swift URL