[openstack-dev] [Neutron] per-agent/driver/plugin requirements

Miguel Ángel Ajo majopela at redhat.com
Wed Feb 18 06:53:58 UTC 2015


On Wednesday, 18 de February de 2015 at 07:00, yamamoto at 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.

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?
  
  
>  
> 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?
  
>  
> 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.  
>  
> 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.  
>  
> 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-request at lists.openstack.org?subject:unsubscribe (mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150218/b5d5f423/attachment.html>


More information about the OpenStack-dev mailing list