SUSE OpenStack Cloud 7

Supplement to Administrator Guide and End User Guide

Authors: Frank Sundermeyer and Tanja Roth
Publication Date: August 04, 2017

Copyright © 2006– 2017 SUSE LLC and contributors. All rights reserved.

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License :

For SUSE trademarks, see http://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof.

About This Guide

SUSE® OpenStack Cloud is an open source software solution that provides the fundamental capabilities to deploy and manage a cloud infrastructure based on SUSE Linux Enterprise. SUSE OpenStack Cloud is powered by OpenStack, the leading community-driven, open source cloud infrastructure project. It seamlessly manages and provisions workloads across a heterogeneous cloud environment in a secure, compliant, and fully-supported manner. The product tightly integrates with other SUSE technologies and with the SUSE maintenance and support infrastructure.

This guide is a supplement to the SUSE OpenStack Cloud Administrator Guide and SUSE OpenStack Cloud End User Guide. It contains additional information for admins and end users that is specific to SUSE OpenStack Cloud.

Many chapters in this manual contain links to additional documentation resources. These include additional documentation that is available on the system and documentation available on the Internet.

For an overview of the documentation available for your product and the latest documentation updates, refer to http://www.suse.com/documentation.

1 Available Documentation

Note
Note: Online Documentation and Latest Updates

Documentation for our products is available at http://www.suse.com/documentation/, where you can also find the latest updates, and browse or download the documentation in various formats.

In addition, the product documentation is usually available in your installed system under /usr/share/doc/manual. You can also access the product-specific manuals and the upstream documentation from the Help links in the graphical Web interfaces.

The following documentation is available for this product:

Deployment Guide

Gives an introduction to the SUSE® OpenStack Cloud architecture, lists the requirements, and describes how to set up, deploy, and maintain the individual components. Also contains information about troubleshooting, support, and a glossary listing the most important terms and concepts for SUSE OpenStack Cloud.

Administrator Guide

Introduces the OpenStack services and their components.

Also guides you through tasks like managing images, roles, instances, flavors, volumes, shares, quotas, host aggregates, and viewing cloud resources. To complete these tasks, use either the graphical Web interface (OpenStack Dashboard, code name Horizon) or the OpenStack command line clients.

End User Guide

Describes how to manage images, instances, networks, object containers, volumes, shares, stacks, and databases. To complete these tasks, use either the graphical Web interface (OpenStack Dashboard, code name Horizon) or the OpenStack command line clients.

Supplement to Administrator Guide and End User Guide

A supplement to the SUSE OpenStack Cloud Administrator Guide and SUSE OpenStack Cloud End User Guide. It contains additional information for admins and end users that is specific to SUSE OpenStack Cloud.

Overview

A manual introducing SUSE OpenStack Cloud Monitoring. It is written for everybody interested in SUSE OpenStack Cloud Monitoring.

OpenStack Operator's Guide

A manual for SUSE OpenStack Cloud operators describing how to prepare their OpenStack platform for SUSE OpenStack Cloud Monitoring. The manual also describes how the operators use SUSE OpenStack Cloud Monitoring for monitoring their OpenStack services.

OpenStack Operator's Guide

A manual for system operators describing how to operate SUSE OpenStack Cloud Monitoring in single mode. The manual also describes how the operators use SUSE OpenStack Cloud Monitoring for monitoring their environment.

2 Feedback

Several feedback channels are available:

Bugs and Enhancement Requests

To report bugs for a product component, or to submit enhancement requests, use https://bugzilla.suse.com/. For documentation bugs, submit a bug report for the component Documentation of the respective product.

If you are new to Bugzilla, you might find the following articles helpful:

Services and Support Options

For services and support options available for your product, refer to http://www.suse.com/support/.

User Comments/Bug Reports

We want to hear your comments about and suggestions for this manual and the other documentation included with this product. If you are reading the HTML version of this guide, use the Comments feature at the bottom of each page in the online documentation at http://www.suse.com/documentation/.

If you are reading the single-page HTML version of this guide, you can use the Report Bug link next to each section to open a bug report at https://bugzilla.suse.com/. A user account is needed for this.

Mail

For feedback on the documentation of this product, you can also send a mail to doc-team@suse.com. Make sure to include the document title, the product version, and the publication date of the documentation. To report errors or suggest enhancements, provide a concise description of the problem and refer to the respective section number and page (or URL).

3 Documentation Conventions

The following notices and typographical conventions are used in this documentation:

  • Warning
    Warning

    Vital information you must be aware of before proceeding. Warns you about security issues, potential loss of data, damage to hardware, or physical hazards.

    Important
    Important

    Important information you should be aware of before proceeding.

    Note
    Note

    Additional information, for example about differences in software versions.

    Tip
    Tip

    Helpful information, like a guideline or a piece of practical advice.

  • tux > command

    Commands that can be run by any user, including the root user.

  • root # command

    Commands that must be run with root privileges. Often you can also prefix these commands with the sudo command to run them.

  • /etc/passwd: directory names and file names

  • PLACEHOLDER: replace PLACEHOLDER with the actual value

  • PATH: the environment variable PATH

  • ls, --help: commands, options, and parameters

  • user: users or groups

  • Alt, AltF1: a key to press or a key combination; keys are shown in uppercase as on a keyboard

  • File, File › Save As: menu items, buttons

  • x86_64 This paragraph is only relevant for the AMD64/Intel 64 architecture. The arrows mark the beginning and the end of the text block.

    System z, POWER This paragraph is only relevant for the architectures z Systems and POWER. The arrows mark the beginning and the end of the text block.

  • Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a chapter in another manual.

4 About the Making of This Manual

This documentation is written in SUSEDoc, a subset of DocBook 5. The XML source files were validated by jing, processed by xsltproc, and converted into XSL-FO using a customized version of Norman Walsh's stylesheets. The final PDF is formatted through FOP from Apache Software Foundation. The open source tools and the environment used to build this documentation are provided by the DocBook Authoring and Publishing Suite (DAPS). The project's home page can be found at https://github.com/openSUSE/daps.

The XML source code of this documentation can be found at https://github.com/SUSE-Cloud/doc-cloud.

1 Changing the SUSE OpenStack Cloud Dashboard Theme

The SUSE OpenStack Cloud Dashboard theme can now be customized. The default SUSE OpenStack Cloud theme is available in the openstack-dashboard-theme-SUSE package. If you want to replace it with a custom theme, you can explore the package contents as an example. When using a custom theme, make sure the resulting package name starts with openstack-dashboard-theme-. Apart from that, go to the Horizon barclamp in Crowbar, switch to the Raw view and adjust the site_theme attribute accordingly. For details about the barclamps in Crowbar, see the Deployment Guide.

2 Managing Images

In the SUSE OpenStack Cloud context, images are virtual disk images that represent the contents and structure of a storage medium or device, such as a hard disk, in a single file. Images are used as a template from which a virtual machine can be started. For starting a virtual machine, SUSE OpenStack Cloud always uses a copy of the image.

Images have both content and metadata. The latter are also called image properties.

Permissions to manage images are defined by the cloud operator during setup of SUSE OpenStack Cloud. Image upload and management may be restricted to cloud administrators or cloud operators only.

Managing images for SUSE OpenStack Cloud requires the following basic steps:

  1. Building Images with SUSE Studio.

    For general and hypervisor-specific requirements, refer to Section 2.1, “Image Requirements”.

  2. Uploading Disk Images to SUSE OpenStack Cloud.

    Images can either be uploaded to SUSE OpenStack Cloud with the unified python-openstackclient from command line or with the SUSE OpenStack Cloud Dashboard. As the Dashboard has some limitations regarding image upload and modification of properties, it is recommended to use the unified python-openstackclient for comprehensive image management.

  3. Specifying Image Properties. You can do so during image upload (using openstack image create) or with openstack image set after the image has already been uploaded. Refer to Procedure 2.2, “Uploading Disk Images to SUSE OpenStack Cloud” and Procedure 2.3, “Modifying Image Properties”.

    Important
    Important: Properties for Architecture, Hypervisor and VM Mode

    OpenStack Image does not check nor automatically detect any image properties. Therefore you need to specify the image's properties manually.

    This is especially important when using mixed virtualization environments to make sure that an image is only launched on appropriate hypervisors. The properties can specify a certain architecture, hypervisor type, or application binary interface (ABI) that the image requires.

2.1 Image Requirements

To build the images to use within the cloud, use SUSE Studio or SUSE Studio Onsite as they provide automatic insertion of management scripts and agents. Make sure any images that you build for SUSE OpenStack Cloud fulfill the following requirements.

2.1.1 General Image Requirements

  • The network is set to DHCP.

  • The image does not include YaST2 Firstboot.

  • The image does not include any end-user license agreement (EULA) dialogs.

  • The image contains the cloud-init package. The package will be automatically added to the image if the following check box in SUSE Studio or SUSE Studio Onsite is enabled: Integrate with SUSE OpenStack Cloud/OpenStack.

    The cloud-init package contains tools used for communication with the instance metadata API, which is provided by Compute. The metadata API is only accessible from inside the VM. The package is needed to pull keypairs into the virtual machine that will run the image.

If you intend to manage the image by the Orchestration module, you also need to include the following package: openstack-heat-cfntools (part of the SUSE OpenStack Cloud ISO).

2.1.2 Image Requirements Depending on Hypervisor

For a list of supported VM guests, refer to the SUSE® Linux Enterprise Server Virtualization Guide, section Supported VM Guests. It is available at https://www.suse.com/documentation/sles-12/book_virt/data/virt_support_guests.html.

Depending on the virtualization platform on which you want to use the image, make sure the image also fulfills the following requirements.

KVM

Appliance format: If you are using SUSE Studio or SUSE Studio Onsite 1.3 to build images, use the SUSE OpenStack Cloud/OpenStack/KVM (.qcow2) format.

Xen

Appliance format: If you are using SUSE Studio or SUSE Studio Onsite 1.3 to build images, use the SUSE OpenStack Cloud/OpenStack/KVM (.qcow2) format.

VMware

Appliance format: If you are using SUSE Studio or SUSE Studio Onsite 1.3 to build images, use the VMware/VirtualBox/KVM (.vmdk) format.

If you are using SUSE Studio or SUSE Studio Onsite to build images, the resulting image will be a monolithic sparse file.

Note
Note: Image Conversion

Sparse images can be uploaded to OpenStack Image. However, it is recommended to convert sparse images into a different format before uploading them to OpenStack Image (because starting VMs from sparse images may take longer).

For a list of supported image types, refer to http://docs.openstack.org/liberty/config-reference/content/vmware.html, section Supported image types.

For details on how to convert a sparse image into different formats, refer to http://docs.openstack.org/liberty/config-reference/content/vmware.html, section Optimize images.

2.1.3 Images for Use With Multiple Hypervisors

If you build the images for SUSE OpenStack Cloud in SUSE Studio or SUSE Studio Onsite, they are compatible with multiple hypervisors by default—even if you may need to convert the resulting image formats before uploading them to OpenStack Image. See Procedure 2.1, “Converting Disk Images to Different Formats” for details.

If your image is not made in SUSE Studio or SUSE Studio Onsite, configure the image as follows to create an image that can be booted on KVM and Xen, for example:

/etc/sysconfig/kernel
INITRD_MODULES="virtio_blk virtio_pci ata_piix ata_generic hv_storvsc"
/boot/grub/menu.lst

To name the partition that should be booted, use:

root=UUID=...

To find the respective UUID value to use, execute the following command:

tune2fs -l /dev/sda2|grep UUID
/etc/fstab

Do not use device names (/dev/...), but UUID=... or LABEL=root entries. For the latter, add the label root to the root file system of your image (in this case, /dev/sda2):

tune2fs -L root /dev/sda2
Disk Format

Use *.qcow2 as disk format for your image.

Image Properties in OpenStack Image

To upload the image to SUSE OpenStack Cloud only once and to use the same image for KVM and Xen, specify the following image options during or after upload:

--public --container-format bare \
--property architecture=x86_64 \
--property vm_mode=hvm \
--disk-format qcow2

2.2 Building Images with SUSE Studio

When creating an appliance for SUSE OpenStack Cloud the following steps are essential:

  1. In SUSE Studio or SUSE Studio Onsite, switch to the Configuration › Appliance tab.

  2. Enable the Integrate with SUSE OpenStack Cloud/OpenStack check box.

  3. On the Build tab, choose the respective appliance format. It mainly depends on the hypervisor on which you want to use the image—see Section 2.1.2, “Image Requirements Depending on Hypervisor”.

For more detailed information on how to build appliance images, refer to the SUSE Studio Onsite documentation, available at http://www.suse.com/documentation/suse_studio/.

2.3 Image Properties

Images have both contents and metadata. The latter are also called properties. The following properties can be attached to an image in SUSE OpenStack Cloud. Set them from the command line when uploading or modifying images. For a list of image properties, see http://docs.openstack.org/developer/python-openstackclient/command-objects/image.html.

2.4 Uploading Images

If you have created an image for SUSE OpenStack Cloud/OpenStack/KVM with SUSE Studio or with SUSE Studio Onsite 1.3, you can upload the image directly as described in Procedure 2.2, “Uploading Disk Images to SUSE OpenStack Cloud”.

Procedure 2.1: Converting Disk Images to Different Formats
  1. Make sure the virt-utils package is installed on the machine used for conversion.

  2. Download the image from SUSE Studio.

  3. To convert qcow2 to vhd images, use the following command:

    qemu-img convert -O vpc CURRENT_IMAGE_FILE FINAL_IMAGE_FILE.vhd
Procedure 2.2: Uploading Disk Images to SUSE OpenStack Cloud

Upload a disk image using the python-openstackclient client.

Images are owned by projects and can be private (accessible to members of the particular project only) or public (accessible to members of all projects). Private images can also be explicitly shared with other projects, so that members of those projects can access the images, too. Any image uploaded to OpenStack Image will get an owner attribute. By default, ownership is set to the primary project of the user that uploads the image.

Set or modify hypervisor-specific properties with the --property key=value option. This can be done directly during image upload (as shown in the examples below). To change the properties after image upload, refer to Procedure 2.3, “Modifying Image Properties”.

  1. In a shell, source the OpenStack RC file for the project that you want to upload an image to. For details, refer to http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html.

  2. Upload the image using openstack image create. Find some example commands for different hypervisors below:

    • For KVM:

      openstack image create IMAGE_NAME \
        --public --container-format bare \
        --property architecture=x86_64 \
        --property hypervisor_type=kvm \
        --disk-format qcow2 \
        --file PATH_TO_IMAGE_FILE.qcow2
    • For Xen:

      openstack image create IMAGE_NAME \
        --public --container-format bare \
        --property architecture=x86_64 \
        --property hypervisor_type=xen \
        --property vm_mode=xen \
        --disk-format qcow2 \
        --file PATH_TO_IMAGE_FILE.qcow2
      Note
      Note: Value of vm_mode

      For Xen PV image import, use vm_mode=xen, for Xen HVM image import use vm_mode=hvm.

    • For VMware:

      openstack image create IMAGE_NAME \
        --public --container-format bare \
        --property vmware_adaptertype="lsiLogic" \
        --property vmware_disktype="preallocated" \
        --property hypervisor_type=vmware \
        --disk-format vmdk --file PATH_TO_IMAGE_FILE.vmdk
      Note
      Note: Value of vmware_disktype

      Depending on which disk type you use, adjust the value of vmware_disktype accordingly. For an overview of which values to use, refer to http://docs.openstack.org/liberty/config-reference/content/vmware.html, Table 2.8. OpenStack Image Service disk type settings.

    • For Docker:

      Find an image in the Docker registry you want to use and save it locally with docker pull IMAGE_NAME, where IMAGE_NAME is the name of the image in the Docker registry. The same name needs to be used when uploading the image with the following command:

      docker save IMAGE_NAME | openstack image create \
      --public --property hypervisor_type=docker \
      --container-format=docker --disk-format=raw IMAGE_NAME
      Important
      Important: Docker Images Need to Run a Long-Living Process

      Docker instances will only be able to spawn successfully, when running a long-living process, for example sshd. Such a process can be configured with CMD or ENTRYPOINT in the Docker.

      Alternatively, such a process can be specified on the command line with the image property os_command_line.

      openstack image set --property os_command_line='/usr/sbin/sshd -D' \
             IMAGE_ID

    If the image upload has been successful, a message appears, displaying the ID that has been assigned to the image.

Note
Note: Updating Images

After having uploaded an image to SUSE OpenStack Cloud, the image contents cannot be modified—only the image's metadata, see Procedure 2.3. To update image contents, you need to delete the current image and upload a modified version of the image. You can also launch an instance from the respective image, change it, create a snapshot of the instance and use the snapshot as a new image.

2.5 Modifying Image Properties

Set or modify hypervisor-specific properties with the --property key=value option. This can be done directly during image upload (see Procedure 2.2) or after the image has been uploaded (as described below).

Procedure 2.3: Modifying Image Properties
  1. In a shell, source the OpenStack RC file for the project that you want to upload an image to. For details, refer to http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html.

  2. If you do not know the ID or the exact name of the image whose properties you want to modify, look it up with:

    openstack image list
  3. Use the openstack image set command to set the properties for architecture, hypervisor type, and virtual machine mode. In the following, find some examples with properties for different hypervisors:

    • For KVM:

      openstacke image set IMAGE_ID_OR_NAME \
        --property architecture=x86_64 \
        --property hypervisor_type=kvm
    • For Xen:

      openstack image set IMAGE_ID_OR_NAME \
        --property architecture=x86_64 \
        --property hypervisor_type=xen \
        --property vm_mode=xen
      Note
      Note: Value of vm_mode

      For Xen PV image import, use vm_mode=xen, for Xen HVM image import use vm_mode=hvm.

    • For VMware:

      openstack image update IMAGE_ID_OR_NAME \
        --property vmware_adaptertype="lsiLogic" \
        --property vmware_disktype="preallocated" \
        --property hypervisor_type=vmware
      Note
      Note: Value of vmware_disktype

      Depending on which disk type you use, adjust the value of vmware_disktype accordingly. For an overview of which values to use, refer to http://docs.openstack.org/liberty/config-reference/content/vmware.html, Table 2.8. OpenStack Image Service disk type settings.

For more information about the architecture, hypervisor_type, and vm_mode properties, refer to http://docs.openstack.org/image-guide/content/image-metadata.html.

2.6 Using a Custom Kernel to Boot Btrfs Images Under Xen

On Xen hosts, starting instances from an image that uses Btrfs as root file system may fail with SUSE OpenStack Cloud 7. As a work-around, boot the Btrfs image with a custom kernel to start the instances. Prepare the Btrfs image as described in Procedure 2.4, “Booting Btrfs Images with a Custom Kernel”.

Procedure 2.4: Booting Btrfs Images with a Custom Kernel
Requirements
  • The python-openstackclient is installed. After you have sourced an OpenStack RC file, use the command line client to upload images from a machine outside of the cloud.

  • To run the python-openstackclient: An OpenStack RC file containing the credentials for the OpenStack project to which you want to upload the images.

  1. Install the grub2-xen package. It provides the grub.xen file required to boot para-virtualized VMs that use the Btrfs file system:

    root # zypper in grub2-x86_64-xen
  2. Create a Glance image with the kernel from this package. For example:

    openstack image create img-grub-xen-x64 \
     --file /usr/lib/grub2/x86_64-xen/grub.xen --public \
     --container-format bare --disk-format raw
  3. Create a second image which uses Btrfs as root file system. For example:

    openstack image create img-btrfs \
      --file openSUSE-Leap-42.1-JeOS-for-XEN.x86_64.qcow2 \
      --container-format bare --disk-format qcow2
  4. Update the image named img-btrfs by adding a kernel_id property to it:

    openstack image set 376c245d-24fe-41e2-8abd-655d4ed8da95 \
    --property kernel_id=72ad3069-6003-4653-86f2-b5914ce33f66

    where 376c245d-24fe-41e2-8abd-655d4ed8da95 is the ID of the image named img-btrfs and 72ad3069-6003-4653-86f2-b5914ce33f66 is the ID of the image named img-grub-xen-x64

  5. Boot the image to start the instance:

    nova boot --flavor FLAVOR --image 376c245d-24fe-41e2-8abd-655d4ed8da95

    This results in a domain XML which contains the kernel you need:

    <domain type='xen' id='2'>
     <name>instance-00000003</name>
     <uuid>12b2ce2b-ba1d-4c14-847f-9476dbae7199</uuid>
     <memory unit='KiB'>524288</memory>
     <currentMemory unit='KiB'>524288</currentMemory>
     <vcpu placement='static'>1</vcpu>
     <bootloader></bootloader>
     <os>
       <type>linux</type>
       <kernel>/var/lib/nova/instances/12b2ce2b-ba1d-4c14-847f-9476dbae7199/kernel</kernel>
       <cmdline>ro root=/dev/xvda</cmdline>
     </os>

2.7 Viewing Images and Image Properties, Deleting Images

In the following, find some examples on how to view images or image properties or how to remove images from OpenStack Image.

Listing Images
openstack image list

Lists ID, name, and status for all images in Image that the current user can access.

Showing Metadata for a Particular Image
openstack image show IMAGE_ID_OR_NAME

Shows metadata of the specified image.

Removing Image Properties
openstack image unset --property PROPERTY IMAGE_ID_OR_NAME
Deleting an Image
openstack image delete IMAGE_ID_OR_NAME

Removes the specified image from OpenStack Image.

2.8 Viewing and Modifying Membership of Private Images

In the following, find some examples on how to view or modify membership of private images:

Listing Members a Private Image is Shared With
glance member-list --image-id IMAGE_ID

Lists the IDs of the projects whose members have access to the private image.

Listing Private Images Shared With a Member
glance member-list --tenant-id PROJECT_ID

Lists the IDs of private images that members of the specified project can access.

Granting Members Access to a Private Image
glance member-create [--can-share] IMAGE_ID_OR_NAME PROJECT_ID_OR_NAME

Grants the specified member access to the specified private image.

By adding the --can-share option, you can allow the members to further share the image.

Revoking Member Access to a Private Image
glance member-delete IMAGE_ID_OR_NAME PROJECT_ID_OR_NAME

Revokes the access of the specified member to the specified private image.

3 Launching Instances from the SUSE OpenStack Cloud Dashboard

Instances are virtual machines that run inside the cloud. To start an instance, a virtual machine image must exist that contains the following information: which operating system to use, a user name and password with which to log in to the instance, file storage, etc. The cloud contains a pool of such images that have been uploaded to OpenStack Image and are accessible to members of different projects.

3.1 Key Parameters

When starting an instance, specify the following key parameters:

Flavor

In OpenStack, flavors define the compute, memory, and storage capacity of nova computing instances. To put it simply, a flavor is an available hardware configuration for a server. It defines the size of a virtual server that can be launched.

For more details and a list of default flavors available, refer to the Administrator Guide, chapter Dashboard or chapter OpenStack command-line clients, section Manage Flavors. The guide is available from http://www.suse.com/documentation.

Key Pair (optional, but recommended)

Key Pairs are SSH credentials that are injected into images when they are launched. For this to work, the image must contain the cloud-init package.

It is recommended to create at least one key pair per project. If you already have generated a key pair with an external tool, you can import it into OpenStack. The key pair can be used for multiple instances belonging to that project.

For details, refer to the End User Guide, chapter OpenStack dashboard or chapter OpenStack command-line clients, section Configure access and security for instances. The guide is available from http://www.suse.com/documentation.

Security Group

In SUSE OpenStack Cloud, security groups are used to define which incoming network traffic should be forwarded to instances. Security groups hold a set of firewall policies (security group rules).

For details, refer to the End User Guide, chapter OpenStack dashboard or chapter OpenStack command-line clients, section Configure access and security for instances. The guide is available from http://www.suse.com/documentation.

Network

Instances can belong to one or multiple networks. By default, each instance is given a fixed IP address, belonging to the internal network.

Boot Source of the Instance

You can launch instances from the following sources. For details, see the End User Guide, chapter OpenStack dashboard or chapter OpenStack command-line clients, section Launch and manage instances. The guide is available from http://www.suse.com/documentation.

  • Images that have been uploaded to SUSE OpenStack Cloud.

  • Volumes that contain images.

  • Instance snapshots.

  • Volume snapshots.

3.2 Launching Instances from Images, Snaphots, or Volumes

For instructions on how to launch instances from images or snapshots, see Launch an Instance.

4 Configuring Access to the Instances

Access to an instance is mainly influenced by the following parameters:

Security Groups and Rules

In SUSE OpenStack Cloud, security groups are used to define which incoming network traffic should be forwarded to instances. Security groups hold a set of firewall policies (security group rules).

For instructions on how to configure security groups and security group rules, see Configure access and security for instances.

Key Pairs

Key Pairs are SSH credentials that are injected into images when they are launched. For this to work, the image must contain the cloud-init package.

It is recommended to create at least one key pair per project. If you already have generated a key pair with an external tool, you can import it into OpenStack. The key pair can be used for multiple instances belonging to that project.

For details on how to create or import keypairs, see Configure access and security for instances.

IP Addresses

Each instance can have two types of IP addresses: private (fixed) IP addresses and public (floating) ones. Private IP addresses are used for communication between instances, and public ones are used for communication with the outside world. When an instance is launched, it is automatically assigned private IP addresses in the networks to which it is assigned. The private IP stays the same until the instance is explicitly terminated. (Rebooting the instance does not have an effect on the private IP addresses.)

A floating IP is an IP address that can be dynamically added to a virtual instance. In OpenStack Networking, cloud administrators can configure pools of floating IP addresses. These pools are represented as external networks. Floating IPs are allocated from a subnet that is associated with the external network. You can allocate a certain number of floating IPs to a project—the maximum number of floating IP addresses per project is defined by the quota. From this set, you can then add a floating IP address to an instance of the project.

For information on how to assign floating IP addresses to instances, see Configure access and security for instances.

4.1 Security Group Rules

You can adjust rules of the default security group and rules of any other security group that has been created. When the rules for a group are modified, the new rules are automatically applied to all running instances belonging to that security group.

Adjust the rules in a security group to allow access to instances via different ports and protocols. This is necessary to be able to access instances via SSH, to ping them, or to allow UDP traffic (for example, for a DNS server running on an instance).

Rules in security groups are specified by the following parameters:

IP Protocol

Protocol to which the rule will apply. Choose between TCP (for SSH), ICMP (for pings), and UDP.

Port/Port Range

For TCP or UDP, define a single port or a port range to open on the virtual machine. ICMP does not support ports. In that case, enter values that define the codes and types of ICMP traffic to be allowed.

Source of traffic (Remote in the SUSE OpenStack Cloud Dashboard)

Decide whether to allow traffic to instances only from IP addresses inside the cloud (from other group members) or from all IP addresses. Specify either an IP address block (in CIDR notation) or a security group as source. Using a security group as source will allow any instance in that security group to access any other instance.

If no further security groups have been created, any instances are automatically assigned to the default security group (if not specified otherwise). Unless you change the rules for the default group, those instances cannot be accessed from any IP addresses outside the cloud.

Procedure 4.1: Configuring Security Group Rules

For quicker configuration, the Dashboard provides templates for often-used rules that, including rules for well-known protocols on top of TCP (such as HTTP or SSH), or rules to allow all ICMP traffic (for pings).

  1. Log in to SUSE OpenStack Cloud Dashboard and select a project from the drop-down box at the top-level row.

  2. Click Project › Compute › Access & Security. The view shows the following tabs: Security Groups, Key Pairs, Floating IPs, and API Access.

  3. On the Security Group tab, click Manage Rules for the security group you want to modify. This opens the Security Group Rules screen that shows the existing rules for the group and lets you add or delete rules.

  4. Click Add Rule to open a new dialog.

    From the Rule drop-down box, you can select templates for often-used rules, including rules for well-known protocols on top of TCP (such as HTTP or SSH), or rules to allow all ICMP traffic (for pings). In the following steps, we will focus on the most commonly-used rules only:

  5. To enable SSH access to the instances:

    1. Set Rule to SSH.

    2. Decide whether to allow traffic to instances only from IP addresses inside the cloud (from other group members) or from all IP addresses.

      • To enable access from all IP addresses (specified as IP subnet in CIDR notation as 0.0.0.0/0), leave the Remote and CIDR fields unchanged.

      • Alternatively, allow only IP addresses from other security groups to access the specified port. In that case, set Remote to Security Group. Select the desired Security Group and Ether Type (IPv4 or IPv6).

  6. To enable pinging the instances:

    1. Set Rule to ALL ICMP.

    2. Decide whether to allow traffic to instances only from IP addresses inside the cloud (from other group members) or from all IP addresses.

      • To enable access from all IP addresses (specified as IP subnet in CIDR notation as 0.0.0.0/0), leave the Remote and CIDR fields unchanged.

      • Alternatively, allow only IP addresses from other security groups to access the specified port. In that case, set Remote to Security Group. Select the desired Security Group and Ether Type (IPv4 or IPv6).

  7. To enable access via a UDP port (for example, for syslog):

    1. Set Rule to Custom UDP.

    2. Leave the Direction and Open Port values untouched.

    3. In the Port text box, enter the value 514.

    4. Decide whether to allow traffic to instances only from IP addresses inside the cloud (from other group members) or from all IP addresses.

      • To enable access from all IP addresses (specified as IP subnet in CIDR notation as 0.0.0.0/0), leave the Remote and CIDR fields unchanged.

      • Alternatively, allow only IP addresses from other security groups to access the specified port. In that case, set Remote to Security Group. Select the desired Security Group and Ether Type (IPv4 or IPv6).

5 Deploying Kubernetes

By combining OpenStack, Docker, Kubernetes, and Flannel, you get a containers solution which works like other OpenStack services. With Magnum, Docker and Kubernetes are made available as first class resources in OpenStack.

5.1 Deploying a Kubernetes Cluster from Command Line

A cluster (formerly bay) is the construct in which Magnum launches container orchestration engines.

Requirements
  • The python-openstackclient is installed. After you have sourced an OpenStack RC file, use the command line client to upload images from a machine outside of the cloud.

  • To run the python-openstackclient: An OpenStack RC file containing the credentials for the OpenStack project to which you want to upload the images.

  • The python-magnumclient is installed.

  • Install the openstack-magnum-k8s-image-x86_64 package. This package provides a virtual machine image with Kubernetes pre-installed, openstack-magnum-k8s-image.x86_64.qcow2. OpenStack Magnum uses this image when creating clusters with its k8s_opensuse_v1 driver.

  1. In a shell, source the OpenStack RC file for the project that you want to upload an image to. For details, refer to http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html.

  2. Create an image for cluster setup. For example:

    openstack image create openstack-magnum-k8s-image \
      --public --disk-format qcow2 \
      --property os_distro='opensuse' \
      --container-format bare \
      --file /srv/tftpboot/files/openstack-magnum-k8s-image/openstack-magnum-k8s-image.x86_64.qcow2
  3. Create a Magnum flavor. For example:

    openstack flavor create --public m1.magnum --id 9 --ram 1024 \
       --disk 10 --vcpus 1

    If you do not have enough resources and RAM on your compute nodes for a flavor of this size, create a smaller flavor instead.

  4. Create a cluster template for Kubernetes. For example:

    magnum cluster-template-create --name k8s_template \
      --image-id openstack-magnum-k8s-image \
      --keypair-id default \
      --external-network-id floating \
      --dns-nameserver 8.8.8.8 \
      --flavor-id m1.magnum \
      --master-flavor-id m1.magnum \
      --docker-volume-size 5 \
      --network-driver flannel \
      --coe kubernetes \
      --master-lb-enabled
  5. Create a Kubernetes cluster using the cluster template you have created in the step above. For example:

    magnum cluster-create --name k8s_cluster --cluster-template k8s_template \
      --master-count 1 --node-count 2

    The resulting cluster will have one master Kubernetes node and two minion nodes.

5.2 Deploying a Kubernetes Cluster from the Dashboard

Alternatively, you can deploy a Kubernetes cluster in the SUSE OpenStack Cloud Dashboard by creating a cluster template and creating a Kubernetes cluster afterward.

Requirements
Procedure 5.1: Creating a Cluster Template in SUSE OpenStack Cloud Dashboard
  1. Log in to SUSE OpenStack Cloud Dashboard and select a project from the drop-down box at the top-level row.

  2. Click Container Infra › Cluster Templates › Create Cluster Template.

    The Create Cluster Template dialog opens, showing the following sections: Info, Node Spec, Network, and Labels.

  3. In the Info section:

    1. Enter a name for the cluster template to create.

    2. As Container Orchestration Engine, choose Kubernetes.

    3. If wanted, activate the following options:

      • Public: The cluster template will be visible for all users in OpenStack.

      • Enable Registry: The cluster can be built with Insecure Docker Registry service.

      • Disable TLS: Switch off the SSL protocol for the cluster.

  4. In the Node Spec section:

    1. Choose the Image you have created in Section 5.1, Step 2.

    2. Choose a Keypair.

    3. Choose the Flavor you have created in Section 5.1, Step 3. It will be used for the minion nodes.

    4. Choose the same flavor as Master Flavor. It will be used for the master node.

    5. As Volume Driver, choose Cinder.

    6. As Docker Storage Driver, choose Device Mapper.

    7. Specify the Docker Volume Size (GB). For example: 5

  5. In the Network section:

    1. As Network Driver, choose Flannel.

    2. Leave the HTTP Proxy, HTTPS Proxy, and No Proxy boxes empty or enter the respective addresses to use.

    3. As External Network ID, enter floating. The network floating will be used to connect to the cluster template you are creating.

    4. Leave the Fixed Network and Fixed Subnet boxes empty.

    5. Enter the DNS server to use for this cluster template. For example: 8.8.8.8.

    6. To deploy the cluster with a load balancer service in front for the cluster services, activate Master LB.

    7. To assign floating IP addresses to the nodes in the cluster, activate Floating IP.

  6. Confirm your changes to create the cluster template.

Procedure 5.2: Creating a Cluster in SUSE OpenStack Cloud Dashboard

Based on the cluster template you have created in Procedure 5.1, “Creating a Cluster Template in SUSE OpenStack Cloud Dashboard”, you can now create a Kubernetes cluster.

  1. Log in to SUSE OpenStack Cloud Dashboard and select a project from the drop-down box at the top-level row.

  2. Click Container Infra › Clusters › Create Cluster.

    The Create Cluster dialog opens, showing the following sections: Info, Size, and Misc.

  3. In the Info section:

    1. Enter a Cluster Name.

    2. From the Cluster Template list, select the template you have created in Procedure 5.1, “Creating a Cluster Template in SUSE OpenStack Cloud Dashboard”.

  4. In the Size section, enter the number of master nodes and minion nodes you want the cluster to have. For example: 1 and 2.

  5. In the Misc section, you can optionally specify a custom URL for node discovery and a Timeout for cluster creation, if wanted. The default is no timeout.

  6. Confirm your changes to create the cluster.

5.3 Deploying a Kubernetes Cluster Without Internet Access

In specific scenarios, you may need to deploy a Kubernetes cluster without access to Internet. For those cases, you need to set up a custom Insecure Docker Registry and use no discovery URL. You can do this either from command line (as described below) or from the SUSE OpenStack Cloud Dashboard.

  1. In a shell, source the OpenStack RC file for the project that you want to upload an image to. For details, refer to http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html.

  2. Create a cluster template as shown in , Step 4, but add the options --registry-enabled and --labels. The registry_url must include the protocol, e.g. http://URL. For example:

    magnum cluster-template-create --name k8s_template_reg_enabled \
     [...]
     --registry-enabled
     --labels registry_url=http://192.168.255.10/srv/files
  3. Create a cluster as shown in , Step 5, but with static IP configuration and setting the option --discovery-url to none. For example:

    magnum cluster-create --name k8s_cluster_without \
      --cluster-template k8s_template_reg_enabled \
      [...]
      --discovery-url none

A Documentation Updates

This chapter lists content changes for this document.

This manual was updated on the following dates:

A.2 February 2017 (Initial Release SUSE OpenStack Cloud 7)

A.3 January 2017 (Maintenance Release SUSE OpenStack Cloud 6)

A.4 February 2015 (Initial Release SUSE OpenStack Cloud 5)

General
  • Moved the SUSE-specific additions for the Administrator Guide and End User Guide to the Supplement to Administrator Guide and End User Guide.

Print this page