+++ date = "2015-09-30" draft = false weight = 2 title = "Lab 02 - Nova - Horizon" +++
The objective of this lab is to you to administering an OpenStack cloud. Let's role play a bit. Your new OpenStack deployment has gone live and you are ready to take on your first customers. These may be paying customers or perhaps a particular department within your organization.
For the purposes of this lab, we'll take two orders. The first order we'll provision via the OpenStack Horizon GUI, the second order, we'll complete with the CLI.
- Order 1: Acme Inc; they would like two users, Alice Anderson, and Bob Barker, to be able to admin a small cloud for their company.
- Order 2: VaultTek Enterprises; they would like Chester Copperpot to be able to admin a small cloud for their company.
-
To get started, if you are not already, sign into the OpenStack web GUI as the user admin (
http://<userid>.alta3.training
) -
Before we get started, click on Project > Compute > Overview
One more thing we can take note of: in the upper right part of the screen is the user you are currently logged in as. In the upper left side of the screen is the project you are currently working within. Look at the screenshot below. The project drop down menu and user drop down menu have both been clearly defined with large red arrows.
-
On the left hand side screen click on Identity > Projects You won't have the same projects on your machine, and that's fine, but below is a projects page that an admin might see.
Note: In OpenStack, users belong to Projects. Projects and tenants are interchangeable terms, used to refer to a group of users, and the total amount of cloud resources those users may consume (for, say, switching on instances). When OpenStack was new, compute had its own authentication mechanism and used to term 'project'. Authorization is now handled by the Keystone service, where it uses the word 'tenant'. The admin tenet has their own default project. This can be useful location to host virtualized services that are integrated into the OpenStack deployment.
-
To start, let's edit the project we are already a part of, On the Projects screen, in the Name column click on the blue admin link
-
You should now be on the 'Project Details: admin' page. In the drop down menu in the upper right, select 'Edit Project'.
-
In the Edit Project box that pops up, click on the Quota tab
-
Change VCPUs from its current value, to something absurd. After all, we're just trying to drive home a point. How about 2 billion? Change the value of VCPU to read, VCPU: 2000000000
-
Change Instances from its current value, to something absurd. Change the value of instances to read, Instances: 1000000000
-
After you've made those two changes, click the 'Save' button at the bottom of the screen.
-
Navigate to Project > Compute > Overview
Examine the pie charts for Instances, and VCPUs. They've changed radically, but only to reflect the permissions our project has been given. Hopefully it is clear that we couldn't possibly have just increased the resource capacity of our system by a factor of 100 million by simply changing the value of a variable.
-
To view actual available system resources, click on Admin > System > Hypervisors. You're welcome to go there now, but we'll devote another lab to exploring this section later. So for now, don't get too caught up in it.
What we want to take away from this section is that projects have associated maximum thresholds that are defined by the project's quotas. Quotas may exceed the actual resource capacity of the total cloud system, therefore the size of a project may be limited by the quota, or resource capacity of the system itself.
Consider that we are currently signed into the system as the admin for the OpenStack deployment. You would never want to give this account out to your customers, so let's create a new project and apply some users.
Users may belong to many projects, but they always must belong to at least one. If a user belongs to a project, and that project is deleted, then that user will not be able to log into the Horizon dashboard until they are once again assigned (at least) one project.
Before we create new users, lets first create a few projects (tenants).
-
Log in as admin to the Horizon interface, and navigate to Identity > Projects.
-
In the upper right hand corner, click the '+Create Project' button. The following screenshot has a giant red arrow on the button you looking for.
-
On the Project Information tab, input the following Project Information (do NOT click Create Project yet!)
Name: acme_inc Description: Acme Inc. is the world's leader in the production of widgets Enabled: (checked)
-
Click on the 'Project Members' tab. We don't yet have any users from the Acme Inc organization, so we won't apply any yet.
-
Now click on 'Quota'
This page controls the operational limits of a project could place on available resources within our infrastructure. For example, we certainly don't want our customer, Acme Inc, to max out our cloud's storage space with widget designs.
-
Let's set an appropriate quota:
Metadata Items: 128
When booting an instance, you can also add arbitrary meta data so that you can more easily identity it among other running instances. This value limits the length of the string where 128 is the default.
VCPUs: 2
VCPUs are the number of available virtualized cores
Instances: 2
The number of instances, or VMs, that maybe created
Injected Files: 5
Injected files are arbitrary local files that can be placed into the instance file system at the time of creation.
Injected File Content (Bytes): 10240
Limits total size (in bytes) of allowable injected files.
Volumes: 2
Volume-Snapshots: 2
Total-Size-of-Volumes-and-Snapshots-(GB): 200
Total accrued size of all stored data.
RAM-(MB): 51200
Security-Groups: 5
The total available security groups this project may create
Security-Group-Rules: 20
The total available security group rules this project may create
Floating-IPs: 4
Total number of floating IP addresses the project may utilize. Floating IPs are applied to instances.
Networks: 3
Number of virtualized networks that may be created
Ports: 50
Routers: 3
Subnets: 3
Maximum number of subnets that may be created by a project.
-
You are now permitted to click the Create Project button
Acme Inc wanted two users to be available to admin their systems, Alice Anderson and Bob Barker, so lets add them now that we have the project space created.
-
Log in to Horizon as admin. On the left hand side of the OpenStack Horizon GUI, click on Identity > Users
-
In the upper right hand corner, click the '+Create User' button.
-
Fill out the 'Create User' screen as follows and click Create User
White spaces and capitals may be used, but they make the login more complex, so please don't use them.
Password: fa5tpa55w0rd ConfirmPassword: fa5tpa55w0rd UserName: aliceanderson Email: <blank> PrimaryProject: acme_inc Role: _member_
-
Create a second user, this will be the Bob Barker profile.
Fill out the second 'Create User' screen and click Create User
Password: fa5tpa55w0rd ConfirmPassword: fa5tpa55w0rd UserName: bobbarker Email: <blank> PrimaryProject: acme_inc Role: _member_
-
Log out the admin account within the Horizon GUI by clicking in the upper right hand corner, and click 'Sign Out'.
-
Log in as
aliceanderson:fa5tpa55w0rd
-
Click on Project > Compute > Overview
This screen should look quite a bit different than the overview screen you saw when you were logged in as admin. Notice that Alice Anderson may only create a total of 2 instance, and utilize a total of 2 VCPUs. These settings reflect what was provisioned in the Project's Quota tab.
If you forget what the admin quota screen looked like, sign out, and sign back in as admin. It is important that you understand that Alice Anderson is a user within a project (tenant), therefore she may only utilize the resources that have been made permissible to the project for which she belongs (acme_inc).
Make sure you clearly understand this partitioning of available system resources into projects (tenants) via quotas before continuing the lab. We're not racing here. Take all the time you need.
-
Double check that you are signed in as
aliceanderson:fa5tpa55word
Notice that the project in the upper left change has changed. You should be signed in as the user aliceanderson, within the project acme_inc.
-
Click on Project > Compute > Instances
-
In the upper right corner, click 'Launch Instance'
-
The Launch Instance dialog box should pop up, on the Details tab, set the settings as follows:
AvailabilityZone: nova InstanceName: acme_vm1 Flavor: m1.xlarge InstanceCount: 1 InstanceBootSource: Boot from image ImageName: cirros
-
Click 'Launch', and the instance will fail.
That's OK, just driving home the point that the project acme_inc does not have enough resources provisioned by their quota to boot the m1.xlarge flavor. Afterall, the m1.xlarge flavor wants to run 4 VCPUs, and we only have 2 available to our project.
-
Let's try again, this time, configure the instance details tab as follows:
AvailabilityZone: nova InstanceName: acme_vm1 Flavor: m1.tiny InstanceCount: 1 InstanceBootSource: Boot from image ImageName: cirros
-
This instance still is not ready for us to launch. Click on the 'Networking' tab
-
Add the network 'private' and 'public' to the instance, by clicking the + sign beside those networks.
-
Once complete, click the 'Launch' button
Immediately upon launching the instance (virtual machine), it will begin spawning. This may take a few minutes, and that's OK. How long the instance takes to spawn is completely dependent on how many resources the instance has been created with, and how the the underlying OpenStack architecture has been designed. Spawning m1.tiny should not take longer than 3 or 5 minutes.
-
Once instance changes from 'Spawning' to 'Running', sign out of the aliceanderson account
-
Log in as
bobbarker:fa5tpa55w0rd
-
Click on Project > Compute > Overview
You should see the same total available resources that the account aliceanderson saw. Remember, both Alice and Bob are part of the same project (acme_inc)
-
Click on Project > Compute > Instances
You should still see the same instance that the account aliceanderson saw. Again, both Alice and Bob are part of the same project (acme_inc)
-
Logged in as bobbarker, click on the 'Launch Instance' button, then create the following instance:
AvailabilityZone: nova InstanceName: acme_vm2 Flavor: m1.tiny InstanceCount: 1 InstanceBootSource: Boot from image ImageName: cirros
-
Click on the 'Networking' tab
-
Add the network 'private' and 'public' to the instance, but clicking the + sign beside those networks.
-
Once complete, click the 'Launch' button, and wait for the acme_vm2 instance to finish spawning. Again, this may take a few moments.
-
Once acme_vm2 is running, click on Project > Compute > Overview
Spend a few minutes checking out this screen. Notice that no more instances or VCPUs are available for this project. It should look similar to the screen shot below:
-
Navigate to Project > Compute > Instances > Instance Name: acme_vm2 > Log Tab
What is the login and password for this vm? Hint look down.
-
Log out of bobbarker, and log back in as admin.
-
Click on Admin > System > Instances
-
Check all the tick boxes beside the running instances. Click 'Terminate Instances'. All instances should begin shutting down.
-
Once more log out of admin, and log back in as aliceanderson or bobbarker.
The acme_inc project should once again have no instances running. Check the Project > Compute > Overview dashboard and the Project > Compute > Instances dashboard to be sure.