Hi On Thu, Jan 16, 2014 at 11:27 PM, Nachi Ueno <na...@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 <rkuk...@redhat.com>: >> On 01/16/2014 03:13 PM, Kyle Mestery wrote: >>> >>> On Jan 16, 2014, at 1:37 PM, Nachi Ueno <na...@ntti3.com> wrote: >>> >>>> Hi Amir >>>> >>>> 2014/1/16 Amir Sadoughi <amir.sadou...@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 <na...@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 <rkuk...@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 <na...@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@lists.openstack.org >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-dev mailing list >>>>>> OpenStack-dev@lists.openstack.org >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> OpenStack-dev@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev