Return the nova instance UUID of worker nodes in kubeminion
templates. We will be able to remove resources from the
ResourceGroups based on nova instance uuid.
Backstory:
In heat a ResourceGroup creates a stack of depth 2. ResourceGroups
support removal policies to declare which resources must be removed.
This can be done by passing the index of the resource or the stack_id
of the nested stack. If a stack update call receives a list of
indices (eg [0, 5, 3]) or nested stack uuid (eg [uuidA, uuidB]), it
will remove the corresponding nested stacks.
In magnum's heat templates, a nested stack logically represents a
nova compute instance which is a cluster node. Using composition in
heat, we can change the way a resources group references the nested
stacks. This proposes to use the nova instance uuid as
'OS::stack_id'.
With this change, an external consumer of the stack (the cluster
autoscaler or an actual user) can remove resources from the
ResourceGroup using the nova instance uuid or resource index. Without
this change, a user or system (which typically knows the name,
server uuid or ip) would have to find in which nested stack a
kubernetes node belongs too. Resulting multiple call to heat.
The end result of this patch can be verified like this:
nested_stack_id=$(openstack stack resource show <STACK_ID_OR_NAME> kube_minions -c physical_resource_id -f value)
openstack stack show "${nested_stack_id}"
Task: 29664
Story: 2005054
Change-Id: I6d776f62d640c72b3228460392b92df94fe56fe6
Currently, there is no guarantee to make sure all nodes of one cluster are
created on different compute hosts. So it would be nice if we can create
a server group and set it with anti-affinity policy to get a better HA
for cluster. This patch is proposing to create a server group for master
and minion nodes with soft-anti-affinity policy by default.
Closes-Bug: #1737802
Change-Id: Icc7a73ef55296a58bf00719ca4d1cdcc304fab86
The instance type of servers at the moment can become quite long
due to the Heat autogenerated names. This patch cleans up the names
so that they are shorter yet contain all the info needed to be able
to know where they belong to.
Change-Id: I5bcbe73f08844242d049b8408221da40d22cd3dc
Previously the master's private IP address was not pushed through to the
minion configuration when the load balancer is disabled as the heat
templates were not wired up in this case. This change resolves that
issue and makes it possible for security groups to be applied to the
master and minion ports.
Change-Id: If85a5434f014c5a09b54dda710d13739e9bff928
Related-Bug: #1544195
This patch move software configs out of resource group (kubeminion.yaml).
With this fix, k8s minions will no duplicate software configs.
Partial-Bug: #1646710
Change-Id: I2cabc40401ce9a12bce7a8103090e0b9f0289e4d
This patch let kubeminions share same wait condition and wait condition
handler resource instead of create same function of resource for each
kubeminion node.
Partial-Bug: #1646720
Change-Id: I890a6f3155737286fe8930de038ba78ff7c2498c
It creates a mismatch between the generated Nova name
and its hostname which can lead to weird problems.
Closes-Bug: 1645730
Change-Id: I1c7dd459caefacaf41dd77e59c1a6e1df3ef0d42
In the swarm_atomic and k8s_atomic drivers container images are
stored in a dedicated cinder volume per cluster node. It is
proven that this architecture can be a scalability bottleneck.
Make the use of cinder volumes for container images and opt-in
option. If docker-volume-size is not specified no cinder
volumes will be created. Before, if docker-volume-size wasn't
specified the default value was 25.
To use cinder volumes for container storage the user will
interact with magnum as before, (meaning the valid values are
integers starting from 1).
Closes-Bug: #1638006
Change-Id: I3394c62a43bbf950b7cf0b86a71b1d9b0481d68f
The 2 k8s atomic drivers we currently support are added to the
same driver. This breaks ironic support with the stevedore
work I'm currently doing.
With stevedore, we can choose only one driver based on the
server_type, os and coe. We won't be able to pick a driver and
then choose an implementation bases on server_type.
Partially-Implements: blueprint magnum-baremetal-full-support
Co-Authored-By: Spyros Trigazis <strigazi@gmail.com>
Change-Id: Ic1b8103551f48f85baa2ed9ff32d5b70b1fab84e
Michal Nasiadka