On Aug 24, 2015, at 4:01 PM, Kevin Benton<blak...@gmail.com> wrote:
I don't think even worse code makes this what's proposed here seem any better.
I'm not really sure what you're saying.
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.
The way to do that is to have it defined explicitly by Neutron and not punt.
+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.
In general, the fight in Neutron *has* to be about common definitions of
networking primitives that can be potentially implemented by multiple backends
whenever possible. That's the entire point of Neutron. I get that it's hard,
but that's the value Neutron brings to the table.
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.
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.
On Mon, Aug 24, 2015 at 2:43 PM, Russell
Bryant<rbry...@redhat.com<mailto:rbry...@redhat.com>> wrote:
On 08/24/2015 05:25 PM, Doug Wiegley wrote:
I took advantage of it to prototype a feature her
That right there is the crux of the objections so far. Don’t get me
wrong, I’d love this, and would abuse it within an inch of its life
regularly.
The alternative is sometimes even worse than a vendor extension or
plugin. Take for example, wanting to add a new load balancing
algorithm, like LEAST_MURDERED_KITTENS. The current list is
hard-coded all over the dang place, so you end up shipping neutron
patches or monkey patches. Opaque pass-through to the driver is evil
from an interoperability standpoint, but in terms of extending code
at the operators choosing, there are MUCH worse sins that are
actively being committed.
I don't think even worse code makes this what's proposed here seem any
better. I'm not really sure what you're saying.
Flavors covers this use case, but in a way that’s up to the operators
to setup, and not as easy for devs to deal with.
Whether the above sounds like it’s a bonus or a massive reason not to
do this will entirely lie in the eye of the beholder, but the vendor
extension use case WILL BE USED, no matter what we say.
Interop really is a key part of this. If we look at this particular
case, yes, I get that there are lots of LB algorithms out there and that
it makes sense to expose that choice to users. However, I do think
what's best for users is to define and document each of them very
explicitly. The end user should know that if they choose algorithm
BEST_LB_EVER, that it means the same thing on cloud A vs cloud B. The
way to do that is to have it defined explicitly by Neutron and not punt.
Maybe in practice the Neutron defined set is a subset of what's
available overall, and the custom (vendor) ones can be clearly marked as
such. In any case, I'm just trying to express what goal I think we
should be striving for.
In general, the fight in Neutron *has* to be about common definitions of
networking primitives that can be potentially implemented by multiple
backends whenever possible. That's the entire point of Neutron. I get
that it's hard, but that's the value Neutron brings to the table.
--
Russell Bryant
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
--
Kevin Benton
