Mirantis OpenStack Express 2.0 - Setting up a Project

This is the sixth in a series of short tutorials showing how to perform common cloud operations tasks in Mirantis OpenStack Express 2.0 — Mirantis’ “Private Cloud as a Service”

In our last tutorial, we looked at defining flavors that describe new VM configurations. Now we’ll look at some higher-level administrative functions, for creating projects and users. We’ll also look at basic Neutron network and router creation, needed to make new projects baseline functional.

Step by Step

projects — sometimes also called ‘Tenants’ or ‘Accounts’ — are organizational units that let you control access to cloud resources and manage their consumption. You can equip project environments with specialized networking, create custom images for their exclusive use, and perform other task-appropriate customizations.

Let’s start by logging into Mirantis OpenStack Express Horizon as the admin, navigating to Projects in the Identity Panel subtab of the Admin menu, and clicking on Create Project.

First, give your project a name and an optional Description. You’ll see a checkbox that gives you the choice of initializing your product in an Enabled state, or not. That’s useful if you have administrative work to do inside the project before granting associated users access. Disabling an active project — something you might try later on — can be used to bar users temporarily from accessing project resources without terminating running instances.

To create a new project, start by giving it a name. Note the Enabled checkbox that lets you set whether your project will be created in a fully-enabled (thus available to users) state or not.

When you create a new project you can assign quotas for various resources: OpenStack will prevent users of the project from going over these limits. But these aren’t the only quotas OpenStack makes available for customization and fine-tuning: you can access more from the command-line interface. Users, too, can be given quotas with respect to projects — we’ll cover quotas in detail in a future tutorial. Meanwhile, the defaults Mirantis OpenStack Express puts in place are generally sensible — they make some resource allocations fixed and others not — the latter are parameterized with a -1.

The Quota tab lets you set project quotas — though these are just a subset of quotas that can be set from the command line. Using the command line, users, too, can be given quotas with respect to projects. In enforcing overlapping quotas, OpenStack resolves differences, insuring that the most-restrictive relevant quota is applied in any situation.

You can also assign users to the project from the project Members tab. For now, we’re going to make sure the admin user has access. In a moment, we’ll create a new user and add them to the project. Meanwhile, let’s finish creating the project.

Adding users to your new project. Here, we add the admin user — less, in this case, as a permission, and more to permit accurate usage record-keeping.

You’ll notice that OpenStack seems to throw an error here, though it also reports successful project creation. This simply means that we left the default quotas in place, some of which were specified as ‘unlimited.’

Our project is created. Note that OpenStack throws what appears to be an error message, here, because we left certain project quotas set to permit "unlimited" usage. In Mirantis OpenStack Express, default quotas are set sensibly, however, with critical resources automatically parceled out among projects fairly.

Now that we have a project, let’s go to the Users tab and create a user. Give the user a name, insert their email, and specify a password. Associate them to the project we just created, and give them a Member role. The ‘+’ button, here, raises the Create Project dialog: we can create projects from the Create User interface. Click create user.

Creating a new user. We can add them to a project at this step.

Now let’s switch to our new project as the admin user, by clicking on the popdown in the upper left.

As you can see, the Horizon display is now a little different. We don’t have access to high-level administrative functions. No instances are active yet. We’re seeing a more-limited view of the system.

Switching to our new project as the admin user. In Overview, we now see the project's activity (none yet), rather than the cloud's as a whole.

Certain things are in place for us. For example, Mirantis OpenStack standard boot images are all defined as Public, so we can use them.

But we switch to the Network tab, look at topology, and see that we have no network, except for the net04_ext external, public network, owned by the Admin. That’s a problem, because we can’t start VMs without a local network and a subnet. And we can’t do much with VMs unless we can reach them from the internet.

So we’re going to quickly make a new network under Neutron that’s functionally identical to the default network at toplevel — configured by Mirantis OpenStack Express’s Fuel installer, when our cloud was deployed.

Though we have access to resources shared by admin with our project, and to resources designated Public, such as Mirantis OpenStack Express default boot images (or shared by admin with our project), our project still starts up unconfigured. Here, we see that the project has access to the net04_ext shared external network. So we need to build a local network for VMs, and attach it to the external network via a router.

Starting to create a new network — the Create Network button is also available from the Network Topology display.

First, we go to Networks, and we create a new network, giving it a name.

Naming our new local network.

Then we’ll specify a subnet, naming that as well, and specifying a local IP address range that’s convenient, using CIDR notation. The conventional choice here is something like 192.168.0.0/24.

Since we want our VMs to have internet access, we’ll also configure a gateway address — the corresponding default is 192.168.0.1, which Horizon will use if we leave this field blank.

Creating a subnet and setting IP address ranges and the gateway address.

We could add additional configuration details, but they're not needed for the simple network we're creating.

Our network and its associated subnet are created.

Now we’ll create a Router to connect our local subnet to the shared external network. Here, all we have to do to start is give it a name, to start.

Creating a router: start by giving it a name.

Then we can click the Set Gateway button, and point it to the net04_ext external network.

Use the Set Gateway button to pop a dialog letting you point the router towards the external network.

You can see the accessible external network in the popdown.

And finally, we can click the Router’s name and add an interface to our local network, bridging that to the external one.

Click the name of your new router to view its detail page and create interfaces.

Click the Add Interface button to create a new interface, connecting the router to our local network.

We can select our local network from the dialog's popdown.

The Network Topology display now shows our local network, connected via router to the net04_ext external network.

One last step, which can save you some head-scratching. When a project is created, it inherits the default security group with only the default settings. So to make VMs accessible via SSH from the internet, you’ll need to visit Access & Security->Security Groups and edit the default group’s rules, adding an inbound rule that allows traffic on port 22.

We still can't access VMs from the internet, though, until we modify the new project's plain vanilla Security Groups rules.

Adding a new Ingress rule, permitting traffic on port 22 (SSH).

Our new rule is added to the 'default' security group rule-set.

Now we can make VMs nternet accessible by giving them floating IP addresses from the external network pool. Does it work? Let’s start a VM, give it a floating IP, and see if we can connect to it. Success!

Now that we've done all our housekeeping, appropriately-configured VMs launched within the project and given a floating IP address can be accessed remotely via SSH, with the appropriate keypair.

Finally, let’s log out of Horizon, and then back in, as the project user we created. As you can see, we’re taken directly to the project’s Overview, and have no option to switch projects: this is now our environment.

Logging into Horizon as our new project user, we can see the more-limited view users have of our cloud.

Now that we’ve learned about projects, our next tutorial will offer an overview of Murano, the application catalog.

Resources:

• Mirantis OpenStack Express 2.0 Documentation
• Mirantis OpenStack Express Operations Guide
• Manage Projects and Users

Check out Express for yourself at https://express.mirantis.com.