Bug 1408777 - Default admin user from default domain does not have Domains tab in Horizon Web Interface.
Summary: Default admin user from default domain does not have Domains tab in Horizon W...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-django-horizon
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Linux
high
medium
Target Milestone: z3
: 10.0 (Newton)
Assignee: Radomir Dopieralski
QA Contact: Ido Ovadia
URL:
Whiteboard:
Depends On: 1403043
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-27 07:18 UTC by ITD27M01
Modified: 2022-07-09 10:53 UTC (History)
17 users (show)

Fixed In Version: python-django-horizon-10.0.2-2.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-28 15:17:35 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Horizon policy files (7.18 KB, application/x-gzip)
2017-01-10 09:52 UTC, ITD27M01
no flags Details
Keystone policy file (1.26 KB, application/x-gzip)
2017-01-10 09:53 UTC, ITD27M01
no flags Details
no domains after patch (43.97 KB, image/png)
2017-03-31 21:24 UTC, Andreas Karis
no flags Details
identity domains without the tabs in horizon (38.42 KB, image/png)
2017-04-04 20:19 UTC, Andreas Karis
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1660602 0 None None None 2017-01-31 12:15:19 UTC
Red Hat Issue Tracker OSP-17078 0 None None None 2022-07-09 10:53:56 UTC
Red Hat Knowledge Base (Solution) 2895411 0 None None None 2017-01-31 16:11:39 UTC
Red Hat Product Errata RHSA-2017:1598 0 normal SHIPPED_LIVE Low: python-django-horizon security, bug fix, and enhancement update 2017-06-28 18:52:32 UTC

Description ITD27M01 2016-12-27 07:18:37 UTC
Description of problem:
After clean installation of RHOSP10 I try to create additional domains and projects from Horizon Dashboard in the Identity section under default admin user. But this section does not have Domains tab. As a result I can't set the domain context to create projects and add users. I can create domains and projects from command line openstack but not from Horizon Dashboard.

Version-Release number of selected component (if applicable):
openstack-dashboard-theme-10.0.1-4.el7ost.noarch
openstack-dashboard-10.0.1-4.el7ost.noarch

How reproducible:

Steps to Reproduce:
1. Install Horizon dashboard.
2. Configure multidomain environment and login to Dashboard as admin user from Default domain.
3. Go to Identity section and try to access Domains tab.

Actual results:
Domains tab does not present in the Identity Section of Horizon Dashboard.

Expected results:
Domains tab is present in the Identity Section of Horizon Dashboard. For ability to set the another domain context to create projects and add users.

Additional info:

Comment 1 Radomir Dopieralski 2017-01-03 14:02:14 UTC
For the domain-scoped tokens to work properly, we need to use a different session engine than the default cookies (as there isn't enough room in the cookies to store all the tokens). Adding this line to local_settings.py makes the "domains" menu item appear properly:

SESSION_ENGINE = 'django.contrib.sessions.backends.cache'

Comment 2 ITD27M01 2017-01-09 14:01:36 UTC
Hi Radomir Dopieralski.
I use memcached service for my installation and have configured this on all openstack api services. There is my local_settings file for dashboard. I think that problem is in some policy configuration for admin user from default domain. Because other users can have access to Domains tab in Horizon.
---
import os
from django.utils.translation import ugettext_lazy as _
from openstack_dashboard import exceptions
from openstack_dashboard.settings import HORIZON_CONFIG
DEBUG = True
WEBROOT = '/dashboard/'
LOGIN_URL = WEBROOT + 'auth/login/'
LOGOUT_URL = WEBROOT + 'auth/logout/'
LOGIN_REDIRECT_URL = WEBROOT
ALLOWED_HOSTS = ['*',]
OPENSTACK_API_VERSIONS = {
    "identity": 3,
    "image": 2,
    "volume": 2,
    "compute": 2,
}
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'
LOCAL_PATH = '/tmp'
SECRET_KEY=''
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': 'memcached:11211',
    },
}
EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
OPENSTACK_HOST = "openstack"
OPENSTACK_KEYSTONE_URL = "https://%s:5000/v3" % OPENSTACK_HOST
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "_member_"
OPENSTACK_KEYSTONE_BACKEND = {
    'name': 'native',
    'can_edit_user': True,
    'can_edit_group': True,
    'can_edit_project': True,
    'can_edit_domain': True,
    'can_edit_role': True,
}
OPENSTACK_ENABLE_PASSWORD_RETRIEVE = True
OPENSTACK_HYPERVISOR_FEATURES = {
    'can_set_mount_point': False,
    'can_set_password': False,
    'requires_keypair': False,
    'enable_quotas': True
}
OPENSTACK_CINDER_FEATURES = {
    'enable_backup': False,
}
OPENSTACK_NEUTRON_NETWORK = {
    'enable_router': True,
    'enable_quotas': True,
    'enable_ipv6': True,
    'enable_distributed_router': False,
    'enable_ha_router': False,
    'enable_lb': True,
    'enable_firewall': True,
    'enable_vpn': True,
    'enable_fip_topology_check': True,
     'segmentation_id_range': {
         'vlan': [2, 4094],
         'vxlan': [2, 65536],
     },
    'supported_vnic_types': ['*'],
}
OPENSTACK_HEAT_STACK = {
    'enable_user_pass': True,
}
IMAGE_CUSTOM_PROPERTY_TITLES = {
    "architecture": _("Architecture"),
    "kernel_id": _("Kernel ID"),
    "ramdisk_id": _("Ramdisk ID"),
    "image_state": _("Euca2ools state"),
    "project_id": _("Project ID"),
    "image_type": _("Image Type"),
}
IMAGE_RESERVED_CUSTOM_PROPERTIES = []
API_RESULT_LIMIT = 1000
API_RESULT_PAGE_SIZE = 20
SWIFT_FILE_TRANSFER_CHUNK_SIZE = 512 * 1024
INSTANCE_LOG_LENGTH = 35
DROPDOWN_MAX_ITEMS = 30
TIME_ZONE = "Europe/Moscow"
POLICY_FILES_PATH = '/etc/openstack-dashboard'
REST_API_REQUIRED_SETTINGS = ['OPENSTACK_HYPERVISOR_FEATURES',
                              'LAUNCH_INSTANCE_DEFAULTS',
                              'OPENSTACK_IMAGE_FORMATS']
---

Comment 3 Radomir Dopieralski 2017-01-09 14:19:39 UTC
Can you also provide your policy files? And please make sure that the Keystone's policy file is the same as the Horizon's.

Comment 4 ITD27M01 2017-01-10 09:52:39 UTC
Created attachment 1239026 [details]
Horizon policy files

Horizon policy files from /etc/openstack-dashboard

Comment 5 ITD27M01 2017-01-10 09:53:51 UTC
Created attachment 1239027 [details]
Keystone policy file

Keystone policy file from /etc/keystone

Comment 6 ITD27M01 2017-01-13 08:04:21 UTC
I have uploaded the requested files. These files come along with the distribution RHOSP10. I have not changed these files.

Comment 7 Radomir Dopieralski 2017-01-23 13:35:42 UTC
They keystone (policy.json) and horizon's (keystone_police.json) policy files are different. This wrong, and can lead to all sorts of problems, where horizon doesn't allow something that keystone allows, and vice versa. You have to copy the policy file from keystone to horizon any time any change is made, so that both programs use the same set policies.

Comment 8 ITD27M01 2017-01-23 16:50:12 UTC
(In reply to Radomir Dopieralski from comment #7)
> They keystone (policy.json) and horizon's (keystone_police.json) policy
> files are different. This wrong, and can lead to all sorts of problems,
> where horizon doesn't allow something that keystone allows, and vice versa.
> You have to copy the policy file from keystone to horizon any time any
> change is made, so that both programs use the same set policies.

Hi Radomir

These files come in RHSOP 10 packages. I didn't change them. I will try to fulfill your recommendations.

Comment 9 ITD27M01 2017-01-23 16:58:03 UTC
I do the following but no changes (Domains tab does not appear for admin user):
[root@srv-os-rhctl01 ~]# diff /etc/keystone/policy.json /etc/openstack-dashboard/keystone_policy.json 
31c31
<     "identity:get_domain": "rule:admin_required or token.project.domain.id:%(target.domain.id)s",
---
>     "identity:get_domain": "rule:admin_required",
44c44
<     "identity:get_user": "rule:admin_or_owner",
---
>     "identity:get_user": "rule:admin_required",
176,177c176,177
<     "identity:list_projects_for_user": "",
<     "identity:list_domains_for_user": "",
---
>     "identity:list_projects_for_groups": "",
>     "identity:list_domains_for_groups": "",
[root@srv-os-rhctl01 ~]# cp /etc/openstack-dashboard/keystone_policy.json /etc/openstack-dashboard/keystone_policy.json.orig
[root@srv-os-rhctl01 ~]# cat /etc/keystone/policy.json > /etc/openstack-dashboard/keystone_policy.json
[root@srv-os-rhctl01 ~]# systemctl restart httpd memcached

Comment 10 ITD27M01 2017-01-23 17:03:21 UTC
And visa versa copy does not have the effect:

[root@srv-os-rhctl01 ~]# cp /etc/keystone/policy.json /etc/keystone/policy.json.orig
[root@srv-os-rhctl01 ~]# cat /etc/openstack-dashboard/keystone_policy.json.orig > /etc/keystone/policy.json
[root@srv-os-rhctl01 ~]# cat /etc/keystone/policy.json > /etc/openstack-dashboard/keystone_policy.json     
[root@srv-os-rhctl01 ~]# systemctl restart httpd memcached

Comment 11 Radomir Dopieralski 2017-01-23 17:15:06 UTC
Are you able to visit the domains page by entering the URL directly? That is, .../dashboard/identity/domains ?

Comment 12 ITD27M01 2017-01-24 07:59:09 UTC
(In reply to Radomir Dopieralski from comment #11)
> Are you able to visit the domains page by entering the URL directly? That
> is, .../dashboard/identity/domains ?

Yes, I have access to this link but I see only one Default domain.

Comment 13 Martin Schuppert 2017-01-24 08:34:14 UTC
(In reply to ITD27M01 from comment #12)
> (In reply to Radomir Dopieralski from comment #11)
> > Are you able to visit the domains page by entering the URL directly? That
> > is, .../dashboard/identity/domains ?
> 
> Yes, I have access to this link but I see only one Default domain.

Hi, I see the same when use the admin from default domain. Then the 'Domains' tab is hidden. If I use a cloud_admin user or any other user from non default domain it gets shown. But still a single domain is shown (one which the user logged in) and not all available domains I see when run a 'openstack domain list' from cli.

Comment 14 ITD27M01 2017-01-24 10:32:27 UTC
It looks very strange. Before starting RHOSP we worked with Mirantis OpenStack and there this functionality worked perfectly. I could log in as default admin to Default domain and go to the Domains tab. There I have seen all my domains (from the /etc/keystone/domins directory). I could do "set domain context" and create projects in those domains. Including to fill the projects with users. It works at least in Mitaka.

Comment 15 Martin Schuppert 2017-01-30 15:07:50 UTC
Two comments after having a closer look at that:

1) for the domain tab not shown to default admin account:

From Domains class of panel.py we need a domain_token, if we do not have one the tab is not shown. 
Maybe that is the issue here.

class Domains(horizon.Panel):
    name = _("Domains")
    slug = 'domains'
    policy_rules = (("identity", "identity:get_domain"),
                    ("identity", "identity:list_domains"))

    @staticmethod
    def can_register():
        return keystone.VERSIONS.active >= 3

    def can_access(self, context):

        request = context['request']
        domain_token = request.session.get('domain_token')


        if keystone.VERSIONS.active < 3:
            return super(Domains, self).can_access(context)

        request = context['request']
        domain_token = request.session.get('domain_token')

        return super(Domains, self).can_access(context) and domain_token


2) for the missing list of domains in domain tab:

When we login to horizon using a cloud_admin user, we see the following:

1) login with user cloudadmin - everything is ok, we also use the adminURL (port 35357) as we login as an admin:

2017-01-26 16:28:26,724 28449 WARNING openstack_auth.backend The Keystone URL in service catalog points to a v2.0 Keystone endpoint, but v3 is specified as the API version to use by Horizon. Using v3 endpoint for authentication.
2017-01-26 16:28:26,725 28449 INFO openstack_auth.forms Login successful for user "cloud_admin".
2017-01-26 16:28:26,909 28449 WARNING openstack_auth.utils The Keystone URL (either in Horizon settings or in service catalog) points to a v2.0 Keystone endpoint, but v3 is specified as the API version to use by Horizon. Using v3 endpoint for authentication.
2017-01-26 16:28:26,909 28449 DEBUG openstack_dashboard.api.keystone Creating a new keystoneclient connection to http://192.168.122.118:35357/v3.
2017-01-26 16:28:26,910 28449 DEBUG keystoneclient.session REQ: curl -g -i -X GET http://192.168.122.118:35357/v3/domains/c247bac26b32439ba87a58444f4d4dce -H "User-Agent: python-keystoneclient" -H "Forwarded: for=192.168.122.1;by=python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}87bc2f0b8ac0233870efcdc9536bae103615174e"
2017-01-26 16:28:28,836 28449 DEBUG keystoneclient.session RESP: [200] Date: Thu, 26 Jan 2017 16:28:26 GMT Server: Apache/2.4.6 (Red Hat Enterprise Linux) Vary: X-Auth-Token,Accept-Encoding x-openstack-request-id: req-14891a7a-a297-4736-9a65-6c91af584582 Content-Encoding: gzip Content-Length: 156 Connection: close Content-Type: application/json 
RESP BODY: {"domain": {"links": {"self": "http://192.168.122.118:35357/v3/domains/c247bac26b32439ba87a58444f4d4dce"}, "description": "", "name": "admin_dom", "enabled": true, "id": "c247bac26b32439ba87a58444f4d4dce"}}

2017-01-26 16:28:28,839 28449 DEBUG keystoneclient.session REQ: curl -g -i -X GET http://192.168.122.118:35357/v3/domains/c247bac26b32439ba87a58444f4d4dce -H "User-Agent: python-keystoneclient" -H "Forwarded: for=192.168.122.1;by=python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}87bc2f0b8ac0233870efcdc9536bae103615174e"
2017-01-26 16:28:29,015 28449 DEBUG keystoneclient.session RESP: [200] Date: Thu, 26 Jan 2017 16:28:28 GMT Server: Apache/2.4.6 (Red Hat Enterprise Linux) Vary: X-Auth-Token,Accept-Encoding x-openstack-request-id: req-ce1047ee-c5cd-47e3-8dc8-0b453e4d9087 Content-Encoding: gzip Content-Length: 156 Connection: close Content-Type: application/json 
RESP BODY: {"domain": {"links": {"self": "http://192.168.122.118:35357/v3/domains/c247bac26b32439ba87a58444f4d4dce"}, "description": "", "name": "admin_dom", "enabled": true, "id": "c247bac26b32439ba87a58444f4d4dce"}}

2017-01-26 16:28:29,015 28449 DEBUG keystoneclient.session REQ: curl -g -i -X GET http://192.168.122.118:35357/v3/projects?domain_id=c247bac26b32439ba87a58444f4d4dce -H "User-Agent: python-keystoneclient" -H "Forwarded: for=192.168.122.1;by=python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}87bc2f0b8ac0233870efcdc9536bae103615174e"
2017-01-26 16:28:29,040 28449 DEBUG keystoneclient.session RESP: [200] Date: Thu, 26 Jan 2017 16:28:29 GMT Server: Apache/2.4.6 (Red Hat Enterprise Linux) Vary: X-Auth-Token,Accept-Encoding x-openstack-request-id: req-073c98e3-bbaa-4b83-b6f6-8bc93521bb31 Content-Encoding: gzip Content-Length: 149 Connection: close Content-Type: application/json 
RESP BODY: {"links": {"self": "http://192.168.122.118:35357/v3/projects?domain_id=c247bac26b32439ba87a58444f4d4dce", "previous": null, "next": null}, "projects": []}

------> here all domains get requested and we receive all:
2017-01-26 16:28:29,042 28449 DEBUG keystoneclient.session REQ: curl -g -i -X GET http://192.168.122.118:35357/v3/domains -H "User-Agent: python-keystoneclient" -H "Forwarded: for=192.168.122.1;by=python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}87bc2f0b8ac0233870efcdc9536bae103615174e"
2017-01-26 16:28:29,067 28449 DEBUG keystoneclient.session RESP: [200] Date: Thu, 26 Jan 2017 16:28:29 GMT Server: Apache/2.4.6 (Red Hat Enterprise Linux) Vary: X-Auth-Token,Accept-Encoding x-openstack-request-id: req-0cc12679-59a0-427a-8cad-fd4712614557 Content-Encoding: gzip Content-Length: 282 Connection: close Content-Type: application/json 
RESP BODY: {"domains": [{"links": {"self": "http://192.168.122.118:35357/v3/domains/16f2094acb0d4175a44c8029501dc184"}, "description": "", "name": "heat", "enabled": true, "id": "16f2094acb0d4175a44c8029501dc184"}, {"links": {"self": "http://192.168.122.118:35357/v3/domains/471353f31b974789b3bb3804b23646ce"}, "description": "", "name": "dom1", "enabled": true, "id": "471353f31b974789b3bb3804b23646ce"}, {"links": {"self": "http://192.168.122.118:35357/v3/domains/c247bac26b32439ba87a58444f4d4dce"}, "description": "", "name": "admin_dom", "enabled": true, "id": "c247bac26b32439ba87a58444f4d4dce"}, {"links": {"self": "http://192.168.122.118:35357/v3/domains/default"}, "description": "The default domain", "name": "Default", "enabled": true, "id": "default"}], "links": {"self": "http://192.168.122.118:35357/v3/domains", "previous": null, "next": null}}


After login we are in "Projects" tab

2) Now switch to "Domains"

2017-01-26 16:34:43,230 28450 WARNING openstack_auth.utils The Keystone URL (either in Horizon settings or in service catalog) points to a v2.0 Keystone endpoint, but v3 is specified as the API version to use by Horizon. Using v3 endpoint for authentication.
2017-01-26 16:34:43,230 28450 DEBUG openstack_dashboard.api.keystone Creating a new keystoneclient connection to http://192.168.122.118:35357/v3.
2017-01-26 16:34:43,231 28450 DEBUG keystoneclient.session REQ: curl -g -i -X GET http://192.168.122.118:35357/v3/domains/c247bac26b32439ba87a58444f4d4dce -H "User-Agent: python-keystoneclient" -H "Forwarded: for=192.168.122.1;by=python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}87bc2f0b8ac0233870efcdc9536bae103615174e"
2017-01-26 16:34:43,276 28450 DEBUG keystoneclient.session RESP: [200] Date: Thu, 26 Jan 2017 16:34:43 GMT Server: Apache/2.4.6 (Red Hat Enterprise Linux) Vary: X-Auth-Token,Accept-Encoding x-openstack-request-id: req-50ad7a90-3ceb-463e-a895-3b87f87f52b7 Content-Encoding: gzip Content-Length: 156 Connection: close Content-Type: application/json 
RESP BODY: {"domain": {"links": {"self": "http://192.168.122.118:35357/v3/domains/c247bac26b32439ba87a58444f4d4dce"}, "description": "", "name": "admin_dom", "enabled": true, "id": "c247bac26b32439ba87a58444f4d4dce"}}

2017-01-26 16:34:43,278 28450 DEBUG keystoneclient.session REQ: curl -g -i -X GET http://192.168.122.118:35357/v3/domains/c247bac26b32439ba87a58444f4d4dce -H "User-Agent: python-keystoneclient" -H "Forwarded: for=192.168.122.1;by=python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}87bc2f0b8ac0233870efcdc9536bae103615174e"
2017-01-26 16:34:43,305 28450 DEBUG keystoneclient.session RESP: [200] Date: Thu, 26 Jan 2017 16:34:43 GMT Server: Apache/2.4.6 (Red Hat Enterprise Linux) Vary: X-Auth-Token,Accept-Encoding x-openstack-request-id: req-5d1a4114-45ad-436e-9c0d-d20c57fcb7ae Content-Encoding: gzip Content-Length: 156 Connection: close Content-Type: application/json 
RESP BODY: {"domain": {"links": {"self": "http://192.168.122.118:35357/v3/domains/c247bac26b32439ba87a58444f4d4dce"}, "description": "", "name": "admin_dom", "enabled": true, "id": "c247bac26b32439ba87a58444f4d4dce"}}

From above we see that we only query a single domain with ID c247bac26b32439ba87a58444f4d4dce . We do not query the list
of available domains!

Looking at /usr/share/openstack-dashboard/openstack_dashboard/dashboards/identity/domains :

We are:
 * cloud_admin, 
 * have permissions to identity:list_domains
 * and have a domain_id

With the above we never end up in the 'else' filling the domains list. In general why 
is there the if and we do not just get the list of domains if we are allowed to have
identity:list_domains ...

class IndexView(tables.DataTableView):
    table_class = project_tables.DomainsTable
    template_name = constants.DOMAINS_INDEX_VIEW_TEMPLATE
    page_title = _("Domains")

    def get_data(self):
        domains = []
        domain_id = api.keystone.get_effective_domain_id(self.request)

        if policy.check((("identity", "identity:list_domains"),),
                        self.request):
            try:
                if domain_id:
                    domain = api.keystone.domain_get(self.request, domain_id)
                    domains.append(domain)
                else:
--->                domains = api.keystone.domain_list(self.request)

---> we never end up in filling the domains list when we have domain_id, which we have

            except Exception:
                exceptions.handle(self.request,
                                  _('Unable to retrieve domain list.'))
        elif policy.check((("identity", "identity:get_domain"),),
                          self.request):
            try:
                domain = api.keystone.domain_get(self.request, domain_id)
                domains.append(domain)
            except Exception:
                exceptions.handle(self.request,
                                  _('Unable to retrieve domain information.'))
        else:
            msg = _("Insufficient privilege level to view domain information.")
            messages.info(self.request, msg)
        return domains

If we reduce the 'if' to always fill the domains list, the domains get listed in horizon
and we can set the context and create user/projects for that domain.

Comment 16 Radomir Dopieralski 2017-01-30 22:14:03 UTC
Thank you Martin for this, I think we figured out what happened. With Keystone V2 you only had a domain token when you had a domain context selected, so in many places the domain context and the domain token are confused and used interchangeably. We need to rework this part to make it work properly with Keystone V3.

Comment 19 Radomir Dopieralski 2017-01-31 12:15:20 UTC
I have a WIP patch upstream for this specific issue: https://review.openstack.org/#/c/427125/3

There will be more patches for the issues in other places.

Comment 20 Martin Schuppert 2017-01-31 13:46:51 UTC
(In reply to Radomir Dopieralski from comment #19)
> I have a WIP patch upstream for this specific issue:
> https://review.openstack.org/#/c/427125/3
> 
> There will be more patches for the issues in other places.

From quick test with the above patch it works for me correct. I can switch the context and get only the users/project from that domain listed in the other tabs.

Comment 21 Radomir Dopieralski 2017-02-16 15:19:59 UTC
The upstream patch merged for Pike, Ocata and Newton.

Comment 40 Andreas Karis 2017-03-31 21:23:43 UTC
Hello,

Is it just me who's crazy, or this is not working?
~~~
[root@overcloud-controller-0 ~]# yum history info 6
Loaded plugins: product-id, search-disabled-repos, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Transaction ID : 6
Begin time     : Fri Mar 31 20:26:24 2017
Begin rpmdb    : 1311:f6a208f24a144e00f2b47543eb92b08696103b87
End time       :            20:28:39 2017 (135 seconds)
End rpmdb      : 1312:0a46ce2a7a61e1de03cd7a88dd93a9494e0c1620
User           : Cloud User <heat-admin>
Return-Code    : Success
Command Line   : localinstall openstack-dashboard-10.0.2-2.el7ost.noarch.rpm openstack-dashboard-theme-10.0.2-2.el7ost.noarch.rpm python-django-horizon-10.0.2-2.el7ost.noarch.rpm python-django-horizon-doc-10.0.2-2.el7ost.noarch.rpm
Transaction performed with:
    Installed     rpm-4.11.3-21.el7.x86_64                  @anaconda/7.3
    Installed     subscription-manager-1.17.15-1.el7.x86_64 @anaconda/7.3
    Installed     yum-3.4.3-150.el7.noarch                  @anaconda/7.3
Packages Altered:
    Updated openstack-dashboard-1:10.0.1-5.el7ost.noarch       @rhos-10.0-signed
    Update                      1:10.0.2-2.el7ost.noarch       @/openstack-dashboard-10.0.2-2.el7ost.noarch
    Updated openstack-dashboard-theme-1:10.0.1-5.el7ost.noarch @rhos-10.0-signed
    Update                            1:10.0.2-2.el7ost.noarch @/openstack-dashboard-theme-10.0.2-2.el7ost.noarch
    Updated python-django-horizon-1:10.0.1-5.el7ost.noarch     @rhos-10.0-signed
    Update                        1:10.0.2-2.el7ost.noarch     @/python-django-horizon-10.0.2-2.el7ost.noarch
    Install python-django-horizon-doc-1:10.0.2-2.el7ost.noarch @/python-django-horizon-doc-10.0.2-2.el7ost.noarch
Scriptlet output:
   1 warning: file /usr/share/openstack-dashboard/static/dashboard/js/ecfdea87e68a.js: remove failed: No such file or directory
history info
~~~

I also set:
~~~
OPENSTACK_API_VERSIONS = {
    "identity": 3
}
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'
~~~

After this, I restarted httpd.

I still cannot see "domains" tab in Identity -> Identity as the admin user ... screenshot attached.

Comment 41 Andreas Karis 2017-03-31 21:24:48 UTC
Created attachment 1267985 [details]
no domains after patch

Comment 42 Radomir Dopieralski 2017-04-03 08:54:34 UTC
That's weird.

Are you able to visit the domains page by entering the URL directly? That is, .../dashboard/identity/domains ?

Comment 43 Andreas Karis 2017-04-04 20:18:20 UTC
Hi,

Yes, I can access http://10.0.0.12/dashboard/identity/domains/

It simply doesn't show in the menu.

Screenshot attached.

Any suggestions? Probably some easy configuration tweak?

- Andreas

Comment 44 Andreas Karis 2017-04-04 20:19:47 UTC
Created attachment 1268745 [details]
identity domains without the tabs in horizon

Comment 45 Radomir Dopieralski 2017-04-05 07:12:49 UTC
I'm afraid there is one more place that needs fixing for this.

Comment 55 Andreas Karis 2017-04-12 16:09:42 UTC
Hello,

I tested this with a full AD setup with keystonev3 and domains. I can confirm that this fixes the display of domains on this page: http://10.0.0.5/dashboard/identity/domains/

However, the tab is still missing, e.g. as the default admin user, I **cannot** see the tab to view other domains.

- Andreas

Comment 56 Andreas Karis 2017-04-12 16:28:05 UTC
I also tested this with the policy file from:
https://raw.githubusercontent.com/openstack/keystone/master/etc/policy.v3cloudsample.json

According to https://access.redhat.com/solutions/2895411

Because I'm testing as the admin user, I picked the UUID of one of my domains and added it in  policy.v3cloudsample.json, then replaced policy.json and restarted httpd
~~~
[root@overcloud-controller-0 keystone]# cp policy.v3cloudsample.json policy.json
cp: overwrite ‘policy.json’? y
[root@overcloud-controller-0 keystone]# systemctl restart keystone
Failed to restart keystone.service: Unit not found.
[root@overcloud-controller-0 keystone]# systemctl restart openstack-keystone
Failed to restart openstack-keystone.service: Unit not found.
[root@overcloud-controller-0 keystone]# systemctl restart httpd
~~~

This didn't work (indeed broke a few things, because I only followed that extract from the above article).

I then copied over and compared keystone policy.json files from OSP 8 and 9:
http://pastebin.test.redhat.com/474842
and restarted httpd (keystone)

In both cases, I **cannot** see the domains tab, but I can reach http://10.0.0.5/dashboard/identity/domains/

So this is either still a bug, or a configuration issue with OSP Director. Did you test this with a devstack or OSP Director deployment?

Comment 57 Radomir Dopieralski 2017-04-12 18:19:05 UTC
I only tested this with packstack, I will try to figure out what is wrong exactly.
I definitely suspect our policy files though.

Comment 58 Martin Schuppert 2017-04-13 13:20:13 UTC
In the packstack env I used for testing where [1] was applied:

When login with admin user in default domain, you do not see the domain tab.

When we use the policy.v3cloudsample.json a cloud_admin needs to have the admin
role in the domain which is specified as the cloud admin domain.

You need to:
1) add the admin user the admin role in the default domain. 
openstack role add --domain default --user 05da09cd576341ed99fbc7545bbfd714 admin

Replace the user ID for your admin user

2) replace the domain_id for the cloud_domain with default

# diff -u /etc/keystone/policy.json.pb /etc/keystone/policy.json
--- /etc/keystone/policy.json.pb	2017-04-13 08:50:18.348804121 -0400
+++ /etc/keystone/policy.json	2017-04-13 09:09:56.099080586 -0400
@@ -1,6 +1,6 @@
 {
     "admin_required": "role:admin",
-    "cloud_admin": "role:admin and domain_id:c247bac26b32439ba87a58444f4d4dce",
+    "cloud_admin": "role:admin and domain_id:default",
     "service_role": "role:service",
     "service_or_admin": "rule:admin_required or rule:service_role",
     "owner" : "user_id:%(user_id)s or user_id:%(target.token.user_id)s",

3) keep /etc/openstack-dashboard/keystone_policy.json in sync with /etc/keystone/policy.json

Now I can login using the admin user from default domain and see the 
domain tab and set the domain context. 

I have not done any other functional tests.

[1] https://access.redhat.com/solutions/2895411

Comment 59 Andreas Karis 2017-04-13 16:09:08 UTC
Hi,

I confirm that the missing step for OSP 10 is this:
~~~
[stack@undercloud-4 ~]$ openstack user list | grep admin
| a6a8adb6356f4a879f079485dad1321b | admin      |
~~~

~~~
[stack@undercloud-4 ~]$ openstack role assignment list | grep a6a8adb6356f4a879f079485dad1321b | grep da558c2a79c24b3096b19ccdbb032361 
| da558c2a79c24b3096b19ccdbb032361 | a6a8adb6356f4a879f079485dad1321b |       | 6e8fedc92dcb481aae9b17a622fa2360 |                                  | False     |
| da558c2a79c24b3096b19ccdbb032361 | a6a8adb6356f4a879f079485dad1321b |       |                                  | 6d3e495643524ebd8823849bea5041a8 | False     |
~~~

~~~
[stack@undercloud-4 ~]$ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin
~~~

~~~
[stack@undercloud-4 ~]$ openstack role assignment list | grep a6a8adb6356f4a879f079485dad1321b | grep da558c2a79c24b3096b19ccdbb032361 
| da558c2a79c24b3096b19ccdbb032361 | a6a8adb6356f4a879f079485dad1321b |       | 6e8fedc92dcb481aae9b17a622fa2360 |                                  | False     |
| da558c2a79c24b3096b19ccdbb032361 | a6a8adb6356f4a879f079485dad1321b |       |                                  | 6d3e495643524ebd8823849bea5041a8 | False     |
| da558c2a79c24b3096b19ccdbb032361 | a6a8adb6356f4a879f079485dad1321b |       |                                  | default                          | False     |
~~~

Now, the admin user can see the Domain tab.

Regards,

Andreas

Comment 60 Andreas Karis 2017-04-13 16:12:12 UTC
I am going to file a documentation bug against: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/integrate_with_identity_service/sec-active-directory

Strange though that we have to do this in 10 now, and before we didn't need it.

Comment 61 Radomir Dopieralski 2017-05-05 14:31:37 UTC
I think this is resolved as a configuration issue.

Comment 64 Andreas Karis 2017-05-11 02:58:47 UTC
Closed in combination with https://bugzilla.redhat.com/show_bug.cgi?id=1442144

Comment 65 Andreas Karis 2017-05-11 03:00:14 UTC
Radomir, I think that closing this as "NOTABUG" is wrong though! You indeed fixed a bug in the code.

Comment 66 Radomir Dopieralski 2017-05-11 12:51:56 UTC
Bu that was a different bug than reported here. We have a separate bugzilla for that one.

Comment 67 Radomir Dopieralski 2017-05-11 12:53:35 UTC
I am open to suggestions about how to best handle this situation. I'm sorry for causing the confusion -- it's because I wasn't strictly obeying the rules.

Comment 68 David Hill 2017-05-11 13:26:15 UTC
What was the other BZ?

Comment 69 Radomir Dopieralski 2017-05-11 13:28:57 UTC
It's https://bugzilla.redhat.com/show_bug.cgi?id=1403043

Comment 70 David Hill 2017-05-11 13:36:02 UTC
This BZ is for RHOSP 10 and the other is for RHOSP 9.  Is it the same issue?

Comment 71 Radomir Dopieralski 2017-05-11 13:37:48 UTC
Yes, it is the same issue, and the patch has been backported to osp (see comment 33). I suppose I should have created a separate bugzilla issue for osp9?

Comment 72 David Hill 2017-05-11 13:39:08 UTC
So then we had an ERRATA for this BZ too ?   I'd close it with an ERRATA then.

Comment 73 Martin Schuppert 2017-05-11 14:00:12 UTC
But to keep in mind, the errata is not yet released for OSP10. AFAIK with the next errata will'll get the rebase to 10.0.3 which then also has the fix for OSP10 included.

Comment 81 errata-xmlrpc 2017-06-28 15:17:35 UTC
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/RHSA-2017:1598


Note You need to log in before you can comment on or make changes to this bug.