Open Stack

Miguel Ángel Ajo


On Wednesday, 18 de February de 2015 at 08:14, yamamoto at valinux.co.jp wrote:

> hi,
>  
> > On Wednesday, 18 de February de 2015 at 07:00, 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.
> > >  
> > >  
> > >  
> >  
> >  
> >  
> > 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?

Connection tracking in OVS. At that point we could do NAT/stateful
firewalling, etc  
>  
> >  
> > 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)
>  
>  


If that’s the case, I would love to see both evaluated side to side,
and make a community decision on that.  
>  
> > > 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.

Then IMHO I don’t believe this is a big deal as for any other 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 speak up, I prefer a. But looping Ihar as he’s doing the majority of
work related to neutron distribution in RH/RDO.
  
>  
> > > 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
> > >  
> > >  
> > >  
> >  
>  
>  
> __________________________________________________________________________
> 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
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150218/7b82cafe/attachment.html>