Open Stack

On 4 November 2015 at 13:21, Shraddha Pandhe <spandhe.openstack at gmail.com>
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.
>
> 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.
>

I personally feel that relying on json blobs is not only dangerously
affecting portability, but it causes us to bloat the business logic, and
forcing us to be doing less efficient when querying/filtering data.

Most importantly though, I feel it's like abdicating our responsibility to
do a good design job. Ultimately, we should be able to identify how to
model these extensions you're thinking of both conceptually and logically.

I couldn't care less if other projects use it, but we ended up using in
Neutron too, and since I lost this battle time and time again, all I am
left with is this rant :)


>
>
> 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>
> 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
>> > 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://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/20151104/1ebc26ac/attachment.html>