Created attachment 1044382 [details] Project drop down doesn't display available projects Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Install Kilo version of Redhat Openstack 2.Login to Horizon dashboard as an admin user 3.create a project through identity menu 4.Create a new user and add this user as a member to the above project 5.login as a above user to horizon dashboard 6.click on Project menu->Instances ->Launch instance Actual results:Projects should be displayed Expected results:Available projects are not displayed Additional info:This is a blocking defect,without fixing this we can't create VM's through Horizon dashboard
how did you deploy? I see this working on a packstack setup, following above steps. (create a new project, create a new user, add that project as the default project for that user). could you please add the output of openstack user role list <newuser> ? Which keystone version are you using?
Created attachment 1044670 [details] User role list I have added a screenshot which shows you the new project (Test Project) and added members to that project(Praveen) and their roles(member/admin etc..)
I'm still unable to reproduce it. What keystone version are you using? Is there a reason to add all service users to that project?
I am using Dell reference architecture to deploy Redhat openstack,team here automated the deployment process so I am using automated deployment framework to install Redhat openstack. Here is the Keystone versions: openstack-keystone-2015.1.0-1.el7ost.noarch python-keystonemiddleware-1.5.1-1.el7ost.noarch python-keystone-2015.1.0-1.el7ost.noarch python-keystoneclient-1.3.0-1.el7ost.noarch
Hi Matthias, There is no particular reason to add all service users,i have removed all other service users now apart from new user(praveen) then logged back in to Horizon using praveen credentials but still Project name is not showing in Project drop down list. I can have a skype call and show you the issue if that helps .
keystone features differ somewhat from API version to API version. keystone from rhos 7 (and earlier) supports both versions. Currently, I need to figure out, if it's a deployment issue, a usage issue or a horizon issue. Unfortunately, this doesn't give any hints.
This issue blocks launching instances Workaround: remove admin role from user. Then everything works as expected.
Moving it to High because a User of multiple projects is not able to switch tenants without the project drop down menu
*** Bug 1247245 has been marked as a duplicate of this bug. ***
I was trying to recreate this bug and ran into what I think is part of the issue I have 2 projects with instances in both projects but from the projects page I can't see which project I'm looking at and don't see the VM that is running in the second project in the overview or instances list. Steps to reproduce: 1. Clean install 2. New User 3. New project test 4. Add new user to test project 5. Make sure test project is default for new user 6. Launch instance in test project (log in as new user and launch instance) 7. as admin you can't directly see new instance that was launched under test project. 8, You can see that it's running by browsing to Identify -> projects -> new project -> see quota -> Shows list of Instances running on that project Also related bug 1240895 deals with showing what project is currently active.
clarification of behavior with python-django-horizon-2015.1.0-10.el70st.noarch If a user has admin role on the active project they get the additional panel for selecting project and user. If they don't have admin role for the active project that panal does not show up. This still doesn't totally explain the empty project list in the Project & User panel
(In reply to Jon Schlueter from comment #14) > clarification of behavior with > python-django-horizon-2015.1.0-10.el70st.noarch > > If a user has admin role on the active project they get the additional panel > for selecting project and user. If they don't have admin role for the active > project that panal does not show up. > > This still doesn't totally explain the empty project list in the Project & > User panel SHOULD the user be able to have admin role right or have the Admin user added to the project as a member? Like you stated, if the project has either of these members you get the additional panel for selecting a project resulting in not being able to create the instance. Is it just user error and trying to add admin rights and admin member to a project is something that should not be done?
> SHOULD the user be able to have admin role right or have the Admin user > added to the project as a member? Like you stated, if the project has > either of these members you get the additional panel for selecting a project > resulting in not being able to create the instance. Is it just user error > and trying to add admin rights and admin member to a project is something > that should not be done? In my tests, you can add a user to a project with admin role only in that project. You still get the "Project&User" tab in Launch instance dialog. I get that filled dialog (i.e. you're able to select, in which project you want to launch your instance): - with a user being only admin on two projects (no _member_ role) - with a user being only admin in one project (no _member_ role in that project), and _member_ in the other project I don't get that dialog, when being a user with two projects with _member_ roles only. I was unable to reproduce the described issue from #c1. Since keystone v2 vs. keystone v3 changed significantly, that might matter here. Unfortunately, nobody could tell me, how the system from #c1 was set up. Looking at the code to collect that information for the drop down box, that is still the same compared to Juno version: https://github.com/openstack/horizon/blob/stable/juno/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py#L57 vs. https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py#L61
What authentication setup was used for original setup? I found a possible sneak path to get empty project list here: https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/user.py#L311 If that sneak path was the case there should be exception log entri in the log from this call LOG.exception('Unable to retrieve project list.') Not sure if this is the cause but thought I'd add this to the conversation and see which version of python-django-openstack-auth was installed and how permissions/authentication relevant to it was setup on the system showing this issue.
Could you please provide a sos report here? Is there any exception being logged, when this happens?
Hi Matthias, I don't have any active deployment,will be deploying new instance today then i can able to provide exception logs if there are any-thanks
Created attachment 1060351 [details] screenshots describe the admin rights issue with creating an instance
Hi Matthias, Audra told me that she will be having call with you today to discuss about the issues we are seeing .
During the debugging session, we found this in the Keystone log; 2015-08-07 14:22:38.220 37833 WARNING keystone.middleware.core [-] RBAC: Invalid token 2015-08-07 14:22:38.221 37833 WARNING keystone.common.wsgi [-] The request you have made requires authentication. 2015-08-07 14:22:38.222 37833 INFO eventlet.wsgi.server [-] 192.168.140.183 - - [07/Aug/2015 14:22:38] "GET /v2.0/tenants HTTP/1.1" 401 405 0.014434 The token handed from Horizon to Keystone for the token list is invalid. It might be an artifact of the "hash to save space" that Horizon does, although we have not seen that as a problem before. As a check, Audra switch the token provider from pki to uuid, restarted the Keystone server, and the project dropdown for the VM lauch was indeed populated, and she was able to launch VMs. Switch the token provider to UUID tokens should have no negative impact and may even have a slight performance benefit. Still, the root cause is not clearly identified here. If the tokens were never valid, Horizon should not be able to perform any actions against any of the services, to include things like listing existing VMs. So, at some point, the tokens are either getting invalidated somehow.
configuration change was to comment out the pki provider and enable the uuid provider and restart keystone. [token] #provider = keystone.token.providers.pki.Provider provider = keystone.token.providers.uuid.Provider
Just to make it clear, this is a config issue and not an issue with the package. It should be probably reported against the used installer.
After applying the configuration change noted in C23 above and applying the patch (0001-Add-projects-switcher-region-switcher-to-RCUE.patch) from BZ 1240895, both the Projects dropdown list in the Dashboard and Projects dropdown on the Launch Instance form are now populated.
OK, now that I know how to reproduce, I was able to create the same issue for me in a different install. (just switch to PKI tokens in keystone)
in my tests, I can confirm, the issue is in django-openstack-auth and not on the keystone side. It looks like horizon uses a wrong and/or hashed token. I filed https://bugs.launchpad.net/django-openstack-auth/+bug/1484499
I proposed a patch upstream How to test: 1. create a user in TWO projects. 2. switch keystone to use pki tokens /etc/keystone/keystone.conf set: provider = keystone.token.providers.pki.Provider where provider was provider = keystone.token.providers.uuid.Provider 3. restart keystone or httpd (depending on deployment method) 4. log that user from 1. into horizon 5. the project switcher on upper corner should be populated and should show the project names
Upstream patch for django-openstack-auth was merged upstream. It will be contained in d-o-a version 1.3.2. This currently blocks using horizon in all installs using pki tokens. Backport is simple
Verified ======== python-django-openstack-auth-1.2.0-4.el7ost.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2015:1721