Process 'neutron-l3-agent' is not monitored by pmon

[Juan Carlos Alonso]

Title
-----

Process 'neutron-l3-agent' does not work.

Brief Description
-----------------

In controller nor computes, '/etc/pmon.d/neutron-l3-agent.conf' file does not exists.
In controller nor computes, '/etc/init.d/neutron-l3-agent' process does not exist.
In controller 'neutron-l3-agent' process appears 'Dead' by default, when tried to start the process it fails.
In computes 'neutron-l3-agent' process appears 'Active' by default, can be stop and start without problems, but any alarm related appear when it is stopped.

Severity
--------
<Major: System/Feature is usable but degraded>

Steps to Reproduce
------------------

On compute and controller nodes:

$ ls /etc/pmon.d/neutron-l3-agent.conf
$ ls /etc/init.d/neutron-l3-agent
$ sudo systemctl status neutron-l3-agent
$ sudo systemctl stop neutron-l3-agent
$ fm alarm-list (only in controller)
$ sudo systemctl start neutron-l3-agent

Expected Behavior
------------------

'/etc/pmon.d/neutron-l3-agent.conf' file exists
'/etc/init.d/neutron-l3-agent' process exists
'neutron-l3-agent' process can be stop
Related alarm should appear
'neutron-l3-agent' can be started
'neutron-l3-agent' status should be displayed

Actual Behavior
----------------

'/etc/pmon.d/neutron-l3-agent.conf' file DOES NOT exist
'/etc/init.d/neutron-l3-agent' process DOES NOT exists
'neutron-l3-agent' process can be stop
Related alarm DOES NOT appear
'neutron-l3-agent' can be started only in computes, in controllers CANNOT

Reproducibility
---------------

100%

System Configuration
--------------------

Multinode Local Storage Virtual Environment

[Ghada Khalil (gkhalil)]

Neutron agents are only scheduled on compute nodes or all-in-one controller nodes. In this report, the configuration is multi-node, so the controllers will not have any neutron agents scheduled on them. So it's expected that there will not be any neutron-l3-agent processes on the controllers.

For the computes, what is the intent of this TC? Where did the TC steps come from?
Are you attempting to kill the process and see if an alarm is generated?

[Ghada Khalil (gkhalil)]

I got some more info...
The neutron-l3-agent process is not currently monitored by pmond. Therefore, it's expected that an alarm is not generated. I will follow up with Matt Peters (stx networking technical lead) on whether it should be added.

[Ghada Khalil (gkhalil)]

I changed the report title to better reflect the issue reported in this bug

[Ghada Khalil (gkhalil)]

Targeting stx.2019.03 - not gating for the October release as this is a very specific test-case related to killing a specific process. The process in question is not currently integrated with pmond, so the current behavior is expected.

[Juan Carlos Alonso (juancarlosa)]

Yes, the purpose of this test is kill the process and see if an alarm is generated. The corresponging test does not indicate the restrictions between configurations.

Based on your feedback need to update the test and wait until pmod can monitored neutron-l3-agent.

[Ghada Khalil (gkhalil)]

I reviewed this with Matt Peters and he said that within the current deployment this process should be monitored by pmond.

To implement this, the pmond registration can be added to neutron puppet manifest. The code must be added under this if-check to ensure it is only enabled when OVS is configured:
if $::platform::params::vswitch_type =~ '^ovs' {
File Reference: https://git.openstack.org/cgit/openstack/stx-config/tree/puppet-manifests/src/modules/openstack/manifests/neutron.pp#n230

The same file includes examples of other neutron processes registering with pmond that can be used as an example:
  file { "/etc/pmon.d/neutron-dhcp-agent.conf":
    ensure => $pmon_ensure,
    target => "/etc/neutron/pmon/neutron-dhcp-agent.conf",
    owner => 'root',
    group => 'root',
    mode => '0755',
  }

That being said, with the introduction of containerized openstack in stx.2019.03, the neutron agents (together with other openstack services) will run in containers and will no longer be monitored by pmon.d, so this work is throw-away.

Therefore, there is no plan to address this issue. Marking as Won't Fix.