In this blog, we will walk you through how to disable extensions by default and enable extensions for tenants who subscribe to the service. The foundation for this blog is attributed to another blog, Managing access to the VMware vCloud Availability for Cloud-to-Cloud Plugin to vCloud Director 9.5, by Daniel Paluszek. The primary difference is that we will cover a few additional steps that were not covered in Daniel’s blog. The four high level steps we will focus on in this blog are:
- Authenticating to vCloud Director
- Retrieving the vCloud Availability extension ID
- Globally disabling the vCloud Availability extension
- Enabling the vCloud Availability extension per tenant
1. Authenticating to vCloud Director
Contents
The first thing we will want to do when managing extensions is authenticate to vCloud Director. There are several ways to do this. I am going to walk through the manual way of doing this using Postman. Tomas Fojta also has a great blog on managing this in a more automated way with his blog Postman and vCloud Director 9.5 Access Token Authentication.
To begin, we will establish a session with vCloud Director and grab the token from the response. To do this, we will create a new session in Postman with an action of POST. For the url, we will point to https://<vcd-fqdn>/api/sessions. Once this is set up, the next thing we will need to do is set up authentication. Just below the URL bar, select the Authorization tab. From there, select Basic Auth for the authentication type and provide the credentials for the vCD system administrator. It is important to use <user>@system as the username since system is a hidden organization that represents the provider.
Once authorization has been defined, next we will need to provide the appropriate headers. Select the headers tab and click in the first box in the key column and add Accept. For the value type application/*+xml;version=31.0. Once you have set up Authorization and Headers, and ensured the type is set to POST, you can submit the request by hitting send.
It is important to note we are using version=31.0 since this is the supported version for vCloud Director 9.5. If you are running other versions of vCloud Director, this value will need to be modified to match the supported version. As an example, for vCloud Director 9.1, this will be set to version=30.0. Any changes made to this value will also need to be updated on any subsequent calls using the Accept header. For more information on API versions, please check the vCloud Director API documentation page.
The response you get will be a block of XML providing some details on the vCD instance. What we are after in this step is the authentication token that was returned with this request. To get the token select the headers tab in the response pane (lower half of the page) and copy the value returned for x-vcloud-authorization. This token will be used to authenticate future requests for this session.
It is important to note, that this token is bound to the session and is time bound. For future sessions, you will need to repeat these steps to get a new session token.
2. Getting the vCloud Availability extension ID
Now that we have authenticated our session with vCloud Director, the next step is to get the ID of the vCloud Availability extension. Create a new tab in Postman with an action of GET and URL of https://<vcd-fqdn>/cloudapi/extensions/ui. Before hitting send, we will want to update our headers to provide authorization. To do this, select the headers tab and add x-vcloud-authorization as a key and paste the value that was returned from the previous step as the value. The header will be used for all future API requests. Once this information has been input, select Send to submit the request. The response for this request will be a list of the installed extensions and associated IDs. The extension we will be looking for is vCloud Availability and its associated ID.
It is important to note the remaining steps, unless otherwise noted, are in JSON. So the Accept header that was used in the previous step is no longer required.
Now that we have the ID for vCloud Availability, lets take a quick look at which tenants currently have access to the extension before we disable it. As before, create a new tab in Postman with an action of GET and this time with a URL of https://<vcd-fqdn>/cloudapi/extensions/ui/<extension id>/tenants. What you should see at this point is a complete list of all tenants since, by default, it is published globally.
3. Globally disabling the vCloud Availability extension
Once we have determined the ID of the vCloud Availability extension, the next thing we will do is disable, or unpublish, it globally. To disable the extension globally, open a new tab with an action of POST and URL of https://<vcd-fqdn>/cloudapi/extensions/ui/<extension id>/tenants/unpublishAll. Once set up, click SEND. What should be returned is an empty list indicating that the extension is no longer applied to any tenants.
To verify this, click on Send again in the tab you created in the previous step and you should now receive an empty list. We can also verify by logging into the UI of one of the tenants to see if the extension is still present. As you can see from the screenshot below, the Availability extension is no longer visible in the tenant UI.
4. Enabling the vCloud Availability Extension per tenant
Now that we have unpublished the extension globally, the final step is to publish it for the tenants that are currently subscribed to the service. The first thing we will do is get a list of all of the tenants and their associated IDs. To retrieve this information, open a new tab in Postman with a GET action and a URL of https://<vcd-fqdn>/api/query?type=organization&format=references. As before, we will set up the x-cloud-authorization header with the auth token retrieved in the first step. In this particular case, the response is XML so we will also add the Accept header with the associated value of application/*+xml;version=31.0. Once the correct URL and headers have been established, click SEND to retrieve a complete list of Organizations with their associated IDs.
Now that we have a complete list of all of the organizations, we will want to extract the tenants who have subscribed to the service and need to have access to the extension. Once this information has been defined, open up a final tab and set the action to POST and URL to https://<vcd-fqdn>/cloudapi/extensions/ui/<extension id>/tenants/publish. As usual, ensure the x-vcloud-authorization header has been set in the header. In this particular step, we will be defining a specific set of customers to enable the extension. To do this, we will provide a payload to this POST. Select the Body tab and select raw for the body type. In the dropdown list select JSON. In the payload section, we will create a JSON list with the tenant names and IDs which we need to publish the extension.
The first time this is run, you will want to ensure you have added System to the list of tenants for the extension to be published.
Once the list has been defined with the appropriate tenant information, hit Send. After posting the request, you will be sent a complete list of all tenants to which the extension has been published. As final test, we will log back into one of our tenants that we just re-enabled and the Availability extension should be present.
Conclusion
Now that we have disabled vCloud Availability at the global level, any new tenant that is added will not have access to the extension by default. As tenants subscribe to the service, the extension will need to be enabled. This can be done manually, as we have shown here, or this can be automated. The key to this is that only the people that need to see the extension will see it, eliminating unnecessary confusion. In a future blog, we will investigate how to automate this process in Postman or other tools such as a vRO workflow.
Please feel free to review other articles related to the vCloud Availability blogs series:
1. vCloud Availability 3.0 Blog Series: Introduction
2. vCloud Availability 3.0 Blog Series: Provider Installation
3. vCloud Availability 3.0 Blog Series: Provider Post Deployment Configuration
4. vCloud Availability 3.0 Blog Series: Tenant Installation
5. vCloud Availability 3.0 Blog Series: Tenant Post Deployment Configuration
6. vCloud Availability 3.0 Blog Series: Managing vCloud Availability Access
7. vCloud Availability 3.0 Blog Series: Cloud Access, Ownership, and Visibility
