<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">More inline,</div><div class="gmail_quote">Salvatore</div><div class="gmail_quote"><br></div><div class="gmail_quote">On 20 January 2016 at 16:51, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you all for the comments.<div><br></div><div>The client that we expect to call this API with thousands of network-ids is nova-scheduler.</div><div><br></div><div>Since this call is happening in the middle of scheduling, we don't want to spend time in paginating or sending multiple requests. I have tens of thousands of networks and subnets in my test cluster right now and with that scale, the extension takes more than 2 seconds to return. </div></div></blockquote><div><br></div><div>What percentage of this time is spent in the GET /v2.0/networks call?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>With multiple calls, scheduler will become very slow.</div></div></blockquote><div><br></div><div>If the calls are serialized that is surely correct. As most production neutron servers employ multiple workers the overhead of doing multiple calls in parallel might however be tolerable.</div><div>I'd like to understand more about your use case. Here are some additional questions</div><div><br></div><div>Is network-id the only attribute you can filter on?<br></div><div>Assuming Neutron provided tags in the API could you leverage those?<br></div><div>Why is not tenant-id a viable alternative?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I agree that sending payload with GET is not recommended and most libraries just drop the payload for such cases.</div></div></blockquote><div><br></div><div>Nevertheless, we're pretty much in control of that. We've already discussed this, and doing so does not violate RFC7231, so it's ok from a protocol perspective.</div><div>If needed, we can tweak the API request processing workflow for allowing this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 2:27 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I tend to agree with Doug and Ryan's stance. If you need to pass 1000s of network-id on a single request you're probably not doing things right on the client side.<div>As Ryan suggested you can try and split the request in multiple requests with acceptable URI lenght and send them in parallel; this will add some overhead, but should work flawlessly.</div><div><br></div><div>Once tags will be implemented you will be able to leverage those to simplify your queries.</div><div><br></div><div>Regarding GET requests with plenty of parameters, this discussion came up on the mailing list a while ago [1]. A good proposal was made in that thread but never formalised as an API-wg guideline; you consider submitting a patch to the API-wg too.</div><div>Note however that Neutron won't be able to support it out of the box considering its WSGI framework completely ignores request bodies on GET requests.</div><div><br></div><div>Salvatore</div><div><br></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-November/078243.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-November/078243.html</a></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 20 January 2016 at 12:33, Ryan Brown <span dir="ltr"><<a href="mailto:rybrown@redhat.com" target="_blank">rybrown@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So having a URI too long error is, in this case, likely an indication that you're requesting too many things at once.<br>
<br>
You could:<br>
1. Request 100 at a time in parallel<br>
2. Find a query that would give you all those networks & page through the reply<br>
3. Page through all the user's networks and filter client-side<br>
<br>
How is the user supposed to be assembling this giant UUID list? I'd think it would be easier for them to specify a query (e.g. "get usage data for all my production subnets" or something).<div><div><br>
<br>
On 01/19/2016 06:59 PM, Shraddha Pandhe wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
Hi folks,<br>
<br>
<br>
I am writing a Neutron extension which needs to take 1000s of<br>
network-ids as argument for filtering. The CURL call is as follows:<br>
<br>
curl -i -X GET<br>
'http://hostname:port/neutron/v2.0/extension_name.json?net-id=fffecbd1-0f6d-4f02-aee7-ca62094830f5&net-id=fffeee07-4f94-4cff-bf8e-a2aa7be59e2e'<br>
-H "User-Agent: python-neutronclient" -H "Accept: application/json" -H<br>
"X-Auth-Token: cccccccccccccccccccccccccccccccc"<br>
<br>
<br>
The list of net-ids can go up to 1000s. The problem is, with such large<br>
url, I get the "Request URI too long" error. I don't want to update this<br>
limit as proxies can have their own limits.<br>
<br>
What options do I have to send 1000s of network IDs?<br>
<br>
1. -d '{}' is not a recommended option for GET call and wsgi Controller<br>
drops the data part when routing the request.<br>
<br>
2. Use POST instead of GET? I will need to write the get_<resource><br>
logic inside create_resource logic for this to work. Its a hack, but<br>
complies with HTTP standard.<br>
<br>
<br>
<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><span><font color="#888888">
<br>
-- <br>
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.</font></span><div><div><br>
<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>
</div></div></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><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><br></div></div>