Managing your cloud resources with OpenStack/en: Difference between revisions

OpenStack is the software suite used on the Compute Canada Cloud to control hardware resources such as computers, storage and networking. It allows the creation and management of virtual machines ("VMs", or "instances"), which act like separate individual machines, by emulation in software. This allows users complete control over their computing environment, from choosing an operating system to software installation and configuration. Diverse use cases are supported, from hosting websites to creating virtual clusters. More documentation on OpenStack can be found at the [http://docs.openstack.org/ OpenStack web site].

This page describes how to perform common tasks encountered while working with OpenStack. It is assumed that you have already read [[Cloud Quick Start]] and understand the basic operations of launching and connecting to a VM. Most tasks can be performed using either the dashboard (as described below), [[OpenStack Command Line Clients|CLI]], or a tool called [https://www.terraform.io/ terraform]; however, some require using command line tools, for example [[#Sharing_an_image_with_another_project|sharing an image with another project]].

OpenStack projects group VMs together and provide a quota out of which VMs and related resources can be created. A project is unique to a particular cloud. All accounts which are members of a project have the same level of permissions, meaning anyone can create or delete a VM within a project they are a member of. You can view the projects you are a member of by logging into an OpenStack dashboard for the cloud(s) you have access to (see [[Cloud#Using_the_Cloud|using the cloud]] for a list of cloud URLs). The active '''project name''' will be displayed in the top left of the dashboard to the right of the cloud logo. If you are a member of more than one project you can switch between active projects by clicking on the drop down menu and clicking a project name.

Projects can be thought of as owned by primary investigators (PIs) and new projects and quota adjustments can only be requested by PIs. In addition request for access to an existing project must be confirmed by the PI owning the project.

Availability zones allow you to indicate what group of physical hardware you would like your VM to run on. On East, West, and Graham clouds, there is only one availability zone, ''Nova'', so there isn't any choice in the matter. However, on Arbutus there are three availability zones: ''Compute'', ''Persistent_01'', and ''Persistent_02''. The ''Compute'' and ''Persistent'' zones only run compute or persistent flavors respectively (see [[virtual machine flavors]]). Using two persistent zones can present an advantage; for example, two instances of a website can run in two different zones to ensure its continuous availability in the case that one of the sites goes down.

A security group is a set of rules to control network traffic into and out of your virtual machines. To manage security groups go to ''Project->Compute->Access & Security'' and select the ''Security Groups'' tab. You will see a list of currently defined security groups. If you have not previously defined any security groups, there will be single default security group.  

[[File:Default_security_group_rules_en.png|400px|thumb| Default Security Group Rules (Click for larger image)]]

* 2 Egress rules, allow your instance to access outside network without any limitation, there is one rule for IPV4 and one for IPV6.

* 2 Ingress rules, allow communication for all the vms that belong to that security group, for both IPV4 and IPV6.

It is safe to add rules to the default security group and you may recall that we did this in [[Cloud Quick Start]] by either adding security rule for [[Creating_a_Linux_VM#Firewall.2C_add_rules_to_allow_SSH|SSH]] or [[Creating_a_Windows_VM#Firewall.2C_add_rules_to_allow_RDP|RDP]] to your default security group so that you were able to connect to your VM.

You can define multiple security groups and a VM can belong to more than one security group. When deciding on how to manage your security groups and rules, think carefully about what needs to be accessed and who needs to access it. Strive to minimize the IP addresses and ports in your Ingress rules. For example, if you will always be connecting to your VM via SSH from the same computer with a static IP it makes sense to allow SSH access only from that IP. To specify the allowed IP or IP range use the [[OpenStack#Using_CIDR_rules|CIDR]] box (use this web based tool for converting [http://www.ipaddressguide.com/cidr IP ranges to CIDR] rules). Further, if you only need to connect to one VM via SSH from the outside and then can use that as a gateway to any other Cloud VMs, it makes sense to put the SSH rule in a separate security group and add that group only to the gateway VM. However, you will also need to ensure your SSH keys are configured correctly to allow you to use SSH between VMs (see [[SSH Keys]]). In addition to CIDR, security rules can be limited within a project using security groups. For example, you can configure a security rule for a VM in your project running a MySQL Database to be accessible from other VMs in the default security group.

The security groups a VM belongs to can be chosen when it is created on the ''Launch Instance'' screen under the ''Access & Security'' tab, or after the VM has been launched by selecting ''Edit Security Groups'' from the dropdown menu of actions for the VM on the ''Project->Compute->Instances'' page.