On Tue, Jun 23, 2015 at 5:48 AM, John Garbutt <j...@johngarbutt.com> wrote:

> On 23 June 2015 at 03:30, Adam Young <ayo...@redhat.com> wrote:
> > On 06/22/2015 10:13 PM, Sajeesh Cimson Sasi wrote:
> > ________________________________
> > From: Adam Young [ayo...@redhat.com]
> > Sent: 23 June 2015 00:01:48
> > To: openstack-dev@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?
>
>
Unfortunately no, the project hierarchy information is only available in
the GET /projects API - having this in the token so it could live in the
context could be a nice improvement (although this would need to feasible
for all types of tokens).


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

Maybe point out where he can find similar tests?

Thanks!


>
> Thanks,
> John
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rodrigo Duarte Sousa
Senior Software Engineer at Advanced OpenStack Brazil
Distributed Systems Laboratory
MSc in Computer Science
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://rodrigods.com <http://lsd.ufcg.edu.br/%7Erodrigods>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to