<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
That also makes sense to me as the simplest option. Looking forward to all of your patches.
<div><br>
</div>
<div>Thanks,<br>
<div><br>
</div>
<div>Amir</div>
<div><br>
<div>
<div>On Jan 16, 2014, at 2:13 PM, Kyle Mestery <<a href="mailto:mestery@siliconloons.com">mestery@siliconloons.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<br>
On Jan 16, 2014, at 1:37 PM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
<br>
<blockquote type="cite">Hi Amir<br>
<br>
2014/1/16 Amir Sadoughi <<a href="mailto:amir.sadoughi@rackspace.com">amir.sadoughi@rackspace.com</a>>:<br>
<blockquote type="cite">Hi all,<br>
<br>
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.<br>
<br>
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?<br>
<br>
>From yesterday’s meeting: <<a href="http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-01-15-16.00.log.html">http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-01-15-16.00.log.html</a>><br>
<br>
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<br>
16:44:39 <rkukura> then the bound MD would return this as the vif_security for the port<br>
16:45:47 <rkukura> existing agents_db RPC would send it from agent to server and store it in the agents_db table<br>
<br>
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.<br>
</blockquote>
<br>
Let's say we have OpenFlowBasedFirewallDriver and<br>
IptablesBasedFirewallDriver in future.<br>
I believe there is no usecase to let user to select such<br>
implementation detail by host.<br>
so it is enough if we have a config security_group_mode=(openflow or<br>
iptables) in OVS MD configuration, then update vif_security based on<br>
this value.<br>
<br>
</blockquote>
I agree with your thinking here Nachi. Leaving this as a global<br>
configuration makes the most sense.<br>
<br>
<blockquote type="cite"><br>
<blockquote type="cite">Thanks,<br>
<br>
Amir<br>
<br>
<br>
On Jan 16, 2014, at 11:42 AM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
<br>
<blockquote type="cite">Hi Mathieu, Bob<br>
<br>
Thank you for your reply<br>
OK let's do (A) - (C) for now.<br>
<br>
(A) Remove firewall_driver from server side<br>
Remove Noop <-- I'll write patch for this<br>
<br>
(B) update ML2 with extend_port_dict <-- Bob will push new review for this<br>
<br>
(C) Fix vif_security patch using (1) and (2). <-- I'll update the<br>
patch after (A) and (B) merged<br>
# config is hardwired for each mech drivers for now<br>
<br>
(Optional D) Rething firewall_driver config in the agent<br>
<br>
<br>
<br>
<br>
<br>
2014/1/16 Robert Kukura <<a href="mailto:rkukura@redhat.com">rkukura@redhat.com</a>>:<br>
<blockquote type="cite">On 01/16/2014 04:43 AM, Mathieu Rohon wrote:<br>
<blockquote type="cite">Hi,<br>
<br>
your proposals make sense. Having the firewall driver configuring so<br>
much things looks pretty stange.<br>
</blockquote>
<br>
Agreed. I fully support proposed fix 1, adding enable_security_group<br>
config, at least for ml2. I'm not sure whether making this sort of<br>
change go the openvswitch or linuxbridge plugins at this stage is needed.<br>
<br>
<br>
<blockquote type="cite">Enabling security group should be a plugin/MD decision, not a driver decision.<br>
</blockquote>
<br>
I'm not so sure I support proposed fix 2, removing firewall_driver<br>
configuration. I think with proposed fix 1, firewall_driver becomes an<br>
agent-only configuration variable, which seems fine to me, at least for<br>
now. The people working on ovs-firewall-driver need something like this<br>
to choose the between their new driver and the iptables driver. Each L2<br>
agent could obviously revisit this later if needed.<br>
<br>
<blockquote type="cite"><br>
For ML2, in a first implementation, having vif security based on<br>
vif_type looks good too.<br>
</blockquote>
<br>
I'm not convinced to support proposed fix 3, basing ml2's vif_security<br>
on the value of vif_type. It seems to me that if vif_type was all that<br>
determines how nova handles security groups, there would be no need for<br>
either the old capabilities or new vif_security port attribute.<br>
<br>
I think each ML2 bound MechanismDriver should be able to supply whatever<br>
vif_security (or capabilities) value it needs. It should be free to<br>
determine that however it wants. It could be made configurable on the<br>
server-side as Mathieu suggest below, or could be kept configurable in<br>
the L2 agent and transmitted via agents_db RPC to the MechanismDriver in<br>
the server as I have previously suggested.<br>
<br>
As an initial step, until we really have multiple firewall drivers to<br>
choose from, I think we can just hardwire each agent-based<br>
MechanismDriver to return the correct vif_security value for its normal<br>
firewall driver, as we currently do for the capabilities attribute.<br>
<br>
Also note that I really like the extend_port_dict() MechanismDriver<br>
methods in Nachi's current patch set. This is a much nicer way for the<br>
bound MechanismDriver to return binding-specific attributes than what<br>
ml2 currently does for vif_type and capabilities. I'm working on a patch<br>
taking that part of Nachi's code, fixing a few things, and extending it<br>
to handle the vif_type attribute as well as the current capabilities<br>
attribute. I'm hoping to post at least a WIP version of this today.<br>
<br>
I do support hardwiring the other plugins to return specific<br>
vif_security values, but those values may need to depend on the value of<br>
enable_security_group from proposal 1.<br>
<br>
-Bob<br>
<br>
<blockquote type="cite">Once OVSfirewallDriver will be available, the firewall drivers that<br>
the operator wants to use should be in a MD config file/section and<br>
ovs MD could bind one of the firewall driver during<br>
port_create/update/get.<br>
<br>
Best,<br>
Mathieu<br>
<br>
On Wed, Jan 15, 2014 at 6:29 PM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
<blockquote type="cite">Hi folks<br>
<br>
Security group for OVS agent (ovs plugin or ML2) is being broken.<br>
so we need vif_security port binding to fix this<br>
(<a href="https://review.openstack.org/#/c/21946/">https://review.openstack.org/#/c/21946/</a>)<br>
<br>
We got discussed about the architecture for ML2 on ML2 weekly meetings, and<br>
I wanna continue discussion in here.<br>
<br>
Here is my proposal for how to fix it.<br>
<br>
<a href="https://docs.google.com/presentation/d/1ktF7NOFY_0cBAhfqE4XjxVG9yyl88RU_w9JcNiOukzI/edit#slide=id.p">https://docs.google.com/presentation/d/1ktF7NOFY_0cBAhfqE4XjxVG9yyl88RU_w9JcNiOukzI/edit#slide=id.p</a><br>
<br>
Best<br>
Nachi<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>