If we deleted an ELB, we often fail to delete the security group,
because deleting the ELB is invisibly asynchronous.
Add a retry loop around delete-security-group to work around this.
Fix#21147
The only tested-working distros are vivid, wily & jessie.
vivid should not really be used because it is no longer supported, so
recommend wily or jessie instead.
For other distros, recommend jessie instead.
Fix#21218
Default distro is jessie, due to the support situation with Ubuntu
distros. Default ubuntu distro is wily.
Update the docs to reflect the recommended distros with kube-up, and to
encourage contributions for other distros.
Spot instances take a lot longer to run; wait up to 15 minutes for the
nodes to launch when we're using spot instances. (Previously we were
waiting 5 minutes).
Once we've built the master, we can build kubeconfig. By doing so, if
we time out waiting for the nodes, the system is still configured
correctly.
In particular, spot instances can be slow to launch.
Related to issue #21200
I think we should probably leave this undocumented for now, until we
have a better way to launch multiple sets of nodes, but it's great for
cost savings while testing!
Fix#21200
This is so we have the same behaviour as on GCE.
This also lets us change the bootstrap script or the config, which is
nice. Instance data is immutable on AWS once it is booted.
Fix#21150
We were assuming the PROJECT env var was set, which the e2e tests do.
But PROJECT is normally not set on AWS (it is set on GCE); this broke as
part of the harmonization.
Revert to the pre-existing behaviour here, where we use "aws_" as the
prefix.
Fix#21141
Fix script for case when neeed to setup cluster
in an existen VPC and subnet with ip mask example: 10.0.0.0/8.
Fixed bug to detect ip of master if provided MASTER_RESERVED_IP.
For some reason detecting master ip was moved to volumes and only when MASTER_RESERVED_IP=auto.
If specify IPv4 for MASTER_RESERVED_IP like `52.1.1.1`, than we could
not detect ip even during last steps of setuping cluster.
step the KUBE_MASTER_IP is reseted because there are no tag for the
volume.
In the e2e tests detect-master is called directly. In turn, it calls
find-tagged-master-ip, which assumed that find-master-pd has already already
been called. But this wasn't true in the e2e case.
We add a call to find-master-pd; it is idempotent.
build-runtime-config was being called in verify-prereqs, which didn't
match how GCE called it, and didn't seem to actually work.
Instead call it just before the master configuration is built. Also
call it just before the node configuration is built, even though the
nodes don't _currently_ require the runtime_config.
If we don't use an elastic IP, the IP address will be lost if we lose
the master for any reason, and a replacement master will not have the
same IP. But the master IP is set both in client kubeconfig files and
the master SSL certificate. Hence the default should be to allocate an
elastic IP for the master.
One complication: AWS doesn't allow tags on elastic IPs, so it is hard
to track the elastic IP so we can delete it as part of kube-down.
Instead, we take the master EBS volume with the elastic IP. This is a
little odd, but works because the master volume & the master elastic IP
really need to be assigned to the same machine, so might be thought of
as a pair.
Also, we now delete the master EBS volume as part of kube-down, as
people expect kube-down to clean-up everything it creates.
This is for internal use at the moment, for testing Ubernetes Lite, but
arguably makes the code a little cleaner.
Also rename KUBE_SHARE_MASTER -> KUBE_USE_EXISTING_MASTER
Robert Bailey