One of the largest value propositions of DevOps is the concept of Self Service provisioning. If you can remove human interaction from resource allocation, you can reduce both the response time and the likelihood of error in configuration. Red Hat CloudForms has a self service feature that allows a user to select from predefined services. You may wish to show different users different catalog items. This might be for security reasons, such as the set of credentials required and provided, or merely to reduce clutter and focus the end user on specific catalog items. Perhaps some items are still undergoing testing and are not ready for general consumption.
Obviously, these predefined services may not match your entire user population.
I’ve been working on setting up a CloudForms instance where members of different groups see different service catalogs. Here is what I did.
Tags are the primary tool used to match up users and their service catalogs. Specifically, A user will only see a catalog item if his group definition matches the Provisioning Scope tag of the Catalog Item. While you can make some catalog items to have a Provisioning Scope of All, you probably want to scope other items down to the target audience.
I have a demonstration setup based on IdM and CloudForms integration. When uses log in to the CloudForms appliance, one of the user groups managed by LDAP will be used to select their CloudForms group. The CloudForms group has a modified Provisioning Scope tag that will be used to select items from the service catalog.
I also have a top level tenant named “North America” that is used to manage the scope of the tags later on. I won’t talk through setting this up, as most CloudForms deployment have something set as a top level tenant.
I’m not going to go through the steps to create a new catalog item. There are other tutorials with go through this in detail.
My organization is adding support for statisticians. Specifically, we need to provide support for VMs that are designed to support a customized version of the R programming environment. All users that need these systems will be members of the stats group in IdM. We want to be able to tag these instances with the stats Provisioning Scope as well. The user is in the cloudusers group as well, which is required to provide access to the CloudForms appliance.
We start by having our sample user log in to the web UI. This has the side effect of prepopulating the user and group data. We could do this manually, but this way is less error prone, if a bit more of hassle.
My user currently only has a single item in her service catalog; the PostgreSQL appliance we make available to all developers. This allows us to have a standard development environment for database work.
Log out and log back in as an administrator. Here comes the obscure part.
Provisioning Scope tags are limited to set of valid values. These values are, by default All or EVMGroup-user_self_service. This second value matches a group with the same name. In order to add an option, we need to modify the tag category associated with this tag.
- As an administrator, on the top right corner of the screen, click on your user name, and select the Configuration option from the dropdown.
- Select your region, in my case this is region 1.
- Across the top of the screen, you will see Settings Region 1, and a series of tabs, most of which have the name of your tenant (those of you that know my long standing issue with this term are probably grinning at my discomfort). Since my top level tenant is “North America” I have a tab called North America Tags which I select. Select accordingly.
- Next to Category select “Provisioning Scope” from the drop down and you can see my existing set of custom tag values for Provisioning Scope. Click on <New Entry> to add a new value, which I will call stats. I also use stats for the description.
- Click the Add button to the right. See Below.
Now we can edit the newly defined “R Project” service to limit it to this provisioning scope.
- Navigate to Services->Catalogs->Catalog Items.
- Select the “R Project” Service.
- Click on the Policy dropdown and select “Edit Tags”
- Click on the drop down to the right of “Select a customer tag to assign” (it is probably set on “Auto Approve -Max CPU *”) and scroll down to Provisioning Scope.
- The dropdown to the right, which defaults to “<Select a Value to Assign”>. Select this and scroll down to the new value. For me, this is stats. The new item will be added to the list.
- Click the Save button in the lower right of the screen.
Your list should look like this:
Finally, create the association between this provisioning scope and the stats group.
- From the dropdown on the top right of the screen that has your username, select Configuration.
- Expand the Access Control accordian
- Select groups.
- From the Configuration dropdown, select “Add a new Group”
- Select a Role for the user. I use EvmRole-user_self_service
- Select a Project/Tenant for the user.
- Click on the checkbox labeled “Look Up External Authentiation Groups”
- A new field appears called “User to Look Up.” I am going to user the “statuser” I created for this example, and click retrieve.
- The dropdown under the LDAP Groups for User is now populated. I select stats.
To assign the tag for this group:
- Scroll down to the bottom of the page
- find and expand the “Provisioning Scope” tag
- Select “stats”
- Click the Add button in the bottom right corner of the page.
Now when statuser logs in to the self service web UI, they see both of the services provided:
One Big Caveat that has messed me up a few times: a user only has one group active at a time. If a user is a member of two groups, CloudForms will select one of them as the active group. Services assigned only to the non-active group will not show up in the service catalog. In my case, I had a group called cloudusers, and since all users are a member of that group, they would only see the Provisioning Scope, and thus the catalog items, for cloudusers, and not the stats group.
The Self Service webUI allows the user to change group to any of the other groups to which they are assigned.
The best option is to try and maintain a one to many relationship between groups and users; constrain most users to a single group to avoid confusion.
This has been a long post. The web UI for CloudForms requires a lot of navigation, and the concepts required to get this to work required more explanation than I originally had planned. As I get more familiar with CloudForms, I’ll try to show how these types of operations can be automated from the command line, converted to Ansible playbooks, and thus checked in to version control.
I’ve also been told that, for simple use cases, it is possible to just put the user groups into separate tenants, and they will see different catalogs. While that does not allow a single item to be in both catalogs, it is significantly easier to set up.
A Big Thank You to Laurent Domb for editing and corrections.
Source From: fedoraplanet.org.
Original article title: Adam Young: Different CloudForms Catalogs for Different Groups.
This full article can be read at: Adam Young: Different CloudForms Catalogs for Different Groups.