Open Stack

Hi Neil,

Please find my reply inline.

On Fri, Nov 6, 2015 at 1:08 PM, Neil Jerram <Neil.Jerram at metaswitch.com>
wrote:

> Yes, maybe. I'm interested in a pluggable IPAM module that will allocate
> an IP address for a VM that depends on where that VM's host is‎ in the
> physical data center network. Is that similar to your requirement?
>
> We have a similar requirement where we want to pick a network thats
accessible in the rack that VM belongs to. We have L3 Top-of-rack, so the
network is confined to the rack. Right now, we are achieving this by naming
physical network name in a certain way, but thats not going to scale.

We also want to be able to make scheduling decisions based on IP
availability. So we need to know rack <-> network <-> mapping.  We can't
embed all factors in a name. It will be impossible to make scheduling
decisions by parsing name and comparing. GoDaddy has also been doing
something similar [1], [2].


> I don't yet know whether that might lead me to want to store additional
> data in the Neutron DB. My intuition though is that it shouldn't, and that
> any additional data or state that I need for this IPAM module should be
> stored separately from the Neutron DB.
>

 Where are you planning to store that information? If we need similar
information, and if more folks need it, we can add it to Neutron DB in IPAM
tables.

[1]
http://www.dorm.org/blog/openstack-architecture-at-go-daddy-part-3-nova/#Scheduler_Customization
[2]
http://www.dorm.org/blog/openstack-architecture-at-go-daddy-part-2-neutron/#Customizations_to_Abstract_Away_Layer_2


> Regards,
>        Neil
>
>


>
> *From: *Shraddha Pandhe
> *Sent: *Friday, 6 November 2015 20:23
> *To: *OpenStack Development Mailing List (not for usage questions)
> *Reply To: *OpenStack Development Mailing List (not for usage questions)
> *Subject: *Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in
> ipam db tables
>
> 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
>>>
>>>
>>
>
> __________________________________________________________________________
> 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/b3197b6d/attachment-0001.html>