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.
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.
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
