+++ date = "2015-09-30" draft = false weight = 06 title = "Lab 06 - Nova - Flavors & Instances" +++
The objective of this lab is to launch an instance from the CLI (utilizing the Nova service). When an instance is launched, it is assigned a flavor, which is a set of resources. Flavors can be of the type public, or private, so we'll study both.
- SSH to your controller as root, you might use:
-
Your browser (https://sshproxy.alta3.training/)
Once logged into the browser, type
screen -x <last initial><first initial>to return to your previous session -
Alternative, you may use PuTTY (Windows), or Terminal (Apple)
-
Run help on the nova service, and review the nova usage. For now, pay special attention to the flavor commands. You can run help by typing the following:
[root@controller ~]#source keystonerc_admin[root@controller ~(keystone_admin)]#nova help | less
- For students who do not have much experience using the less command:
- Press CTRL + F to go forward one window, and CTRL + B to go back one window
- Press CTRL + D to go forward one half window, and CTRL + U to go back one half window
- Press q to quit Less utility and return to the CLI
- If you have never used the less utility, you might find the following cheat sheet useful (http://sheet.shiar.nl/less)
-
Use nova flavor-list to see what default flavors are installed with OpenStack. When you see these, the concept of 'resources' should become more clear. Your output should look like the following:
[root@controller ~(keystone_admin)]# nova flavor-list+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ | ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | +----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ | 1 | m1.tiny | 512 | 1 | 0 | | 1 | 1.0 | True | | 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True | | 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True | | 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True | | 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True | +----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ -
Answer the following questions:
- How many more VCPUs does m1.xlarge have over m1.tiny?
- How many more much more memory does m1.xlarge have over m1.tiny?
- What do you think Is_Public means?
- Hint: Is it possible a specific tenant might require access to a 'special' flavor?
-
Maybe all of our customers want access to a specific flavor; one with 512 Mb of RAM, 2 volumes, 1 VCPU, named "custom.shrimpy2". We can do that with the following command:
[root@controller ~(keystone_admin)]#nova flavor-create custom.shrimpy2 7 512 2 1
- Question: Look at the command you just copy & pasted. The values 512 (Mb of RAM), and 2 (volumes), and 1 (VCPU) should be clear. So why was the value of 6 included?
- Hint: Run the command "nova flavor-list", and exame the table once more. 1... 2... 3... 4... 5...
- If the command is still unclear, run 'nova help flavor-create'
-
Look for shrimpy on the flavor list as multiple users. What we are illustrating, is that this is a publicly available flavor.
[root@controller ~(keystone_admin)]#nova flavor-list+----+----------------+-----------+------+-----------+------+-------+-------------+-----------+ | ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | +----+----------------+-----------+------+-----------+------+-------+-------------+-----------+ | 1 | m1.tiny | 512 | 1 | 0 | | 1 | 1.0 | True | | 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True | | 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True | | 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True | | 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True | | 6 | custom.shrimpy | 512 | 2 | 0 | | 1 | 1.0 | True | | 7 |custom.shrimpy2 | 512 | 2 | 0 | | 1 | 1.0 | True | <---- There it is! +----+----------------+-----------+------+-----------+------+-------+-------------+-----------+
-
Switch to the user Alice Anderson, and confirm she can see the flavor. Type the following:
[root@controller ~(keystone_admin)]#source keystonerc_aliceanderson[root@controller ~(keystone_aliceanderson)#nova flavor-list -
Switch to the user Chester Copperpot, and confirm he can see the flavor. Type the following:
[root@controller ~(keystone_alicenaderson)]#source keystonerc_chestercopperpot[root@controller ~(keystone_chestercopperpot)]#nova flavor-list
Alice Anderson and her team might need a custom flavor that is uniquely tuned for a project she is working on. For example, Alice's team needs to occasionally render video on a 'monster' instance with 128 GB of memory. We want Alice and her team to have access to this instance, but not our other customers. If we create a new flavor as described above, the user would have access to the custom flavor, but so would all other tenants in the cloud. Giving everyone access to a 'monster' flavor might not be desirable. Customers not requiring (or paying) for the 'monster' flavor might drive our cloud into full capacity rather quickly. To prevent this, lets restrict access to the custom flavor.
-
If you haven't done so before, issue the nova help flavor-create command.
[root@controller ~(keystone_chestercopperpot)]#nova help flavor-create
- Review the output, then answer the following questions:
- Is RAM described in GB or MB?
- Is Disk size described GB or MB?
- What is the default value for --is-public?
-
Notice that a flavor may have an optional argument --is-public to be set as true or false, where the default is true. Let's toggle it to false and see what happens.
[root@controller ~(keystone_chestercopperpot)]#source keystonerc_admin[root@controller ~(keystone_admin)]#nova flavor-create --is-public false secret.monster 8 125000 8 200[root@controller ~(keystone_admin)]#nova flavor-list
- Why is the number 7 included after secret.monster?
- Hint: If you've forgotten, scroll up a little bit and look at the output from the
nova help flavor-createcommand - Do you see the new secret.monster flavor listed? Think for a moment. Why or why not?
- Hint: Did we say which tenants have access to this secret flavor yet?
-
We need to tell OpenStack who should gain access to this project. Let's choose admin to start. Type the following:
[root@controller ~(keystone_admin)]#nova help | grep flavor[root@controller ~(keystone_admin)]#nova help flavor-access-add[root@controller ~(keystone_admin)]#keystone tenant-list -
Highlight the Tenant_ID associated with the tenant admin
-
When you highlight a value, you auto-copy it; no need to CTRL + C
[root@controller ~(keystone_admin)]#nova flavor-access-add 8 300b2cc45c3846939e589310ae714e46<-- your value will be different! Retrieved with keystone tenant-list[root@controller ~(keystone_admin)]#nova flavor-list
-
The admin should now see the flavor secret.monster displayed, as the tenant admin has been given access to the project.
-
See if you can figure out how to allow Alice Anderson access to the flavor as well. It is okay to struggle a bit. If you get really stuck, the steps are listed below:
[root@controller ~(keystone_admin)]#keystone tenant-list
-
Highlight the Tenant_ID associated with the tenant acme_inc
[root@controller ~(keystone_admin)]#nova flavor-access-add 8 the_tenant_id_of_acme_inc[root@controller ~(keystone_admin)]#source keystonerc_aliceanderson[root@controller ~(keystone_aliceanderson)]#nova flavor-list -
Alice Anderson should see the presence of secret.monster displayed, as the tenant acme_inc was given access to the project
-
Question: Should Chester Copperpot (a tenant of VaultTek) be able to see the project? Think about it, then issue the following commands to find out!
[root@controller ~(keystone_aliceanderson)]#source keystonerc_chestercopperpot[root@controller ~(keystone_chestercopperpot)]#nova flavor-list -
The user chestercopperpot should not see the flavor secret.monster, as the tenant vault_tek was not given access to the project.
-
Let's try launching some instances from the CLI. SSH to your controller and log in as root, source yourself as the keystonerc_chestercopperpot user permission set.
-
See what flavor, images, and networks are available for use. Type the following commands:
[root@controller ~(keystone_chestercopperpot)]#nova flavor-list[root@controller ~(keystone_chestercopperpot)]#nova image-list[root@controller ~(keystone_chestercopperpot)]#neutron net-list -
There are a few things we have not studied yet that we are working with here. We have not studied networking yet. Normally, we would first create a network for a tenant, and then launch that instance within that tenant's private network. We can study that later, for now, highlight the id of the private network
- Remember, highlighting will auto-copy
-
Boot an instance called vt1 with the flavor custom.shrimpy2, from the image cirros, and place it on the private network (more on networking is coming up)
NOTE: Instances typically will be placed on their own tenant network, and include a 'security group' (a set of IP rules); things we haven't yet studied (we'll get there in subsequent labs). Launching an instance without defining a security group, will result in using the 'default' security group, which denies all incoming traffic.
[root@controller ~(keystone_chestercopperpot)]#nova boot --flavor custom.shrimpy2 --image cirros --nic net-id=<private_network_id> vt1+--------------------------------------+-----------------------------------------------+ | Property | Value | +--------------------------------------+-----------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | nova | | OS-EXT-STS:power_state | 0 | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | - | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | adminPass | 7XbbjiX9Pbcn | | config_drive | | | created | 2015-10-04T22:18:35Z | | flavor | custom.shrimpy2 (7) | | hostId | | | id | bee8e2d9-ac2e-4190-a251-139216bb0a8b | | image | cirros (8a724f78-2673-4ea1-b607-373626a15afb) | | key_name | - | | metadata | {} | | name | vt1 | | os-extended-volumes:volumes_attached | [] | | progress | 0 | | security_groups | default | | status | BUILD | | tenant_id | ad1d9eeaf2884c7e8eac33ec0f3ef6e5 | | updated | 2015-10-04T22:18:36Z | | user_id | 85787ab96a6f442a8ab51bac131175b4 | +--------------------------------------+-----------------------------------------------+
- Of course your output will be unique from what is listed above. Use your output to answer the following questions:
- What is the task state?
- What ID was this instance assigned?
- What tenant does this instance belong to?
- What name was this instance given?
- What image was used to boot this instance?
-
Display a list of the running instances within the current tenant
[root@controller ~(keystone_chestercopperpot)]#nova list
- What is the status?
- What is the power state?
- Hint: Issue the command again in a few minutes if they do not say "ACTIVE" and "Running" respectively.
-
Display information only about the running instance vt1 that was just created:
[root@controller ~(keystone_chestercopperpot)]#nova show vt1 -
Log into the Horizon dashboard interface as
chestercopperpot//fa5tpa55w0rdthen navigate to:
- Navigate to: Project > Compute > Instances
- You've had some experience clicking around in Horizon instances before. Do it again! If nothing else, check out the log and console tabs for the instance.
- This found by clicking on the instance name (vt1), then clicking on the log tab (or console tab).
- That's it for this lab! We'll continue to explore manipulating instances, but feel free to exploring launching instances from the CLI or Horizon, or checking out other Nova commands while you wait.