OPENSTACKDOCSTHEME(1) openstackdocstheme OPENSTACKDOCSTHEME(1)

openstackdocstheme - openstackdocstheme 3.3.0

openstackdocstheme is a Sphinx documentation extension that includes theme support for Open Infrastructure Foundation projects.

The openstackdocs theme is used for documentation that is published to docs.openstack.org and developer.openstack.org. It is intended for use by OpenStack projects governed by the Technical Committee.

The starlingxdocs theme is used for documentation that is published to docs.starlingx.io. It is intended for use by StarlingX projects governed by the Technical Steering Committee.

NOTE:

Prior to using this theme, ensure your project can use the OpenStack brand by referring to the brand guidelines at https://www.openstack.org/brand.

NOTE:

Some of the settings below are included in the file generated by Sphinx when you initialize a project, so they may already have values that need to be changed.
1.
Update the requirements list for your project to include openstackdocstheme (usually in test-requirements.txt).
2.
If your project previously used the oslosphinx theme (without modifying the header navigation), remove oslosphinx from your requirements list, and then in your conf.py you can remove the import statement and extension listing for oslosphinx.
3.
Once done, you should add 'openstackdocstheme' to the list of extensions Sphinx needs to initialize and configure the theme:
extensions = [
    # ...
    'openstackdocstheme',
    # ...
]
html_theme = 'openstackdocs'
4.
Set the options to link to the git repository on https://opendev.org and bug tracker.
The prefix and repo name. For example, 'openstack/python-glanceclient'.
Set to True if using StoryBoard.

NOTE:

If using StoryBoard, do not set bug_project and bug_tag options.
The project name or ID. For launchpad, it's a string like python-glanceclient. If unspecified, the "Report a bug" links are not shown. This option can be removed if using StoryBoard.
Launchpad bug tag. If unspecified, no tag is set. The default is empty. This option can be removed if using StoryBoard.

One example for a project using launchpad:

# openstackdocstheme options
openstackdocs_repo_name = 'openstack/python-glanceclient'
openstackdocs_bug_project = 'python-glanceclient'
openstackdocs_bug_tag = ''

One example for a project using StoryBoard:

# openstackdocstheme options
openstackdocs_repo_name = 'openstack/infra-manual'
openstackdocs_use_storyboard = true
5.
Remove the options that will be automatically configured by the theme.
  • project
  • html_last_updated_fmt
6.
Configure version-related options.

For everything except documentation in the api-guide, api-ref, and releasenotes paths, the theme will automatically set the version of your documentation. This behavior can be manually configured by setting the openstackdocs_auto_version option to either True or False.

If your documentation is auto-versioned, you should remove the options related to versioning as they will be overridden.

  • version
  • release
7.
(Optional) Manually configure the project name.

The theme will automatically set the project name used in your documentation. You can disable this behavior by setting the openstackdocs_auto_name option to false and configuring the project option to the name you wish to use.

8.
(Optional) Link to the PDF file.

If you build a PDF file as well, the theme can create a link to it. Set openstack_pdf_link to True to generate the link. The file is expected to be named doc-<shortname>.pdf and placed in the top-level directory where <shortname> is the openstackdocs_repo_name. For example with:

openstackdocs_repo_name = "openstack/python-glanceclient"

the shortname is python-glanceclient and the filename will be doc-python-glanceclient.pdf. Use the variable openstackdocs_pdf_filename to override the generated file name.

Changed in version 2.2.0: The config options openstack_pdf_link and openstackdocs_pdf_filename were introduced.

Changed in version 2.1.0: The repository_name, bug_project, bug_tag and use_storyboard config options were renamed to openstackdocs_repo_name, openstackdocs_bug_project, openstackdocs_bug_tag and openstackdocs_use_storyboard, respectively. Aliases are provided but these will be removed in a future release.

Changed in version 2.1.0: The openstackdocs_auto_version and openstackdocs_auto_name config options were added.

Changed in version 1.20: In older versions of openstackdocstheme, it was necessary to manually configure the html_last_updated_fmt option for HTML output and the latex_engine and latex_elements options if you required PDF output. This is no longer the case as these attributes are now configured automatically.

If you are using this theme for API reference documentation, set the sidebar navigation in the html_theme_options in the conf.py file:

# To use the API Reference sidebar dropdown menu,
# uncomment the html_theme_options parameter.  The theme
# variable, sidebar_dropdown, should be set to `api_ref`.
# Otherwise, the list of links for the User and Ops docs
# appear in the sidebar dropdown menu.
html_theme_options = {
    # ...
    "sidebar_dropdown": "api_ref",
    "sidebar_mode": "toc",
    # ...
}

If you are using this theme for documentation you want to release based on git tags on your repository, set the release dropdown menu option in the html_theme_options in the conf.py file. By default it is set to False:

html_theme_options = {
    # ...
    "show_other_versions": "True",
    # ...
}

If you are using this theme for a project with published documentation that predates the Mitaka release cycle, set the earliest published version in the html_theme_options in the conf.py file to the name of the first series with documentation available. By default it is set to None:

html_theme_options = {
    # ...
    "earliest_published_series": "grizzly",
    # ...
}

WARNING:

Do not use this for release-notes as they are always published as one document with internal versioning.

A badge pointing out the support status of a document is shown now for repositories that have stable/ branches. The badge is not displayed for api-ref, api-guide and releasenotes documents. It can be disabled with the display_badge html theme option:

    html_theme_options = {
    # ...
    "display_badge": False,
    # ...
}

The TOC on the left contains a global section (to navigate between pages) and a local section (showing page contents). If the TOC is displayed in the text, you might want to disable the global section of the TOC:

html_theme_options = {
    # ...
    "display_global_toc_section": False,
    # ...
}

If you are using this theme for something other than docs.openstack.org, you can customize the root title ("OpenStack Docs") that appears in the page title and the left arrow tooltip:

html_theme_options = {
    # ...
    "root_title": "OpenStack Governance",
    # ...
}

The configuration option openstack_projects can be used to define custom roles that build links that update automatically when branches are created for each release series. Builds on the master branch link to the latest documentation.

In the conf.py for the source documentation, add:

openstack_projects = ['horizon']

Then in the documentation source, link to a target using syntax like:

:horizon-doc:`Launching Instances with Horizon <user/launch-instances.html>`

NOTE:

Do not use this feature to reference projects that have a different branching policy, for example, only have a master branch.

The demo documentation provides example output to ensure it matches what's expected. The link below points to the example output when using the theme for all documentation that is not API reference.

[image: Documentation Logo] [image]

The demo documentation provides example markup for looking at the expected output.

This is a sidebar which may be used to provide related or reference material. It is displayed in proximity to, but outside the main text.

The project aims for simple implementation, massive scalability, and a rich set of features. Cloud computing experts from around the world contribute to the project.

Here's an example glossary:

An OpenStack grouped release of projects that came out in the spring of 2011. It included Compute (nova), Object Storage (swift), and the Image service (glance). Cactus is a city in Texas, US and is the code name for the third release of OpenStack. When OpenStack releases went from three to six months long, the code name of the release changed to match a geography nearest the previous summit.
Cloud Auditing Data Federation (CADF) is a specification for audit event data. CADF is supported by OpenStack Identity.
One of the RPC primitives used by the OpenStack message queue software. Sends a message and waits for a response.

Here's an example configuration:

[DEFAULT]
...
my_ip = 10.0.0.31
vnc_enabled = True
vncserver_listen = 0.0.0.0
vncserver_proxyclient_address = 10.0.0.31
novncproxy_base_url = http://controller:6080/vnc_auto.html

Here's another example that's python code:

def builder_inited(app):
    theme_dir = os.path.join(os.path.dirname(__file__), 'theme')
    LOG.info('Using openstack theme from %s' % theme_dir)
    # Insert our theme directory at the front of the search path and
    # force the theme setting to use the one in the package. This is
    # done here, instead of in setup(), because conf.py is read after
    # setup() runs, so if the conf contains these values the user
    # values overwrite these. That's not bad for the theme, but it
    # breaks the search path.
    app.config.html_theme_path.insert(0, theme_dir)
    # Set the theme name
    app.config.html_theme = 'openstack'
    # Re-initialize the builder, if it has the method for setting up
    # the templates and theme.
    if hasattr(app.builder, 'init_templates'):
        app.builder.init_templates()

Here's the same example but with ..code-block: ini to test the pygments lexer:

[DEFAULT]
...
my_ip = 10.0.0.31
vnc_enabled = True
vncserver_listen = 0.0.0.0
vncserver_proxyclient_address = 10.0.0.31
novncproxy_base_url = http://controller:6080/vnc_auto.html

Here's a sample table:

Name Role Description
Nova Compute To implement services and associated libraries to provide massively scalable, on demand, self service access to compute resources, including bare metal, virtual machines, and containers.
Neutron Networking OpenStack Neutron is an SDN networking project focused on delivering networking-as-a-service (NaaS) in virtual compute environments.
Swift Object store Swift is a highly available, distributed, eventually consistent object/blob store. Organizations can use Swift to store lots of data efficiently, safely, and cheaply. It's built for scale and optimized for durability, availability, and concurrency across the entire data set. Swift is ideal for storing unstructured data that can grow without bound.
... ... ...

Notices take these forms.

NOTE:

A comment with additional information that explains a part of the text.

IMPORTANT:

Something you must be aware of before proceeding.

TIP:

An extra but helpful piece of practical advice.

CAUTION:

Helpful information that prevents the user from making mistakes.

SEE ALSO:

A reference to another piece of related information, like a related setting or upstream documentation

WARNING:

Critical information about the risk of data loss or security issues.

Added in version 9.0.0-Mitaka.

Added in version 10.0.0-Newton.

Changed in version 10.0.0-Newton: Added support for new tags!

Changed in version 11.0.0-Ocata: Showing that multiple notices work!

Deprecated since version 11.0.0-Ocata: Use Notices instead.

Deprecated since version 12.0.0-Pike: A second deprecation notice

Configure access and security for instances

Before you launch an instance, you should add security group rules to enable users to ping and use SSH to connect to the instance. Security groups are sets of IP filter rules that define networking access and are applied to all instances within a project. To do so, you either add rules to the default security group or add a new security group with rules.

Key pairs are SSH credentials that are injected into an instance when it is launched. To use key pair injection, the image that the instance is based on must contain the cloud-init package. Each project should have at least one key pair. For more information, see import a key pair.

If you have generated a key pair with an external tool, you can import it into OpenStack. The key pair can be used for multiple instances that belong to a project. For more information, see ? (TODO!).

When an instance is created in OpenStack, it is automatically assigned a fixed IP address in the network to which the instance is assigned. This IP address is permanently associated with the instance until the instance is terminated. However, in addition to the fixed IP address, a floating IP address can also be attached to an instance. Unlike fixed IP addresses, floating IP addresses are able to have their associations modified at any time, regardless of the state of the instances involved.

Add a rule to the default security group

This procedure enables SSH and ICMP (ping) access to instances. The rules apply to all instances within a given project, and should be set for every project unless there is a reason to prohibit SSH or ICMP access to the instances.

This procedure can be adjusted as necessary to add additional security group rules to a project, if your cloud requires them.

NOTE:

When adding a rule, you must specify the protocol used with the destination port or source port.
1.
Log in to the dashboard, choose a project, and click Access & Security. The Security Groups tab shows the security groups that are available for this project.
2.
Select the default security group and click Edit Rules.
3.
To allow SSH access, click Add Rule.
4.
In the Add Rule dialog box, enter the following values:
Rule SSH
Remote CIDR
CIDR 0.0.0.0/0

NOTE:

To accept requests from a particular range of IP addresses, specify the IP address block in the CIDR box.
5.
Click Add.

Instances will now have SSH port 22 open for requests from any IP address.

6.
To add an ICMP rule, click Add Rule.
7.
In the Add Rule dialog box, enter the following values:
Rule All ICMP
Direction Ingress
Remote CIDR
CIDR 0.0.0.0/0
8.
Click Add.

Instances will now accept all incoming ICMP packets.

Add a key pair

Create at least one key pair for each project.

1.
Log in to the dashboard, choose a project, and click Access & Security.
2.
Click the Keypairs tab, which shows the key pairs that are available for this project.
3.
Click Create Keypair.
4.
In the Create Keypair dialog box, enter a name for your key pair, and click Create Keypair.
5.
Respond to the prompt to download the key pair.

Import a key pair

1.
Log in to the dashboard, choose a project, and click Access & Security.
2.
Click the Keypairs tab, which shows the key pairs that are available for this project.
3.
Click Import Keypair.
4.
In the Import Keypair dialog box, enter the name of your key pair, copy the public key into the Public Key box, and then click Import Keypair.
5.
Save the *.pem file locally.
6.
To change its permissions so that only you can read and write to the file, run the following command:
$ chmod 0600 yourPrivateKey.pem

NOTE:

If you are using the dashboard from a Windows computer, use PuTTYgen to load the *.pem file and convert and save it as *.ppk. For more information see the WinSCP web page for PuTTYgen.
7.
To make the key pair known to SSH, run the ssh-add command:
$ ssh-add yourPrivateKey.pem

The Compute database registers the public key of the key pair.

The dashboard lists the key pair on the Access & Security tab.

Allocate a floating IP address to an instance

When an instance is created in OpenStack, it is automatically assigned a fixed IP address in the network to which the instance is assigned. This IP address is permanently associated with the instance until the instance is terminated.

However, in addition to the fixed IP address, a floating IP address can also be attached to an instance. Unlike fixed IP addresses, floating IP addresses can have their associations modified at any time, regardless of the state of the instances involved. This procedure details the reservation of a floating IP address from an existing pool of addresses and the association of that address with a specific instance.

1.
Log in to the dashboard, choose a project, and click Access & Security.
2.
Click the Floating IPs tab, which shows the floating IP addresses allocated to instances.
3.
Click Allocate IP to Project.
4.
Choose the pool from which to pick the IP address.
5.
Click Allocate IP.
6.
In the Floating IPs list, click Associate.
7.
In the Manage Floating IP Associations dialog box, choose the following options:
  • The IP Address field is filled automatically, but you can add a new IP address by clicking the + button.
  • In the Ports to be associated field, select a port from the list. The list shows all the instances with their fixed IP addresses.
8.
Click Associate.

NOTE:

To disassociate an IP address from an instance, click the Disassociate button.

To release the floating IP address back into the pool of addresses, click the More button and select the Release Floating IP option.

OpenStack dashboard

As a cloud end user, you can use the OpenStack dashboard to provision your own resources within the limits set by administrators. You can modify the examples provided in this section to create other types and sizes of server instances.

The dashboard is available on the node with the nova-dashboard server role.

1.
Ask the cloud operator for the host name or public IP address from which you can access the dashboard, and for your user name and password.
2.
Open a web browser that has JavaScript and cookies enabled.

NOTE:

To use the Virtual Network Computing (VNC) client for the dashboard, your browser must support HTML5 Canvas and HTML5 WebSockets. The VNC client is based on noVNC. For details, see noVNC: HTML5 VNC Client. For a list of supported browsers, see Browser support.
3.
In the address bar, enter the host name or IP address for the dashboard.
https://ipAddressOrHostName/

NOTE:

If a certificate warning appears when you try to access the URL for the first time, a self-signed certificate is in use, which is not considered trustworthy by default. Verify the certificate or add an exception in the browser to bypass the warning.
4.
On the Log In page, enter your user name and password, and click Sign In.

The top of the window displays your user name. You can also access Settings or sign out of the dashboard.

The visible tabs and functions in the dashboard depend on the access permissions, or roles, of the user you are logged in as.

  • If you are logged in as an end user, the Project tab is displayed.
  • If you are logged in as an administrator, the Project tab (OpenStack dashboard—Project tab) and Admin tab (OpenStack dashboard—Admin tab) are displayed.

OpenStack dashboard—Project tab

Projects are organizational units in the cloud, and are also known as tenants or accounts. Each user is a member of one or more projects. Within a project, a user creates and manages instances.

From the Project tab, you can view and manage the resources in a selected project, including instances and images. You select the project from the CURRENT PROJECT list at the top of the tab.

Figure: Project tab [image]

From the Project tab, you can access the following tabs:

Overview: View reports for the project.

Instances: View, launch, create a snapshot from, stop, pause, or reboot instances, or connect to them through VNC.

Volumes: Use the following tabs to complete these tasks:

  • Volumes: View, create, edit, and delete volumes.
  • Volume Snapshots: View, create, edit, and delete volume snapshots.
  • Images: View images and instance snapshots created by project users, plus any images that are publicly available. Create, edit, and delete images, and launch instances from images and snapshots.

Access & Security: Use the following tabs to complete these tasks:

  • Security Groups: View, create, edit, and delete security groups and security group rules.
  • Key Pairs: View, create, edit, import, and delete key pairs.
  • Floating IPs: Allocate an IP address to or release it from a project.
  • API Access: View API endpoints.

Network Topology: View the network topology.

Networks: Create and manage public and private networks.

Routers: Create and manage subnets.

Containers: Create and manage containers and objects.

applications.

OpenStack dashboard—Admin tab

Administrative users can use the Admin tab to view usage and to manage instances, volumes, flavors, images, projects, users, services, and quotas.

Figure: Admin tab [image]

Access the following categories to complete these tasks:

Overview: View basic reports.

Resource Usage: Use the following tabs to view the following usages:

Daily Report: View the daily report.

Stats: View the statistics of all resources.

Hypervisors: View the hypervisor summary.

Host Aggregates: View, create, and edit host aggregates. View the list of availability zones.

Instances: View, pause, resume, suspend, migrate, soft or hard reboot, and delete running instances that belong to users of some, but not all, projects. Also, view the log for an instance or access an instance through VNC.

Volumes: View, create, edit, and delete volumes and volume types.

Flavors: View, create, edit, view extra specifications for, and delete flavors. A flavor is size of an instance.

Images: View, create, edit properties for, and delete custom images.

Networks: View, create, edit properties for, and delete networks.

Routers: View, create, edit properties for, and delete routers.

System Info: Use the following tabs to view the service information:

  • Services: View a list of the services.
  • Compute Services: View a list of all Compute services.

Network Agents: View the network agents.

Default Quotas: View default quota values. Quotas are hard-coded in OpenStack Compute and define the maximum allowable size and number of resources.

Projects: View, create, assign users to, remove users from, and delete projects.

Users: View, create, enable, disable, and delete users.

Configure access and security for instances

Before you launch an instance, you should add security group rules to enable users to ping and use SSH to connect to the instance. Security groups are sets of IP filter rules that define networking access and are applied to all instances within a project. To do so, you either add rules to the default security group Add a rule to the default security group or add a new security group with rules.

Key pairs are SSH credentials that are injected into an instance when it is launched. To use key pair injection, the image that the instance is based on must contain the cloud-init package. Each project should have at least one key pair. For more information, see the section Add a key pair.

If you have generated a key pair with an external tool, you can import it into OpenStack. The key pair can be used for multiple instances that belong to a project. For more information, see the section Import a key pair.

When an instance is created in OpenStack, it is automatically assigned a fixed IP address in the network to which the instance is assigned. This IP address is permanently associated with the instance until the instance is terminated. However, in addition to the fixed IP address, a floating IP address can also be attached to an instance. Unlike fixed IP addresses, floating IP addresses are able to have their associations modified at any time, regardless of the state of the instances involved.

Add a rule to the default security group

This procedure enables SSH and ICMP (ping) access to instances. The rules apply to all instances within a given project, and should be set for every project unless there is a reason to prohibit SSH or ICMP access to the instances.

This procedure can be adjusted as necessary to add additional security group rules to a project, if your cloud requires them.

NOTE:

When adding a rule, you must specify the protocol used with the destination port or source port.
1.
Log in to the dashboard, choose a project, and click Access & Security. The Security Groups tab shows the security groups that are available for this project.
2.
Select the default security group and click Edit Rules.
3.
To allow SSH access, click Add Rule.
4.
In the Add Rule dialog box, enter the following values:
Rule Remote
SSH CIDR

NOTE:

To accept requests from a particular range of IP addresses, specify the IP address block in the CIDR box.
5.
Click Add.

Instances will now have SSH port 22 open for requests from any IP address.

6.
To add an ICMP rule, click Add Rule.
7.
In the Add Rule dialog box, enter the following values:
Rule Direction
All ICMP Ingress
8.
Click Add.

Instances will now accept all incoming ICMP packets.

Add a key pair

Create at least one key pair for each project.

1.
Log in to the dashboard, choose a project, and click Access & Security.
2.
Click the Keypairs tab, which shows the key pairs that are available for this project.
3.
Click Create Keypair.
4.
In the Create Keypair dialog box, enter a name for your key pair, and click Create Keypair.
5.
Respond to the prompt to download the key pair.

Import a key pair

1.
Log in to the dashboard, choose a project, and click Access & Security.
2.
Click the Keypairs tab, which shows the key pairs that are available for this project.
3.
Click Import Keypair.
4.
In the Import Keypair dialog box, enter the name of your key pair, copy the public key into the Public Key box, and then click Import Keypair.
5.
Save the *.pem file locally.
6.
To change its permissions so that only you can read and write to the file, run the following command:
$ chmod 0600 yourPrivateKey.pem

NOTE:

If you are using the dashboard from a Windows computer, use PuTTYgen to load the *.pem file and convert and save it as *.ppk. For more information see the WinSCP web page for PuTTYgen.
7.
To make the key pair known to SSH, run the ssh-add command.
$ ssh-add yourPrivateKey.pem

The Compute database registers the public key of the key pair.

The dashboard lists the key pair on the Access & Security tab.

Allocate a floating IP address to an instance

When an instance is created in OpenStack, it is automatically assigned a fixed IP address in the network to which the instance is assigned. This IP address is permanently associated with the instance until the instance is terminated.

However, in addition to the fixed IP address, a floating IP address can also be attached to an instance. Unlike fixed IP addresses, floating IP addresses can have their associations modified at any time, regardless of the state of the instances involved. This procedure details the reservation of a floating IP address from an existing pool of addresses and the association of that address with a specific instance.

1.
Log in to the dashboard, choose a project, and click Access & Security.
2.
Click the Floating IPs tab, which shows the floating IP addresses allocated to instances.
3.
Click Allocate IP to Project.
4.
Choose the pool from which to pick the IP address.
5.
Click Allocate IP.
6.
In the Floating IPs list, click Associate.
7.
In the Manage Floating IP Associations dialog box, choose the following options:
1.
The IP Address field is filled automatically, but you can add a new IP address by clicking the + button.
2.
In the Ports to be associated field, select a port from the list.

The list shows all the instances with their fixed IP addresses.

8.
Click Associate.

NOTE:

To disassociate an IP address from an instance, click the Disassociate button.

To release the floating IP address back into the pool of addresses, click the More button and select the Release Floating IP option.

The Database service provides scalable and reliable cloud provisioning functionality for both relational and non-relational database engines. Users can quickly and easily use database features without the burden of handling complex administrative tasks.

Prerequisites. Before you create a database instance, you need to configure a default datastore and make sure you have an appropriate flavor for the type of database instance you want.

1.
Configure a default datastore.

Because the dashboard does not let you choose a specific datastore to use with an instance, you need to configure a default datastore. The dashboard then uses the default datastore to create the instance.

1.
Add the following line to /etc/trove/trove.conf:
default_datastore = DATASTORE_NAME

Replace ``DATASTORE_NAME`` with the name that the administrative user set when issuing the trove-manage command to create the datastore. You can use the trove datastore-list command to display the datastores that are available in your environment.

For example, if your MySQL datastore name is set to mysql, your entry would look like this:

default_datastore = mysql
2.
Restart Database services on the controller node:
# service trove-api restart
# service trove-taskmanager restart
# service trove-conductor restart
2.
Verify flavor.

Make sure an appropriate flavor exists for the type of database instance you want.

Create database instance. Once you have configured a default datastore and verified that you have an appropriate flavor, you can create a database instance.

1.
Log in to the dashboard, choose a project, and click Databases.
2.
Click Database Instances. This lists the instances that already exist in your environment.
3.
Click Launch Instance.
4.
In the Launch Database dialog box, specify the following values.

Details

Database Name: Specify a name for the database instance.

Flavor: Select an appropriate flavor for the instance.

Volume Size: Select a volume size. Volume size is expressed in GB.

Initialize Databases: Initial Database

Optionally provide a comma separated list of databases to create, for example:

database1, database2, database3

Initial Admin User: Create an initial admin user. This user will have access to all the databases you create.

Password: Specify a password associated with the initial admin user you just named.

Host: Optionally, allow the user to connect only from this host. If you do not specify a host, this user will be allowed to connect from anywhere.

5.
Click the Launch button. The new database instance appears in the databases list.

You can use Database services to backup a database and store the backup artifact in the Object Storage module. Later on, if the original database is damaged, you can use the backup artifact to restore the database. The restore process creates a database instance.

This example shows you how to back up and restore a MySQL database.

1.
Log in to the dashboard, choose a project, and click Databases.
2.
Click Database Instances. This displays the existing instances in your system.
3.
Click Create Backup.
4.
In the Backup Database dialog box, specify the following values:

Name

Specify a name for the backup.

Database Instance

Select the instance you want to back up.

5.
Click Backup. The new backup appears in the backup list.

Now assume that your original database instance is damaged and you need to restore it. You do the restore by using your backup to create a new database instance.

1.
Log in to the dashboard, choose a project, and click Databases.
2.
Click Database Backups. This lists the available backups.
3.
Check the backup you want to use and click Restore Backup.
4.
In the Launch Database dialog box, specify the values you want for the new database instance.
5.
Click the Restore From Database tab and make sure that this new instance is based on the correct backup.
6.
Click Launch.

The new instance appears in the database instances list.

The OpenStack Networking service provides a scalable system for managing the network connectivity within an OpenStack cloud deployment. It can easily and quickly react to changing network needs (for example, creating and assigning new IP addresses).

Networking in OpenStack is complex. This section provides the basic instructions for creating a network and a router. For detailed information about managing networks, refer to the OpenStack Administrator Guide.

1.
Log in to the dashboard, choose a project, and click Networks.
2.
Click Create Network.
3.
In the Create Network dialog box, specify the following values.

Network tab

Network Name: Specify a name to identify the network.

Subnet tab

Create Subnet: Select this check box to create a subnet

You do not have to specify a subnet when you create a network, but if you do not specify a subnet, any attached instance receives an Error status.

Subnet Name: Specify a name for the subnet.

Network Address: Specify the IP address for the subnet.

IP Version: Select IPv4 or IPv6.

Gateway IP: Specify an IP address for a specific gateway. This parameter is optional.

Disable Gateway: Select this check box to disable a gateway IP address.

Subnet Detail tab

Enable DHCP: Select this check box to enable DHCP.

Allocation Pools Specify IP address pools.

DNS Name Servers: Specify a name for the DNS server.

Host Routes: Specify the IP address of host routes.

4.
Click Create.

The dashboard shows the network on the Networks tab.

1.
Log in to the dashboard, choose a project, and click Routers.
2.
Click Create Router.
3.
In the Create Router dialog box, specify a name for the router and click Create Router.

The new router is now displayed in the Routers tab.

4.
Click the new router's Set Gateway button.
5.
In the External Network field, specify the network to which the router will connect, and then click Set Gateway.

1.
To connect a private network to the newly created router, on the Routers tab, click the name of the router.
2.
On the Router Details page, click Add Interface.
3.
In the Add Interface dialog box, select a Subnet.
4.
Optionally, in the Add Interface dialog box, set an IP Address for the router interface for the selected subnet.

If you choose not to set the IP Address value, then by default OpenStack Networking uses the first host IP address in the subnet.

The Router Name and Router ID fields are automatically updated.

5.
Click Add Interface.

You have successfully created the router. You can view the new topology from the Network Topology tab.

1.
Add rules to the default security group:
Permit ICMP (ping):
$ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range  | Source Group |
+-------------+-----------+---------+-----------+--------------+
| icmp        | -1        | -1      | 0.0.0.0/0 |              |
+-------------+-----------+---------+-----------+--------------+
Permit secure shell (SSH) access:
$ nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range  | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp         | 22        | 22      | 0.0.0.0/0 |              |
+-------------+-----------+---------+-----------+--------------+
2.
Create a floating IP address on the ext-net external network:
$ neutron floatingip-create ext-net
Created a new floatingip:
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| fixed_ip_address    |                                      |
| floating_ip_address | 203.0.113.102                        |
| floating_network_id | 9bce64a3-a963-4c05-bfcd-161f708042d1 |
| id                  | 05e36754-e7f3-46bb-9eaa-3521623b3722 |
| port_id             |                                      |
| router_id           |                                      |
| status              | DOWN                                 |
| tenant_id           | 7cf50047f8df4824bc76c2fdf66d11ec     |
+---------------------+--------------------------------------+

Testing ordered lists and auto-numbering

1.
Item 1
1.
Item 1, Item 1
2.
Item 2, Item 1
2.
Item 2
1.
Item 2, Item 1
2.
Item 2, Item 2
1.
Item 2, Item 2, Item 1
2.
Item 2, Item 2, Item 2

Testing ordered lists and auto-numbering w/ note directive

NOTE:

1.
Item 1
1.
Item 1, nested under 1

NOTE:

1.
Item 1, nested in note under Item 1
2.
Item 2, nested in note under Item 1
2.
Item 2, nested under 1
2.
Item 2
•
Search Page

Author name not set

2015-2018, OpenStack Contributors

November 29, 2024 3.3.0