ee5fb6911b
First, including rst files is inconvenient and does not play well with references (ends up in duplicates). Make user/keystone a proper separate document. Second, address various factual errors in both keystone documents. Change-Id: I5d54c0727c428956424deb7998e86ad3e802bdf6
2.2 KiB
Using Keystone
Ultimately, as bifrost was designed for relatively short-lived
installations to facilitate rapid hardware deployment, the default
operating mode is referred to as noauth mode. In order to
leverage Keystone authentication for the roles, Bifrost reads
configuration from clouds.yaml. If clouds.yaml
has not been generated through the
bifrost-keystone-client-config role, one of the following
steps need to take place:
Update the role defaults for each role you plan to make use. This may not make much sense for most users, unless they are carrying such changes as downstream debt.
Invoke ansible-playbook with variables being set to override the default behavior. Example:
-e enable_keystone=true -e noauth_mode=false -e cloud_name=bifrostSet the global defaults for tagret (
master/playbooks/inventory/group_vars/target).
OpenStack Client usage
A user wishing to invoke OSC commands against the bifrost
installation, should set the OS_CLOUD environment variable.
An example of setting the environment variable and then executing the
OSC command to list all baremetal nodes:
export OS_CLOUD=bifrost
openstack baremetal node listFor administration actions, use the bifrost-admin
cloud:
export OS_CLOUD=bifrost-admin
openstack endpoint listKeystone roles
Ironic, which is the underlying OpenStack component bifrost helps a user leverage, supports two different roles in keystone that helps govern the rights a user has in keystone.
These roles are baremetal_admin and
baremetal_observer and a user can learn more about the
roles from the ironic install
guide.
Individual playbook use
The OpenStack Ansible modules utilize clouds.yaml file
to obtain authentication details to connect to determine details. The
bifrost roles that speak with Ironic for actions such as enrollment of
nodes and deployment, automatically attempt to collect authentication
data from clouds.yaml. A user can explicitly select the
cloud they wish to deploy to via the cloud_name
parameter.