Re: [openstack-dev] [nova][keystone] Nova calls to Keystone
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
Re: [openstack-dev] [nova][keystone] Nova calls to Keystone
From: John Garbutt [j...@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 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? [[** 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-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. [[** * 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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
Re: [openstack-dev] [nova][keystone] Nova calls to Keystone
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
Re: [openstack-dev] [nova][keystone] Nova calls to Keystone
From: Adam Young [ayo...@redhat.com] Sent: 23 June 2015 08:00:48 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova][keystone] Nova calls to Keystone On 06/22/2015 10:13 PM, Sajeesh Cimson Sasi wrote: From: Adam Young [ayo...@redhat.commailto:ayo...@redhat.com] Sent: 23 June 2015 00:01:48 To: openstack-dev@lists.openstack.orgmailto: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. 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:unsubscribemailto: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. [[** Thank you Adam. I will check it best regards sajeesh __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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
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. 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. 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. __ 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
Re: [openstack-dev] [nova][keystone] Nova calls to Keystone
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. 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:unsubscribemailto: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 ? 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
Re: [openstack-dev] [nova][keystone] Nova calls to Keystone
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 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. 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. 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 __ 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
[openstack-dev] [nova][keystone] Nova calls to Keystone
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. 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
