<div>
<br>
</div>
<div><div><br></div><div><span style="font-size: 10pt;">Miguel Ángel Ajo</span></div><div><br></div></div>
<p style="color: #A0A0A8;">On Wednesday, 18 de February de 2015 at 08:14, yamamoto@valinux.co.jp wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>hi,</div><div><br></div><blockquote type="cite"><div><div>On Wednesday, 18 de February de 2015 at 07:00, <a href="mailto:yamamoto@valinux.co.jp">yamamoto@valinux.co.jp</a> wrote:</div><blockquote type="cite"><div><div>hi,</div><div> </div><div>i want to add an extra requirement specific to OVS-agent.</div><div>(namely, I want to add ryu for ovs-ofctl-to-python blueprint. [1]</div><div>but the question is not specific to the blueprint.)</div><div>to avoid messing deployments without OVS-agent, such a requirement</div><div>should be per-agent/driver/plugin/etc. however, there currently</div><div>seems no standard mechanism for such a requirement.</div><div> </div><div> </div></div></blockquote><div><br></div><div><br></div><div>Awesome, I was thinking of the same a few days ago, we make lots</div><div>and lots of calls to ovs-ofctl, and we will do more if we change to</div><div>security groups/routers in OF, if that proves to be efficient, and we</div><div>get CT.</div></div></blockquote><div><br></div><div>CT?</div></div></div></span></blockquote><div><br></div><div><span style="font-size: 14px;">Connection tracking in OVS. At that point we could do NAT/stateful</span></div><div><span style="font-size: 14px;">firewalling, etc</span> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><blockquote type="cite"><div><div><br></div><div>After this change, what would be the differences of ofagent to ovs-agent ? </div><div><br></div><div>I guess OVS set’s rules in advance, while ofagent works as a normal</div><div>OF controller?</div></div></blockquote><div><br></div><div>the basic architecture will be same.</div><div><br></div><div>actually it was suggested to merge two agents during spec review.</div><div>i think it's a good idea for longer term. (but unlikely for kilo)</div></div></div></span></blockquote><div><br></div><div>If that’s the case, I would love to see both evaluated side to side,</div><div>and make a community decision on that. </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><blockquote type="cite"><div><div> </div><div> </div><blockquote type="cite"><div><div> </div><div>some ideas:</div><div> </div><div>a. don't bother to make it per-agent.</div><div>add it to neutron's requirements. (and global-requirement)</div><div>simple, but this would make non-ovs plugin users unhappy.</div><div> </div></div></blockquote><div>I would simply go with a, what’s the ryu’s internal requirement list? is</div><div>it big?</div></div></blockquote><div><br></div><div>no additional requirements as far as we use only openflow part of ryu.</div></div></div></span></blockquote><div><br></div><div><span style="font-size: 14px;">Then IMHO I don’t believe this is a big deal as for any other dependency.</span> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><blockquote type="cite"><div><div> </div><blockquote type="cite"><div><div> </div><div>b. make devstack look at per-agent extra requirements file in neutron tree.</div><div>eg. neutron/plugins/$Q_AGENT/requirements.txt</div><div> </div></div></blockquote><div>IMHO that would make distribution work a bit harder because we</div><div>may need to process new requirement files, but my answer could depend</div><div>on what I asked for a. </div></div></blockquote><div><br></div><div>probably.</div><div>i guess distributors can speak up.</div></div></div></span></blockquote><div><span style="font-size: 14px;">I speak up, I prefer a. But looping Ihar as he’s doing the majority of</span></div><div><span style="font-size: 14px;">work related to neutron distribution in RH/RDO.</span></div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><blockquote type="cite"><div><blockquote type="cite"><div><div> </div><div>c. move OVS agent to a separate repository, just like other</div><div>after-decomposition vendor plugins. and use requirements.txt there.</div><div>for longer term, this might be a way to go. but i don't want to</div><div>block my work until it happens.</div><div> </div><div> </div></div></blockquote><div><br></div><div>We’re not ready for that yet, as co-gating has proven as a bad strategy</div><div>and we need to keep the reference implementation working for tests. </div></div></blockquote><div><br></div><div>i agree that it will not likely be ready in near future.</div><div><br></div><div>YAMAMOTO Takashi</div><div><br></div><blockquote type="cite"><blockquote type="cite"><div><div> </div><div>d. follow the way how openvswitch is installed by devstack.</div><div>a downside: we can't give a jenkins run for a patch which introduces</div><div>an extra requirement. (like my patch for the mentioned blueprint [2])</div><div> </div><div>i think b. is the most reasonable choice, at least for short/mid term.</div><div> </div><div>any comments/thoughts?</div><div> </div><div>YAMAMOTO Takashi</div><div> </div><div>[1] <a href="https://blueprints.launchpad.net/neutron/+spec/ovs-ofctl-to-python">https://blueprints.launchpad.net/neutron/+spec/ovs-ofctl-to-python</a></div><div>[2] <a href="https://review.openstack.org/#/c/153946/">https://review.openstack.org/#/c/153946/</a></div><div> </div><div>__________________________________________________________________________</div><div>OpenStack Development Mailing List (not for usage questions)</div><div>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe (<a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>)</div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div><div> </div><div> </div></div></blockquote></blockquote><div><br></div><div>__________________________________________________________________________</div><div>OpenStack Development Mailing List (not for usage questions)</div><div>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>