Open Stack

________________________________________
From: John Garbutt [john at johngarbutt.com]
Sent: 23 June 2015 14:18:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][keystone] Nova calls to Keystone

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?

[[**
****
 Initially there was a plan to keep the hierarchy information in the keystone token itself.
But that plan  was dropped mainly because of the concerns regarding the size of the token.
Some other reasons also might be there. Currently , hierarchy info need to retrieved separately. 
*****
**]]


>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.
[[**
*********
 If the hierarchy info was there in the token itself, I could have easily 
followed the existing Nova unit tests. Now I am afraid that  I have to do
something  different.

*********
**]]

Thanks,
John

__________________________________________________________________________
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