Open Stack

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

On 02/18/2015 08:14 AM, YAMAMOTO Takashi wrote:
> hi,
> 
>> 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.
> 
> 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.

The I suggest to just go with a. If you want to make distributions
happier, just make sure you mark appropriate entries in
requirements.txt with some metadata to suggest its an ovs plugin only
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 am packaging neutron for RDO, and I speak up. I don't think
maintaining multiple requirements files is a good option, for it will
require updating packaging tools not to miss updates for the files.
Also, how would you make sure those dependencies stay consistent with
openstack/requirements repo? Do you plan to update tooling around the
bot that proposes updates to requirements.txt files in each project?

I think this option requires too much from those who will implement it
in all the tools around, and does not seem to justify itself in
comparison with trivial option 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.
>>> 

That's a proper direction long term, but as it was already suggested
here, it's not going to happen shortly, so no need to block your work
on it.

>>> 
>> 
>> 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-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
>>> 
>>> 
>> 
>> 
> 
> __________________________________________________________________________
>
> 
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

iQEcBAEBAgAGBQJU5J9FAAoJEC5aWaUY1u57eJwH/2+O55t7VjOS0qwM2txpMDV4
MnvMeucX5MBvpcTZ4UuE1gHMxiMHFTmhr5i5Cv+05Pnv7sbyPju+I2Ksi2kdAHlz
4Y5WiJpvrHbEtT2SdJ3OWvjvFUuhz6NM8XMhcCViVBXE3rdLzBVf864Y/8pwZt7d
dR6qiyxIQB+4BbhEqe3G0YWZdULWOBKEH7TM5uXiUewA1p0v14Yt3ysfpGd7Z5t9
HY9Ty1t4JOMB5s0BTGF2LubcaRGNh6Aj596mRCo9OryKy5NR95A/SFBx2B0CIIgV
i58f+PqHlFcoMHp1Qv3H4LUcxfZXitxjheSXA2cAsWDTW6kulnsYMfnSpjfVE0Q=
=4fro
-----END PGP SIGNATURE-----