Open Stack

Yes, actually, we have done some effort and practice to ensure that dvr has
a better performance and stability, but i am not sure whether it would be
accepted, so that's why i say : ("I’m not sure whether the following issue
is problematic…"). in my opinion, i think it's very helpful.

2014-10-29 20:36 GMT+08:00 Hly <henry4hly at gmail.com>:

>
>
> Sent from my iPad
>
> On 2014-10-29, at 下午6:33, Maru Newby <marun at redhat.com> wrote:
>
> >
> > On Oct 29, 2014, at 8:12 AM, Yangxurong <yangxurong at huawei.com> wrote:
> >
> >> Hi,
> >>
> >> I’m not sure whether following issue is problematic, and both, our team
> do some effort, so I submit two blueprints:
> >> [1.] optimize dvr flows:
> >> Currently, accurate ovs flows in terms of full mac are used to
> communicate among distributed router, but here comes problem : (1)the more
> distributed router node, the more flows; (2)different distributed router
> across DC cannot communicate through tunnel and additional operation under
> same mac prefix configuration. So it would be useful to shift the
> complete-matching of mac to fuzzy Matching, like prefix matching, reducing
> the number of flows and leading to communicate among different DC though
> configuring same mac prefix through tunnel.
> >> Link: https://blueprints.launchpad.net/neutron/+spec/optimize-dvr-flows
> >
> > I think we need to focus on paying down technical debt (both in the code
> and on the testing side) related to dvr before we seriously consider the
> kind of optimization that you are proposing.  I’m also unclear as to why we
> would want to pursue a solution to a problem whose severity doesn’t appear
> to be clear ("I’m not sure whether the following issue is problematic…").
> >
>
> DVR stability is the first class for sure, but if the code and logic could
> be less and simpler, there is more chance of stability. By my
> understanding, since DVR mac range has been configured as a prefix, so
> prefix based judgement instead of one by one flow setup triggered by
> mesh-like message notifying would simplify the code logic, thus indirectly
> contribute to overall stability. Also, it would remove hundreds of flows in
> the ovs in a middle scale cluster, very helpful for trouble shooting.
>
> Wu
>
> >
> > Maru
> >
> >>
> >> [2.]add port timestamp:
> >> It would be worth adding timestamp fields including create_at,
> update_at and delete_at in the table of port in neutron, so users can
> monitor port change conveniently, for example portal or management center
> wants to query the ports that have changed or refreshed during the latest
> 5sec in a large scale application. If not, it's time-consuming and low
> effectiveness.
> >> Link: https://blueprints.launchpad.net/neutron/+spec/add-port-timestamp
> >>
> >> Any response I will appreciate.
> >>
> >> Thanks,
> >> Xurong Yang
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20141029/8dfa9717/attachment.html>