Each infrastructure service in the SIPCluster custom resource should be
a descendant of a key that is a valid service type; however, errors in
the name of an infrastructure service type are only logged as info;
processing of the SIP CR continues even when an infrastructure service
type is invalid.
This change introduces up-front validation by adding a new field to the
infrastructure service config, serviceType. When a serviceType is
invalid, SIP will not begin processing the CR because the Kubernetes API
server will reject the SIPCluster resource. The key under which an
infrastructure service resides is now treated as an arbitrary value.
Signed-off-by: Drew Walters <andrew.walters@att.com>
Change-Id: I082dac7eae6893decfca12227caf0ea50bc1fa30
2a5dacae95