Open Stack

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

(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

(Optional D) Rething firewall_driver config in the agent





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
>