Open Stack

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.

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

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

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