Contents
Once the nodes are installed and configured you can start deploying the OpenStack services in order to finalize the installation. The services need to be deployed in a given order, because they depend on one another. Deployment is done from the Crowbar Web interface through recipes, so-called “Barclamps”.
The services controlling the cloud (including storage management and control services) need to be installed on the Controller Node. However, you may not use your Controller Node as a compute or storage host. Here is a list with services that may not be installed on the Controller Node: , , . These services need to be installed on dedicated nodes.
The OpenStack services need to be deployed in the following order. For general instructions on how to edit and deploy Barclamp, refer to Section 5.1, “Barclamp”. Deploying Swift and Ceph is optional; all other services must be deployed.
Deploying Ceph (optional, unsupported)
![]() | Ceph not Supported |
---|---|
As of SUSE Cloud 1.0, Ceph is not officially supported but rather included as a technical preview, so using Nova Volume instead is recommended. |
The OpenStack services are automatically installed on the nodes by using so-called Barclamps—a set of recipes, templates, and installation instructions. All existing Barclamps can be accessed from the Crowbar Web interface by clicking on
. To edit a Barclamp, proceed as follows:
Open a browser and point it to the Crowbar Web interface available at port
3000
of the Administration Server, for example http://192.168.124.10:3000/. Log in as user crowbar
. The password defaults to
crowbar
, if you have not changed it.
Click
to open the menu. Alternatively you may filter the list to or Barclamps by choosing the respective option from . The Barclamps contain general recipes for setting up and configuring all nodes, while the are dedicated to OpenStack service deployment and configuration.Click a Barclamp's name. You can either
a proposal or an existing one.When creating a new proposal, give it a meaningful name and description. You can create several proposals, for example, for testing purposes, but only one at a time can be deployed.
Most OpenStack Barclamps consist of two sections: the
section lets you change the configuration, and the section lets you choose onto which nodes to deploy the Barclamp.To edit the
section, change the values via the Web form. Alternatively you can directly edit the configuration file by clicking .![]() | Raw Mode |
---|---|
Only use the mode in case an option cannot be changed via Web form. Raw mode does not perform any syntax checks.If you switch between mode and Web form ( mode), make sure to your changes before switching, otherwise they will be lost. |
In the not drop a node onto the input field—this is rather used to filter the list of !
section of the OpenStack Barclamp you can drag and drop nodes from the column to the desired role. You need to drop the node onto the role name. DoOne or more nodes are usually automatically pre-selected for available roles. If this pre-selection does not meet your requirements, remove it before dragging new nodes to the role. To remove a node from a role, click the respective icon.
To save and deploy your edits, click Section 5.1.1, “Deactivate a Proposal that Already has been Deployed” for details.
. To just save your changes without deploying them, click . To remove the complete proposal, click . A proposal that already has been deployed can only be deleted manually, seeIf you deploy a proposal onto a node where a previous one is still active, the new proposal will overwrite the old one.
![]() | Wait Until a Proposal has been Deployed |
---|---|
Deploying a proposal might take some time (up to several minutes). It is strongly recommended to always wait until you see the note “Successfully applied the proposal” before proceeding on to the next proposal. |
![]() | Barclamp Deployment Failure |
---|---|
In case the deployment of a Barclamp fails, make sure to fix the reason that has caused the failure and deploy the Barclamp again. Refer to the respective troubleshooting section at Section 6.1.2, “OpenStack Node Deployment” for help. A deployment failure may leave your node in an inconsistent state. |
To finally deactivate a proposal that already has been deployed, you
first need to root
on the Administration Server
afterwards:
P_NAME="proposal_name_to_delete
" SERVICE="service_name
" crowbar $SERVICE proposal delete $P_NAME crowbar $SERVICE delete $P_NAME
proposal_name_to_delete
needs to be replaced
by the name of the proposal you want to delete.
service_name
needs to be replaced by one of
the following strings representing the OpenStack services:
ceph
, database
,
glance
, keystone
,
nova_dashboard
, nova
,
swift
.
The very first service that needs to be deployed is the
. The database service is used by all other services. It must be installed on the Controller Node.SUSE Cloud only supports
as an , so this value must not be changed.is another core component that is used by all other OpenStack services. It provides authentication and authorization services. needs to be installed on the Controller Node. You can configure the following parameters of this Barclamp:
Must be set to
. This is the default.Name of the proposal you deployed in the previous step (see Section 5.2, “Deploying the Database”). The default value should be correct.
Tenant for the users. Do not change the default value of
openstack
.
Username and password for the regular user and the administrator. Both accounts can be used to log in to the SUSE Cloud Dashboard to manage Keystone users and access.
The permanent administrator token (random string).
Expiration Date for the administrator token. Must be entered in the
form
YYYY-MM-DD
THH:MM
,
e.g. 2015-03-31T12:00.
When sticking with the default value HTTP
, public
communication will not be encrypted. Choose HTTPS
to
use SSL for encryption and specify the path to the certificate
files. Note that you need to create and copy the certificate prior to
deploying Keystone, see Section 4.3.3, “Enabling SSL”
for instructions.
Swift adds an object storage service to SUSE Cloud that lets you store single files such as images or snapshots. It offers high data security by storing the data redundantly on a pool of Storage Nodes—therefore Swift needs to be installed on at least two dedicated nodes.
It is recommended not to change the defaults in the Barclamp proposal, unless you know exactly what you requir. However you should change the
. If you plan to change the value, it is important to know that you need at least as many Storage Nodes as .The Swift service consists of three different roles:
The ring maintains the information about the location of objects, replicas, and devices. It can be compared to an index, that is used by various OpenStack services to look up the physical location of objects.
must only be installed on a single node; it is recommended to use the Controller Node.The Swift proxy server takes care of routing requests to Swift. Installing a single instance of
on the Controller Node is recommended.The virtual object storage service. Install this role on all dedicated Swift Storage Nodes (at least two), but not on any other node.
![]() | Swift-storage Needs Dedicated Machines |
---|---|
Never install the Swift-storage service on a node that runs other OpenStack services. |
Ceph adds a redundant block storage service to SUSE Cloud. It lets you store persistent devices that can be mounted from instances. It offers high data security by storing the data redundantly on a pool of Storage Nodes—therefore Ceph needs to be installed on at least two dedicated nodes.
For more information on the Ceph project, vist http://ceph.com/.
![]() | Ceph not Supported |
---|---|
As of SUSE Cloud 1.0, Ceph is not officially supported but rather included as a technical preview, so using Nova Volume instead is recommended. |
The Ceph Barclamp only has one configuration option: telling Ceph which devices to use on the nodes. Edit the Barclamp in
and search for the following lines"devices": [ ],
Add a comma-separated list of devices that should be used by Ceph. For example:
"devices": [ "/dev/sdb", "/dev/sdc", "/dev/sdd" ],
![]() | Devices |
---|---|
Not all of the devices used for Ceph need to exist on all nodes. All devices from a node matching the list will be used. They must not be mounted prior to deploying Ceph. Any data stored on these devices will be lost. |
The Ceph service consists of three different roles:
Master cluster monitor daemon for the Ceph distributed file system.
must only be installed on a single node; it is recommended to use the Controller Node.Cluster monitor daemon for the Ceph distributed file system.
needs to be installed on two or four Storage Nodes.![]() | Number of Ceph Monitor Nodes |
---|---|
In addition to the node running the Ceph-mon-master service an additional two or four nodes also need to run the service. The sum of the and the nodes must always be an odd number (either three or five).Nodes running cannot be deleted or temporarily be disabled. |
The virtual block storage service. Install this role on all dedicated Ceph Storage Nodes (at least two), but not on any other node.
![]() | -store Needs Dedicated Machines |
---|---|
Never deploy on a node that runs other non-Ceph OpenStack services. The only service that may be deployed together with it is . |
Deploying Ceph requires to perform the steps in a given order:
Edit the Barclamp proposal to specify the devices to be used by Ceph as described above.
Drag and drop a node (for example, the Controller Node) to the
role.Drag and drop two or four nodes to the
role. Note that the maximum number of nodes cannot exceed four and that the sum of and nodes must be odd.Drag and drop all dedicated Ceph Storage Nodes to the
(at least two). You may also use the nodes with the roles, but not the node (you can add that one later).Click
to deploy your proposal. This can take some time.If you also want to use the
as a Storage Node, drag and drop it to the role and click again. Note that it is not recommended to use the Controller Node for non-management purposes such as storage or compute.Glance provides discovery, registration, and delivery services for virtual disk images. An image is needed to start an instance—it is its pre-installed root-partition. All images you want to use in your cloud to boot instances from, are provided by Glance.
Glance should be deployed onto the Controller Node. There are a lot of options to configure Glance. The most important ones are explained below—for a complete reference refer to http://github.com/dellcloudedge/crowbar/wiki/Glance--barclamp.
Directory in which all images uploaded to Glance are stored. If you want to put the images onto a separate partition or volume, you need to mount this partition or volume on the Controller Node prior to deploying the Glance proposal (see Section 4.3.1, “ Providing a Volume or Separate Partition for the Glance Image Repository ”). Specify the mount point of the partition or volume here.
When sticking with the default value HTTP
, public
communication will not be encrypted. Choose HTTPS
to
use SSL for encryption and specify the path to the certificate
files. Note that you need to create and copy the certificate prior to
deploying Glance, see Section 4.3.3, “Enabling SSL” for
instructions.
Set these two options to true
to enable users to
upload images to Glance. If unset, only the operator will be able to
upload images.
Enable and configure image caching in this section. By default, image caching is disabled. Learn more about Glance's caching feature at http://docs.openstack.org/developer/glance/cache.html.
Nova provides key services for managing the SUSE Cloud, sets up the Compute Nodes, and provides a block storage service that either makes use of Ceph (if deployed) or uses local disks. There are a lot of options to configure Nova. The most important ones are explained below—for a complete reference refer to https://github.com/dellcloudedge/crowbar/wiki/Nova--barclamp. You will also find details about Nova's network modes on that page.
Choose between the
and hypervisors (other available options are currently not supported by SUSE). As of SUSE Cloud 1.0 choosing more than one hypervisor is not supported.In case you have not deployed Ceph, Nova Volume will use a single device on the contrnode; to provide block storage. Specify which device to use with this option. If Ceph has been deployed, it is used automatically and you will not be able to choose any disks here.
![]() | Nova Volume |
---|---|
Nova Volume only runs on the host onto which Section 2.3.1, “Cloud Storage Services” for more information. is deployed. Make sure the chosen device is equipped with enough disk space (a RAID is strongly recommended). See |
When sticking with the default value HTTP
, public
communication will not be encrypted. Choose HTTPS
to
use SSL for encryption and specify the path to the certificate
files. Note that you need to create and copy the certificate prior to
deploying Nova, see Section 4.3.3, “Enabling SSL”
for instructions.
After having started an instance you can display its VNC console in the
Nova Dashboard via browser using the noVNC
implementation. By default this connection is not encrypted and can
potentially be eavesdropped. To encrypt it, you can make use of SSL by
setting to true
. If
you do not specify any additional certificates, the same ones as for
Nova will be used.
The Nova service consists of two different roles:
Distributing and scheduling the instances is managed by the
. It also provides networking and messaging services. needs to be installed on the Controller Node.Provides the hypervisor (KVM or Xen) and tools needed to manage the instances. “workhorses” of the cloud—each instance is started on a Compute Node.
needs to be installed on every Compute Node. The Compute Nodes are theThe last service that needs to be deployed is the Nova Dashboard. It provides a Web interface for users to start and stop instances and for administrators to manage users, groups, roles, etc. Nova Dashboard should be installed on the Controller Node. The following attributes can be configured:
Must be set to
. This is the default.Name of the proposal for
and you deployed in the previous steps. The default value should be correct.Usually SSL certificates are checked for whether they have been signed by a trusted organization. Use this option to turn off checks. Useful in testing environments when using self-signed certificates. In production environments you should always use signed certificates and set this option to
(default).
When sticking with the default value true
, public communication will not be encrypted. Set
HTTPS
to true
to use SSL for
encryption and specify the path to the certificate files. Note that you
need to create and copy the certificate prior to deploying Nova
Dashboard, see Section 4.3.3, “Enabling SSL” for
instructions.
With a successful deployment of the Nova Dashboard, the SUSE Cloud installation is finished. In order to be able to test your setup by starting an instance one last step remains to be done—uploading an image to the Glance service. Refer to Section “Managing Images” (Chapter 2, Using OpenStack Command Line Interfaces, ↑User Guide for Administrators) for instructions. Images for SUSE Cloud can be built in SUSE Studio—see this blog post for details: http://blog.susestudio.com/2012/10/kvm-build-format-suse-cloud-support.html.
Now you can hand over to the cloud administrator to set up users, roles, flavors, etc.— refer to the User Guide for Administrators (↑User Guide for Administrators) for details.