ovs mech_driver depends on neutron server firewall_driver option instead of the agent firewall_driver option to determine if hybrid plug can be used

[Andreas Scheuring]

The ovs mechanism driver determins if hybrid plug should be used along the firewall_driver [1] setting that is made on the neutron server [2].

        IPTABLES_FW_DRIVER_FULL = ("neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver")
        hybrid_plug_required = (cfg.CONF.SECURITYGROUP.firewall_driver in (IPTABLES_FW_DRIVER_FULL, 'iptables_hybrid'))

--> Only if the cfg.CONF.SECURITYGROUP.firewall_driver option is configure to be hybrid, hybrid plug is enabled.

Let's assume you have a cloud, with a few nodes running lb and some other running ovs l2 agent.
- neutron server: firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver (for lb)
- cpu node1: neutron-lb-agt: firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver (for lb)
- cpu node 2: neutron -ovs-agt: firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver (for ovs)

Expected behavior
==============
ovs agent uses hybrid plug, as it is configured in its configuration

Actual result
==========

You'll never get a hybrid plug, as the neutron server does only consider its own fw_driver option instead of the agent option
--> No Security Groups

I see two approaches that can be discussed
=================================

#1 allow listing of multiple fw drivers in the neutron server configuration file

#2 Determine the hybrid_plug_required variable along the fw_driver configured in the l2 agent (agent can report this to the sever as part of its regular state report and mech_driver can use this information to set hybrid plug option correctly when port_binding is requested)

[1] http://docs.openstack.org/liberty/config-reference/content/networking-options-securitygroups.html
[2] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#L49

[Rossella Sblendido (rossella-o)]

Thanks Andreas for filing this.. #2 is more complex, requires more code and it's probably an overkill.
#1 looks better....even if we actually only need to know which firewall the ovs agent is using. How about adding a conf value for the ovs mech driver and check that in the code instead of the global firewall driver ? That seems more straightforward...

[Miguel Angel Ajo (mangelajo)]

I agree #1 seems more reasonable, we'd allow mixing LB / OVS, but not OVS hybrid with OVS non hybrid..

[Jakub Libosvar (libosvar)]

I talked about this with several people already. With ovs-firewall driver in place you can also have multiple ovs-agents while some of them require hybrid plug and some not.

I don't get #1 approach much, does it mean having mapping like hostname:driver type. Honestly I like approach No. 2 way better and I planned to implement something like that. It would be just adding hybrid_plugging or vif_details to agent configuration payload and then using this information at get_vif_details: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py

Approach #2 won't require manually keeping configurations consistent between server and agents.

[Jakub Libosvar (libosvar)]

This is the link I wanted to send: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#L87

[Andreas Scheuring (andreas-scheuring)]

@Jakub: Exactly this was my intention with approach #2
@Rossella: I agree with your statement, that #1 is less effort. So what you're proposing is this:

[security_group]
firewall_driver = blabla

[ovs] or [ovs-mech]
firewall_driver = hybrid...

However I see Jakubs concerns of keeping this option in sync cross all agents.

My proposal was more to rename:
firewall_driver to
firewall_drivers = blabla, hybrid...
and then check if the hybrid driver is listed in fw_drivers. Not sure if that makes sense...

On the other hand, the cloud administrator proabalby wants a single point for "enforcing" security groups via the firewall_driver. Maybe the agents should get this configuration from the server instead of having their own option - not sure.

[Rossella Sblendido (rossella-o)]

@Andreas, yes that was my proposal, you summarized it perfectly.

@Jakub I understand your concern...

pros of your approach #2
* no need to introduce a new entry in the config file
* being able to have ovs agents that use different firewall drivers

cons of approach #2
* more data will be passed in the RPC call...that has a cost too
* bigger change

The requirement of having all the ovs agent use the same firewall doesn't seem to be a big deal. That's what most automation tools do anyway. Well I am still in favour of #1

[Andreas Scheuring (andreas-scheuring)]

if we go that way, what is the purpose of the security group section? Should it get deprecated in favor of type driver specific options?

[Miguel Angel Ajo (mangelajo)]

I think the extra data passed in RPC is not a big thing, it can be done in the periodic updates, and no other calls.

The usability part Jakub mentions in favor of "#2" (no need to replicate that confing around anymore) convinces me, I really believe it shouldn't be necessary to support hybrid / non hybrid cloud mixes (it's good for testing / benchmarking anyway), but if it's a side effect of making configuration easier, then +1 from me.

[Andreas Scheuring (andreas-scheuring)]

After some discussion at the summit, I personally would rather tackle the approach, where we have the fw driver defined per agent. Cause this would allow having a cloud with some nodes using ovs-hybrid-fw and some brand new ovs-fw driver.

An easy approach would be to make the agent defined fw driver an attribute of the agent status report. On portbinding, the mech driver could use the agent information to determine if hybrid plug should be used or not. A variant of that could be, that this field is only reported on agent start, and then stored somehwhere in the server...

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/311814
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=2f17a30ba04082889f3a703aca1884b031767942
Submitter: Jenkins
Branch: master

commit 2f17a30ba04082889f3a703aca1884b031767942
Author: Kevin Benton <email address hidden>
Date: Fri Apr 29 18:01:51 2016 -0700

    OVS Mech: Set hybrid plug based on agent config

    This adjusts the logic in the OVS mechanism driver to determine
    what the ovs_hybrid_plug value should be set to in the VIF details.
    Previously it was based purely on the firewall driver configured on
    the server side. This prevented a mixed environment where some agents
    might be running a native OVS firewall driver while others are still
    based on the IPTables hybrid driver.

    This patch has the OVS agents report back whether they want hybrid
    plugging in their configuration dictionary sent during report_state.
    The OVS agent sets this based on an explicit attribute on the firewall
    driver requesting OVS hybrid plugging.

    To maintain backward compat, if an agent doesn't report this, the old
    logic of basing it off of the server-side config is applied.

    DocImpact: The server no longer needs to be configured with a firewall
               driver for OVS. It will read config from agent state reports.
    Closes-Bug: #1560957
    Change-Id: Ie554c2d37ce036e7b51818048153b466eee02913

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/neutron 9.0.0.0b1 development milestone.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/327996

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/327996
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=7a969d4b0a5ae902695b3204a858305b5122c5ff
Submitter: Jenkins
Branch: stable/mitaka

commit 7a969d4b0a5ae902695b3204a858305b5122c5ff
Author: Kevin Benton <email address hidden>
Date: Fri Apr 29 18:01:51 2016 -0700

    OVS Mech: Set hybrid plug based on agent config

    This adjusts the logic in the OVS mechanism driver to determine
    what the ovs_hybrid_plug value should be set to in the VIF details.
    Previously it was based purely on the firewall driver configured on
    the server side. This prevented a mixed environment where some agents
    might be running a native OVS firewall driver while others are still
    based on the IPTables hybrid driver.

    This patch has the OVS agents report back whether they want hybrid
    plugging in their configuration dictionary sent during report_state.
    The OVS agent sets this based on an explicit attribute on the firewall
    driver requesting OVS hybrid plugging.

    To maintain backward compat, if an agent doesn't report this, the old
    logic of basing it off of the server-side config is applied.

    DocImpact: The server no longer needs to be configured with a firewall
               driver for OVS. It will read config from agent state reports.
    Closes-Bug: #1560957
    Change-Id: Ie554c2d37ce036e7b51818048153b466eee02913
    (cherry picked from commit 2f17a30ba04082889f3a703aca1884b031767942)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 8.3.0 release.