Replies inline.
On Fri, Nov 6, 2015 at 1:48 PM, Salvatore Orlando <salv.orla...@gmail.com> wrote: > More comments inline. > I shall stop trying being ironic (pun intended) in my posts. > :( > > Salvatore > > On 5 November 2015 at 18:37, Kyle Mestery <mest...@mestery.com> wrote: > >> On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes <jaypi...@gmail.com> wrote: >> >>> On 11/04/2015 04:21 PM, Shraddha Pandhe wrote: >>> >>>> Hi Salvatore, >>>> >>>> Thanks for the feedback. I agree with you that arbitrary JSON blobs will >>>> make IPAM much more powerful. Some other projects already do things like >>>> this. >>>> >>> >>> :( Actually, though "powerful" it also leads to implementation details >>> leaking directly out of the public REST API. I'm very negative on this and >>> would prefer an actual codified REST API that can be relied on regardless >>> of backend driver or implementation. >>> >> >> I agree with Jay here. We've had people propose similar things in Neutron >> before, and I've been against them. The entire point of the Neutron REST >> API is to not leak these details out. It dampens the strength of the >> logical model, and it tends to have users become reliant on backend >> implementations. >> > > I see I did not manage to convey accurately irony and sarcasm in my > previous post ;) > The point was that thanks to a blooming number of extensions the Neutron > API is already hardly portable. Blob attributes (or dict attributes, or > key/value list attributes, or whatever does not have a precise schema) are > a nail in the coffin, and also violate the only tenet Neutron has somehow > managed to honour, which is being backend agnostic. > And the fact that the port binding extension is pretty much that is not a > valid argument, imho. > On the other hand, I'm all in for extending DB schema and driver logic to > suit all IPAM needs; at the end of the day that's what do with plugins for > all sort of stuff. > Agreed. Filed an rfe bug: https://bugs.launchpad.net/neutron/+bug/1513981. Spec coming up for review. > > > >> >> >>> >>> e.g. In Ironic, node has driver_info, which is JSON. it also has an >>>> 'extras' arbitrary JSON field. This allows us to put any information in >>>> there that we think is important for us. >>>> >>> >>> Yeah, and this is a bad thing, IMHO. Public REST APIs should be >>> structured, not a Wild West free-for-all. The biggest problem with using >>> free-form JSON blobs in RESTful APIs like this is that you throw away the >>> ability to evolve the API in a structured, versioned way. Instead of >>> evolving the API using microversions, instead every vendor just jams >>> whatever they feel like into the JSON blob over time. There's no way for >>> clients to know what the server will return at any given time. >>> >>> Achieving consensus on a REST API that meets the needs of a variety of >>> backend implementations is *hard work*, yes, but it's what we need to do if >>> we are to have APIs that are viewed in the industry as stable, >>> discoverable, and reliably useful. >>> >> >> ++, this is the correct way forward. >> > > Cool, but let me point out that experience has thought us that anything > that is a result of a compromise between several parties following > different agendas is bound to failure as it does not fully satisfy the > requirements of any stakeholder. > If these information are needed for making scheduling decisions based on > network requirements, then it makes sense to expose this information also > at the API layer (I assume there also plans for making the scheduler > *seriously* network aware). However, this information should have a > well-defined schema with no leeway for 'extensions; such schema can evolve > over time. > > >> Thanks, >> Kyle >> >> >>> >>> Best, >>> -jay >>> >>> Best, >>> -jay >>> >>> Hoping to get some positive feedback from API and DB lieutenants too. >>>> >>>> >>>> On Wed, Nov 4, 2015 at 1:06 PM, Salvatore Orlando >>>> <salv.orla...@gmail.com <mailto:salv.orla...@gmail.com>> wrote: >>>> >>>> Arbitrary blobs are a powerful tools to circumvent limitations of an >>>> API, as well as other constraints which might be imposed for >>>> versioning or portability purposes. >>>> The parameters that should end up in such blob are typically >>>> specific for the target IPAM driver (to an extent they might even >>>> identify a specific driver to use), and therefore an API consumer >>>> who knows what backend is performing IPAM can surely leverage it. >>>> >>>> Therefore this would make a lot of sense, assuming API portability >>>> and not leaking backend details are not a concern. >>>> The Neutron team API & DB lieutenants will be able to provide more >>>> input on this regard. >>>> >>>> In this case other approaches such as a vendor specific extension >>>> are not a solution - assuming your granularity level is the >>>> allocation pool; indeed allocation pools are not first-class neutron >>>> resources, and it is not therefore possible to have APIs which >>>> associate vendor specific properties to allocation pools. >>>> >>>> Salvatore >>>> >>>> On 4 November 2015 at 21:46, Shraddha Pandhe >>>> <spandhe.openst...@gmail.com <mailto:spandhe.openst...@gmail.com>> >>>> wrote: >>>> >>>> Hi folks, >>>> >>>> I have a small question/suggestion about IPAM. >>>> >>>> With IPAM, we are allowing users to have their own IPAM drivers >>>> so that they can manage IP allocation. The problem is, the new >>>> ipam tables in the database have the same columns as the old >>>> tables. So, as a user, if I want to have my own logic for ip >>>> allocation, I can't actually get any help from the database. >>>> Whereas, if we had an arbitrary json blob in the ipam tables, I >>>> could put any useful information/tags there, that can help me >>>> for allocation. >>>> >>>> Does this make sense? >>>> >>>> e.g. If I want to create multiple allocation pools in a subnet >>>> and use them for different purposes, I would need some sort of >>>> tag for each allocation pool for identification. Right now, >>>> there is no scope for doing something like that. >>>> >>>> Any thoughts? If there are any other way to solve the problem, >>>> please let me know >>>> >>>> >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> 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 >>>> >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev