Open Stack

Hi

On Thu, Jan 16, 2014 at 11:27 PM, Nachi Ueno <nachi at ntti3.com> wrote:
> Hi Bob, Kyle
>
> I pushed (A) https://review.openstack.org/#/c/67281/.
> so could you review it?
>
> 2014/1/16 Robert Kukura <rkukura at redhat.com>:
>> 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.
>
> Our community resource is limited, so we should focus on some usecase and
> functionalities.
> If there is no strong supporter for this usecase, we shouldn't do it.
> We should take simplest implementation for our focused usecase.
>
>>>> 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.
>
> Let's discuss more when you could have openflow based security group
> implementation.
>
> This is my thought for general architecture.
> - We should be able to manage such agent network behavior via Agent
> Resource REST API in the server.
> - The server should control agents,
> - Agents should have only rpc connection information.
>
> so I'm +1 for option4. Agent can't work without server anyway, and he
> can wait until it will be connected with servers.

I agree with this general architecture, but we still need some local
settings for the agent, such as local bridge_mappings and local_ip. I
don't know how this informations could be stored on the server side.

IMHO the main issue here and for a lot of bugs in neutron (I'm
thinking about pooling issues in the agent) comes from the fact that
port creation is delegated to nova. I think that neutron should be
able to create tap interfaces thanks to a mandatory l2-agent. This
agent would be responsible for creating nwfilters used by libvirt for
mac/ip anti spoofing, for creating bridges/flow s/iptables chains and
whatever the tap needs to get connected correctly.

So with option 4 described above, the new RPC message to the selected
agent would be create_port([port_dict_extended_by_MD]), and the
firewall driver would get instantiated depending on arguments of
create port. get_device_details wouldn't be necessary anymore.

With such an architecture, we wouldn't have to tell neutron about
vif_security or vif_type when it creates a port. When Neutron get
called with port_create, it should only return the tap created.

I don't know if such a proposal is reasonable since I can't find good
informations about the ability of libvirt to use an already created
tap, when it creates a VM. It seem to be usable with KVM.
But I would love to have feedback of the communnity on this
architecture. May be it has already been discussed on the ML, so
please give me the pointer.

Bests,
Mathieu

>
>>>>
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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