> On 17 February 2015 at 22:00, YAMAMOTO Takashi <yamam...@valinux.co.jp> > wrote: > >> hi, >> >> i want to add an extra requirement specific to OVS-agent. >> (namely, I want to add ryu for ovs-ofctl-to-python blueprint. [1] >> but the question is not specific to the blueprint.) >> to avoid messing deployments without OVS-agent, such a requirement >> should be per-agent/driver/plugin/etc. however, there currently >> seems no standard mechanism for such a requirement. >> >> some ideas: >> >> a. don't bother to make it per-agent. >> add it to neutron's requirements. (and global-requirement) >> simple, but this would make non-ovs plugin users unhappy. >> >> b. make devstack look at per-agent extra requirements file in neutron tree. >> eg. neutron/plugins/$Q_AGENT/requirements.txt >> >> c. move OVS agent to a separate repository, just like other >> after-decomposition vendor plugins. and use requirements.txt there. >> for longer term, this might be a way to go. but i don't want to >> block my work until it happens. >> >> d. follow the way how openvswitch is installed by devstack. >> a downside: we can't give a jenkins run for a patch which introduces >> an extra requirement. (like my patch for the mentioned blueprint [2]) >> >> i think b. is the most reasonable choice, at least for short/mid term. >> >> any comments/thoughts? >> > > 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.
my plan is the former. the latter would need to invent a backend-neutral api which covers large enough subset of openflow and nicira extensions. my impression is that it isn't a reasonable amount of work for the benefit. > > 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 :) sure, there's always been too much things to do. > > 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. i tend to think the latter is too much. but if we decide to go the route, i agree it's reasonable to have separate jobs. either ways, i need to write working code first. so i want to be able to try jenkins runs. adding ryu to global-requirements [3] would allow it, while it doesn't hurt anything as far as i know. (i'm not familiar with infra stuff though. please correct me if wrong.) [3] https://review.openstack.org/#/c/154354/ YAMAMOTO Takashi > > Thoughts? > > Cheers, > Armando > > >> >> YAMAMOTO Takashi >> >> [1] https://blueprints.launchpad.net/neutron/+spec/ovs-ofctl-to-python >> [2] https://review.openstack.org/#/c/153946/ >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
