OpenStack - User contributions [en]

Horizon/DomainWorkFlow

2015-07-14T19:40:52Z

Dan Nguyen:

== Intro ==
This wiki describes how to enable Domain Scoped Token support in Horizon and how to navigate the existing work flows.

=== Prerequisites ===
==== devstack ====
You'll need to have keystone running in a VM or somewhere you can reach it from Horizon.

==== Cloud Admin account in keystone ====
If a user has an 'admin' role and access to the Cloud Admin domain then they are considered to be a Cloud Admin.
One way to enable this account to grant your admin user access to the 'default' domain.
* Dig the admin token out of keystone.conf
grep -i 'admin_token' /etc/keystone/keystone.conf
* Grant the admin access to the cloud admin domain
curl -s -H "X-Auth-Token: <ADMIN_TOKEN>" -X PUT http://127.0.0.1:5000/v3/domains/default/users/<ADMIN_ID>/roles/<ADMIN_ROLE_ID>
Note: If you are having trouble finding the ADMIN_ID, you can find it with this command:
mysql -D keystone -e 'select id from user where name = "admin";'
Note: If you are having trouble finding the ADMIN_ROLE_ID, you can find it with this command:
mysql -D keystone -e 'select id from role where name = "admin";'

==== keystone policy.json file====
You can start testing with the default /etc/keystone/policy.json file but at some point you will want to switch in the following file:
https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json

Change the following line in the policy.v3cloudsample.json and swap it with the /etc/keystone/policy.json
Remember: He who laughs last had a backup!

old:
...
"cloud_admin": "rule:admin_required and domain_id:admin_domain_id",
...
new:
...
# use 'default' or whatever your cloud admin domain id is
"cloud_admin": "rule:admin_required and domain_id:default",
...

==== memcached ====
*Memcached should be installed and running (perhaps on the same host as horizon to keep things simple)
*The memcached client library needs to be installed in horizon's venv (python-memcached==1.53)
*Horizon needs to be configured to use memcached

local_settings.py
...
# We recommend you use memcached for development; otherwise after every reload
# of the django development server, you will have to login again. To use
# memcached set CACHES to something like
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': '127.0.0.1:11211',
}
}
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
...

==== keystone v3 ====
Horizon needs to be configured to use keystone v3 and multi domain support

Copy the keystone devstack's policy file: /etc/keyston/policy.json into your horizon directory:
horizon/openstack_dashboard/conf/keystone_policy.v3cloudsample.json

Determine the default role name:
mysql -D keystone -e 'select name from role where name like "%ember";'
In my case it has changed from "_member_" to "Member".

local_settings.py
...
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "Member"
...
OPENSTACK_API_VERSIONS = { "identity": 3, }
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'default'
OPENSTACK_KEYSTONE_URL = "http://%s:5000/v3" % OPENSTACK_HOST
...
POLICY_FILES = {
#'identity': 'keystone_policy.json',
'identity': 'keystone_policy.v3cloudsample.json',
...

==== django-openstack-auth ====
You'll need to pull down this patch to be able to retrieve a domain scoped token from the http session.
https://review.openstack.org/#/c/141153/

==== horizon ====
You'll need to pull down this patch in your horizon repo for horizon to understand multi-domain setups.
https://review.openstack.org/#/c/148082/

==== keystone ====
Allows a Domain Admin to list role assignments without a project token
https://review.openstack.org/#/c/180846/

==== keystone client ====
Allows a Domain Admin to list role assignments without a project token
https://review.openstack.org/#/c/188184/

=== Users ===
This page only considers three users
TODO(esp): Add use cases for Cloud Admin and Domain Admin
* Cloud Admin
* Domain Admin
* User (_member_ role)

==== Set up the cloud admin user ====
* Convert the admin user to be a Cloud Admin
curl -s -H "X-Auth-Token: <ADMN_TOKEN>" -X PUT http://127.0.0.1:5000/v3/domains/<DEFAULT DOMAIN>/users/<ADMIN USER ID>/roles/<ADMIN ROLE ID>

=== Workflow 1. Cloud Admin sets a Domain Context ===
[[File:Switch-domain-workflow-1.png]]

==== Cloud Admin Logs in ====
[[File:1. Log In.png]]
==== Cloud Admin navigates to the Identity Dashboard and Domain panel ====
[[File:2. Identity-Domains.png]]
==== Cloud Admin switches Domain context ====
[[File:3. Set Domain Context.png]]

Horizon/DomainSupport

2015-07-14T00:06:04Z

Dan Nguyen: /* Next Steps */

== (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

==== Project Admin ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains.
Project Admin is restricted to quota mgmt and listing roles, role_assignments by the current keystone v3 policy file.
Project Admin can not currently manage the members of it's project due to permissions for list_users.

==== Domain Admins and Project Admins should be mutually exclusive. ====
Domain Admin + Project Admin is not recommended

==== Only Cloud Admin(s) should have a role on an admin domain ====
Non-Cloud Admin users should not have a role on the default admin domain

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

=== Known Issues ===
- User with Domain Admins and Project Member
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose
- Pure Domain Admin Create Project will not have a quotas tab. (will need Cloud Admin to adjust if not using default values)

=== Horizon Bugs ===
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

=== Next Steps ===
- DOA patch
- Keystone patch
- Fix Horzon Bugs

=== Test Cases ===

=== Future ===
- angular goodness
- persona driven workflows
- keystone changes
- quota management

Horizon/DomainSupport

2015-07-14T00:05:39Z

Dan Nguyen: /* Horizon Bugs */

== (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

==== Project Admin ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains.
Project Admin is restricted to quota mgmt and listing roles, role_assignments by the current keystone v3 policy file.
Project Admin can not currently manage the members of it's project due to permissions for list_users.

==== Domain Admins and Project Admins should be mutually exclusive. ====
Domain Admin + Project Admin is not recommended

==== Only Cloud Admin(s) should have a role on an admin domain ====
Non-Cloud Admin users should not have a role on the default admin domain

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

=== Known Issues ===
- User with Domain Admins and Project Member
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose
- Pure Domain Admin Create Project will not have a quotas tab. (will need Cloud Admin to adjust if not using default values)

=== Horizon Bugs ===
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

=== Next Steps ===
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

=== Test Cases ===

=== Future ===
- angular goodness
- persona driven workflows
- keystone changes
- quota management

Horizon/DomainSupport

2015-07-14T00:04:44Z

Dan Nguyen: /* Project Admin should be deprecated */

== (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

==== Project Admin ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains.
Project Admin is restricted to quota mgmt and listing roles, role_assignments by the current keystone v3 policy file.
Project Admin can not currently manage the members of it's project due to permissions for list_users.

==== Domain Admins and Project Admins should be mutually exclusive. ====
Domain Admin + Project Admin is not recommended

==== Only Cloud Admin(s) should have a role on an admin domain ====
Non-Cloud Admin users should not have a role on the default admin domain

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

=== Known Issues ===
- User with Domain Admins and Project Member
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose
- Pure Domain Admin Create Project will not have a quotas tab. (will need Cloud Admin to adjust if not using default values)

=== Horizon Bugs ===
- list_role_assignments (pure domain admin)
- Group manage members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

=== Next Steps ===
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

=== Test Cases ===

=== Future ===
- angular goodness
- persona driven workflows
- keystone changes
- quota management

Horizon/MerlinEval

2015-06-08T23:38:47Z

Dan Nguyen: /* Steps */

== Merlin Horizon Integration ==
This page walks through the instructions of how to install Merlin into Horizon.

=== Useful Links ===
https://wiki.openstack.org/wiki/Merlin
https://github.com/stackforge/merlin

=== Steps ===
1. Create a workspace for horizon and merlin projects
$ mkdir <workspace>
$ cd <workspace>
$ git clone https://github.com/openstack/horizon.git
$ git clone https://github.com/stackforge/merlin.git

2a. Update Horizons local_settings.py
$ cd horizon/openstack_dashboard/local/
$ cp local_settings.py.example local_settings.py

2b. Add sqlite database
$ vi local_settings.py
...
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'horizon.sqlite3'
}
}
...

3. Create Horizon's .venv
$ cd horizon/
$ ./run_test.sh

4. Create symlinks to from Merlin to Horizon
$ cd .venv/lib/python2.7/site-packages/
$ ln -s <workspace>/merlin/merlin/ .
$ ln -s <workspace>/merlin/extensions/mistral .

5. Add Mistral Panel to Horizon
$ cd <workspace>/openstack_dashboard/enabled/_50_add_mistral_panel.py .

6. Sync the database
$ cd <workspace>/horizon/
$ source .venv/bin/activate
$ python manage.py syncdb

7. Start Horizon dev server
$ ./run_test.sh --runserver

=== Screen Shots ===
[[File:Mistral1.png]]

[[File:Mistral2.png]]

[[File:Mistral3.png]]

Horizon/MerlinEval

2015-06-08T23:38:22Z

Dan Nguyen: /* Steps */

== Merlin Horizon Integration ==
This page walks through the instructions of how to install Merlin into Horizon.

=== Useful Links ===
https://wiki.openstack.org/wiki/Merlin
https://github.com/stackforge/merlin

=== Steps ===
1. Create a workspace for horizon and merlin projects
$ mkdir <workspace>
$ cd <workspace>
$ git clone https://github.com/openstack/horizon.git
$ git clone https://github.com/stackforge/merlin.git

2a. Update Horizons local_settings.py
$ cd horizon/openstack_dashboard/local
$ cp local_settings.py.example local_settings.py

2b. Add sqlite database
$ vi local_settings.py
...
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'horizon.sqlite3'
}
}
...

3. Create Horizon's .venv
$ cd horizon/
$ ./run_test.sh

4. Create symlinks to from Merlin to Horizon
$ cd .venv/lib/python2.7/site-packages/
$ ln -s <workspace>/merlin/merlin/ .
$ ln -s <workspace>/merlin/extensions/mistral .

5. Add Mistral Panel to Horizon
$ cd <workspace>/openstack_dashboard/enabled/_50_add_mistral_panel.py .

6. Sync the database
$ cd <workspace>/horizon/
$ source .venv/bin/activate
$ python manage.py syncdb

7. Start Horizon dev server
$ ./run_test.sh --runserver

=== Screen Shots ===
[[File:Mistral1.png]]

[[File:Mistral2.png]]

[[File:Mistral3.png]]

Horizon/MerlinEval

2015-06-08T18:38:38Z

Dan Nguyen:

== Merlin Horizon Integration ==
This page walks through the instructions of how to install Merlin into Horizon.

=== Useful Links ===
https://wiki.openstack.org/wiki/Merlin
https://github.com/stackforge/merlin

=== Steps ===
1. Create a workspace for horizon and merlin projects
$ mkdir <workspace>
$ git clone https://github.com/openstack/horizon.git
$ git clone https://github.com/stackforge/merlin.git

2a. Update Horizons local_settings.py
$ cd ../openstack_dashboard/local
$ cp local_settings.py.example local_settings.py

2b. Add sqlite database
$ vi local_settings.py
...
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'horizon.sqlite3'
}
}
...

3. Create Horizon's .venv
$ cd horizon/
$ ./run_test.sh

4. Create symlinks to from Merlin to Horizon
$ cd .venv/lib/python2.7/site-packages/
$ ln -s <workspace>/merlin/merlin/ .
$ ln -s <workspace>/merlin/extensions/mistral .

5. Add Mistral Panel to Horizon
$ cd <workspace>/openstack_dashboard/enabled/_50_add_mistral_panel.py .

6. Sync the database
$ cd <workspace>/horizon/
$ source .venv/bin/activate
$ python manage.py syncdb

7. Start Horizon dev server
$ ./run_test.sh --runserver

=== Screen Shots ===
[[File:Mistral1.png]]

[[File:Mistral2.png]]

[[File:Mistral3.png]]

Horizon/MerlinEval

2015-06-08T18:36:28Z

Dan Nguyen: /* Screen Shots */

== Merlin Horizon Integration ==
This page walks through the instructions of how to install Merlin into Horizon.

=== Useful Links ===
https://github.com/stackforge/merlin

=== Steps ===
1. Create a workspace for horizon and merlin projects
$ mkdir <workspace>
$ git clone https://github.com/openstack/horizon.git
$ git clone https://github.com/stackforge/merlin.git

2a. Update Horizons local_settings.py
$ cd ../openstack_dashboard/local
$ cp local_settings.py.example local_settings.py

2b. Add sqlite database
$ vi local_settings.py
...
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'horizon.sqlite3'
}
}
...

3. Create Horizon's .venv
$ cd horizon/
$ ./run_test.sh

4. Create symlinks to from Merlin to Horizon
$ cd .venv/lib/python2.7/site-packages/
$ ln -s <workspace>/merlin/merlin/ .
$ ln -s <workspace>/merlin/extensions/mistral .

5. Add Mistral Panel to Horizon
$ cd <workspace>/openstack_dashboard/enabled/_50_add_mistral_panel.py .

6. Sync the database
$ cd <workspace>/horizon/
$ source .venv/bin/activate
$ python manage.py syncdb

7. Start Horizon dev server
$ ./run_test.sh --runserver

=== Screen Shots ===
[[File:Mistral1.png]]

[[File:Mistral2.png]]

[[File:Mistral3.png]]

Horizon/MerlinEval

2015-06-08T18:35:51Z

Dan Nguyen: /* Screen Shots */

File:Mistral3.png

2015-06-08T18:33:42Z

Dan Nguyen:

File:Mistral2.png

2015-06-08T18:33:27Z

Dan Nguyen:

File:Mistral1.png

2015-06-08T18:32:47Z

Dan Nguyen:

Horizon/MerlinEval

2015-06-08T18:29:58Z

Dan Nguyen: /* Merlin Horizon Integration */

Horizon/MerlinEval

2015-06-08T18:17:57Z

Dan Nguyen: /* Heading text */

Horizon/MerlinEval

2015-06-08T17:49:42Z

Dan Nguyen: /* Merlin Horizon Integration */

== Merlin Horizon Integration ==
This page walks through the instructions of how to install Merlin into Horizon.

=== Heading text ===

=== Steps ===
1. Create a workspace for horizon and merlin projects
$ mkdir <workspace>
$ git clone https://github.com/openstack/horizon.git
$ git clone https://github.com/stackforge/merlin.git

2a. Update Horizons local_settings.py
$ cd ../openstack_dashboard/local
$ cp local_settings.py.example local_settings.py

2b. Add sqlite database
$ vi local_settings.py
...
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'horizon.sqlite3'
}
}
...

3. Create Horizon's .venv
$ cd horizon/
$ ./run_test.sh

4. Create symlinks to from Merlin to Horizon
$ cd .venv/lib/python2.7/site-packages/
$ ln -s <workspace>/merlin/merlin/ .
$ ln -s <workspace>/merlin/extensions/mistral .

5. Add Mistral Panel to Horizon
$ cd <workspace>/openstack_dashboard/enabled/_50_add_mistral_panel.py .

6. Sync the database
$ cd <workspace>/horizon/
$ source .venv/bin/activate
$ python manage.py syncdb

7. Start Horizon dev server
$ ./run_test.sh --runserver

Horizon/MerlinEval

2015-06-08T17:47:27Z

Dan Nguyen: /* Steps */

== Merlin Horizon Integration ==
This page walks through the instructions of how to install Merlin into Horizon.

=== Steps ===
1. Create a workspace for horizon and merlin projects
$ mkdir <workspace>
$ git clone https://github.com/openstack/horizon.git
$ git clone https://github.com/stackforge/merlin.git

2a. Update Horizons local_settings.py
$ cd ../openstack_dashboard/local
$ cp local_settings.py.example local_settings.py

2b. Add sqlite database
$ vi local_settings.py
...
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'horizon.sqlite3'
}
}
...

3. Create Horizon's .venv
$ cd horizon/
$ ./run_test.sh

4. Create symlinks to from Merlin to Horizon
$ cd .venv/lib/python2.7/site-packages/
$ ln -s <workspace>/merlin/merlin/ .
$ ln -s <workspace>/merlin/extensions/mistral .

5. Add Mistral Panel to Horizon
$ cd <workspace>/openstack_dashboard/enabled/_50_add_mistral_panel.py .

6. Sync the database
$ cd <workspace>/horizon/
$ source .venv/bin/activate
$ python manage.py syncdb

7. Start Horizon dev server
$ ./run_test.sh --runserver

Horizon/MerlinEval

2015-06-08T17:37:07Z

Dan Nguyen:

Horizon/MerlinEval

2015-06-08T17:02:55Z

Dan Nguyen: /* Merlin Horizon Integration */

Horizon/MerlinEval

2015-06-08T16:33:41Z

Dan Nguyen: Created page with "== Merlin Horizon Integration == This page walks through the instructions of how to install Merlin into Horizon. === Steps === 1. Create a workspace for horizon and merlin pr..."

Horizon/DomainSupport

2015-05-07T16:56:53Z

Dan Nguyen: /* Known Issues */

== (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

==== Project Admin should be deprecated ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains

==== Domain Admins and Project Admins should be mutually exclusive. ====
Domain Admin + Project Admin is not recommended

==== Only Cloud Admin(s) should have a role on an admin domain ====
Non-Cloud Admin users should not have a role on the default admin domain

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

=== Known Issues ===
- User with Domain Admins and Project Member
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose
- Pure Domain Admin Create Project will not have a quotas tab. (will need Cloud Admin to adjust if not using default values)

=== Horizon Bugs ===
- list_role_assignments (pure domain admin)
- Group manage members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

=== Next Steps ===
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

=== Test Cases ===

=== Future ===
- angular goodness
- persona driven workflows
- keystone changes
- quota management

Horizon/DomainSupport

2015-05-01T22:55:14Z

Dan Nguyen:

== (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

==== Project Admin should be deprecated ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains

==== Domain Admins and Project Admins should be mutually exclusive. ====
Domain Admin + Project Admin is not recommended

==== Only Cloud Admin(s) should have a role on an admin domain ====
Non-Cloud Admin users should not have a role on the default admin domain

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

=== Known Issues ===
- User with Domain Admins and Project Member
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose

=== Horizon Bugs ===
- list_role_assignments (pure domain admin)
- Group manage members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

=== Next Steps ===
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

=== Test Cases ===

=== Future ===
- angular goodness
- persona driven workflows
- keystone changes
- quota management

Horizon/DomainSupport

2015-05-01T22:52:04Z

Dan Nguyen:

== (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

==== Project Admin should be deprecated ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains

==== Domain Admins and Project Admins should be mutually exclusive. ====
Domain Admin + Project Admin is not recommended

==== Only Cloud Admin(s) should have a role on an admin domain ====
Non-Cloud Admin users should not have a role on the default admin domain

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

===== Known Issues =====
- User with Domain Admins and Project Member
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose

===== Horizon Bugs =====
- list_role_assignments (pure domain admin)
- Group manage members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

==== Next Steps =====
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

===== Test Cases =====

===== Future =====
- angular goodness
- persona driven workflows
- keystone changes
- quota management

Horizon/DomainSupport

2015-05-01T22:43:00Z

Dan Nguyen: /* Best Practices */

== (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

==== Project Admin should be deprecated ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains

==== Domain Admins and Project Admins should be mutually exclusive. ====
Domain Admin + Project Admin is not recommended

==== Only Cloud Admin(s) should have a role on an admin domain ====
Non-Cloud Admin users should not have a role on the default admin domain

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

'''Known Issues'''
- Mixing Domain Admin + Project Admin
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose

'''Horizon Bugs'''
- luigi (project member, invalid Catalog Service:compute)
- list_role_assignments (pure domain admin)
- Group manange members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

'''Next Steps'''
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

'''Test Cases'''

'''Future'''
- angular goodness
- persona driven workflows
- keystone changes
- quota inheritance

Horizon/DomainSupport

2015-05-01T01:25:10Z

Dan Nguyen: /* Domain Support (Work In Progress) */

== (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

==== Project Admin should be deprecated ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains

==== Domain Admins and Project Admins should be mutually exclusive. ====
Domain Admin + Project Admin is not recommended

==== Domain Admins and Project Members should be mutually exclusive. ====
Domain Admin + Project Member is not recommended (even in the same domain)

==== Only Cloud Admin(s) should have a role on an admin domain ====
Non-Cloud Admin users should not have a role on the default admin domain

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

'''Known Issues'''
- Mixing Domain Admin + Project Admin
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose

'''Horizon Bugs'''
- luigi (project member, invalid Catalog Service:compute)
- list_role_assignments (pure domain admin)
- Group manange members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

'''Next Steps'''
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

'''Test Cases'''

'''Future'''
- angular goodness
- persona driven workflows
- keystone changes
- quota inheritance

Horizon/DomainSupport

2015-05-01T01:21:38Z

Dan Nguyen: /* Domain Admins and Project Admins should be mutually exclusive. */

== Domain Support (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

==== Project Admin should be deprecated ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains

==== Domain Admins and Project Admins should be mutually exclusive. ====
Domain Admin + Project Admin is not recommended

==== Domain Admins and Project Members should be mutually exclusive. ====
Domain Admin + Project Member is not recommended (even in the same domain)

==== Only Cloud Admin(s) should have a role on an admin domain ====
Non-Cloud Admin users should not have a role on the default admin domain

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

'''Known Issues'''
- Mixing Domain Admin + Project Admin
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose

'''Horizon Bugs'''
- luigi (project member, invalid Catalog Service:compute)
- list_role_assignments (pure domain admin)
- Group manange members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

'''Next Steps'''
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

'''Test Cases'''

'''Future'''
- angular goodness
- persona driven workflows
- keystone changes

Horizon/DomainSupport

2015-05-01T01:21:23Z

Dan Nguyen: /* Best Practices */

Horizon/DomainSupport

2015-05-01T01:07:45Z

Dan Nguyen: /* Best Practices */

== Domain Support (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

==== Project Admin should be avoided ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains

==== Domain Admins and Project Admins should be mutually exclusive. ====
Domain Admin + Project Admin is not recommended
Domain Admin + Project Member is not recommended

==== Only Cloud Admin(s) should have a role on an admin domain ====
Non-Cloud Admin users should not have a role on the default admin domain

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

'''Known Issues'''
- Mixing Domain Admin + Project Admin
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose

'''Horizon Bugs'''
- luigi (project member, invalid Catalog Service:compute)
- list_role_assignments (pure domain admin)
- Group manange members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

'''Next Steps'''
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

'''Test Cases'''

'''Future'''
- angular goodness
- persona driven workflows
- keystone changes

Horizon/DomainSupport

2015-05-01T01:05:15Z

Dan Nguyen: /* An new admin domain should be created */

== Domain Support (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
- Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

==== Project Admin should be avoided ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains

==== Domain Admins and Project Admins should be mutually exclusive. ====
- Domain Admin + Project Admin is not recommended
- Domain Admin + Project Member is not recommended

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

'''Known Issues'''
- Mixing Domain Admin + Project Admin
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose

'''Horizon Bugs'''
- luigi (project member, invalid Catalog Service:compute)
- list_role_assignments (pure domain admin)
- Group manange members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

'''Next Steps'''
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

'''Test Cases'''

'''Future'''
- angular goodness
- persona driven workflows
- keystone changes

Horizon/DomainSupport

2015-05-01T00:15:57Z

Dan Nguyen: /* Domain Admins and Project Admins should be mutually exclusive. */

== Domain Support (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
- Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.
- Non-Cloud Admin users should not have a role on the default admin domain

==== Project Admin should be avoided ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains

==== Domain Admins and Project Admins should be mutually exclusive. ====
- Domain Admin + Project Admin is not recommended
- Domain Admin + Project Member is not recommended

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

'''Known Issues'''
- Mixing Domain Admin + Project Admin
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose

'''Horizon Bugs'''
- luigi (project member, invalid Catalog Service:compute)
- list_role_assignments (pure domain admin)
- Group manange members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

'''Next Steps'''
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

'''Test Cases'''

'''Future'''
- angular goodness
- persona driven workflows
- keystone changes

Horizon/DomainSupport

2015-04-30T23:37:02Z

Dan Nguyen: /* Avoid mixing User Type roles */

== Domain Support (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
- Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.
- Non-Cloud Admin users should not have a role on the default admin domain

==== Project Admin should be avoided ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains

==== Domain Admins and Project Admins should be mutually exclusive. ====
- Domain Admin + Project Admin is not supported
- Domain Admin + Project Member is not supported

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

'''Known Issues'''
- Mixing Domain Admin + Project Admin
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose

'''Horizon Bugs'''
- luigi (project member, invalid Catalog Service:compute)
- list_role_assignments (pure domain admin)
- Group manange members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

'''Next Steps'''
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

'''Test Cases'''

'''Future'''
- angular goodness
- persona driven workflows
- keystone changes

Horizon/DomainSupport

2015-04-30T23:34:14Z

Dan Nguyen:

== Domain Support (Work In Progress) ==

=== Use Cases ===
- LDAP, AD, MySQL support

=== Best Practices ===

==== Keystone v3 policy files ====
Horizon should use the same keystone v3 policy file as the keystone API

==== An new admin domain should be created ====
- Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.
- Non-Cloud Admin users should not have a role on the default admin domain

==== Project Admin should be avoided ====
Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains

==== Avoid mixing User Type roles ====
- Domain Admin + Project Member is not supported
- Domain Admin + Project Admin is not supported

=== Definitions ===

==== User Types / Personas ====

===== Cloud Admin =====
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.

===== Domain Admin =====
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.

===== Project Admin =====
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.

===== Project User =====
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

''Note:''
Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

'''Known Issues'''
- Mixing Domain Admin + Project Admin
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose

'''Horizon Bugs'''
- luigi (project member, invalid Catalog Service:compute)
- list_role_assignments (pure domain admin)
- Group manange members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

'''Next Steps'''
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

'''Test Cases'''

'''Future'''
- angular goodness
- persona driven workflows
- keystone changes

Horizon/DomainSupport

2015-04-30T23:05:36Z

Dan Nguyen: Created page with "'''Domain Support (Work In Progress)''' '''Use Cases''' - LDAP, AD, MySQL support '''Best Practices''' - Use the same policy files all around - Create a separate domain a..."

'''Domain Support (Work In Progress)'''

'''Use Cases'''
- LDAP, AD, MySQL support

'''Best Practices'''
- Use the same policy files all around
- Create a separate domain as the default Admin domain
- Discourage use of Project Admin
- Discourage use of Mixed roles (Domain Admin + Project Member)

'''Definitions'''

'''Known Issues'''
- Mixing Domain Admin + Project Admin
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose

'''Horizon Bugs'''
- luigi (project member, invalid Catalog Service:compute)
- list_role_assignments (pure domain admin)
- Group manange members (pure domain admin)
- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

'''Next Steps'''
- DOA patch
- Keystone patch
- Fix Horzon Bugs
- UX/UI - project picker, set domain context changes

'''Test Cases'''

'''Future'''
- angular goodness
- persona driven workflows
- keystone changes

Horizon/DomainWorkFlow

2015-02-27T21:25:09Z

Dan Nguyen: /* keystone v3 */

== Intro ==
This wiki describes how to enable Domain Scoped Token support in Horizon and how to navigate the existing work flows.

=== Prerequisites ===
==== devstack ====
You'll need to have keystone running in a VM or somewhere you can reach it from Horizon.

==== Cloud Admin account in keystone ====
If a user has an 'admin' role and access to the Cloud Admin domain then they are considered to be a Cloud Admin.
One way to enable this account to grant your admin user access to the 'default' domain.
* Dig the admin token out of keystone.conf
grep -i 'admin_token' /etc/keystone/keystone.conf
* Grant the admin access to the cloud admin domain
curl -s -H "X-Auth-Token: <TOKEN>" -X PUT http://127.0.0.1:5000/v3/domains/default/users/<ADMIN_ID>/roles/<ADMIN_ROLE_ID>
Note: If you are having trouble finding the ADMIN_ROLE_ID, you can find it with this command:
mysql -D keystone -e 'select id from role where name = "admin";'

==== keystone policy.json file====
You can start testing with the default /etc/keystone/policy.json file but at some point you will want to switch in the following file:
https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json

Change the following line in the policy.v3cloudsample.json and swap it with the /etc/keystone/policy.json
Remember: He who laughs last had a backup!

old:
...
"cloud_admin": "rule:admin_required and domain_id:admin_domain_id",
...
new:
...
# use 'default' or whatever your cloud admin domain id is
"cloud_admin": "rule:admin_required and domain_id:default",
...

==== memcached ====
*Memcached should be installed and running (perhaps on the same host as horizon to keep things simple)
*The memcached client library needs to be installed in horizon's venv (python-memcached==1.53)
*Horizon needs to be configured to use memcached

local_settings.py
...
# We recommend you use memcached for development; otherwise after every reload
# of the django development server, you will have to login again. To use
# memcached set CACHES to something like
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': '127.0.0.1:11211',
}
}
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
...

==== keystone v3 ====
Horizon needs to be configured to use keystone v3 and multi domain support

Copy the keystone devstack's policy file: /etc/keyston/policy.json into your horizon directory:
horizon/openstack_dashboard/conf/keystone_policy.v3cloudsample.json

Determine the default role name:
mysql -D keystone -e 'select name from role where name like "%ember";'
In my case it has changed from "_member_" to "Member".

local_settings.py
...
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "Member"
...
OPENSTACK_API_VERSIONS = { "identity": 3, }
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'default'
OPENSTACK_KEYSTONE_URL = "http://%s:5000/v3" % OPENSTACK_HOST
...
POLICY_FILES = {
#'identity': 'keystone_policy.json',
'identity': 'keystone_policy.v3cloudsample.json',
...

==== django-openstack-auth ====
You'll need to pull down this patch to be able to retrieve a domain scoped token from the http session.
https://review.openstack.org/#/c/141153/

==== horizon ====
You'll need to pull down this patch in your horizon repo for horizon to understand multi-domain setups.
https://review.openstack.org/#/c/148082/

=== Users ===
This page only considers three users
TODO(esp): Add use cases for Cloud Admin and Domain Admin
* Cloud Admin
* Domain Admin
* User (_member_ role)

==== Set up the cloud admin user ====
* Convert the admin user to be a Cloud Admin
curl -s -H "X-Auth-Token: <TOKEN>" -X PUT http://127.0.0.1:5000/v3/domains/<DEFAULT DOMAIN>/users/<ADMIN USER ID>/roles/<ADMIN ROLE ID>

=== Workflow 1. Cloud Admin sets a Domain Context ===
[[File:Switch-domain-workflow-1.png]]

==== Cloud Admin Logs in ====
[[File:1. Log In.png]]
==== Cloud Admin navigates to the Identity Dashboard and Domain panel ====
[[File:2. Identity-Domains.png]]
==== Cloud Admin switches Domain context ====
[[File:3. Set Domain Context.png]]

Horizon/DomainWorkFlow

2015-01-22T19:14:38Z

Dan Nguyen:

Horizon/DomainWorkFlow

2015-01-22T19:14:06Z

Dan Nguyen: /* Users */

Horizon/DomainWorkFlow

2015-01-22T18:23:39Z

Dan Nguyen: /* Cloud Admin impersonates a Domain or switches Domain context */

Horizon/DomainWorkFlow

2015-01-20T23:38:17Z

Dan Nguyen: /* keystone policy.json file */

Horizon/DomainWorkFlow

2015-01-20T23:37:10Z

Dan Nguyen: /* Cloud Admin account in keystone */

Horizon/DomainWorkFlow

2015-01-20T23:32:15Z

Dan Nguyen:

Horizon/DomainWorkFlow

2015-01-20T23:27:16Z

Dan Nguyen: /* keystone policy.json file */

Horizon/DomainWorkFlow

2015-01-20T23:26:32Z

Dan Nguyen:

Horizon/DomainWorkFlow

2015-01-13T00:47:47Z

Dan Nguyen:

File:3. Set Domain Context.png

2015-01-13T00:41:49Z

Dan Nguyen:

File:2. Identity-Domains.png

2015-01-13T00:39:25Z

Dan Nguyen:

File:1. Log In.png

2015-01-13T00:38:58Z

Dan Nguyen:

Horizon/DomainWorkFlow

2015-01-13T00:36:28Z

Dan Nguyen: /* Workflow 1. Cloud Admin creates a new Domain and Resources */

Horizon/DomainWorkFlow

2015-01-13T00:34:00Z

Dan Nguyen: /* Workflow 1. Cloud Admin creates a new Domain and Resources */

File:Switch-domain-workflow-1.png

2015-01-13T00:32:24Z

Dan Nguyen:

Horizon/DomainWorkFlow

2015-01-13T00:27:26Z

Dan Nguyen:

Horizon/DomainWorkFlow

2015-01-13T00:24:26Z

Dan Nguyen: /* keystone v3 */