neutron: use --config-dir for L3/VPN agent

[Ihar Hrachyshka]

Since Kilo, neutron has split its advanced services into separate repositories that are now not guaranteed to be installed (including configuration files like fwaas_driver.ini or vpn_agent.ini). For devstack, we dynamically generate list of cli arguments to start l3/vpn agent based on which services are enabled in local.conf. This approach is not applicable for distributions though that usually ship a service manifest with the list of cli arguments hardcoded. Since now we cannot assume fwaas_driver.ini or other configuration files that may be read by L3 agent are present on the system, we should be more flexible.

oslo.config allows to use --config-dir argument instead of --config-file arguments, and populate the directory on demand, based on which packages are installed in the system.

Though devstack is strictly not affected by the problem, we should lead by example and adopt unified --config-dir argument to pass l3 agent configuration via CLI. Distributions are free to adopt the approach on their own schedule.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/163773

[Armando Migliaccio (armando-migliaccio)]

Not sure I understand why this fix is needed at all. If it's fair to assume that Neutron services can understand the config-dir option, why are we polluting grenade/devstack with something that is ultimately a deployment issue that depends on how a distro or a packager decides to install and run services?

[OpenStack Infra (hudson-openstack)]

Change abandoned by Ihar Hrachyshka (<email address hidden>) on branch: master
Review: https://review.openstack.org/163773
Reason: As per discussion, it does not belong to upstream. For those interested, RDO handles the issue as in [1] and [2].

[1]: https://github.com/openstack-packages/neutron/blob/f20-master/openstack-neutron.spec#L602
[2]: https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/openstack-neutron-vpnaas.spec#L97

[OpenStack Infra (hudson-openstack)]

Change abandoned by Ihar Hrachyshka (<email address hidden>) on branch: master
Review: https://review.openstack.org/163490
Reason: As per discussion, it does not belong to upstream. For those interested, RDO handles the issue as in [1] and [2].

[1]: https://github.com/openstack-packages/neutron/blob/f20-master/openstack-neutron.spec#L602
[2]: https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/openstack-neutron-vpnaas.spec#L97

[Armando Migliaccio (armando-migliaccio)]

This is become relevant in light of bug #1490990. I wonder if we can just pass simply --config-dir=/etc/neutron (without too much specialization) to the neutron commands. What would be the implications?

[Ihar Hrachyshka (ihar-hrachyshka)]

Passing --config-dir /etc/neutron would mean that e.g. neutron-server loads config values from e.g. dhcp_agent.ini, which is wrong. It's not just theoretically wrong, some services may use contradictory values for the same settings. F.e. sr-iov agent sets firewall to noop, while ovs agent that may be running on the same node to serve non sr-iov ports needs proper firewall.

Config-dirs are useful when you have in that dir only those files that apply to the service.

[Armando Migliaccio (armando-migliaccio)]

I thought about it, but wouldn't this be loaded only if the opts are actively registered?

[Ihar Hrachyshka (ihar-hrachyshka)]

Yes, sure, other options are ignored. The problem is that both sr-iov and ovs agents register and use the same firewall_driver option, they only need different values.

Or e.g. report intervals, they may be different for different agents. Or even host =, there may be use cases to use different host names for agents on the same node... I believe the less magic we use, the more explicit we are about which configuration is exposed to a service, the better.

[Armando Migliaccio (armando-migliaccio)]

Yes, I can see that this can be fishy. Let's leave it alone.

[Armando Migliaccio (armando-migliaccio)]

This bug is > 240 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

[Armando Migliaccio (armando-migliaccio)]

Isn't https://review.openstack.org/#/c/342048/ going to make this tricky?

[Armando Migliaccio (armando-migliaccio)]

Isn't this the reason why we ultimately chose not to adopt config-dir? It's slowly coming back to me...

[Ihar Hrachyshka (ihar-hrachyshka)]

It's up to deployment tool or packaging how to store and pass options to services. Devstack may build multiple --config-file options to pass to neutron-server; while distributions may go with a more dynamic approach, maintaining specific config-dirs per service, and loading everything inside with --config-dir (like RDO does). It is of no neutron business to enforce a specific model, or implement any of those approaches for distributions and even devstack. We will obviously need to make sure devstack is adopting one of those approaches, and there are already patches for that from YAMAMOTO (https://review.openstack.org/#/c/342493/), but it's not correct to track that kind of adoption as a neutron bug.