unable to get lists from VPNaaS after upgrade to Mitaka

[Tejeev Patel]

We recently upgraded a customer cloud from Liberty to Mitaka (they are running trusty) and it appears to have broken the communication between the dashboard and the neutron-vpn information. Possibly a change in the way the records are stored in the database since it seems to affect Horizon's ability to list and manipulate pre upgrade vpns?

In Dashboard, when loading the Project > NETWORK > VPN page, we get an "Error: Unabel to retrieve VPN Services list."

Customer can edit the new created policy but can not get teh older policy information prior to upgrades.

I see that the vpn agents are running on neutron-gateways and the horizon config is set to include the tab. The vpn agent is however returning the following timeout traceback: https://pastebin.ubuntu.com/p/rCTSYDPpv9/

Generally trying to load VPNaaS dashboard page did not generate any log entries though it did generate the same error the customer reported.

I've restarted the neutron-vpn-agent services one at a time on each of the boxes but still getting the error.

I did find this warning in vpn-agent logs noting they couldn't find a router but not sure it's related as more were not generated:
https://pastebin.ubuntu.com/p/YSw2wN3MGz/

I found that the neutron cli is able to get the vpn-service-list (https://pastebin.ubuntu.com/p/FF2d9ydHXV/) but horizon still can't. I believe horizon can not communicate with the vpn-agent api but the neutron cli can.

[Akihiro Motoki (amotoki)]

neutron-vpnaas-dashboard was split out from horizon in Pike, so there is no mitaka or liberty release of neutron-vpnaas-dashboard. As of Mitaka, VPN panel was provided as part of horizon.
I wonder why neutron-vpnaas-dashboard is related to Mitaka or Liberty release.
From this reason, I mark this bug as Invalid in neutron-vpnaas-dashboard.

[Akihiro Motoki (amotoki)]

Apart from neutron-vpnaas-dashboard vs horizon, horizon does not communicate with neutron-vpn-agent directly. horizon just communicates with neutron server (i.e., neutron API), so you need to split your problem into two parts: horizon -> neutron API, and neutron API -> neutron-vpn-agent.

In your environment, neutron CLI can communicate with neutron server, so it seems neutron-vpnaas is enabled. horizon use the same interface to communicate with neutron server, so it should work in general.

You can enable more detail logging in horizon to log communication between horizon and neutron server.
You can configure local_settings.py:

LOGGING = {
    'version': 1,
    # When set to True this will disable all logging except
    # for loggers specified in this configuration dictionary. Note that
    # if nothing is specified here and disable_existing_loggers is True,
    # django.db.backends will still log unless it is disabled explicitly.
    'disable_existing_loggers': False,
    'handlers': {
        'null': {
            'level': 'DEBUG',
            'class': 'logging.NullHandler',
        },
        'console': {
            'level': 'DEUBG', <-------------------------
            'class': 'logging.StreamHandler',
        },
    },
    'loggers': {
      ....
        'neutronclient': {
            'handlers': ['console'],
            'level': 'DEBUG', <------------
            'propagate': False,
        },

[Tejeev Patel (tejeevpatel)]

I've pulled this from an engineer's notes and replaced some of the info with --- to protect the customer but as the engineer said:
"Those NULLs correlate with the subnet_id field. The message is that NoneType has no 'cidr' field - the subnet object has a 'cidr' field. So, it's trying to resolve the subnet and falling over.

Subnet is a required field in VPNaaS, and not having one assigned is likely the issue. The next question is which OpenStack network these VPNs should be attached to, which we'll ask the customer."

These VPNs were apparently functional before upgrades if I understand the customer correctly.

INSERT INTO `vpnservices` VALUES ('---','---','---','','ACTIVE',1,NULL,'---','---',NULL);

Hopefully this helps.

[James Page (james-page)]

Just a headsup - trusty retained openswan however it was dropped in utopic so Xenial/Mitaka or later based deployments don't feature VPNaaS support.

[James Page (james-page)]

Focussing this on the dashboard charm for now.

Please can you:

  juju config openstack-dashboard debug=true

and then reproduce the problem and append the logs from /var/log/apache2 to this bug report.

Marking 'Incomplete' and 'Low' for now.

[Launchpad Janitor (janitor)]

[Expired for OpenStack openstack-dashboard charm because there has been no activity for 60 days.]