Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/18/2015 08:45 PM, Armando M. wrote:
> 
> 
> On 17 February 2015 at 22:00, YAMAMOTO Takashi
> <yamamoto at valinux.co.jp <mailto: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 :)

Even if we leave both options available, packagers wouldn't avoid
shipping ryu, for if the option is present in the code and can be
controlled from config files, then we should assume some users will
switch implementations, and we don't want to break them.

> 
> 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://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU536CAAoJEC5aWaUY1u57Q/4H/iJPbp/KA9ouI6lVv5v7U+i3
gOh4SSwWkc047iaPYmJmcvvLFSujSX9se3LJllaLZAnvVwpwViIqmx7BfcVMrGFP
FVi3Jgz8yhEVXIrAz0wdrU1G2h13Gt1S67Oparype8Ivf5RzFx1ahHKVXVC89VYz
XRo5rk7V4LTAUNB3IlPP8xpCalyuw67eyx2ubY8efbH7i342gJ/JHykxIWKlBNHL
szjy3ydim7MyGCzFVrQUjQkw7jhH9cEbVAZU1MCXwzpuO0M+1Aciype0mtlAzo45
i+A+GfDtF9SGxH0D1PUepUwDXZ+P1UyyA53q41KDZ6Vg3ESRmYN3GUu/N/LXtgY=
=3eA4
-----END PGP SIGNATURE-----