Customizing VPC Functionality (vpcs.xml)

The vpcs.xml file is a Viewpoint configuration file that specifies what the GUI looks like and how Viewpoint interacts with Moab in relation to VPCs. The vpcs.xml file requires a root XML element named <vpcs>. The <vpcs> element contains the following child elements:

<properties>

The <properties> element consists of three child elements:

• <disk-model>
• <fiscal-year-end>
• <bare-metal-variable>

For more information on the <disk-model> and the <fiscal-year-end> elements, see Configuring the Properties Element. For more information on the <bare-metal-variable> element, see Accessing Bare Metal Machines with Viewpoint.

<provision>

The <provision> element contains the information necessary to create, or provision, a new VPC. Through the <provision> element, you can customize the user interface and its associated functionality. Specific examples of configurable actions via the <provision> element include following:

• Allocate what pages display to users when creating a new VPC, including component definition.
• Define resources the user can consume.
• Run an mshow -a request for resources.
• Respond when Moab returns valid VPC transactions.
• Perform the create VPC action.

<modify>

The <modify> element contains all information necessary to modify a VPC and the reservations that exist on them. This element also establishes the rules for modifying configurable attributes of a VPC.

<archive>

The <archive> element contains all information necessary to archive reservations and the configuration settings and data stored on them. Archives can be used for backup purposes, or they can be used as a sort of template for future workloads. For example, an archived reservation that has a fresh install of MATLAB can be used for different workloads.

<vpc-management>

The <vpc-management> element allows you to customize the table on the the VPC Management page. You can modify the allowable action buttons, the table display, and the details panel for an item in the table in this element.

Adding a Reservation

The process to add a reservation to a VPC is very similar to the process of creating a VPC. Users select the resources they wish to add, Viewpoint verifies these resources are available, and the resources are reserved until the 'add reservation' action is funded.

To specify the details about this process, you can modify the <add-vm> element. The children of this element are very similar to those of the <provision> element. The child elements of <add-vm> are:

• <components> - Components are displayed to the user in the order they are passed.
• <request> - Each <requirement> element is assumed to be of type "single" because there is no queue and only one new reservation is added.
• <cart-item> - Viewpoint expects a <description> that defines the detailed description to be put in the database. This can be any string decider.
• <action> - The <action> element defines what Viewpoint should do to add a reservation to an existing VPC.

Managing VPC Users

Viewpoint has the ability to manage user roles and access to a VPC. This information is stored on the database configured with Viewpoint. You can configure user management options within the vpcs.xml file. This configuration is done through the <modify-users> element. Within the <modify-users> element, the "host" and "path" attributes are optional. In the Manage environment, when a user selects a VPC and clicks Manage Users, the VPC Management page displays:

User roles are divided into role groups. In the above image, there are two role groups. An organization can have as many roles and role groups as they wish, but each role should belong to exactly one role group. Role groups are for display only; the database is unaware of which roles belong to which role groups.

To specify a role group, use the <role-group> element. This element requires one or more <role> elements and an optional <description> element. The description is displayed to the user as the section header. The individual <role> elements require a description (which is displayed to the user) as well as a unique id. The id is stored in the database with the user that has that role.

Here is an example that configures two role groups and produces the example image above:

<role-group id="admin"> 
  <description>Admin Access</description> 
  <role id="acl"> 
   <description>Admin</description> 
  </role> 
 </role-group> 
 <role-group id="vlans"> 
  <description>VLAN Access</description> 
  <role id="dev_vlan" default="true"> 
   <description>Development</description> 
  </role> 
  <role id="test_vlan"> 
   <description>Test</description> 
  </role> 
 </role-group> 

Special ACL Role

There is a special role that uses the keyword of "acl". If the "acl" role is used, the VPC users with the Access Control List (ACL) role are added to the VPCs ACL in Moab upon modification. If a user is part of a VPCs ACL, they are able to view, modify, and administer the VPC.

Syncing VPC Users with an external source

Every role other than "acl" is used to communicate the modification information to an external source. In order to communicate with an external source, a path that points to an executable script is required. The script is passed an argument of "id=<vpc_id>". It is expected that the script gets the user information from Viewpoint's database. By default, the script is found on the web server. If the "host" attribute is set to the value moab, the script is found on the Moab host. The Moab host is determined by the Moab connection information found in core.xml.

External Source Response XML

When the user clicks Modify, the script found in the path is executed. Execution of a script is expected to return a result of a particular interface. The XML looks something like this:

<response type="manage-vpc-users"> 
  <result success="true"> 
    The users were successfully modified.
  </result> 
</response>

The script defined in the path must be executable.

Role Validation

With the <validation> optional element, you can set rules to check if the inputs on the manage users dialog are valid. The user is notified that they should change their inputs to valid values. The validation requirements are evaluated every time the user wants to make a change. After each change, the validation is checked and the response is fired. If the current role setup is invalid, the user cannot select another user and cannot click OK until the conflict is resolved. As soon as the user enters a valid value, the warning messages go away and the OK button is re-enabled.

In order to accomplish role validation, you must specify a validation rule and the associated response. In the <validation> element, create a child <rule> and <response>. The <rule> element must evaluate to false for the response to occur. This element should be any boolean decider. The <response> element describes the behavior of the GUI when <rule> evaluates to false.

A <response> element defines which components to invalidate and the corresponding error message. The <response> element has a <message> element as well as any number of <component> elements that get invalidated with the message.

In this example, validation is configured to verify all VPC users have at least one role:

<validation> 
  <validation-rule> <requirement logical-operation="or"> 
    <value> 
     <component id="test_vlan" /> 
    </value> 
    <value> 
     <component id="dev_vlan" /> 
    </value> 
    <value> 
     <component id="acl" /> 
    </value> 
   </requirement> 
   <response strict="true"> 
    <message>All users must have at least one role</message> 
    <component id="test_vlan" /> 
    <component id="dev_vlan" /> 
    <component id="acl" /> 
   </response> 
  </validation-rule> 
 </validation>