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

YAMAMOTO Takashi yamamoto at valinux.co.jp
Thu Feb 19 06:24:27 UTC 2015


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

my plan is the former.

the latter would need to invent a backend-neutral api which covers
large enough subset of openflow and nicira extensions.
my impression is that it isn't a reasonable amount of work for the benefit.

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

sure, there's always been too much things to do.

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

i tend to think the latter is too much.  but if we decide to go
the route, i agree it's reasonable to have separate jobs.

either ways, i need to write working code first.  so i want to be
able to try jenkins runs.  adding ryu to global-requirements [3]
would allow it, while it doesn't hurt anything as far as i know.
(i'm not familiar with infra stuff though.  please correct me if wrong.)

[3] https://review.openstack.org/#/c/154354/

YAMAMOTO Takashi

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



More information about the OpenStack-dev mailing list