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