While I don't think it is a bad idea to allow the arbitrary k/v on resources just be aware that the content gets a little wonky as you allow users to place anything they want on resources.
I will also voice support for the tag model. The other option is a way to allow the extra values to have clear validators (but that raises other concerns). Simplicity in this case will be the winner. +1 for the transparent to the back end. Sent via mobile > On Aug 24, 2015, at 22:00, Gal Sagie <[email protected]> wrote: > > 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 > this solution on code patching. > I agree with Russell on the definition of Neutron end goal, but what good can > it provide if clouds stop using Neutron because > it doesn't provide them the appropriate support or "better yet" start solving > these problems in "creative" ways thats ends up > missing the entire point of Neutron. (and then clouds stop using Neutron > because they will blame it for the lack of interoperability) > > I think that this is a good enough middle solution and as Armando suggested > in the patch it self, we should work > in a separate task towards making the users/developers/operators understand > (either with documentation or other methods) that the correct > end goal would be to standardize things in the API. > > Implementing it like nova-tags seems to me like a good way to prevent too > much abuse. > > And as i mentioned in the spec [1], there are important use cases for this > feature in the API level > that is transparent to the backend implementation (Multi site OpenStack and > mixed environments (for example Kuryr)) > > Thanks, > Gal. > > [1] https://review.openstack.org/#/c/216021/ > > On Tue, Aug 25, 2015 at 1:19 AM, Doug Wiegley <[email protected]> > wrote: >>> >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. >> >> >> Including me. >> >> 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. >> >> 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. >> >> Thanks, >> doug >> >> >> >> >> >> >>> On Aug 24, 2015, at 4:01 PM, Kevin Benton <[email protected]> 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 <[email protected]> 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: [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> -- >>> Kevin Benton >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Best Regards , > > The G. > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
