OPENSTACKDOCSTHEME(1)

📦 version 3.6.0, in arch rolling

🌟 openstackdocstheme — the icon behind OPENSTACKDOCSTHEME(1) 🌟

💖 NAME, bestie 💖

openstackdocstheme — openstackdocstheme 3.6.0

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

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 at https://governance.openstack.org/reference/projects/index.html.

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 at https://docs.starlingx.io/governance/reference/projects/index.html.

🛠️ USING THE THEME 🛠️

Note: Before you use this theme, make sure your project can use the OpenStack brand by checking the brand guidelines at https://www.openstack.org/brand. No cap, this matters.
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. Lowkey convenient, highkey something to check.
  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 that’s done, you should add 'openstackdocstheme' to the list of extensions Sphinx needs to initialize and configure the theme:
extensions = [
    # ...
    'openstackdocstheme',
    # ...
]

html_theme = 'openstackdocs'
  1. Set the options to link to the git repository on https://opendev.org and bug tracker.
  • openstackdocs_repo_name — The prefix and repo name. For example, 'openstack/python-glanceclient'.
  • openstackdocs_use_storyboard — Set to True if using StoryBoard.
Note: If using StoryBoard, do not set bug_project and bug_tag options.
  • openstackdocs_bug_project — 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.
  • openstackdocs_bug_tag — 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
  1. Remove the options that will be automatically configured by the theme. They’re giving “I got this” energy:
  • project
  • html_last_updated_fmt
  1. 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
  1. (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.

  1. (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.

✨ ADDITIONAL CONFIGURATION ✨

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",
    # ...
}

The search bar in the sidebar is disabled by default. To enable it, set the sidebar_search option to True for project-scoped search:

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

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. That’s a hard no, bestie.

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. Respectfully, don’t do it.

🎀 DEMONSTRATION EXAMPLE 🎀

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]

🦋 Demo documentation 🦋

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.

🍓 Glossary 🍓

Here’s an example glossary:

  • Cactus — 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.
  • CADF — Cloud Auditing Data Federation (CADF) is a specification for audit event data. CADF is supported by OpenStack Identity.
  • CALL — One of the RPC primitives used by the OpenStack message queue software. Sends a message and waits for a response.

🧚 Literal Blocks 🧚

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

💜 Code Blocks 💜

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()

okay bestie, 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

🧾 Tables

Here's a sample table, and yes it's giving very organized main character energy:

OpenStack projects

┌─────────┬──────────────┬─────────────────────────┐
│ 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

Notices take these forms, and they are so useful for keeping docs from being chaos:

📝 note

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

🚨 important

Important: Something you must be aware of before proceeding.

💡 tip

Tip: An extra but helpful piece of practical advice.

⚠️ caution

Caution: Helpful information that prevents the user from making mistakes.

👀 seealso

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

🛑 warning

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

⏳ Configuration addition and deprecation notices

  • 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 (<# 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 import a key pair (<# 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.
  1. Click Add.

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

  1. To add an ICMP rule, click Add Rule.
  2. In the Add Rule dialog box, enter the following values:
┌───────────┬───────────┐
│ Rule      │ All ICMP  │
├───────────┼───────────┤
│ Direction │ Ingress   │
├───────────┼───────────┤
│ Remote    │ CIDR      │
├───────────┼───────────┤
│ CIDR      │ 0.0.0.0/0 │
└───────────┴───────────┘
  1. 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: ok so if ur on a Windows computer 🪟 and u wanna use the dashboard, u gotta grab PuTTYgen and use it to load the *.pem file, then convert + save it as *.ppk. For more info, peep the WinSCP web page for PuTTYgen at http://winscp.net/eng/docs/ui_puttygen 💅
  1. 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. slay, it's official now ✨

💖 Allocate a floating IP address to an instance

So when an instance gets created in OpenStack, it's automatically assigned a fixed IP address in the network it's assigned to. That IP is permanently associated with the instance until the instance is terminated — like, ride or die, no cap 😌

But bestie, in addition to the fixed IP address, a floating IP address can also be attached to an instance. And unlike fixed IP addresses, floating IP addresses can have their associations modified at any time, regardless of the state of the instances involved. iconic behaviour tbh 🦋 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 — it 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. bye bestie, back to the pool u go 👋

🌈 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. go off, customize ur little heart out 💅

🎀 Log in to the dashboard

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. (yes, u actually have to ask, no cap 🙈)
  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 at https://github.com/kanaka/noVNC/blob/master/README.md. For a list of supported browsers, see Browser support at https://github.com/kanaka/noVNC/wiki/Browser-support.
  1. 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. lowkey normal, don't panic 💀
  1. 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. main character energy fr 👑

🦋 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] 🖼️

⭐ Project tab

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

🌸 Compute tab

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 tab

Network Topology: View the network topology.

Networks: Create and manage public and private networks.

Routers: Create and manage subnets.

🍓 Object Store tab

Containers: Create and manage containers and objects.

🔥 Orchestration tab

Stacks: Use the REST API to orchestrate multiple composite cloud 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. admin girlies stay winning 💅

Figure: Admin tab [image] 🖼️

🌈 Admin tab

Access the following categories to complete these tasks:

🧚 System Panel tab

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. 📏

💖 Identity Panel tab

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 (see 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. no skipping that part bestie 😭
  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.
  1. Click Add.

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

  1. To add an ICMP rule, click Add Rule.
  2. In the Add Rule dialog box, enter these values (yes, exactly these, no improvising 💅):
    • Rule: All ICMP
    • Direction: Ingress
  3. Click Add.

Instances will now accept all incoming ICMP packets. That's it, that's the whole vibe check and they passed ✨

🔑 Add a key pair

Create at least one key pair for each project. Non-negotiable bestie, you need keys 🗝️

  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. Don't skip this, the download prompt is literally the whole point 🙈

📥 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: http://winscp.net/eng/docs/ui-puttygen.
  1. 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. Iconic behaviour honestly 👑

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. Like, ride or die, until death do us part 💀

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 — so they're the commitment-phobe of IPs, and that's a feature 🦋 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.

  1. 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. Setting it free, we love a clean breakup 🫶

🗄️ Create and manage databases

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. Basically: databases without the admin-induced crying 😭

🧚 Create a database instance

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. Do your homework first, bestie 📚

  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
  1. Restart Database services on the controller node:
# service trove-api restart
# service trove-taskmanager restart
# service trove-conductor restart
  1. 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. Let's goooo 🔥

  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.

  1. Click the Launch button. The new database instance appears in the databases list. Slay, it exists now ✨

💾 Backup and restore a database

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.

📦 To backup the database instance

  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.

  1. Click Backup. The new backup appears in the backup list. Screenshot-worthy moment, ngl 📸

♻️ To restore a database instance

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. Glow-up via backup, we love to see it 💖

  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. Double check it bestie, don't restore the wrong one 🙈
  6. Click Launch.

The new instance appears in the database instances list.

🕸️ Create and manage networks

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: https://docs.openstack.org/neutron/latest/admin/

🌈 Create a network

  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. So like... technically optional, but also a trap 💀

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.

  1. Click Create.

The dashboard shows the network on the Networks tab.

🛰️ Create a router

  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.

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

🔌 Connect a router

  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.

  1. Click Add Interface.

You have successfully created the router — you can view the new topology from the Network Topology tab. Slay. 💅

🚀 Launch an instance

🔐 To access your instance remotely

  1. Add rules to the default security group:

a. 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 |              |
+-------------+-----------+---------+-----------+--------------+

b. 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 |              |
+-------------+-----------+---------+-----------+--------------+
  1. 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

Author name not set

2015-2018, OpenStack Contributors

Catch u later, bestie 💖 — this was OPENSTACKDOCSTHEME(1), version 3.6.0, dated Apr 03, 2026. Periodt. 🌈

📦 where this page comes from