So, a customer today reached out to us asking if Rackspace provided the entire infrastructure IP address ranges in use on cloud. The answer is, no. However, that doesn’t mean that making your firewall rules, or autoscale automation need to be painful.
In fact, Rackspace Cloud utilizes Openstack which fully supports API calls which will easily be able to provide this detail in just a few simple short steps. To do this you require nova to be installed, this is really relatively easy to install, and instructions for installing it can be found here;
https://support.rackspace.com/how-to/installing-python-novaclient-on-linux-and-mac-os/
Once you have installed nova, it’s simply a case of making sure you set these 4 lines correctly in your .bash_profile
OS_USERNAME=mycloudusernamegoeshere OS_TENANT_NAME=yourrackspaceaccountnumbergoeshereusuallysomethinglike1010101010 OS_AUTH_SYSTEM=rackspace OS_PASSWORD=apikeygoeshere OS_AUTH_URL=https://identity.api.rackspacecloud.com/v2.0/ OS_REGION_NAME=LON OS_NO_CACHE=1 export OS_USERNAME OS_TENANT_NAME OS_AUTH_SYSTEM OS_PASSWORD OS_AUTH_URL OS_REGION_NAME OS_NO_CACHE
OS_USERNAME is your mycloud login username (normally the primary user).
OS_TENANT_NAME is your Customer ID, it’s the number that appears in the URL of your control panel link, see below picture for illustration
OS_PASSWORD is a bit misleading, this is actually where your apikey goes , but I think it’s possible to authenticate using your control panel password too, don’t do that for security reasons.
OS_REGION_NAME is pretty self explanatory, this is simply the region that you would like to list cloud-server IP’s in or rather, the region that you wish to perform NOVA API calls.
Making the API call using the nova API wrapper
# supernova lon list --tenant 100010101 --fields accessIPv4,name [SUPERNOVA] Running nova against lon... +--------------------------------------+-----------------+-----------+ | ID | accessIPv4 | Name | +--------------------------------------+-----------------+-----------+ | 7e5a7f99-60ae-4c28-b2b8 | 1.1.1.1 | xapp | | 94747603-812d-4594-850b | 1.1.1.1 | rabbit2 | | d5b318aa-0fa2-4269-ae00 | 1.1.1.1 | elastic5 | | 6c1d8d33-ae5e-44be-b9f0 | 1.1.1.1 | | elastic6 | | 9f79a7dc-fd19-4f8f-9c26 |1.1.1.1 | | elastic3 | | 05b1c52b-6ced-4db0-8af2 | 11.1.1.1 | | elastic1 | | c8302366-f2f9-4c36-8f7a | 1.1.1.1 | | app5 | | b159cd07-8e68-49bc-83ee | 1.1.1.1 | | app6 | | f1f31eef-97c6-4c68-b01a | 1.1.1.1 | | ruby1 | | 64b7f0fd-8f2f-4d5f-8f89 | 1.1.1.1 | | build3 | | e320c051-b5cf-473a-9f96 | 1.1.1.1 | mysql2 | | 4fddd022-59a8-4502-bf6e | 1.1.1.1 | | mysql1 | | c9ad6951-f5f9-4351-b31d | 1.1.1.1 | | worker2 | +--------------------------------------+-----------------+-----------+
This is pretty useful for managing autoscale permissions if you need to make sure your corporate network can be connected to from your cloud-servers when new cloud-servers with new IP are built out. considerations like this are really important when putting together a solution. The nice thing is the tools are really quite simple and flexible. If I wanted I could have pulled out detail for servicenet instead. I hope this helps make some folks lives a bit easier and works to demystify API to others that haven’t had the opportunity to use it.
You are probably wondering though, what field names can I use? a nova show will reveal this against one of your server UUID’s
# supernova lon show someuuidgoeshere
+-------------------------------------+------------------------------------------------------------------+
| Property | Value |
+-------------------------------------+------------------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-SRV-ATTR:host | censored |
| OS-EXT-SRV-ATTR:hypervisor_hostname | censored |
| OS-EXT-SRV-ATTR:instance_name | instance-734834278-sdfdsfds- |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | - |
| OS-EXT-STS:vm_state | active |
| censorednet network | censored |
| accessIPv4 | censored |
| accessIPv6 | censored |
| created | 2015-12-11T14:12:08Z |
| flavor | 15 GB I/O v1 (io1-15) |
| hostId | 860... |
| id | 9f79a7dc-fd19-4f8f-9c26-72a335ed2be8 |
| image | Debian 8 (Jessie) (PVHVM) (cf16c435-7bed-4dc3-b76e-57b09987866d) |
| metadata | {"build_config": "", "rax_service_level_automation": "Complete"} |
| name | elastic3 |
| private network | |
| progress | 100 |
| public network | |
| status | ACTIVE |
| tenant_id | |
| updated | 2016-02-27T09:30:20Z |
| user_id | |
+-------------------------------------+------------------------------------------------------------------+
I censored some of the fields.. but you can see all of the column names, so if you wanted to see metadata and progress only, with the server uuid and server name.
nova list --fields name, metadata, progress
This could be pretty handy for detecting when a process has finished building, or detecting once automation has completed. The possibilities with API are quite endless. API is certainly the future, and, there is no reason why, in the future, people won't be building and deploying websites thru API only, and some sophisticated UI wrapper like NOVA.
Admittedly, this is very far away, but that should be what the future technology will be made of, stuff like LAMBDA, serverless architecture, will be the future.