Comment 4 for bug 1877125

Related issue to the https-enable:

Since config_apply_runtime_manifest() checks for INITIAL_CONFIG_COMPLETE_FLAG prior to allowing a runtime manifest apply; the https update is not applied at runtime.

e.g. logs from the SX system:

# The runtime manifest apply for https is initiated at 15:06:
sysinv 2020-05-06 15:06:46.206 128486 INFO sysinv.conductor.manager [-] applying runtime manifest config_uuid=77d4495a-d16b-4402-a168-d612616452ec, classes: ['platform::haproxy::runtime', 'openstack::keystone::endpoint::runtime', 'openstack::horizon::runtime', 'platform::firewall::runtime']
sysinv 2020-05-06 15:06:49.671 128486 INFO sysinv.agent.rpcapi [-] config_apply_runtime_manifest: fanout_cast: sending config 77d4495a-d16b-4402-a168-d612616452ec {'classes': ['platform::haproxy::runtime', 'openstack::keystone::endpoint::runtime', 'openstack::horizon::runtime', 'platform::firewall::runtime'], 'force': False, 'personalities': ['controller']} to agent

However, the .initial_config_complete isnt until 15:18
                                                       |
-rw-r--r-- 1 root root 0 May 6 15:18 .initial_config_complete

This is similar case in the the non-SX lab case mentioned above.

Potential solutions:
1) automation waits for /etc/platform/.initial_config_complete (initial puppet manifest applied) before performing the system modify https, or performs host-lock/unlock to update the config if its performed prior to .initial_config_complete .

2) investigate whether https can be applied at this point in the runtime manifest (e.g. via Force option). This alternative would require some investigation from https/networking to determine whether a force apply is possible and valid at this point as the manifests required to be applied are: ['platform::haproxy::runtime', 'openstack::keystone::endpoint::runtime', 'openstack::horizon::runtime', 'platform::firewall::runtime']