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 <gkot...@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." <arma...@gmail.com> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > Date: Wednesday, November 4, 2015 at 11:38 PM > To: OpenStack List <openstack-dev@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.openst...@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.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> 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://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 >> >> > > __________________________________________________________________________ > 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
