On 08/25/2015 01:00 AM, Gal Sagie 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))
To be clear, I support the feature as long as it's documented that it's opaque to Neutron backends. My argument is about the general idea of arbitrary pass-through to backends, which you don't seem to be proposing. -- 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
