Re: [Openstack] Horizon Bug 1004412 Details

2012-10-06 Thread John Griffith
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

2012-10-06 Thread Gabriel Hurley
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

2012-10-06 Thread Joe Topjian
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