<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hello mordred</div><div><br></div><div>I do not understand the need of "use_direct_get" parameter. Currently I can do the conn.list_servers(filters={"status": "ACTIVE", "name": "srv8-"})<br></div><div><br></div><div>And I see the corresponding request on the server side:</div><div>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div><div>REQ: curl -g -i -X GET "<a href="https://openstack:8774/v2.1/40e5d3f91fb44ccaa9056252efc243a7/servers/detail?name=srv8-&status=ACTIVE">https://openstack:8774/v2.1/40e5d3f91fb44ccaa9056252efc243a7/servers/detail?name=srv8-&status=ACTIVE</a>" -H "Accept: application/json" -H "User-Agent: openstacksdk/0.27.0 keystoneauth1/3.13.1 python-requests/2.21.0 CPython/3.6.5" -H "X-Auth-Token: {SHA256}900ab80fe15448ceec851db2c14e2993ecd9634cefb897e71573c6d9496f701d"<br>RESP: [200] Content-Length: 3645 Content-Type: application/json Date: Thu, 11 Apr 2019 08:15:57 GMT Openstack-Api-Version: compute 2.1 Vary: OpenStack-API-Version, X-OpenStack-Nova-API-Version X-Compute-Request-Id: req-e8622002-fb1d-4deb-8bf2-609d6a4b50c9 X-Openstack-Nova-Api-Version: 2.1<br>RESP BODY: {"servers": <...><br>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</div><div><br></div><div><br></div><div>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</div><div>2019-04-11 11:15:57.997 9810 INFO nova.osapi_compute.wsgi.server [req-e8622002-fb1d-4deb-8bf2-609d6a4b50c9 bbe117ded750704ba460feaabff6190c6b07c9acabc91066878cfca0c8362f48 40e5d3f91fb44ccaa9056252efc243a7 - 95ab4645f0764ac782765cbdcc79bbff 95ab4645f0764ac782765cbdcc79bbff] 172.30.202.194 "GET /v2.1/40e5d3f91fb44ccaa9056252efc243a7/servers/detail?name=srv8-&status=ACTIVE HTTP/1.1" status: 200 len: 3974 time: 0.2514541</div><div><br></div><div>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</div><div><br></div><div>Igor Tiunov<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пн, 8 апр. 2019 г. в 13:24, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 4/8/19 9:04 AM, Игорь Тиунов wrote:<br>
> Hi.<br>
> I saw that there some work regarding filtering in the inventory module. Also, I looked at how it will be used in future versions of ansible (os_server_facts module).<br>
> <br>
> I am worried about client-side nature of this filtering. The large deployments can have thousands of vms in one openstack project and such an environment can be very dynamic (vms are created/deleted frequently). The inventory collection can be done from multiple ansible management nodes and all these facts can lead to significant performance impact not only on the client side but on the server side also - a large amount of data will be requested from nova api servers.<br>
> I want to propose the usage of server-side filtering capability for nova API:<br>
> <br>
> <a href="https://developer.openstack.org/api-ref/compute/?expanded=list-servers-detail#list-servers" rel="noreferrer" target="_blank">https://developer.openstack.org/api-ref/compute/?expanded=list-servers-detail#list-servers</a><br>
> <br>
> These filters are used at database level and will add a significant performance boost during inventory collection.<br>
> I want to propose the usage of filters in ansible openstack inventory plugin but first, such filters should be implemented in openstacksdk level.<br>
> I suggest splitting filters into two parts - the api_filters and metadata_filters. The api_filters will be used for server-side filtering and metadata_filters for client-side filtering.<br>
> I have created the snippet with prototype code. There a _split_filters method and related changes for list_hosts and search_hosts methods:<br>
> <br>
> <a href="https://gist.github.com/ITD27M01/01bc73120bb97b237f53fa418dc83629" rel="noreferrer" target="_blank">https://gist.github.com/ITD27M01/01bc73120bb97b237f53fa418dc83629</a><br>
> <br>
> What do you think?<br>
<br>
Generally speaking, I think it's a good idea. However, there's a few <br>
things to be aware of that make this a little more complex. Namely - in <br>
addition to fire-and-forget programs like the os_ modules or the ansible <br>
inventory code, we also support users with long lives that do high <br>
volume interactions, such as nodepool. Unfortunately, in terms of <br>
efficiency, these two use cases want opposite things.<br>
<br>
For the short-term programs, as you mention, we want to maximize use of <br>
server-side filters. We also want to do things like use GET <br>
/servers/{id}. For the long-lived high-volume programs, we want to <br>
support a mode that combines caching and batching - rather than making <br>
1000 queries to the server a second each with their own server-side <br>
filter conditions, it's more efficient to make one call every 5 seconds, <br>
cache the result, and do client-side filtering.<br>
<br>
We're currently good at the second use case and less good at the first.<br>
<br>
We took a step towards being better at the first use case with the <br>
use_direct_get parameter. Use direct get tells openstacksk to use direct <br>
GET /servers/{id} type calls rather than filtering a full list locally <br>
when a single resource is wanted by id.<br>
<br>
We need to fix this for get_server for reasons <br>
<a href="https://review.openstack.org/#/c/540389/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/540389/</a>.<br>
<br>
We should also update the logic for the default value to set <br>
use_direct_get=True if caching is enabled, and set it to false if it <br>
isn't - that way normal people don't have to care.<br>
<br>
We should almost CERTAINLY start setting this parameter to True in all <br>
of the ansible modules and inventory (I think the cases in which we want <br>
use_direct_get=False for ansible are VERY explicit - it involves having <br>
caching enabled to use external caching like redis - and I think in <br>
those cases we can expect a user to set the flag explicitly in config)<br>
<br>
So I think what we should potentially do here is expand on that config <br>
flag and have it pushdown server-side filters. In fact, if you read the <br>
value of that in your _split_filters method, then split filters could <br>
either return things in api_filters or not. Then we can take the idea <br>
and push it down into the underlying code so that inventory is just <br>
calling search_severs ... or something. I'm sure we'll need to figure <br>
out some details once we get in to it.<br>
<br>
One additional thing that will make this slightly more complex - but <br>
also I believe might allow us to do a few hard patches and get a LOT of <br>
benefit across the SDK.<br>
<br>
Right now we have the 'cloud' layer which used to be the shade library, <br>
and we have the 'resource' layer which came from the openstacksdk <br>
library. They share almost nothing, other than the connection object and <br>
some Adapters, but we're working to change that. One of the next things<br>
on the list is to get the 'cloud' layer to be built on top of the <br>
'resource' layer for server interactions. We're already using the sdk <br>
layer for servers: <a href="https://review.openstack.org/#/c/530770" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/530770</a> (although as <br>
mentioned use_direct_get needs fixed) ...<br>
<br>
What I think would be BEST would be if we taught <br>
openstack.resource.Resource about use_direct_get - and then put your <br>
_split_filters logic in there (although I believe the equiv logic is <br>
already there, so it might just be a matter of harnessing it.<br>
<br>
I think we can certainly start with inventory - as well as changing the <br>
default for use_direct_get in the inventory module and in <br>
lib/ansible/module_utils/openstak.py.<br>
<br>
Monty<br>
<br>
</blockquote></div></div></div></div>