A good understanding of cloud related settings can go a long way in efficiently managing your data center environment. In a previous lesson, we had already talked about users and groups. Of course, users and groups belong to something called a project in any cloud environment. But what exactly is a project? A project is a unit of ownership in a cloud environment. The name project is subject to some ambiguity, especially in new administrators. In traditional IT environments, people used to call this a tenant. A project is a tenant. For example, I could have a project named sales and inside this project all resources for the sales department would be available. Somebody else say from the marketing project would not be able to see the resources inside the sales project. Most resources, such as a virtual machines, volumes and images, belong to a specific project. Needless to say, projects can contain users, and users need to be assigned to specific roles within the project. Let's say you're an administrator working with the sales team. Then you can be a user in this sales project with the administrator role. So as you may have guessed, we need to create new projects to get started with supporting multi tenancy in a cloud environment. This only works with the cloud edition of IBM PowerVC named IBM Cloud PowerVC Manager. To create projects, you use the open stack project create command. It's as simple as that. You can then give it a description and the name of the project. In this example, we're creating a project named project dev. To delete a project, use the open stack project delete command, with the name of the project that you want to be deleted. To view a list of available projects, use the open stack project list command, a sample output of this command is shown here. We see three projects in our sample output with their own unique identifiers automatically assigned to it by open stack. The third one in this list is named IBM default, and it's the default project created during installation. When you log in as the root user immediately after installation, you are logged into the IBM default project. Managing user roles is also an important task. Here's a list of roles you can assign to the users of your environment. This list of roles can be viewed using the open stack role list minus c name command. Let's describe these roles. So first we have the admin role. This is the complete access to and control of PowerVC. Then there is the admin assist role, users with this role can perform create and edit tasks, but do not have privileges to perform remove or delete operations. For example, to delete a virtual machine, or a volume, or remove a host or a network. Then there is the viewer role. This has read only access to the assigned project and cannot perform any actions. Managers of a project can be assigned as viewers if they just wish to see what's going on. Then there is self service. This role is available in IBM Cloud PowerVC Manager only. It has a greatly simplified graphical interface view. It cannot see virtual machines that they do not own. Users with this role are allowed to perform a limited set of actions on virtual machines that he or she owns, subject to cloud policies that might require approval from an administrator or the project manager user. Which brings us to the project manager role. This is also available in IBM Cloud PowerVC Manager only. This role also has a simplified view but significant permissions within that view to reduce the need for admin involvement. This role is introduced specifically for IBM Cloud PowerVC Manager to fill the gap between the admin and self service roles. A user with the project manager role cannot see the underlying infrastructure and has no access to other projects on which they do not have a role, but within the scope of their assignment project there otherwise, much like an admin. Delegation of the project manager role should free up admin users to manage the infrastructure and PowerVC itself. For example, this user can approve requests from other users of the project, thus freeing up the admins to focus on other tasks. Then there is the VM manager role, and this role can view most things and has significant control over virtual machines from deployment through deletion, but cannot control infrastructure, storage, or images. Similarly, we have the storage manager role. This role can view most things, but can't affect much other than storage. The image manager role is similar too, it can view most things but can't affect much other than the images. The VM user can view most things but can't affect much other than performing lifecycle operations on existing virtual machines. There's also a deployer role and as the name states, and this role can view most things but can't affect much other than deploying new virtual machines. Now we've talked about creating users in a previous lesson. This was using the operating system command user add. Now we've talked about adding the users to a project in your environment with a specific role. So for example, you may assign user A as VM user within the sales project and user B as the project manager within the marketing project, and so forth. By now, the parlance should be clear, so let's see a few examples of these commands. Let's say you want to add a user named viewer to your project and the project is sales with the viewer role. Let's say you want to add a user named viewer one to the project sales with the viewer role. This is the command you would use. The open stack roll adds command with the project attribute, the user attributes, and finally the name of the role. This is how the command looks to add a new admin user to the sales project. And this is the syntax of the commands that we've been talking about. Finally, this is how to delete a user from a project. In this example, we delete the root user from the IBM default project. As we saw before, after creating admin users, it's best not to use the root user just for accountability reasons. We talked about the self service role, most non admin users of your it environment, say developers who need access to your virtual machines, will be self service users. Here's the graphical interface of the self service users. As you can see on the left side pane, a lot of the features available for the admin user are hidden from this user. We'll conclude our look at PowerVC topics with a round up of other interesting features, that's coming right up in the next video. [MUSIC]
