Open Stack

Replies inline.


On Fri, Nov 6, 2015 at 1:48 PM, Salvatore Orlando <salv.orlando at 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 <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.
>


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.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
>>
>>
>
> __________________________________________________________________________
> 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/7ddd7297/attachment.html>