[openstack-dev] Suspected SPAM - Re: [vitrage] about  "is_admin" in ctx

Weyl, Alexey (Nokia - IL/Kfar Sava) alexey.weyl at nokia.com
Wed May 17 10:47:30 UTC 2017


Yes the ‘is_admin_project’ represent the tenant.

I have tried to use many different users which are part of the admin, alt_demo, nova, vitrage, new_tenant that I have created and they all returned the is_admin_project=True.

At the moment as I said only the admin user will be able to see the all-tenants, although this is not correct, and there are other users has the permissions to see all-tenants as well.

We have added a new tab in horizon under the admin tab, where those who has permission to see that tab can see the vitrages all-tenants.

In our case only the Admin at the moment will actually see all the entities.


From: dong.wenjuan at zte.com.cn [mailto:dong.wenjuan at zte.com.cn]
Sent: Wednesday, May 17, 2017 12:24 PM
To: Weyl, Alexey (Nokia - IL/Kfar Sava) <alexey.weyl at nokia.com>
Cc: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev]Suspected SPAM - Re: [vitrage] about  "is_admin" in ctx

Hi Alexey,

Currently we use 'is_admin' as 'is_admin_project'[1], right?

I think the 'is_admin_project' represent the tenant , not be related to user.

So why 'is_admin_project' alaways return 'True' with all of the user and tenants is the issue.

What about a user which is not 'admin' but have the 'admin' role?

Should the user with 'admin' role see all  all-tenants?

[1] https://github.com/openstack/vitrage/blob/master/vitrage/api_handler/apis/base.py#L94




Original Mail
Sender:  <alexey.weyl at nokia.com>;
To:  <openstack-dev at lists.openstack.org>;
Date: 2017/05/15 22:49
Subject: Re: [openstack-dev]Suspected SPAM - Re:  [vitrage] about  "is_admin" in ctx


Sorry it took me so long to answer due to the Boston Summit.

After making some more checks in order to make it sure, the results are the following:

1.      The context that we use has 2 properties regarding admin (is_admin, is_admin_project).

2.      The is_admin property regards whether the user that has done the inquiry is the admin or not. So the only way it is True is if the user is  admin.

3.      The is_admin_project I thought will represent the tenant of the user, but from all of the user and tenants that I have used, it laways returned  me True.

4.      Due to that I have decided to use the is_admin property in the context to indicate whether the user can see all-tenants or not.

5.      This is not a perfect solution because also users such as nova/cinder/all project names seems to be able to see the admin tab. In our case  what will happen is that although in the UI we have the admin tab for those users, the data we will show in the vitrage tab is not of all the tenants but this specific tenant.


From: Weyl, Alexey (Nokia - IL/Kfar Sava) [mailto:alexey.weyl at nokia.com]
Sent: Tuesday, April 25, 2017 3:10 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Suspected SPAM - Re: [openstack-dev] [vitrage] about  "is_admin" in ctx

Hi Wenjuan,

This is a good question, I need to check it a bit more thoroughly.

It’s just that at the moment we are preparing for the Boston Openstack Summit and thus it will take me a bit more time to answer that.

Sorry for the delay.

Alexey ☺

From: dong.wenjuan at zte.com.cn<mailto:dong.wenjuan at zte.com.cn> [mailto:dong.wenjuan at zte.com.cn]
Sent: Friday, April 21, 2017 11:08 AM
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [vitrage] about  "is_admin" in ctx

Hi all,

I'm a little confused about the "is_amdin" in ctx.

From the hook(https://github.com/openstack/vitrage/blob/master/vitrage/api/hooks.py#L73),  "is_admin" means admin user,.

But we define the macro as "admin project"( https://github.com/openstack/vitrage/blob/master/vitrage/api_handler/apis/base.py#L94  ). But in my opinion,  it should be the admin role. Correct me if i'm wrong :).



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170517/562426a5/attachment.html>

More information about the OpenStack-dev mailing list