Open Stack

Gary,

I agree. Moving away from that option, I am trying to propose the idea of
extended IPAM tables: https://bugs.launchpad.net/neutron/+bug/1513981 and
https://review.openstack.org/#/c/242688/

On Sun, Nov 8, 2015 at 12:10 AM, Gary Kotton <gkotton at vmware.com> wrote:

> I think that id we can move to a versioned object model model then it will
> be better. Having random json blobs passed around is going to cause
> problems.
>
> From: "Armando M." <armamig at gmail.com>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: Wednesday, November 4, 2015 at 11:38 PM
> To: OpenStack List <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam
> db tables
>
>
>
> 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
>>
>>
>
> __________________________________________________________________________
> 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/20151109/835fe56e/attachment-0001.html>