Re: [Openstack] Horizon Bug 1004412 Details
On Sat, Oct 6, 2012 at 7:09 PM, Gabriel Hurley wrote: > All of what you said is correct. Those filtering issues (which applied > to volumes, keypairs, and security groups at least) were tracked in > separate tickets in Nova and all got fixed towards the tail end of Folsom. > I don’t have the commits handy, sorry. The proper fix was filtering the > results returned from Nova correctly on that end; the fix on the ticket you > listed was only a defense against the problem on Horizon’s end. > > ** ** > > **- **Gabriel > > ** ** > > *From:* > openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net[mailto: > openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] *On > Behalf Of *Joe Topjian > *Sent:* Saturday, October 06, 2012 11:19 AM > *To:* openstack > *Subject:* [Openstack] Horizon Bug 1004412 Details > > ** ** > > Hello, > > ** ** > > I've been aware of Bug 1004412 ( > https://bugs.launchpad.net/horizon/+bug/1004412) in my Essex deployments > for a while and finally had some time to look into it in detail. > > ** ** > > I believe I have found the cause and wanted to discuss what I found vs how > it was fixed in the patch. > > ** ** > > From what I can see, when an admin requests a list of volumes, all volumes > in the cloud are returned. But when an admin requests a list of instances, > only instances owned by the admin are returned -- unless an option to > return all instances is specified. > > ** ** > > Because of these two distinct actions, the chances of a KeyError happening > when visiting /nova/instances_and_volumes is extremely high once other > projects begin working in the OpenStack environment: all volumes from all > projects are returned but only admin instances are returned, so any volume > attached in another project cannot find its corresponding instance. > > ** ** > > I see two proper solutions to this issue: either only return volumes owned > by the admin or return all instances in all projects by default. I was > unable to figure out (without doing too many changes) how to filter > volumes, so I decided on the latter solution. In views.py, I modified the > call to get a list of instances to be: > > ** ** > > if self.request.user.is_admin(): > > self._instances_list = api.server_list(self.request, > all_tenants=True) > > else: > > self._instances_list = api.server_list(self.request) > > ** ** > > Without looking at the implementation details, but instead what the > implementation is trying to achieve, I do not see this same issue being > resolved in the patch ( > https://github.com/openstack/horizon/commit/155bfb72c1b5f866236928f4ffd0c2567dc556f3 > ). > > ** ** > > My question is if I have incorrectly assessed the issue or if the patch is > taking other things into account that I'm not aware of? > > ** ** > > Thanks, > > Joe > > > > > ** ** > > -- > Joe Topjian > > Systems Administrator > > Cybera Inc. > > ** ** > > www.cybera.ca > > ** ** > > Cybera is a not-for-profit organization that works to spur and support > innovation, for the economic benefit of Alberta, through the use > of cyberinfrastructure. > > ** ** > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > Hi Joe and Gabriel, The changes were in fact merged to Folsom as Gabriel mentioned. The specific patches were: Cinder-Volume: Ie9d74e9c09fa0c192ab6257b5fb02d65b593cbfb<https://review.openstack.org/#q,Ie9d74e9c09fa0c192ab6257b5fb02d65b593cbfb,n,z> Cinder-Snapshot: I2a8338d77badc70201bb315198183f2091df43fb<https://review.openstack.org/#q,I2a8338d77badc70201bb315198183f2091df43fb,n,z> Further details can be viewed (including the Nova-Volume version of the patches) in the bug: https://bugs.launchpad.net/horizon/+bug/967882 Thanks, John ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Horizon Bug 1004412 Details
All of what you said is correct. Those filtering issues (which applied to volumes, keypairs, and security groups at least) were tracked in separate tickets in Nova and all got fixed towards the tail end of Folsom. I don't have the commits handy, sorry. The proper fix was filtering the results returned from Nova correctly on that end; the fix on the ticket you listed was only a defense against the problem on Horizon's end. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Joe Topjian Sent: Saturday, October 06, 2012 11:19 AM To: openstack Subject: [Openstack] Horizon Bug 1004412 Details Hello, I've been aware of Bug 1004412 (https://bugs.launchpad.net/horizon/+bug/1004412) in my Essex deployments for a while and finally had some time to look into it in detail. I believe I have found the cause and wanted to discuss what I found vs how it was fixed in the patch. >From what I can see, when an admin requests a list of volumes, all volumes in >the cloud are returned. But when an admin requests a list of instances, only >instances owned by the admin are returned -- unless an option to return all >instances is specified. Because of these two distinct actions, the chances of a KeyError happening when visiting /nova/instances_and_volumes is extremely high once other projects begin working in the OpenStack environment: all volumes from all projects are returned but only admin instances are returned, so any volume attached in another project cannot find its corresponding instance. I see two proper solutions to this issue: either only return volumes owned by the admin or return all instances in all projects by default. I was unable to figure out (without doing too many changes) how to filter volumes, so I decided on the latter solution. In views.py, I modified the call to get a list of instances to be: if self.request.user.is_admin(): self._instances_list = api.server_list(self.request, all_tenants=True) else: self._instances_list = api.server_list(self.request) Without looking at the implementation details, but instead what the implementation is trying to achieve, I do not see this same issue being resolved in the patch (https://github.com/openstack/horizon/commit/155bfb72c1b5f866236928f4ffd0c2567dc556f3). My question is if I have incorrectly assessed the issue or if the patch is taking other things into account that I'm not aware of? Thanks, Joe -- Joe Topjian Systems Administrator Cybera Inc. www.cybera.ca<http://www.cybera.ca> Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Horizon Bug 1004412 Details
Hello, I've been aware of Bug 1004412 ( https://bugs.launchpad.net/horizon/+bug/1004412) in my Essex deployments for a while and finally had some time to look into it in detail. I believe I have found the cause and wanted to discuss what I found vs how it was fixed in the patch. >From what I can see, when an admin requests a list of volumes, all volumes in the cloud are returned. But when an admin requests a list of instances, only instances owned by the admin are returned -- unless an option to return all instances is specified. Because of these two distinct actions, the chances of a KeyError happening when visiting /nova/instances_and_volumes is extremely high once other projects begin working in the OpenStack environment: all volumes from all projects are returned but only admin instances are returned, so any volume attached in another project cannot find its corresponding instance. I see two proper solutions to this issue: either only return volumes owned by the admin or return all instances in all projects by default. I was unable to figure out (without doing too many changes) how to filter volumes, so I decided on the latter solution. In views.py, I modified the call to get a list of instances to be: if self.request.user.is_admin(): self._instances_list = api.server_list(self.request, all_tenants=True) else: self._instances_list = api.server_list(self.request) Without looking at the implementation details, but instead what the implementation is trying to achieve, I do not see this same issue being resolved in the patch ( https://github.com/openstack/horizon/commit/155bfb72c1b5f866236928f4ffd0c2567dc556f3 ). My question is if I have incorrectly assessed the issue or if the patch is taking other things into account that I'm not aware of? Thanks, Joe -- Joe Topjian Systems Administrator Cybera Inc. www.cybera.ca Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
