SIGHUP on ironic services¶
It is a common practice for daemons to use SIGHUP as a signal to reconfigure a server by reloading configuration files (as mentioned in Wikipedia). This specification describes adding this feature to the ironic-conductor and ironic-api services.
Issuing a SIGHUP signal (via, for example,
kill -s 1 <process-id>) to an
ironic (ironic-api and ironic-conductor) service causes the service to be
It is a common practice for daemons to use SIGHUP as a signal to reconfigure a server by reloading configuration files (as mentioned in Wikipedia). This specification describes how ironic will support SIGHUP, such that select configuration options can be reloaded during runtime.
This is useful, for example, during a rolling upgrade. After unpinning
pin_release_version configuration option), SIGHUP could be
used to restart the services with the updated option value.
Another example is for operators to more easily enable or disable the debug logging without having to stop and (re)start the services.
Note that SIGHUP is not supported on Windows.
We will leverage code from these libraries:
the oslo.service library provides support for services to handle this signal. We would change the ironic services so that they are launched with
restart_method='mutate'. When the library code handles the SIGHUP signal, it gets any changes for mutable configuration options.
The oslo.config library adds support for
mutableconfiguration options. Only mutable configuration options can be reloaded. A mutable option note (“Note: This option can be changed without restarting.”) is added to the description of a mutable configuration option in the ironic.conf.sample file. It logs any changed mutable configuration options. It also logs a warning for any changed options that are not mutable.
With these changes, when a SIGHUP occurs, the service will reload with values from the mutable options. A warning is logged for changes to any immutable options.
Mutable configuration options¶
Mutable configuration options that will be available are:
options from other libraries. To date, the only mutable options that are used by the ironic services are from the oslo.log library:
Other ironic configuration options can be made mutable in the future; such changes should have corresponding release notes. The belief is that most, if not all, of the configuration options should be made mutable. However, that is outside the scope of this specification – which is to lay the groundwork to make this possible with a small number of options. When mentioning that ironic supports SIGHUP, operators might assume (incorrectly) that this applies to all configuration options, so we should make other configuration options available in a timely fashion.
The value of a mutable configuration option should not be cached; or at least, if it is cached, the value must be updated upon a SIGHUP occurrence.
Change the desired configuration option values, stop the service, and then start it again.
Data model impact¶
State Machine Impact¶
REST API impact¶
Client (CLI) impact¶
“openstack baremetal” CLI¶
RPC API impact¶
Driver API impact¶
Nova driver impact¶
Other end user impact¶
The operator will be able to change certain configuration options and issue a SIGHUP to have an ironic service restart using the changed option values.
Other deployer impact¶
Among other things, this can be used for rolling upgrades.
Primary assignee: rloo (Ruby Loo)
change our services so they are launched with
change the desired configuration options so that they are mutable
make sure the mutable options are not cached, or if they are, make sure that they are updated appropriately with a SIGHUP occurrence
If we stop and restart a service in the e.g. multinode grenade testing, we could change that and issue a SIGHUP instead.
Upgrades and Backwards Compatibility¶
Changing the value of mutable configuration options will now take effect when a SIGHUP is issued. We need this to support rolling upgrades.
The use of SIGHUP (in the context of
be documented as part of the rolling upgrade process.