<div dir="ltr"><div><div><div><div><div><div><div><div><div>I agree with Doug and Kevin, i think it is very hard for Neutron to keep the pace in every area of Networking abstraction, and i prefer<br>this solution on code patching.<br>I agree with Russell on the definition of Neutron end goal, but what good can it provide if clouds stop using Neutron because<br></div></div>it doesn't provide them the appropriate support or "better yet" start solving these problems in "creative" ways thats ends up<br></div>missing the entire point of Neutron. (and then clouds stop using Neutron because they will blame it for the lack of interoperability)<br><br></div>I think that this is a good enough middle solution and as Armando suggested in the patch it self, we should work<br></div>in a separate task towards making the users/developers/operators understand (either with documentation or other methods) that the correct<br></div>end goal would be to standardize things in the API. <br><br></div>Implementing it like nova-tags seems to me like a good way to prevent too much abuse.<br><br></div>And as i mentioned in the spec [1], there are important use cases for this feature in the API level<br></div>that is transparent to the backend implementation (Multi site OpenStack and mixed environments (for example Kuryr))<br><div><br></div><div>Thanks,<br></div><div>Gal.<br></div><div><br>[1] <a href="https://review.openstack.org/#/c/216021/" target="_blank">https://review.openstack.org/#/c/216021/</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 25, 2015 at 1:19 AM, Doug Wiegley <span dir="ltr"><<a href="mailto:dougwig@parksidesoftware.com" target="_blank">dougwig@parksidesoftware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div><blockquote type="cite"><div dir="ltr"><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">In general, the fight in Neutron *has* to be about common definitions of </span><span style="font-size:12.8000001907349px">networking primitives that can be potentially implemented by multiple </span><span style="font-size:12.8000001907349px">backends whenever possible. That's the entire point of Neutron. I get </span><span style="font-size:12.8000001907349px">that it's hard, but that's the value Neutron brings to the table.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I think that everyone agrees with you on this point.</span></div></div></blockquote></div><div><br></div></span><div>Including me.</div><div><br></div><div>The tricky part comes when the speed of neutron adding to the api bottlenecks other things, or when the abstractions just aren’t there yet, because the technology in question isn’t mature enough. Do we provide relief valves, knowing they will be abused as much as help, or do we hold a hard line? These tags are a relief valve.</div><div><br></div><div>I’m in favor of them, and I’m in favor of holding to the abstraction. It seems there has to be a middle ground.</div><div><br></div><div>Thanks,</div><div>doug</div><div><div class="h5"><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><div><blockquote type="cite"><div>On Aug 24, 2015, at 4:01 PM, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:</div><br><div><div dir="ltr">><span style="font-size:12.8000001907349px">I don't think even worse code makes this what's proposed here seem any </span><span style="font-size:12.8000001907349px">better. I'm not really sure what you're saying.</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I think he's saying that as a vendor he is looking for ways to expose things that aren't normally available and ends up doing terrible evil things to achieve it. :) And if the metadata tags were available, they would be the new delivery vehicle of choice since they are much better than monkey-patching.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">The </span><span style="font-size:12.8000001907349px">way to do that is to have it defined explicitly by Neutron and not punt.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">+1, but the concern was that having these data bags easily available will eliminate a lot of the incentive contributors had to work together to standardize what they were trying to do. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">In general, the fight in Neutron *has* to be about common definitions of </span><span style="font-size:12.8000001907349px">networking primitives that can be potentially implemented by multiple </span><span style="font-size:12.8000001907349px">backends whenever possible. That's the entire point of Neutron. I get </span><span style="font-size:12.8000001907349px">that it's hard, but that's the value Neutron brings to the table.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I think that everyone agrees with you on this point. It seems like Doug was just pointing out from the vendor perspective that it's very tempting to slap something together based on what is available, and now we will be providing a tool to make that route even easier.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div>After thinking about it, an out-of-tree driver abusing tags is a much better place for us to be than monkey-patching code. At least with tags it's obvious that it's bolted on metadata rather than entirely different API behavior monkey-patched in.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 24, 2015 at 2:43 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 08/24/2015 05:25 PM, Doug Wiegley wrote:<br>
>> I took advantage of it to prototype a feature her<br>
><br>
> That right there is the crux of the objections so far. Don’t get me<br>
> wrong, I’d love this, and would abuse it within an inch of its life<br>
> regularly.<br>
><br>
> The alternative is sometimes even worse than a vendor extension or<br>
> plugin. Take for example, wanting to add a new load balancing<br>
> algorithm, like LEAST_MURDERED_KITTENS. The current list is<br>
> hard-coded all over the dang place, so you end up shipping neutron<br>
> patches or monkey patches. Opaque pass-through to the driver is evil<br>
> from an interoperability standpoint, but in terms of extending code<br>
> at the operators choosing, there are MUCH worse sins that are<br>
> actively being committed.<br>
<br>
</span>I don't think even worse code makes this what's proposed here seem any<br>
better. I'm not really sure what you're saying.<br>
<span><br>
> Flavors covers this use case, but in a way that’s up to the operators<br>
> to setup, and not as easy for devs to deal with.<br>
><br>
> Whether the above sounds like it’s a bonus or a massive reason not to<br>
> do this will entirely lie in the eye of the beholder, but the vendor<br>
> extension use case WILL BE USED, no matter what we say.<br>
<br>
</span>Interop really is a key part of this. If we look at this particular<br>
case, yes, I get that there are lots of LB algorithms out there and that<br>
it makes sense to expose that choice to users. However, I do think<br>
what's best for users is to define and document each of them very<br>
explicitly. The end user should know that if they choose algorithm<br>
BEST_LB_EVER, that it means the same thing on cloud A vs cloud B. The<br>
way to do that is to have it defined explicitly by Neutron and not punt.<br>
<br>
Maybe in practice the Neutron defined set is a subset of what's<br>
available overall, and the custom (vendor) ones can be clearly marked as<br>
such. In any case, I'm just trying to express what goal I think we<br>
should be striving for.<br>
<br>
In general, the fight in Neutron *has* to be about common definitions of<br>
networking primitives that can be potentially implemented by multiple<br>
backends whenever possible. That's the entire point of Neutron. I get<br>
that it's hard, but that's the value Neutron brings to the table.<br>
<div><div><br>
--<br>
Russell Bryant<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div>Kevin Benton</div></div>
</div>
</div></blockquote></div><br></div></div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Best Regards ,<br><br>The G. </div>
</div>