* OpenStack: add server group name override annotation
* use retries to listinstances
* add support for multiple clusters in same tenant
* run hack-expected.sh
* add test for serverGroupName annotation
* use retry
This will make use of the kOps taks engine to retry failed servers.
The former approach had the side effect of not making kOps fail when the
last retry failed:
Because there is now a server present - although in an erroneous state -
the "instance task" which the task engine retried reconciled the server
(port, floating ip) instead of recreating it again.
With the approach of letting the task engine retry the failed servers
this will be handled correctly.
This aims to improve the experience when creating openstack servers and
they run into issues during scheduling, which is not covered by the
create API request.
So after creating the instance kops waits for it to become ACTIVE and if
not, tries to reprovision the instance by deleting the failed instance
and creating a new one.
If the last attempt was still not successful, erroneous instances will
persist to allow further investigation, and the task will fail, which
will ultimately fail the update call.
This enables us to change the ServerGroup affinity policies using
annotations on instance groups.
The default affinity policy still is "anti-affinity".
This PR introduces two fixes:
1) Add missing RetryWithBackoff to DeleteInstanceWithID
2) Fix broken retry logic in all other delete functions. In the current implementation, as the first Delete request will almost certainly return nil, the function will return true and the retry will not try again, resulting in assets not getting deleted from OpenStack
Also, the current writeBackoff is pretty aggressive and I introduced a bit less hasty deleteBackoff.
The change has been tested with OpenStack. I verified that all APIs we are hitting will eventually return the 404 (type) we are looking for.
Ignoring replace with no spec changes
Updating replace cancellation to only not set generation, instead of not performing the update
Bazel updates
Setting generation in common clientset code
Bazel updates
We don't call klog.InitFlags yet, because that will cause a flag
redefinition error until we get everyone to stop using glog. That
will happen when we update to k8s 1.13.