Open Stack

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.openstack at 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 <mestery at mestery.com> wrote:
>
>> On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes <jaypipes at 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.orlando at gmail.com <mailto: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 <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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/20151106/1f30ba2c/attachment.html>