Open Stack

On 17 February 2015 at 22:00, YAMAMOTO Takashi <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.
>
> 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.

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 :)

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.

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-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/c884ad1f/attachment.html>