[openstack-dev] [nova][keystone] Nova calls to Keystone
ayoung at redhat.com
Tue Jun 23 02:30:48 UTC 2015
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.
>> 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
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev