Open Stack

On 06/22/2015 10:13 PM, Sajeesh Cimson Sasi wrote:
>
>
> ------------------------------------------------------------------------
> *From:* Adam Young [ayoung at redhat.com]
> *Sent:* 23 June 2015 00:01:48
> *To:* openstack-dev at lists.openstack.org
> *Subject:* Re: [openstack-dev] [nova][keystone] Nova calls to Keystone
>
> 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.
>
>
> Hi Adam,
>                Thanks a lot. I am not planning to talk to the live 
> keystone server in the unit test.
>                I don't think that I need to monkey patch the 
> KeystoneClient. In the nova api code, there are two methods 
> (get_parent_project and get_immediate_child_list),which uses 
> keystoneclient.I can monkey patch those two methods to return fixed 
> data according to a fake hierarchy. Am I right ?

Its not great, but not horrible.  It seems to match the scope of what 
you are testing.  However, you might want to consider doing a mock for 
the whole Keystoneclient call, as that really should beo utside of the 
unit test for the Nova code.


>               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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150622/9fec9032/attachment.html>