Bumping this up :)
Folks, does anyone else have a similar requirement to ours? Are folks making scheduling decisions based on networking? On Thu, Nov 5, 2015 at 12:24 PM, Shraddha Pandhe < spandhe.openst...@gmail.com> wrote: > Hi, > > I agree with all of you about the REST Apis. > > As I said before, I had to bring up the idea of JSON blob because based on > previous discussions, it looked like neutron community was not willing to > enhance the schemas for different ipam dbs. Entire rationale behind > pluggable IPAM is to provide flexibility. So, community should be open to > ideas for enhancing the schema to incorporate more information in the db > tables. I would be extremely happy if use cases for different companies are > considered and schema is enhanced to include specific columns in db > schemas instead of a column with random JSON blob. > > Lets pick up subnets db table for example. We have some use cases where it > would be great if following information is associated with the subnet db > table > > 1. Rack switch info > 2. Backplane info > 3. DHCP ip helpers > 4. Option to tag allocation pools inside subnets > 5. Multiple gateway addresses > > We also want to store some information about the backplanes locally, so a > different table might be useful. > > In a way, this information is not specific to our company. Its generic > information which ought to go with the subnets. Different companies can use > this information differently in their IPAM drivers. But, the information > needs to be made available to justify the flexibility of ipam > > In Yahoo! OpenStack is still not the source of truth for this kind of > information and database limitation is one of the reasons. I would prefer > to avoid having our own database to make sure that our use-cases are always > shared with the community. > > > > > > > > > On Thu, Nov 5, 2015 at 9:37 AM, Kyle Mestery <mest...@mestery.com> wrote: > >> On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes <jaypi...@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. >> >> >>> >>> 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. >> >> 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.orla...@gmail.com <mailto: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 <mailto: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://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://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
