Open Stack

On 23 June 2015 at 03:30, Adam Young <ayoung at redhat.com> wrote:
> 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 .
>    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.

This is maybe a dumb question, but...

Could this information not come from the keystone middleware at the
same time we get all the other identity information, and just live in
the context?

>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.
>

Please use mock to do that for you, following the pattern of the
existing Nova unit tests. I think you will find that easier.

Thanks,
John