<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 17 February 2015 at 22:00, YAMAMOTO Takashi <span dir="ltr"><<a href="mailto:yamamoto@valinux.co.jp" target="_blank">yamamoto@valinux.co.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">hi,<br>
<br>
i want to add an extra requirement specific to OVS-agent.<br>
(namely, I want to add ryu for ovs-ofctl-to-python blueprint. [1]<br>
but the question is not specific to the blueprint.)<br>
to avoid messing deployments without OVS-agent, such a requirement<br>
should be per-agent/driver/plugin/etc. however, there currently<br>
seems no standard mechanism for such a requirement.<br>
<br>
some ideas:<br>
<br>
a. don't bother to make it per-agent.<br>
add it to neutron's requirements. (and global-requirement)<br>
simple, but this would make non-ovs plugin users unhappy.<br>
<br>
b. make devstack look at per-agent extra requirements file in neutron tree.<br>
eg. neutron/plugins/$Q_AGENT/requirements.txt<br>
<br>
c. move OVS agent to a separate repository, just like other<br>
after-decomposition vendor plugins. and use requirements.txt there.<br>
for longer term, this might be a way to go. but i don't want to<br>
block my work until it happens.<br>
<br>
d. follow the way how openvswitch is installed by devstack.<br>
a downside: we can't give a jenkins run for a patch which introduces<br>
an extra requirement. (like my patch for the mentioned blueprint [2])<br>
<br>
i think b. is the most reasonable choice, at least for short/mid term.<br>
<br>
any comments/thoughts?<br></blockquote><div><br></div><div>One thing that I want to ensure we are clear on is about the agent's OpenFlow communication strategy going forward, because that determines how we make a decision based on the options you have outlined: do we enforce the use of ryu while ovs-ofctl goes away from day 0? Or do we provide an 'opt-in' type of approach where users can explicitly choose if/when to adopt ryu in favor of ovs-ofctl? The latter means that we'll keep both solutions for a reasonable amount of time to smooth the transition process.</div><div><br></div><div>If we adopt the former (i.e. ryu goes in, ovs-ofctl goes out), then option a) makes sense to me, but I am not sure how happy deployers, and packagers are going to be welcoming this approach. There's already too much going on in Kilo right now :)</div><div><br></div><div>If we adopt the latter, then I think it's desirable to have two separate configurations with which we test the agent. This means that we'll have a new job (besides the existing ones) that runs the agent with ryu instead of ovs-ofctl. This means that option d) is the viable one, where DevStack will have to install the dependency based on some configuration variable that is determined by the openstack-infra project definition.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Cheers,</div><div>Armando</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
YAMAMOTO Takashi<br>
<br>
[1] <a href="https://blueprints.launchpad.net/neutron/+spec/ovs-ofctl-to-python" target="_blank">https://blueprints.launchpad.net/neutron/+spec/ovs-ofctl-to-python</a><br>
[2] <a href="https://review.openstack.org/#/c/153946/" target="_blank">https://review.openstack.org/#/c/153946/</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>