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

Bug #1799590 reported by Juan Carlos Alonso on 2018-10-23
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
StarlingX
Medium
Ghada Khalil

Bug Description

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) wrote :

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?

tags: added: stx.net
tags: added: stx.networking
removed: stx.net
Changed in starlingx:
status: New → Incomplete
Ghada Khalil (gkhalil) wrote :

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.

summary: - Process 'neutron-l3-agent' does not work
+ Process 'neutron-l3-agent' is not monitored by pmon
Ghada Khalil (gkhalil) wrote :

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

Ghada Khalil (gkhalil) wrote :

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.

Changed in starlingx:
status: Incomplete → Triaged
importance: Undecided → Low
tags: added: stx.2019.03
Ghada Khalil (gkhalil) on 2018-10-24
Changed in starlingx:
importance: Low → Medium

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) wrote :

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.

Changed in starlingx:
assignee: nobody → Ghada Khalil (gkhalil)
status: Triaged → Won't Fix
Ken Young (kenyis) on 2019-01-18
tags: added: stx.2019.05
removed: stx.2019.03
Ken Young (kenyis) on 2019-04-05
tags: added: stx.2.0
removed: stx.2019.05
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers