update/cgcs-patch/restart-info.html
Al Bailey 16b393f3ab Cleanup openstack components from patch scripts and tests
There were several example patch templates that demonstrated
how to patch some of the openstack processes.
Most of those openstack processes have been removed from bare
metal, so these scripts have been updated or removed.

Story: 2004764
Task: 30343
Change-Id: Ie6339d9f2dbf12e7d1a2b689676cca866b844a83
Signed-off-by: Al Bailey <Al.Bailey@windriver.com>
2019-04-04 09:39:18 -05:00

232 lines
7.8 KiB
HTML
Executable File

<!DOCTYPE html>
<html>
<head>
<style>
table, th, td {
border: 1px solid black;
border-collapse: collapse;
padding: 10px;
}
</style>
</head>
<body>
<table>
<caption>
<font size=10>Process restart information</font>
</caption>
<thead>
<tr>
<th>Process/Service</th>
<th>Function</th>
<th>In service patchable</th>
<th>Managed by</th>
<th>Restart command</th>
<th>Patch Restart command</th>
<th>Restart dependency</th>
<th>Impact(if restarted while in operation)</th>
<th>Special handling required</th>
</tr>
</thead>
<tr>
<td><font color="blue">haproxy</font></td>
<td>A Proxy service that is responsible for forwarding external REST
API requests to OpenStack and StarlingX services that listening on the
internal interfaces.
</td>
<td>Y</td>
<td>SM</td>
<td><b>sm-restart-safe service haproxy</b><br>
which runs the following:<br><br>
/bin/sh /etc/init.d/haproxy stop<br>
/bin/sh /etc/init.d/haproxy start
</td>
<td><b>/usr/local/sbin/patch-restart-haproxy</b></td>
<td>N</td>
<td>While the service is restarted, the outstanding requests will fail
and new requests will get connection error until the service is
re-enabled.
</td>
<td>Y</td>
</tr>
<tr>
<td><font color="blue">sm</font></td>
<td>Service management daemon</td>
<td>N</td>
<td>PMON</td>
<td><b>/etc/init.d/sm restart</b></td>
<td><b></b></td>
<td>N</td>
<td>Will cause all services disabled on the active controller before
the standby controller takes over the control.
</td>
<td>N</td>
</tr>
<tr>
<td><font color="blue">sm-api</font></td>
<td>Daemon that provides sm api</td>
<td>N</td>
<td>PMON</td>
<td><b></b></td>
<td><b></b></td>
<td>N</td>
<td></td>
<td>N</td>
</tr>
<tr>
<td><font color="blue">sm-eru</font></td>
<td>Daemon that records sm eru data</td>
<td>N</td>
<td></td>
<td><b></b></td>
<td><b></b></td>
<td>N</td>
<td></td>
<td>N</td>
</tr>
<tr>
<td><font color="blue">sm-watchdog</font></td>
<td>Daemon that loads NFS watchdog module to look for and handle
stalled NFS threads
</td>
<td>N</td>
<td></td>
<td><b></b></td>
<td><b></b></td>
<td>N</td>
<td></td>
<td>N</td>
</tr>
<tr>
<td><font color="blue">keystone-all</font></td>
<td>Keystone provides services that support an identity, token
management, and service catalog and policy functionality.
</td>
<td>Y</td>
<td>SM</td>
<td><b>sm-restart-safe service keystone</b><br>
which runs the following:<br><br>
/bin/sh /usr/lib/ocf/resource.d/openstack/keystone stop<br>
/bin/sh /usr/lib/ocf/resource.d/openstack/keystone start
</td>
<td><b>/usr/local/sbin/patch-restart-processes keystone-all</b></td>
<td>N</td>
<td>While the service is restarted, the outstanding requests will fail
and new requests will get connection error until the service is
re-enabled.
</td>
<td>N</td>
</tr>
<tr>
<td><font color="blue">Horizon</font></td>
<td>Horizon - Openstack Dashboard GUI
</td>
<td>Y</td>
<td>SM</td>
<td><b>sm-restart service horizon</b><br>
</td>
<td><b>/usr/bin/horizon-patching-restart</b></td>
<td>N</td>
<td>When horizon is restarted via the patch restart command all users
will be logged out. If they try to log back in before the server is
up again they will see an internal server error. It usually takes
less than a minute for the service to restart
</td>
<td>N</td>
</tr>
<tr>
<td><font color="blue">IO-Monitor</font></td>
<td>Daemon which monitors devices and raises alarms for excessive storage IO load.</td>
<td>Y</td>
<td>PMON</td>
<td><b>pmon-restart io-monitor-manager</b></td>
<td><b>/usr/local/sbin/patch-restart-processes io-monitor-manager</b></td>
<td>N</td>
<td>Generally there should be no impact. It is very unlikely for
the system to encounter an excessive storage IO load which will
only last a couple of seconds until the io-monitor process is restarted,
such that it will not be detected.
</td>
<td>N</td>
</tr>
<tr>
<td><font color="blue">vim</font></td>
<td>Virtual Infrastructure Manager</td>
<td>Y</td>
<td>SM</td>
<td><b>sm-restart-safe service vim</b></td>
<td><b></b></td>
<td>N</td>
<td>While the service is restarting, requests through the VIM API or
through the Nova API Proxy will fail. Any instance actions normally
triggered due to instance state changes (from nova) will not occur
until the process starts up again and audits the instance states.
</td>
<td>N</td>
</tr>
<tr>
<td><font color="blue">vim-api</font></td>
<td>Virtual Infrastructure Manager API</td>
<td>Y</td>
<td>SM</td>
<td><b>sm-restart-safe service vim-api</b></td>
<td><b></b></td>
<td>N</td>
<td>While the service is restarting, requests through the external VIM
API will fail.
</td>
<td>N</td>
</tr>
<tr>
<td><font color="blue">vim-webserver</font></td>
<td>Virtual Infrastructure Manager Web Server</td>
<td>Y</td>
<td>SM</td>
<td><b>sm-restart-safe service vim-webserver</b></td>
<td><b></b></td>
<td>N</td>
<td>No impact. This service is for design use only.</td>
<td>N</td>
</tr>
<tr>
<td><font color="blue">ceph-osd & ceph-mon</font></td>
<td>Ceph OSD and Monitor processes</td>
<td>Y</td>
<td>PMON</td>
<td><b>/etc/ceph/ceph_pmon_wrapper.sh restart</b><br></td>
<td><b>/etc/ceph/ceph_pmon_wrapper.sh restart</b></td>
<td>N</td>
<td>Ceph processes on a node will restart (ceph-mon and ceph-osd). The restart
will take at most 30s and functionality should not be affected. Note that this
command should not be executed at the same time on storage-0 and any of the
controller nodes as we do not support restarting two of the three ceph-mon at
the same time.
</td>
<td>Restarting it on controller-0, controller-1 & storage-0,
at the same time with ceph-rest-api, sysinv or ceph-manager
on the active controller should be avoided due to ~30 secs delay to ceph APIs.
This delay happens when any of the ceph-mon changes state and may cause timeouts
when dependent services restart. Recommendations: (1) On the active controller,
restart Ceph before the other service; (2) updating ctrl-0,ctrl-1 & storage-0
at the same time should be avoided.</td>
</tr>
<tfoot>
<tr>
<th>Process/Service</th>
<th>Function</th>
<th>In service patchable</th>
<th>Managed by</th>
<th>Restart command</th>
<th>Patch Restart command</th>
<th>Restart dependency</th>
<th>Impact(if restarted while in operation)</th>
<th>Special handling required</th>
</tr>
</tfoot>
</table>
</body>
</html>