Open Stack

More comments inline.
I shall stop trying being ironic (pun intended) in my posts.

Salvatore

On 5 November 2015 at 18:37, Kyle Mestery <mestery at mestery.com> wrote:

> On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes <jaypipes at 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.



>
>
>>
>> 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.orlando at gmail.com <mailto:salv.orlando at 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.openstack at gmail.com <mailto:spandhe.openstack at 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-request at lists.openstack.org?subject:unsubscribe
>>>         <
>>> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>>>     <
>>> http://OpenStack-dev-request@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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151106/782a96a5/attachment.html>