Unified Cloud Platform

VPC Differences

AWS VPC is supported in UCP within Network Manager.  As we built up Network Manager, we created some differences with AWS VPC when comparing LCP and UCP.  This is temporary.  We will reach parity between UCP and LCP as it pertains to VPC.  Below is a table that lists the actions that can be performed through the both the Dashboard or API depending on the platform at this time. 
 

Note: that these differences in the table below only apply to AWS.   

Legend:

X - Supported feature
Ø - Not supported

Scaling across Subnets in VPC

With a UCP account, RightScale ServerArrays support scaling across multiple subnets which may span one or more Availability Zones in a given VPC.

Endpoint URL Change

The most substantial change for Rightscale API users who are using a UCP account will be the change of the API endpoint to match the Rightscale UCP environment that your account is hosted in.

For example, you may have used an API endpoint to login to Rightscale and set a cookie with your legacy Rightscale account:

https://my.rightscale.com/api/acct/<account ID>/login

When your account is hosted in or migrated to a UCP environment, the endpoint URL will need changing for the same login call. As an example, 'us-3' is a Rightscale UCP environment, so the updated endpoint would be as follows:

https://us-3.rightscale.com/api/acct/<account ID>/login

You can determine the endpoint that you are supposed to use by simply logging into the Rightscale dashboard, viewing or switching to your UCP account and observing the address bar for your browser. It should reflect a URL with the appropriate sub-domain, which in turn will be the endpoint you are supposed to use for that particular account.

API Redirects

It's important to note that if you do forget to change your endpoint, and are still using the legacy 'my.rightscale.com' API endpoint with a UCP account, then the API will return an HTTP 302 redirect. Along with this redirect, we also return a <Location> header that points you to the appropriate endpoint, however we DO NOT make the updated call to the new endpoint for you. 

For example, if I were to issue the following Curl command (which uses my.rightscale.com) to establish an API 1.5 login/session for a UCP account, it will return an HTTP 302 and a <Location> header with the updated API endpoint/URL, like so:

curl -v -H 'X-API-VERSION:1.5' -c myCookie -d "email=joe.user@rightscale.com&password=<user password>&account_href=/api/accounts/<UCP account ID>"  https://my.rightscale.com/api/session

And the subsequent output (shortened for brevity):

< Status: 302 Found
< X-Runtime: 21
< Location: https://us-3.rightscale.com/api/session

So, in this case, the API endpoint should be updated to us-3.rightscale.com instead of my.rightscale.com for this particular account.

We HIGHLY recommend updating your scripts, code or libraries to the newer UCP compatible API endpoint as soon as possible. If you wish to continue using the my.rightscale.com endpoint, then it is your responsibility to ensure that your scripts, code or libraries that are using our API can take advantage of this <Location> header as needed.

API 1.0 to 1.5 Translation Layer

It is also important to understand that you can continue to perform an API 1.0 call against an account in a UCP environment. The only requirement is that the endpoint must be changed to match the account environment (as mentioned previously). The API 1.0 call will be translated to its API 1.5 counterpart and will be automatically ran.

For example, the following Curl command uses API 1.0 and will login, create an API session and set a login cookie. Notice the X-API-VERSION header is set to 1.0 still, and the endpoint is set to us-3 for a UCP account. This call will be translated to it's corresponding 1.5 call and will be successfully executed:

curl -v -H 'X-API-VERSION:1.0' -c myCookie -u joe.user@rightscale.com:<user password> https://us-3.rightscale.com/api/acct/<UCP account ID>/login

Here is the Curl output showing the HTTP 204 response code, which is a success for this call:

< HTTP/1.1 204 No Content
* Server nginx/1.0.14 is not blacklisted
< Server: nginx/1.0.14
< Date: Thu, 31 Oct 2013 19:18:28 GMT
< Connection: keep-alive
< Status: 204 No Content

Important! Most API 1.0 calls can be translated to API 1.5 calls, however there may be certain calls that fail or are not supported. For this reason, we recommend updating any scripts, code or libraries that utilize API 1.0 to utilize API 1.5 instead.