In the pre-kubernetes world, the VIM was always guaranteed
to start after the OpenStack services were up and running
(e.g. rabbitmq, nova, cinder). This ordering was enforced
by Service Management. The initialization code in the VIM
is based on this assumption, so the VIM simply exits when
one of the required OpenStack services is not present.
In kubernetes deployments, the OpenStack services are all
running in pods, which do not come up until after the VIM
(which is a baremetal service) has already intialized.
This happens (for example) when an AIO-SX host is
rebooted (e.g. after being unlocked). In this case, the
VIM will repeatedly exit until the OpenStack services it
needs come up. This is undesirable because the VIM is
a key component and the lack of a VIM prevents other
system operations from being done (e.g. host lock).
The solution is to allow the VIM to come up before any
of the OpenStack pods are running. The specific issue
was with the rabbitmq pod, which was preventing the
VIM's compute plugin from being initialized. The
solution is to have the VIM query rabbitmq for the
exchange it needs, prior to attempting to initialize
the compute plugin. The VIM will continue to do this
until the rabbitmq pod is available and allow other
VIM components to continue to run.
Change-Id: Iaf2403d361da6f32c7bccc3d27726562887a7524
Story: 2003910
Task: 28556
Signed-off-by: Bart Wensley <barton.wensley@windriver.com>
0a170a5f11