<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 4, 2015 at 1:38 PM, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 4 November 2015 at 13:21, Shraddha Pandhe <span dir="ltr"><<a href="mailto:spandhe.openstack@gmail.com" target="_blank">spandhe.openstack@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Salvatore,<div><br></div><div>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.</div><div><br></div><div>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. </div></div></blockquote><div><br></div></span><div>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</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Most importantly though, I feel it's like abdicating our responsibility to do a good design job.</div></div></div></div></blockquote><div> </div><div> </div><div>How does it affect portability?</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div><a href="https://bugs.launchpad.net/neutron/+bug/1464361">https://bugs.launchpad.net/neutron/+bug/1464361</a></div><div> </div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>If we add our own database for internal stuff, we go back to the same problem of allowing bad design.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Ultimately, we should be able to identify how to model these extensions you're thinking of both conceptually and logically.</div></div></div></div></blockquote><div><br></div><div>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. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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 :)</div><div><div class="h5"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div>Hoping to get some positive feedback from API and DB <span style="font-size:13px">lieutenants too.</span></div><div><span style="font-size:13px"><br></span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 4, 2015 at 1:06 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:salv.orlando@gmail.com" target="_blank">salv.orlando@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.<div>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.</div><div><br></div><div>Therefore this would make a lot of sense, assuming API portability and not leaking backend details are not a concern.</div><div>The Neutron team API & DB lieutenants will be able to provide more input on this regard.</div><div><br></div><div>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.</div><span><font color="#888888"><div><br></div><div>Salvatore</div></font></span><div><div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 4 November 2015 at 21:46, Shraddha Pandhe <span dir="ltr"><<a href="mailto:spandhe.openstack@gmail.com" target="_blank">spandhe.openstack@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr"><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'">Hi folks,</div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'"><br></div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'">I have a small question/suggestion about IPAM.<br></div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'"><br></div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'">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.</div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'"><br></div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'">Does this make sense?</div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'"><br></div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'">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.</div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'"><br></div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'">Any thoughts? If there are any other way to solve the problem, please let me know<br></div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'"><br></div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'"><br></div><div style="padding:1px 5px;margin-bottom:3px;color:rgb(0,0,0);font-family:'Lucida Grande'"><br></div></div>
<br></div></div><span>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></span></blockquote></div><br></div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>