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

2. Enable the Integrate with SUSE OpenStack Cloud Crowbar/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”.

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

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: 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: 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 https://docs.openstack.org/nova/pike/admin/configuration/hypervisor-vmware.html, section 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: 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.

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: 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: 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 https://docs.openstack.org/glance/latest/admin/useful-image-properties.html, section OpenStack Image Service disk type settings.

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>

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

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. List the Magnum image uploaded to Glance using the openstack image list | grep openstack-magnum-k8s-image. If no image found, you can create an image for cluster setup as shown below:

   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.

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.

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.

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