<div dir="ltr">><span style="font-family:arial,sans-serif;font-size:13px">Flag is only for admin use, tenant can't see it, and the default policy for router is setup by config file.</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><font face="arial, sans-serif">It's still a public API that will have to follow a deprecation cycle. If a new API was going to be introduced for admins to control the distributed nature of routers, it would have been nice to introduce a little more control than distributed=True/False (e.g. how many SNAT IPs are consumed, etc). At this point we are stuck because any new API entries would require a blueprint and the feature proposal freeze deadline is long gone.</font></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">It COULD be compatible for DVR work on vlan, but there were some bugs several months before, that DVR mac are not written successfully on the egress packet, I'm not sure if it is fixed in the merged code.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">The current DVR wiki[1] still shows that the tenant_network_type has to be VXLAN. </span><span style="font-family:arial,sans-serif;font-size:13px">I didn't know about this issue until just recently and I'm not sure if there are plans yet to fix it for Juno.</span><span style="font-family:arial,sans-serif;font-size:13px"> </span><span style="font-family:arial,sans-serif;font-size:13px">If it were in an incubation tree somewhere and not on Gerrit for the majority of the cycle, the bug could have been worked on in parallel by other volunteers interested in VLAN support. </span><span style="font-family:arial,sans-serif;font-size:13px">Now that DVR is solidifying, VLAN support may even require a blueprint unless it's blessed by the right cores, which would mean people with VLAN deployments would not be able to use DVR until Kilo is released next next May.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>The whole point is that there is nowhere to work on big features like this in a fast, iterative, and open manner. The incubator could be a perfect place for this type of work.</div>
<div><br></div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">1. </span><font face="arial, sans-serif"><a href="https://wiki.openstack.org/wiki/Neutron/DVR/HowTo">https://wiki.openstack.org/wiki/Neutron/DVR/HowTo</a></font><span style="font-family:arial,sans-serif;font-size:13px"> </span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 27, 2014 at 1:22 AM, loy wolfe <span dir="ltr"><<a href="mailto:loywolfe@gmail.com" target="_blank">loywolfe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Wed, Aug 27, 2014 at 2:44 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class=""><div>><span style="font-family:arial,sans-serif;font-size:13px">Incubator doesn't mean being kicked out of tree, it just mean that the API and resource model needs to be baked for fast iteration, and can't be put in tree temporarily.</span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div></div><div class=""><div><span style="font-family:arial,sans-serif;font-size:13px">That was exactly my point about developing a major feature like DVR. Even with a limited API change (the new distributed flag), it has an impact on the the router/agent </span><span style="font-family:arial,sans-serif;font-size:13px">DB </span><span style="font-family:arial,sans-serif;font-size:13px">resource model and currently isn't compatible with VLAN based ML2 deployments. It's not exactly a hidden optimization like an improvement to some RPC handling code. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div></div></blockquote><div><br></div><div>Flag is only for admin use, tenant can't see it, and the default policy for router is setup by config file.</div>
<div><br></div><div>It COULD be compatible for DVR work on vlan, but there were some bugs several months before, that DVR mac are not written successfully on the egress packet, I'm not sure if it is fixed in the merged code.</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:13px"></span></div>
<div><font face="arial, sans-serif">A huge piece of the DVR development had to happen in Neutron forks and 40+ revision chains of Gerrit patches. It was very difficult to follow without being heavily involved with the L3 team. This would have been a great candidate to develop in the incubator if it existed at the time. It would have been easier to try as it was developed and to explore the entire codebase. Also, more people could have been contributing bug fixes and improvements since an entire section of code wouldn't be 'owned' by one person like it is with the author of a Gerrit review. </font></div>
<div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">></font><span style="font-family:arial,sans-serif;font-size:13px">For DVR, as it has no influence on tenant facing API resource model, it works as the built-in backend, and this feature has accepted wide common interests,</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div><span style="font-family:arial,sans-serif;font-size:13px">As was pointed out before, common interest has nothing to do with incubation. Incubation is to rapidly iterate on a new feature for Neutron. It shouldn't be restricted to API changes, it should be used for any major new features that are possible to develop outside of the Neutron core. If we are going to have this new incubator tool, we should use it to the fullest extent possible.</span></div>
</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
</div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 6:19 PM, loy wolfe <span dir="ltr"><<a href="mailto:loywolfe@gmail.com" target="_blank">loywolfe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><font face="arial, sans-serif">Incubator doesn't mean being kicked out of tree, it just mean that the API and resource model needs to be baked for fast iteration, and can't be put in tree temporarily. As kyle has said, incubator is not talking about moving 3rd drivers out of tree, which is in another thread.</font><br>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">For DVR, as it has no influence on tenant facing API resource model, it works as the built-in backend, and this feature has accepted wide common interests, it's just the internal performance optimization tightly coupled with existing code, so it should be developed in tree.</font></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Wed, Aug 27, 2014 at 8:08 AM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div dir="ltr">From what I understand, the intended projects for the incubator can't operate without neutron because they are just extensions/plugins/drivers.<div>
<br></div><div>For example, if the DVR modifications to the reference reference L3 plugin weren't already being developed in the tree, DVR could have been developed in the incubator and then merged into Neutron once the bugs were ironed out so a huge string of Gerrit patches didn't need to be tracked. If that had happened, would it make sense to keep the L3 plugin as a completely separate project or merge it? I understand this is the approach the load balancer folks took by making Octavia a separate project, but I think it can still operate on its own, where the reference L3 plugin (and many of the other incubator projects) are just classes that expect to be able to make core Neutron calls.</div>
</div>
<br></div><div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></div></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div>Kevin Benton</div>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>