Re: [openstack-dev] [Neutron]issue about dvr flows and port timestamp
On Oct 29, 2014, at 8:12 AM, Yangxurong yangxur...@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…). 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]issue about dvr flows and port timestamp
Sent from my iPad On 2014-10-29, at 下午6:33, Maru Newby ma...@redhat.com wrote: On Oct 29, 2014, at 8:12 AM, Yangxurong yangxur...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]issue about dvr flows and port timestamp
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 henry4...@gmail.com: Sent from my iPad On 2014-10-29, at 下午6:33, Maru Newby ma...@redhat.com wrote: On Oct 29, 2014, at 8:12 AM, Yangxurong yangxur...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]issue about dvr flows and port timestamp
On Oct 29, 2014, at 1:36 PM, Hly henry4...@gmail.com wrote: Sent from my iPad On 2014-10-29, at 下午6:33, Maru Newby ma...@redhat.com wrote: On Oct 29, 2014, at 8:12 AM, Yangxurong yangxur...@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. If we’re going to refactor/optimize/whatever any part of Neutron, the first requirement is that we can maintain the expectations of the code (i.e. ensure good test coverage) across changes. DVR is no different from any other feature in this regard. I would welcome any effort you want to devote to improving DVR’s testing story such that the kind of optimizations you are proposing would have less potential to cause regressions. In addition to baseline test coverage, I would also expect to see test additions validating flow generation such that reviewers would be able to easily identify the benefit of your proposed optimizations by comparing the results before and after. Maru 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
