hi, > On Wednesday, 18 de February de 2015 at 07:00, [email protected] 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. >> >> > > > Awesome, I was thinking of the same a few days ago, we make lots > and lots of calls to ovs-ofctl, and we will do more if we change to > security groups/routers in OF, if that proves to be efficient, and we > get CT.
CT? > > After this change, what would be the differences of ofagent to ovs-agent ? > > I guess OVS set’s rules in advance, while ofagent works as a normal > OF controller? the basic architecture will be same. actually it was suggested to merge two agents during spec review. i think it's a good idea for longer term. (but unlikely for kilo) > > >> >> 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. >> > I would simply go with a, what’s the ryu’s internal requirement list? is > it big? no additional requirements as far as we use only openflow part of ryu. > >> >> b. make devstack look at per-agent extra requirements file in neutron tree. >> eg. neutron/plugins/$Q_AGENT/requirements.txt >> > IMHO that would make distribution work a bit harder because we > may need to process new requirement files, but my answer could depend > on what I asked for a. probably. i guess distributors can speak up. >> >> 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. >> >> > > We’re not ready for that yet, as co-gating has proven as a bad strategy > and we need to keep the reference implementation working for tests. i agree that it will not likely be ready in near future. YAMAMOTO Takashi >> >> 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? >> >> 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: [email protected]?subject:unsubscribe >> (mailto:[email protected]?subject:unsubscribe) >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
