When a DevOps user logs in, they are placed directly into the Self Service Portal. However, an Owner/Admin user lands into the Dashboard page when they log in. For such users to access the Service Portal they need to click the xPlore menu item at the top menu bar and click on the Cloud Resources sub-menu item.
xPlore.Cloud Self Service Portal is really very simple to understand and then navigate. No matter which cloud or what resource on them you are accessing or managing, the basic user interface does not change much.
The following screen-shots are the Admin and DevOps User views respectively. The main areas of the UI are marked on them with colored rectangles.
Fig 1: Owner/Admin view of xPlore.Cloud front-end
Fig 2: DevOps user view of xPlore.Cloud front-end
A Feature usually corresponds to a particular Cloud Service, which may or may not correspond to a particular Cloud Resource. For example, a Server feature within xPlore.Cloud represents a Virtual Machine. But, in different clouds this might be called by different names and exposed through specific cloud services. At AWS, these are EC2 instances, in Azure and VMWare this is called a Virtual Machine. But, within xPlore.Cloud, this will always be referred to as a Server.
In Fig 1, above, the red rectangle bounds the drop down of the Features that are available for the currently active Cloud Access Server (or, simply the Cloud). Below is a separate image of the Features drop-down with the constituent sections highlighted by colored rectangles for both Admin and DevOps views.
- Red rectangle at the top: This is the drop down and when you select a feature, that acts as the header for the content.
- Blue rectangle: The Cloud resources/services are listed in this section. Notice the DevOps view has only one feature, viz., Server listed, whereas the admin view has several of them. This means that the DevOps user does not have permissions on any of the Features except only for the Server feature.
- Gray rectangle: This section lists the Lookup Tables that various features might be internally using. E.g., the Create Server action for an AWS account could have a drop down of Availability Zones for the Self Service users to choose from. Since these are internal setup data, usually only the developers will need access to the interface to manipulate these tables. But, an admin user can very well permit (using the Access control module) selected DevOps users to access these to do data entry.
- Red rectangle: This is the interface to enter/modify configuration parameter values for the active cloud (CAS). Only admin users have access to this menu item.
- Purple rectangle: This provides cloud specific help and is actually written by the developers of the cloud features themselves.
To know more about what features are available and how to use each of them, you must click the Help menu item within the Features drop down.
An action is some kind of an operation on a Feature/Cloud Resource. For example, for the Feature Server, there can be the following actions:
- Resync (Resync xPlore.Cloud data cache with that of the target cloud)
- Create (Create a new server)
- Start (Start a server)
- Stop (Stop a server)
- Terminate (Terminate a server)
- Console (Launch a RDP/SSH connection to the server)
Within the xPlore.Cloud Service Portal, actions appear as buttons in the row representing an instance of the corresponding cloud resource. In Fig 1 and 2 above, these appear within the blue rectangles. The small rectangles at top-right are the global actions Create and Resync.
To know more about what actions are available and how to use each of them, you must refer to the Help menu item within the Features drop down.
Cloud Access Server (CAS)¶
From a back-end perspective, this is a server that facilitates the connectivity between the service portal and the target cloud.
From the DevOps user’s perspective, this usually corresponds to a particular Cloud account.
However, your organisation’s programmers and admins may well have abstracted this one-to-one connection out and created a more meaningful term for you to refer to. E.g., they could have used a single CAS to connect to multiple Cloud accounts and provided the CAS’ names that might have better contextual meanings to you as a user. In most situations, your administrator should already have exposed only the CASes that you need access to and you may not even need to bother about what they represent, except for the immediate connotations like, use the Development CAS to launch dev servers and use the Production CAS to launch production servers. That sort of thing.
Region is a further classification concept within a CAS.
In many public and private clouds, the concept of a Region may already have a natural correspondence. E.g. the regions in AWS or Azure. But, in case of others, this could be something artificially manufactured by the developers.
For example, in the xPlore.Cloud reference implementation for VMWare, the Regions correspond to different vSphere or ESXi hosts.
Again, in most cases, your Administrators should already have restricted your access to the ones that are relevant to you and you may not need to directly bother about this at all.