On Wed, Nov 4, 2015 at 1:38 PM, Armando M. <arma...@gmail.com> wrote:
> > > 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. > How does it affect portability? I don't think it forces us to do anything. 'Allows'? Maybe. But that can be solved. Before making any design decisions for internal feature-requests, we should first check with the community if its a wider use-case. If it is a wider use-case, we should collaborate and fix it upstream the right way. I feel that, its impossible for the community to know all the use-cases. Even if they knew, it would be impossible to incorporate all of them. I filed a bug few months ago about multiple gateway support for subnets. https://bugs.launchpad.net/neutron/+bug/1464361 It was marked as 'Wont fix' because nobody else had this use-case. Adding and maintaining a patch to support this is super risky as it breaks the APIs. A JSON blob would have helped me here. I have another use-case. For multi-ip support for Ironic, we want to divide the IP allocation ranges into two: Static IPs and extra IPs. The static IPs are pre-configured IPs for Ironic inventory whereas extra IPs are the multi-ips. Nobody else in the community has this use-case. If we add our own database for internal stuff, we go back to the same problem of allowing bad design. > Ultimately, we should be able to identify how to model these extensions > you're thinking of both conceptually and logically. > I would agree with that. If theres an effort going on in this direction, ill be happy to join. Without this, people like us with unique use-cases are stuck with having patches. > > 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