Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 08:14, yamam...@valinux.co.jp wrote: > hi, > > > On Wednesday, 18 de February de 2015 at 07:00, yamam...@valinux.co.jp > > (mailto: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. > > > > > > > > > > > > > > > > > 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? Connection tracking in OVS. At that point we could do NAT/stateful firewalling, etc > > > > > 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) > > If that’s the case, I would love to see both evaluated side to side, and make a community decision on that. > > > > 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. Then IMHO I don’t believe this is a big deal as for any other dependency. > > > > 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. > > I speak up, I prefer a. But looping Ihar as he’s doing the majority of work related to neutron distribution in RH/RDO. > > > > 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: > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > (mailto: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 > (mailto: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