Open Stack

On 01/16/2014 03:13 PM, Kyle Mestery wrote:
> 
> On Jan 16, 2014, at 1:37 PM, Nachi Ueno <nachi at ntti3.com> wrote:
> 
>> Hi Amir
>>
>> 2014/1/16 Amir Sadoughi <amir.sadoughi at rackspace.com>:
>>> Hi all,
>>>
>>> I just want to make sure I understand the plan and its consequences. I’m on board with the YAGNI principle of hardwiring mechanism drivers to return their firewall_driver types for now.
>>>
>>> However, after (A), (B), and (C) are completed, to allow for Open vSwitch-based security groups (blueprint ovs-firewall-driver) is it correct to say: we’ll need to implement a method such that the ML2 mechanism driver is aware of its agents and each of the agents' configured firewall_driver? i.e. additional RPC communication?
>>>
>>> From yesterday’s meeting: <http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-01-15-16.00.log.html>
>>>
>>> 16:44:17 <rkukura> I've suggested that the L2 agent could get the vif_security info from its firewall_driver, and include this in its agents_db info
>>> 16:44:39 <rkukura> then the bound MD would return this as the vif_security for the port
>>> 16:45:47 <rkukura> existing agents_db RPC would send it from agent to server and store it in the agents_db table
>>>
>>> Does the above suggestion change with the plan as-is now? From Nachi’s response, it seemed like maybe we should support concurrent firewall_driver instances in a single agent. i.e. don’t statically configure firewall_driver in the agent, but let the MD choose the firewall_driver for the port based on what firewall_drivers the agent supports.

I don't see the need for anything that complex, although it could
certainly be done in any MD+agent that needed it.

I personally feel statically configuring a firewall driver for an L2
agent is sufficient right now, and all ports handled by that agent will
use that firewall driver.

Clearly, different kinds of L2 agents that coexist within a deployment
may use different firewall drivers. For example, linuxbridge-agent might
use iptables-firewall-driver, openvswitch-agent might use
ovs-firewall-driver, and hyperv-agent might use something else.

I can also imagine cases where different instances of the same kind of
L2 agent on different nodes might use different firewall drivers. Just
as a hypothetical example, lets say that the ovs-firewall-driver
requires new OVS features (maybe connection tracking). A deployment
might have this new OVS feature available on some if its nodes, but not
on others. It could be useful to configure openvswitch-agent on the
nodes with the new OVS version to use ovs-firewall-driver, and configure
openvswitch-agent on the nodes without the new OVS version to use
iptables-firewall-driver. That kind of flexibility seems best supported
by simply configuring the firewall driver in /ovs_neutron_plugin.ini on
each node, which is what we currently do.

>>
>> Let's say we have OpenFlowBasedFirewallDriver and
>> IptablesBasedFirewallDriver in future.
>> I believe there is no usecase to let user to select such
>> implementation detail by host.

I suggest a hypothetical use case above. Not sure how important it is,
but I'm hesitant to rule it out without good reason.

>> so it is enough if we have a config security_group_mode=(openflow or
>> iptables) in OVS MD configuration, then update vif_security based on
>> this value.

This is certainly one way the MD+agent combination could do it. It would
require some RPC to transmit the choice of driver or mode to the agent.
But I really don't think the MD and server have any business worrying
about which firewall driver class runs in the L2 agent. Theoretically,
the agent could be written in java;-). And don't forget that users may
want to plug in a custom firewall driver class instead.

I think these are the options, in my descending or of current preference:

1) Configure firewall_driver only in the agent and pass vif_security
from the agent to the server. Each L2 agent gets the vif_security value
from its configured driver and includes it in the agents_db RPC data.
The MD copies the vif_security value from the agents_db to the port
dictionary.

2) Configure firewall_driver only in the agent but the hardwire
vif_security value for each MD. This is a reasonable short term solution
until we actually have multiple firewall drivers that can work with
single MD+agent.

3) Configure firewall_driver only in the agent and configure the
vif_security value for each MD in the server. This is a slight
improvement on #2 but doesn't handle the use case above. It seems more
complicated and error prone for the user than #1.

4) Configure the firewall_driver or security_group_mode for each MD in
the server. This would mean some new RPC is needed to for the agent to
fetch the fthis from the server at startup. This could be problematic if
the server isn't running when the L2 agent starts.

>>
> I agree with your thinking here Nachi. Leaving this as a global
> configuration makes the most sense.
> 
>>
>>> Thanks,
>>>
>>> Amir
>>>
>>>
>>> On Jan 16, 2014, at 11:42 AM, Nachi Ueno <nachi at ntti3.com> wrote:
>>>
>>>> Hi Mathieu, Bob
>>>>
>>>> Thank you for your reply
>>>> OK let's do (A) - (C) for now.
>>>>
>>>> (A) Remove firewall_driver from server side
>>>>    Remove Noop <-- I'll write patch for this

This gets replaced with the enable_security_groups server config, right?

>>>>
>>>> (B) update ML2 with extend_port_dict <-- Bob will push new review for this
>>>>
>>>> (C) Fix vif_security patch using (1) and (2). <-- I'll update the
>>>> patch after (A) and (B) merged
>>>>    # config is hardwired for each mech drivers for now

I completely agree with doing A, B, and C now. My understanding is that
this is equivalent to my option 2 above.

>>>>
>>>> (Optional D) Rething firewall_driver config in the agent

See above for my current view on that. But a decision on D can be
deferred for now, at least until we have a choice of firewall drivers.

-Bob


>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2014/1/16 Robert Kukura <rkukura at redhat.com>:
>>>>> On 01/16/2014 04:43 AM, Mathieu Rohon wrote:
>>>>>> Hi,
>>>>>>
>>>>>> your proposals make sense. Having the firewall driver configuring so
>>>>>> much things looks pretty stange.
>>>>>
>>>>> Agreed. I fully support proposed fix 1, adding enable_security_group
>>>>> config, at least for ml2. I'm not sure whether making this sort of
>>>>> change go the openvswitch or linuxbridge plugins at this stage is needed.
>>>>>
>>>>>
>>>>>> Enabling security group should be a plugin/MD decision, not a driver decision.
>>>>>
>>>>> I'm not so sure I support proposed fix 2, removing firewall_driver
>>>>> configuration. I think with proposed fix 1, firewall_driver becomes an
>>>>> agent-only configuration variable, which seems fine to me, at least for
>>>>> now. The people working on ovs-firewall-driver need something like this
>>>>> to choose the between their new driver and the iptables driver. Each L2
>>>>> agent could obviously revisit this later if needed.
>>>>>
>>>>>>
>>>>>> For ML2, in a first implementation, having vif security based on
>>>>>> vif_type looks good too.
>>>>>
>>>>> I'm not convinced to support proposed fix 3, basing ml2's vif_security
>>>>> on the value of vif_type. It seems to me that if vif_type was all that
>>>>> determines how nova handles security groups, there would be no need for
>>>>> either the old capabilities or new vif_security port attribute.
>>>>>
>>>>> I think each ML2 bound MechanismDriver should be able to supply whatever
>>>>> vif_security (or capabilities) value it needs. It should be free to
>>>>> determine that however it wants. It could be made configurable on the
>>>>> server-side as Mathieu suggest below, or could be kept configurable in
>>>>> the L2 agent and transmitted via agents_db RPC to the MechanismDriver in
>>>>> the server as I have previously suggested.
>>>>>
>>>>> As an initial step, until we really have multiple firewall drivers to
>>>>> choose from, I think we can just hardwire each agent-based
>>>>> MechanismDriver to return the correct vif_security value for its normal
>>>>> firewall driver, as we currently do for the capabilities attribute.
>>>>>
>>>>> Also note that I really like the extend_port_dict() MechanismDriver
>>>>> methods in Nachi's current patch set. This is a much nicer way for the
>>>>> bound MechanismDriver to return binding-specific attributes than what
>>>>> ml2 currently does for vif_type and capabilities. I'm working on a patch
>>>>> taking that part of Nachi's code, fixing a few things, and extending it
>>>>> to handle the vif_type attribute as well as the current capabilities
>>>>> attribute. I'm hoping to post at least a WIP version of this today.
>>>>>
>>>>> I do support hardwiring the other plugins to return specific
>>>>> vif_security values, but those values may need to depend on the value of
>>>>> enable_security_group from proposal 1.
>>>>>
>>>>> -Bob
>>>>>
>>>>>> Once OVSfirewallDriver will be available, the firewall drivers that
>>>>>> the operator wants to use should be in a MD config file/section and
>>>>>> ovs MD could bind one of the firewall driver during
>>>>>> port_create/update/get.
>>>>>>
>>>>>> Best,
>>>>>> Mathieu
>>>>>>
>>>>>> On Wed, Jan 15, 2014 at 6:29 PM, Nachi Ueno <nachi at ntti3.com> wrote:
>>>>>>> Hi folks
>>>>>>>
>>>>>>> Security group for OVS agent (ovs plugin or ML2) is being broken.
>>>>>>> so we need vif_security port binding to fix this
>>>>>>> (https://review.openstack.org/#/c/21946/)
>>>>>>>
>>>>>>> We got discussed about the architecture for ML2 on ML2 weekly meetings, and
>>>>>>> I wanna continue discussion in here.
>>>>>>>
>>>>>>> Here is my proposal for how to fix it.
>>>>>>>
>>>>>>> https://docs.google.com/presentation/d/1ktF7NOFY_0cBAhfqE4XjxVG9yyl88RU_w9JcNiOukzI/edit#slide=id.p
>>>>>>>
>>>>>>> Best
>>>>>>> Nachi
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>