The above two rules doesn't seem correct.
If the user stops contrail-api or ifmap service, all the services in contrail-config is restarted. This not the expected behavior. Perhaps, we may want to restart all the services expect for the service being stopped by the user?
/etc/contrail/ supervisord_ config_ files/contrail- config. rules
{ "Rules": [ STATE_STOPPED" , "action": "service supervisor-config restart"}, STATE_EXITED" , "action": "service supervisor-config restart"}, STATE_FATAL" , "action": "service supervisor-config restart"}, STATE_STOPPED" , "action": "service supervisor-config restart"}, STATE_EXITED" , "action": "service supervisor-config restart"}, STATE_FATAL" , "action": "service supervisor-config restart"}
{"processname": "contrail-api", "process_state": "PROCESS_
{"processname": "contrail-api", "process_state": "PROCESS_
{"processname": "contrail-api", "process_state": "PROCESS_
{"processname": "ifmap", "process_state": "PROCESS_
{"processname": "ifmap", "process_state": "PROCESS_
{"processname": "ifmap", "process_state": "PROCESS_
]
}
"processname": "contrail-api", "process_state": "PROCESS_ STATE_STOPPED" , "action": "service supervisor-config restart" STATE_STOPPED" , "action": "service supervisor-config restart"
"processname": "ifmap", "process_state": "PROCESS_
The above two rules doesn't seem correct.
If the user stops contrail-api or ifmap service, all the services in contrail-config is restarted. This not the expected behavior. Perhaps, we may want to restart all the services expect for the service being stopped by the user?