| An Ansible playbook for taking a Ubuntu 16.04 node and turning it into a testshib | |
| service provider for testing keystone/horizon federation. | |
| Roles can be found here: | |
| * https://galaxy.ansible.com/dstanek/devstack/ | |
| * https://galaxy.ansible.com/dstanek/keystone-sp/ | |
| Steps: | |
| 1. Create a new VM (Rackspace, Virtualbox, whatever) | |
| 2. Run 'ansible-playbook -i "[ip address]," playbook.yml' where [ip address] is your VM's IP. |
| " pull gist cvimrc.vim every hour and at Chrome startup | |
| set autoupdategist | |
| " don't allow web pages to auto focus on input boxes when they load | |
| set noautofocus | |
| " smooth scrolling | |
| set smoothscroll | |
| let barposition = "bottom" | |
| let blacklists = ["https://inbox.google.com/*"] |
| #!/usr/bin/env python3 | |
| # Download https://www.openstack.org/summit/austin-2016/summit-schedule/mine/?goback=1 | |
| # to mine.html and then run this script. The my.ics can be imported into your | |
| # calendar. | |
| # | |
| # Common problems: | |
| # - i've only tested against my calendar (and got feedback about bugs from others) so | |
| # so you may find the parsing isn't quite right |
| #!/usr/bin/env python3 | |
| import collections | |
| import datetime | |
| import json | |
| MIN_INC = 5 | |
| EVENT_CONTINUED = object() | |
| EMPTY = object() |
This is a crazy rought draft. More like a semi-organized brainstorm.
To provide a stable API for building drivers. This gives third-party driver writers time (a full cycle) to update their drivers to fulfill new API expectations.
In Keystone we deliver our drivers in the same package as the managers. This makes it much easier for us to deal with changing APIs than for third-party developers.
| What? | |
| ----- | |
| Functional tests are black box tests that we can use to specify what makes Keystone. | |
| 1. Base tests that all Keystone implementations must pass | |
| 2. Optional tests specific to a setup (Federation) | |
| 3. They are not run using the Keystone client | |
| 4. They can be pointed to any cloud that you wish to test (shouldn't be a production cloud) |
| ;$TTL 86400 | |
| $TTL 10 | |
| ;@ IN SOA example-cloud.local. root.localhost. ( | |
| ; 1 ; Serial | |
| ; 604800 ; Refresh | |
| ; 86400 ; Retry | |
| ; 2419200 ; Expire | |
| ; 86400 ) ; Negative Cache TTL | |
| @ IN SOA RegionOne.example-cloud.local. root.localhost. ( | |
| 1 ; Serial |
| [dashboard] | |
| title = Things I Need To DO! | |
| description = A dashboard to help me focus my review efforts | |
| foreach = is:watched is:open limit:10 NOT label:Workflow-1 | |
| [section "Needs a review"] | |
| query = NOT label:Code-Review<=-1,self NOT label:Code-Review>=1,self NOT owner:self | |
| [section "Needs me to do something"] | |
| query = owner:self (label:Workflow<=-1 OR label:Verified-1 OR label:Code-Review<=-1) |
2015-05-18 11:15:00-07:00
Room 211,
Who can do what? In OpenStack, it is the Policy engine that controls these decisions. A secure deployment means moving beyond the default policy provided with the base distribution. But how do you write policy rules that reflect your security decisions? This presentation, Adam Young, a core Keystone developer from the Red Hat Identity Management team, explain the access control policy mechanism fr...
Enabling Real-world Interoperable Hybrid Cloud Use Cases Using OpenStack's Federated Identity Capabilities
| import collections | |
| import re | |
| import routes | |
| from keystone import assignment | |
| from keystone import auth | |
| from keystone import catalog | |
| from keystone.common import controller | |
| from keystone import credential |