Hi Neil, Please find my reply inline.
On Fri, Nov 6, 2015 at 1:08 PM, Neil Jerram <neil.jer...@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.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 > >
__________________________________________________________________________ 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
