Agent startup's messages not seen

[alonsocamaro]

• Title: Agent startup's messages not seen

  Agent Version

f5-openstack-agent (9.0.1)

root@node-2:/var/log# grep -i debug /etc/neutron/services/f5/f5-openstack-agent.ini
# Show debugging output in log (sets DEBUG log level output).
debug = True

Operating System

Mirantis 9.0 / Ubuntu 14.04.4 LTS

OpenStack Release

Mitaka

Description

After installing the agent. I did a service start of the agent but no diagnostic message was being shown neither positive or negative. After checking with ps it seemed no new process was created in the controller.

I had to strace it to find out what was happening:

19548 write(2, "ImportError", 11)       = 11
19548 write(2, ": ", 2)                 = 2
19548 write(2, "No module named neutron_lbaas.services.loadbalancer", 51) = 51
19548 write(2, "\n", 1)                 = 1
19548 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f4bdff75330}, {0x45a0f5, [], SA_RESTORER, 0x7f4bdff75330}, 8) = 0
19548 exit_group(1)                     = ?
19548 +++ exited with 1 +++

Doing a grep on /var/log/ and /var/log//* didn't show the above error message.

OpenStack Release

Mitaka

Description

Log the messages to somewhere appropriate.

[richbrowne]

Hi Alonso,

Thanks for your issue report. It looks like you are missing a dependency. The agent is trying to import the constants from neutron_lbaas; however, they do not exist. If you are not installing the agent on the neutron controller, you will need to install this also.

[jputrino]

@alonsocamaro The instructions for installing the service provider package from neutron_lbaas are here: http://lbaasv2-test.readthedocs.io/en/release-8.0.6/map_quick-start-guide.html#install-the-f5-service-provider-package

[alonsocamaro]

Thanks Rich! I will give another try.

[mattgreene]

@alonsocamaro, was this issue resolved via the link to the installation instructions or are you still having problems? If not, can we close this issue?

[alonsocamaro]

Hi Matt

The issue I reported is not about not being able to install it yet I was having problems.

What I wanted to report here is that when agent initialization fails no logs are generated and I had to use strace (which customers should not expected to use) to figure out what was going on.

I would not say this is a high severity or high priority but instead a usability enhancement: I think that all the messages that are currently sent to stderr should be logged with the appropriate logging priority. ie: fatal errors like the one show above should logged with "error" priority

Regards

  Ulises

[mattgreene]

Agreed. We do see logs on CentOS, so perhaps something has been broken on Ubuntu. We'll treat this as a bug and triage, but I'll lower the priority one notch since you were able to complete installation.

[ssorenso]

Team,

I see this in two parts:

• The init.d script not following CSB standards as per a bug following that
  • The init.d script should be doing something to check and/or validate the proper installation status of all dependencies
  • And/or the installation process should outline all dependencies prior to allowing installation
• The agent application, when run on its own, results in an unhandled exception that results in a panic that dumps into a CLI traceback
  • This is 'okay' if debug mode has been set in the .ini file as it provides the necessary information for folks to troubleshoot the issue
  • This is not 'okay' if the debug mode is not enabled in the .ini file as it should be a clean exit as per the customer's settings
  • In both cases, a /var/log, logged message should be created to assist in troubleshooting at any level or setting

As such, in this fix, I propose to...

• Catch the import errors in the agent.py
• Handle the exception by creating an intelligent exception class, object instance that is application-owned
  • Class will handle pre-Oslo logging as well as provide suggested next steps to users
• This will handle the graceful logging of the issue
  • Even if Oslo's logger instance does not yet exist or is not yet installed
  • Produce a traceback in the CLI if appropriate with the debug setting being true in the .ini file
• The agent.py executable will then gracefully exit with errno.ENOSYS
• In the even that the Oslo logging instance is created and does exist, then Oslo logging will handle the issue as it does for any other exception
  • In addition to this as it is an installation error, it will provide the fact that there are missing dependencies
• As installation processes are liable to change, and that code changes take an additional process, all suggestions will be brief to the fact of things being missing and that they should be installed

With the changes in this bug's sister bug, we should be able to handle the situation where the customer does not have the proper dependencies installed at multiple levels to hopefully keeping from user confusion.

Please let me know if this does not satisfy this bug's indicated problem statement.

[dflanigan]

This issue was not reference in the merge.