Open Stack

zhi <changzhi1990 at gmail.com> wrote:

> hi, all.
>
>     I have faced some strange problems when getting LBaaS resources, such as loadbalancers, listeners, pools, etc.
>
>     For example, when I send a request which only filtering "id" attribute, like this:
>
> >>> curl -g -i -X GET  
> http://10.0.44.233:9696/v2.0/lbaas/listeners.json?fields=id \
> -H "User-Agent: python-neutronclient" \
> -H "Accept: application/json" \
> -H "X-Auth-Token: xxx"
>
> >>> {"listeners": [{"protocol_port": 9998, "protocol": "HTTP",  
> "description": "", "default_tls_container_ref": null, "admin_state_up":  
> false, "loadbalancers": [{"id": "509781c5-4bab-42e6-99d5-343c991f018b"}],  
> "sni_container_refs": [], "connection_limit": -1, "default_pool_id":  
> null, "id": "e55cec57-060f-4d22-9b7c-1c37f612a4cd", "name": ""},  
> {"protocol_port": 99, "protocol": "HTTP", "description": "",  
> "default_tls_container_ref": null, "admin_state_up": true,  
> "loadbalancers": [{"id": "509781c5-4bab-42e6-99d5-343c991f018b"}],  
> "sni_container_refs": [], "connection_limit": -1, "default_pool_id":  
> "b360fc75-b23d-46a3-b936-6c9480d35219", "id":  
> "f8392236-e065-4aa2-a4ef-d6c6821cc038", "name": ""}, {"protocol_port":  
> 9998, "protocol": "HTTP", "description": "", "default_tls_container_ref":  
> null, "admin_state_up": true, "loadbalancers": [{"id":  
> "744b68a0-f08f-459a-ab7e-c43a6cb3b299"}], "sni_container_refs": [],  
> "connection_limit": -1, "default_pool_id":  
> "83a9d8ed-017b-412d-89c8-bd1e36295d81", "id":  
> "c6ff129c-96c5-4121-b0dd-2258016b2f36", "name": ""}]}
>
>
>     API returns all the information about  the listeners rather only the "id" attribute. This problem also exists in every LBaaS resource, such loadbalaners, pools, etc.
>
>     I have already registered a bug in launchpad[1], and there is a patch to solve this problem about pools resource[2]. But I don't know if my solution is correctly. ;-(
>
>     Could someone give me some advice?

I actually believe that it’s an issue in neutron itself: I believe that its  
API layer should handle the needed filtering, including for passed in  
fields list.

We have a patch in progress that guard against plugins returning fields  
that are not defined in active attribute map:  
https://review.openstack.org/#/c/352809/

We should probably think about a similar approach in the base controller  
code to do the needed filtering as per fields query passed.

Ihar