[openstack-dev] [nova][keystone] Nova calls to Keystone

Adam Young ayoung at redhat.com
Mon Jun 22 18:31:48 UTC 2015

On 06/20/2015 02:46 PM, Sajeesh Cimson Sasi wrote:
> Hi All,
>    I need your advice for the implementation of the following 
> blueprint. https://review.openstack.org/#/c/160605 
> <https://review.openstack.org/#/c/160605> .
>    All the use cases mentioned in the blueprint have  been implemented 
> and the complete code is up for review.
> https://review.openstack.org/#/c/149828/
>   However, we have an issue on which we need your input. In the nova 
> quota api call, keystone calls are made to
>   get the parent_id and the child project or sub project list. This is 
> required because nova doesn't store any information
>   regarding the hierarchy. Hierarchy Information is  taken during run 
> time,  from keystone. Since the keystone calls are
>   made inside the api call, it is not possible to give any dummy or  
> fake values while writing the unit tests. If the keystone
>   call was made outside the api call, we could have given fake values 
> in the test cases. However,  the keystone calls for
>    parent_id and child projects are made inside the api call.
>   Can anyone suggest an elegant solution to this problem? What is the 
> proper way to implement this ?
>     Did anybody encounter and solve a  similar  problem ? Many thanks 
> for any suggestions!
>          best regards
>            sajeesh
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
If you are talking to a live Keystone server, make sure you are using 
valid data.

If you are not talking to a live keystone server in a unit test, use 
RequestsMock or equivalent (varied by project)  to handle the HTTP 
request and response.

A worst case approach is to monkey patch the Keystoneclient.  Please 
don't do that if you can avoid it;  better to provide a mock alternative.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150622/b3fba707/attachment.html>

More information about the OpenStack-dev mailing list