Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Kevin Benton]

There is something that isn't clear to me from your patch and based on your 
description of the workflow below. It sounds like you are following the basic 
L3 to ToR topology so each rack is a broadcast domain. If that’s the case, each 
rack should be a Neutron network and the mapping should be between racks and 
Networks, not racks and Subnets.

Also, can you elaborate a bit on the multiple gateway use case? If a subnet is 
isolated to a rack, wouldn’t all of the clients in that rack just want to use 
the ToR as their default gateway?


> On Nov 9, 2015, at 9:39 PM, Shraddha Pandhe  
> wrote:
> 
> Hi Carl,
> 
> Please find me reply inline
> 
> 
> On Mon, Nov 9, 2015 at 9:49 AM, Carl Baldwin  > wrote:
> On Fri, Nov 6, 2015 at 2:59 PM, Shraddha Pandhe  > wrote:
> 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].
> 
> This is precisely the use case that the large deployers team (LDT) has 
> brought to Neutron [1].  In fact, GoDaddy has been at the forefront of that 
> request.  We've had discussions about this since just after Vancouver on the 
> ML.  I've put up several specs to address it [2] and I'm working another 
> revision of it.  My take on it is that Neutron needs a model for a layer 3 
> network (IpNetwork) which would group the rack networks.  The IpNetwork would 
> be visible to the end user and there will be a network <-> host mapping.  I 
> am still aiming to have working code for this in Mitaka.  I discussed this 
> with the LDT in Tokyo and they seemed to agree.  We had a session on this in 
> the Neutron design track [3][4] though that discussion didn't produce 
> anything actionable.
> 
> Thats great. L3 layer network model is definitely one of our most important 
> requirements. All our go-forward deployments are going to be L3. So this is a 
> big deal for us. 
>  
> Solving this problem at the IPAM level has come up in discussion but I don't 
> have any references for that.  It is something that I'm still considering but 
> I haven't worked out all of the details for how this can work in a portable 
> way.  Could you describe how you imagine how this flow would work from a 
> user's perspective?  Specifically, when a user wants to boot a VM, what 
> precise API calls would be made to achieve this on your network and how where 
> would the IPAM data come in to play?
> 
> Here's what the flow looks like to me.
> 
> 1. User sends a boot request as usual. The user need not know all the network 
> and subnet information beforehand. All he would do is send a boot request.
> 
> 2. The scheduler will pick a node in an L3 rack. The way we map nodes <-> 
> racks is as follows:
> a. For VMs, we store rack_id in nova.conf on compute nodes
> b. For Ironic nodes, right now we have static IP allocation, so we 
> practically know which IP we want to assign. But when we move to dynamic 
> allocation, we would probably use 'chassis' or 'driver_info' fields to store 
> the rack id.
> 
> 3. Nova compute will try to pick a network ID for this instance.  At this 
> point, it needs to know what networks (or subnets) are available in this 
> rack. Based on that, it will pick a network ID and send port creation request 
> to Neutron. At Yahoo, to avoid some back-and-forth, we send a fake network_id 
> and let the plugin do all the work.
> 
> 4. We need some information associated with the network/subnet that tells us 
> what rack it belongs to. Right now, for VMs, we have that information 
> embedded in physnet name. But we would like to move away from that. If we had 
> a column for subnets - e.g. tag, it would solve our problem. Ideally, we 
> would like a column 'rack id' or a new table 'racks' that maps to subnets, or 
> something. We are open to different ideas that work for everyone. This is 
> where IPAM can help.
> 
> 5. We have another requirement where we want to store multiple gateway 
> addresses for a subnet, just like name servers.
> 
> 
> We also have a requirement where we want to make scheduling decisions based 
> on IP availability. We want to allocate multiple IPs to the hosts. e.g. We 
> want to allocate X IPs to a host. The flow in that case would be
> 
> 1. User sends a boot request with --num-ips X
> The network/subnet level complexities need not be exposed to the user. 
> For 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Carl Baldwin]

On Mon, Nov 9, 2015 at 1:39 PM, Shraddha Pandhe
 wrote:
> Thats great. L3 layer network model is definitely one of our most important
> requirements. All our go-forward deployments are going to be L3. So this is
> a big deal for us.

I think we're on a good path to getting this figured out over the next
two releases.  I plan to work out booting a VM to an IpNetwork in
Mitaka and then a few more heavy lifting migrations and API additions
will follow in the N release.

>> Solving this problem at the IPAM level has come up in discussion but I
>> don't have any references for that.  It is something that I'm still
>> considering but I haven't worked out all of the details for how this can
>> work in a portable way.  Could you describe how you imagine how this flow
>> would work from a user's perspective?  Specifically, when a user wants to
>> boot a VM, what precise API calls would be made to achieve this on your
>> network and how where would the IPAM data come in to play?
>
>
> Here's what the flow looks like to me.
>
> 1. User sends a boot request as usual. The user need not know all the
> network and subnet information beforehand. All he would do is send a boot
> request.
>
> 2. The scheduler will pick a node in an L3 rack. The way we map nodes <->
> racks is as follows:
> a. For VMs, we store rack_id in nova.conf on compute nodes
> b. For Ironic nodes, right now we have static IP allocation, so we
> practically know which IP we want to assign. But when we move to dynamic
> allocation, we would probably use 'chassis' or 'driver_info' fields to store
> the rack id.
>
> 3. Nova compute will try to pick a network ID for this instance.  At this
> point, it needs to know what networks (or subnets) are available in this
> rack. Based on that, it will pick a network ID and send port creation
> request to Neutron. At Yahoo, to avoid some back-and-forth, we send a fake
> network_id and let the plugin do all the work.
>
> 4. We need some information associated with the network/subnet that tells us
> what rack it belongs to. Right now, for VMs, we have that information
> embedded in physnet name. But we would like to move away from that. If we
> had a column for subnets - e.g. tag, it would solve our problem. Ideally, we
> would like a column 'rack id' or a new table 'racks' that maps to subnets,
> or something. We are open to different ideas that work for everyone. This is
> where IPAM can help.
>
> 5. We have another requirement where we want to store multiple gateway
> addresses for a subnet, just like name servers.

Do you have a more detailed description around this use case for
multiple gateways?

> We also have a requirement where we want to make scheduling decisions based
> on IP availability. We want to allocate multiple IPs to the hosts. e.g. We
> want to allocate X IPs to a host. The flow in that case would be

I will soon (today hopefully) post an update to my spec [1] outlining
how I envision the flow will be.  I don't plan to store any
information in IPAM for my use cases but the networking-calico project
may still want to pursue some enhancements to the interface to allow
this down the road.

I need to think about your request for more than one IP on the port.
This is a use case that I had not previously considered.  Thanks for
bringing it up.

Carl

[1] https://review.openstack.org/#/c/225384/

> 1. User sends a boot request with --num-ips X
> The network/subnet level complexities need not be exposed to the user.
> For better experience, all we want our users to tell us is the number of IPs
> they want.
>
> 2. When the scheduler tries to find an appropriate host in L3 racks, we want
> it to find a rack that can satisfy this IP requirement. So, the scheduler
> will basically say, "give me all racks that have >X IPs available". If we
> have a 'Racks' table in IPAM, that would help.
> Once the scheduler gets a rack, it will apply remaining filters to
> narrow down to one host and call nova-compute. The IP count will be
> propagated to nova compute from scheduler.
>
>
> 3. Nova compute will call Neutron and send the node details and IP count
> along. Neutron IPAM driver will then look at the node details, query the
> database to find a network in that rack and allocate X IPs from the subnet.

__
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

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Doug Wiegley]

> On Nov 5, 2015, at 1:24 PM, Shraddha Pandhe  
> 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.

I’d be careful on nomenclature here. What you indicate with the blobs becomes 
an api change, and thus has all the warts previously mentioned.

If what you want is simply a way for a specific driver/plugin/vendor to store 
more data, that can be done with a driver/plugin/vendor specific db table, with 
an association id back to the general table. That can be done now, without any 
api impact or approval.

So are you saying you want to extend the db schema dynamically (allowed today), 
or you want to extend the public interface dynamically (not allowed, except in 
the case of entirely new api extensions) ?

Thanks,
doug

> 
> 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  > wrote:
> On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes  > 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
>  
> >> 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 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Carl Baldwin]

On Fri, Nov 6, 2015 at 2:59 PM, Shraddha Pandhe  wrote:
>
> 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].
>

This is precisely the use case that the large deployers team (LDT) has
brought to Neutron [1].  In fact, GoDaddy has been at the forefront of that
request.  We've had discussions about this since just after Vancouver on
the ML.  I've put up several specs to address it [2] and I'm working
another revision of it.  My take on it is that Neutron needs a model for a
layer 3 network (IpNetwork) which would group the rack networks.  The
IpNetwork would be visible to the end user and there will be a network <->
host mapping.  I am still aiming to have working code for this in Mitaka.
I discussed this with the LDT in Tokyo and they seemed to agree.  We had a
session on this in the Neutron design track [3][4] though that discussion
didn't produce anything actionable.

Solving this problem at the IPAM level has come up in discussion but I
don't have any references for that.  It is something that I'm still
considering but I haven't worked out all of the details for how this can
work in a portable way.  Could you describe how you imagine how this flow
would work from a user's perspective?  Specifically, when a user wants to
boot a VM, what precise API calls would be made to achieve this on your
network and how where would the IPAM data come in to play?

Carl

[1] https://bugs.launchpad.net/neutron/+bug/1458890
[2] https://review.openstack.org/#/c/225384/
[3] https://etherpad.openstack.org/p/mitaka-neutron-next-network-model
[4] https://www.openstack.org/summit/tokyo-2015/schedule/design-summit
__
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

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Shraddha Pandhe]

Hi Carl,

Please find me reply inline


On Mon, Nov 9, 2015 at 9:49 AM, Carl Baldwin  wrote:

> On Fri, Nov 6, 2015 at 2:59 PM, Shraddha Pandhe <
> spandhe.openst...@gmail.com> wrote:
>>
>> 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].
>>
>
> This is precisely the use case that the large deployers team (LDT) has
> brought to Neutron [1].  In fact, GoDaddy has been at the forefront of that
> request.  We've had discussions about this since just after Vancouver on
> the ML.  I've put up several specs to address it [2] and I'm working
> another revision of it.  My take on it is that Neutron needs a model for a
> layer 3 network (IpNetwork) which would group the rack networks.  The
> IpNetwork would be visible to the end user and there will be a network <->
> host mapping.  I am still aiming to have working code for this in Mitaka.
> I discussed this with the LDT in Tokyo and they seemed to agree.  We had a
> session on this in the Neutron design track [3][4] though that discussion
> didn't produce anything actionable.
>
> Thats great. L3 layer network model is definitely one of our most
important requirements. All our go-forward deployments are going to be L3.
So this is a big deal for us.


> Solving this problem at the IPAM level has come up in discussion but I
> don't have any references for that.  It is something that I'm still
> considering but I haven't worked out all of the details for how this can
> work in a portable way.  Could you describe how you imagine how this flow
> would work from a user's perspective?  Specifically, when a user wants to
> boot a VM, what precise API calls would be made to achieve this on your
> network and how where would the IPAM data come in to play?
>

Here's what the flow looks like to me.

1. User sends a boot request as usual. The user need not know all the
network and subnet information beforehand. All he would do is send a boot
request.

2. The scheduler will pick a node in an L3 rack. The way we map nodes <->
racks is as follows:
a. For VMs, we store rack_id in nova.conf on compute nodes
b. For Ironic nodes, right now we have static IP allocation, so we
practically know which IP we want to assign. But when we move to dynamic
allocation, we would probably use 'chassis' or 'driver_info' fields to
store the rack id.

3. Nova compute will try to pick a network ID for this instance.  At this
point, it needs to know what networks (or subnets) are available in this
rack. Based on that, it will pick a network ID and send port creation
request to Neutron. At Yahoo, to avoid some back-and-forth, we send a fake
network_id and let the plugin do all the work.

4. We need some information associated with the network/subnet that tells
us what rack it belongs to. Right now, for VMs, we have that information
embedded in physnet name. But we would like to move away from that. If we
had a column for subnets - e.g. tag, it would solve our problem. Ideally,
we would like a column 'rack id' or a new table 'racks' that maps to
subnets, or something. We are open to different ideas that work for
everyone. This is where IPAM can help.

5. We have another requirement where we want to store multiple gateway
addresses for a subnet, just like name servers.


We also have a requirement where we want to make scheduling decisions based
on IP availability. We want to allocate multiple IPs to the hosts. e.g. We
want to allocate X IPs to a host. The flow in that case would be

1. User sends a boot request with --num-ips X
The network/subnet level complexities need not be exposed to the user.
For better experience, all we want our users to tell us is the number of
IPs they want.

2. When the scheduler tries to find an appropriate host in L3 racks, we
want it to find a rack that can satisfy this IP requirement. So, the
scheduler will basically say, "give me all racks that have >X IPs
available". If we have a 'Racks' table in IPAM, that would help.
Once the scheduler gets a rack, it will apply remaining filters to
narrow down to one host and call nova-compute. The IP count will be
propagated to nova compute from scheduler.


3. Nova compute will call Neutron and send the node details and IP count
along. Neutron IPAM driver will then look at the node details, query the
database to find a network in that rack and allocate X IPs from the subnet.



> Carl
>
> [1] 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Shraddha Pandhe]

Gary,

I agree. Moving away from that option, I am trying to propose the idea of
extended IPAM tables: https://bugs.launchpad.net/neutron/+bug/1513981 and
https://review.openstack.org/#/c/242688/

On Sun, Nov 8, 2015 at 12:10 AM, Gary Kotton <gkot...@vmware.com> wrote:

> I think that id we can move to a versioned object model model then it will
> be better. Having random json blobs passed around is going to cause
> problems.
>
> From: "Armando M." <arma...@gmail.com>
> Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
> Date: Wednesday, November 4, 2015 at 11:38 PM
> To: OpenStack List <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam
> db tables
>
>
>
> 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. Ultimately, we should be able to identify how to
> model these extensions you're thinking of both conceptually and logically.
>
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ___

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Gary Kotton]

I think that id we can move to a versioned object model model then it will be 
better. Having random json blobs passed around is going to cause problems.

From: "Armando M." <arma...@gmail.com<mailto:arma...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, November 4, 2015 at 11:38 PM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db 
tables



On 4 November 2015 at 13:21, Shraddha Pandhe 
<spandhe.openst...@gmail.com<mailto: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. Ultimately, we should be able to identify how to model these 
extensions you're thinking of both conceptually and logically.

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<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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Shraddha Pandhe]

Replies inline.


On Fri, Nov 6, 2015 at 1:48 PM, Salvatore Orlando 
wrote:

> More comments inline.
> I shall stop trying being ironic (pun intended) in my posts.
>

:(


>
> Salvatore
>
> On 5 November 2015 at 18:37, Kyle Mestery  wrote:
>
>> On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes  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.
>>
>
> I see I did not manage to convey accurately irony and sarcasm in my
> previous post ;)
> The point was that thanks to a blooming number of extensions the Neutron
> API is already hardly portable. Blob attributes (or dict attributes, or
> key/value list attributes, or whatever does not have a precise schema) are
> a nail in the coffin, and also violate the only tenet Neutron has somehow
> managed to honour, which is being backend agnostic.
> And the fact that the port binding extension is pretty much that is not a
> valid argument, imho.
> On the other hand, I'm all in for extending DB schema and driver logic to
> suit all IPAM needs; at the end of the day that's what do with plugins for
> all sort of stuff.
>


Agreed. Filed an rfe bug: https://bugs.launchpad.net/neutron/+bug/1513981.
Spec coming up for review.



>
>
>
>>
>>
>>>
>>> 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.
>>
>
> Cool, but let me point out that experience has thought us that anything
> that is a result of a compromise between several parties following
> different agendas is bound to failure as it does not fully satisfy the
> requirements of any stakeholder.
> If these information are needed for making scheduling decisions based on
> network requirements, then it makes sense to expose this information also
> at the API layer (I assume there also plans for making the scheduler
> *seriously* network aware). However, this information should have a
> well-defined schema with no leeway for 'extensions; such schema can evolve
> over time.
>
>
>> 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
 > 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
 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Shraddha Pandhe]

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  wrote:
>
>> On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes  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
 > 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 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Neil Jerram]

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?

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.

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<mailto: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<mailto:mest...@mestery.com>> wrote:
On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes 
<jaypi...@gmail.com<mailto: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> 
<mailto:salv.orla...@gmail.com<mailto:salv.orla...@gmail.com>>> wrote:

Arbitrary blobs are a powerful tools to circumvent limitations of an
API, 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Salvatore Orlando]

More comments inline.
I shall stop trying being ironic (pun intended) in my posts.

Salvatore

On 5 November 2015 at 18:37, Kyle Mestery  wrote:

> On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes  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.
>

I see I did not manage to convey accurately irony and sarcasm in my
previous post ;)
The point was that thanks to a blooming number of extensions the Neutron
API is already hardly portable. Blob attributes (or dict attributes, or
key/value list attributes, or whatever does not have a precise schema) are
a nail in the coffin, and also violate the only tenet Neutron has somehow
managed to honour, which is being backend agnostic.
And the fact that the port binding extension is pretty much that is not a
valid argument, imho.
On the other hand, I'm all in for extending DB schema and driver logic to
suit all IPAM needs; at the end of the day that's what do with plugins for
all sort of stuff.



>
>
>>
>> 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.
>

Cool, but let me point out that experience has thought us that anything
that is a result of a compromise between several parties following
different agendas is bound to failure as it does not fully satisfy the
requirements of any stakeholder.
If these information are needed for making scheduling decisions based on
network requirements, then it makes sense to expose this information also
at the API layer (I assume there also plans for making the scheduler
*seriously* network aware). However, this information should have a
well-defined schema with no leeway for 'extensions; such schema can evolve
over time.


> 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
>>> > 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
>>> >
>>> wrote:
>>>
>>> Hi folks,
>>>
>>> I have a small 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Shraddha Pandhe]

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

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Germy Lure]

I don't know if this would make more sense. Let's assume that
we add arbitrary blobs(ABs) to IPAM even every neutron object. What
would happen? People can do anything via those APIs. Any new
attribute even the whole model could be passed through those
so-called ABs. Except the architecture issues, I think people like
Shraddha would never report any case to the community. People even
didn't need the community. Because they even can define an object
contains only id and AB. eg. Port like this:
{
"id":"" #uuid format
"params":{} # a json dictionary
}
Everything can be filled in this *Big Box*. Is that an API?

But on the other hand, If we don't have such a block. People must
extend API and extra tables themselves or push community approve
and merge the feature which will be a long cycle. In the end, people
would think that Neutron is so bad to use it with so many limitations
and update like a snail.

It's difficult, but it's time to make a decision. OK, I prefer adding it.

Thanks.
Germy
.
__
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

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Jay Pipes]

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.



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.


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
> 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
>
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: 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Jim Rollenhagen]

On Thu, Nov 05, 2015 at 11:55:50AM -0500, Jay Pipes 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.
> 
> >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.

Right, this has caused Ironic some pain in the past (though it does make
it easier for drivers to add some random info they need). I'd like to
try to move away from this sometime soon(tm).

// jim

> 
> 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.
> 
> 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
> >> 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
> >>
> >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
> >

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Kyle Mestery]

On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes  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
>> > 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
>> >
>> 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)
>> 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Shraddha Pandhe]

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  wrote:

> On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes  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
>>> > 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
>>> 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[John Belamaric]

If you have custom data you want to keep for your driver, you should create 
your own database tables to track that information. For example, the reference 
driver creates its own tables to track its data in ipam* tables.

John

On Nov 4, 2015, at 3:46 PM, Shraddha Pandhe 
> 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

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Shraddha Pandhe]

On Wed, Nov 4, 2015 at 1:38 PM, Armando M.  wrote:

>
>
> On 4 November 2015 at 13:21, 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.
>>
>> 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 > > 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:
 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Shraddha Pandhe]

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.


Hoping to get some positive feedback from API and DB lieutenants too.


On Wed, Nov 4, 2015 at 1:06 PM, Salvatore Orlando 
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 
> 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

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Salvatore Orlando]

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 
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-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Shraddha Pandhe]

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

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Armando M.]

On 4 November 2015 at 13:21, 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.
>
> 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. Ultimately, we should be able to identify how to
model these extensions you're thinking of both conceptually and logically.

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 
> 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 > > 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

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Joshua Harlow]

Shraddha Pandhe wrote:



On Wed, Nov 4, 2015 at 3:12 PM, Kevin Benton > wrote:

>If we add our own database for internal stuff, we go back to the
same problem of allowing bad design.

I'm not sure I understand what you are saying here. A JSON blob that
only one driver knows how to interpret is worse than a vendor table.

I am only talking about the IPAM tables here. The reference
implementation doesn't need to play with JSON blob at all. Rather I
would say, it shouldn't. It can be left up to the vendors/users to
manage that blob responsibly. I can create my own database and point my
IPAM module to that, but then IPAM tables are practically useless for
me. The only reason for suggesting the blob is flexibility, which is the
main reason for pluggability of IPAM.

They both are specific to one driver but at least with a vendor
table you can have DB migrations, integrity, column queries, etc.
Additionally, the vendor table with extra features exposed via an
API extension makes it more clear to the API caller what is vendor
specific.


I agree that thats a huge advantage of having a db. But sometimes, it
may not be absolutely necessary to have an extra DB.

e.g. For multiple gateways support, a separate database would probably
add more overhead than required. All I want is to be able to fetch those
IPs.

The user can take a responsible decision whether to use the blob or the
database depending on the requirement, if they have the flexibility.

Can you elaborate what you mean by bad design?

When we are working on internal features, we have to follow different
timelines. Having an arbitrary blob can sometimes make us use that by
default, especially under pressing deadlines, instead of consulting with
broader audience and finding the right solution.


Just my 2 cents, and I know this since I'm on the team shraddha is on, 
but the above isn't really that great of an excuse for having/adding 
arbitrary blob(s); thinking long-term and figuring out what is really 
required (and perhaps that ends up being a structured format vs a json 
blob) is usually the better way of dealing with these types of issues 
(knowingly fully well that it is not always possible).


Everyone in every company has different timelines and that (IMHO) 
shouldn't be a 'way out' of consulting with a broader audience and 
finding the right solution...




On Nov 4, 2015 3:58 PM, "Shraddha Pandhe"
>
wrote:



On Wed, Nov 4, 2015 at 1:38 PM, Armando M. > wrote:



On 4 November 2015 at 13:21, 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.

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 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Kevin Benton]

>If we add our own database for internal stuff, we go back to the same
problem of allowing bad design.

I'm not sure I understand what you are saying here. A JSON blob that only
one driver knows how to interpret is worse than a vendor table. They both
are specific to one driver but at least with a vendor table you can have DB
migrations, integrity, column queries, etc. Additionally, the vendor table
with extra features exposed via an API extension makes it more clear to the
API caller what is vendor specific.

Can you elaborate what you mean by bad design?
On Nov 4, 2015 3:58 PM, "Shraddha Pandhe" 
wrote:

>
>
> On Wed, Nov 4, 2015 at 1:38 PM, Armando M.  wrote:
>
>>
>>
>> On 4 November 2015 at 13:21, 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.
>>>
>>> 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 

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Shraddha Pandhe]

On Wed, Nov 4, 2015 at 3:12 PM, Kevin Benton  wrote:

> >If we add our own database for internal stuff, we go back to the same
> problem of allowing bad design.
>
> I'm not sure I understand what you are saying here. A JSON blob that only
> one driver knows how to interpret is worse than a vendor table.
>
I am only talking about the IPAM tables here. The reference implementation
doesn't need to play with JSON blob at all. Rather I would say, it
shouldn't. It can be left up to the vendors/users to manage that blob
responsibly. I can create my own database and point my IPAM module to that,
but then IPAM tables are practically useless for me. The only reason for
suggesting the blob is flexibility, which is the main reason for
pluggability of IPAM.


> They both are specific to one driver but at least with a vendor table you
> can have DB migrations, integrity, column queries, etc. Additionally, the
> vendor table with extra features exposed via an API extension makes it more
> clear to the API caller what is vendor specific.
>

I agree that thats a huge advantage of having a db. But sometimes, it may
not be absolutely necessary to have an extra DB.

e.g. For multiple gateways support, a separate database would probably add
more overhead than required. All I want is to be able to fetch those IPs.

The user can take a responsible decision whether to use the blob or the
database depending on the requirement, if they have the flexibility.

Can you elaborate what you mean by bad design?
>
When we are working on internal features, we have to follow different
timelines. Having an arbitrary blob can sometimes make us use that by
default, especially under pressing deadlines, instead of consulting with
broader audience and finding the right solution.



> On Nov 4, 2015 3:58 PM, "Shraddha Pandhe" 
> wrote:
>
>>
>>
>> On Wed, Nov 4, 2015 at 1:38 PM, Armando M.  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