Category Archives: supernova

Using Nova/Supernova to increase quota allotments in Openstack

Posted on by

I noticed there were some changes to the way we used openstack quotas today. So I had to do it the manual way! Please note that this can only be done thru the Admin API function, so if you are a Rackspace customer you would need to reach out to us to do this, unless you ran your own openstack or devstack implementation in-house.

Here is how I achieved it:

supernova {environment} {action} --option {number} {customer_ID}

supernova lon quota-update --instances 250 10010101

There is a lot of different commands available, use nova help to get more detail

 supernova lon help quota-update
[SUPERNOVA] Running nova against lon...
usage: nova quota-update [--user ] [--instances ]
                         [--cores ] [--ram ]
                         [--floating-ips ]
                         [--fixed-ips ]
                         [--metadata-items ]
                         [--injected-files ]
                         [--injected-file-content-bytes ]
                         [--injected-file-path-bytes ]
                         [--key-pairs ]
                         [--security-groups ]
                         [--security-group-rules ]
                         [--server-groups ]
                         [--server-group-members ]
                         [--force]
                         

Update the quotas for a tenant/user.

Positional arguments:
                     ID of tenant to set the quotas for.

Optional arguments:
  --user               ID of user to set the quotas for.
  --instances        New value for the "instances" quota.
  --cores                New value for the "cores" quota.
  --ram                    New value for the "ram" quota.
  --floating-ips 
                                New value for the "floating-ips" quota.
  --fixed-ips        New value for the "fixed-ips" quota.
  --metadata-items 
                                New value for the "metadata-items" quota.
  --injected-files 
                                New value for the "injected-files" quota.
  --injected-file-content-bytes 
                                New value for the "injected-file-content-
                                bytes" quota.
  --injected-file-path-bytes 
                                New value for the "injected-file-path-bytes"
                                quota.
  --key-pairs        New value for the "key-pairs" quota.
  --security-groups 
                                New value for the "security-groups" quota.
  --security-group-rules 
                                New value for the "security-group-rules"
                                quota.
  --server-groups 
                                New value for the "server-groups" quota.
  --server-group-members 
                                New value for the "server-group-members"
                                quota.
  --force                       Whether force update the quota even if the
                                already used and reserved exceeds the new
                                quota.

Resetting Rax_Service_Level_Automation metadata

Posted on by

This one is worth a mention because it causes some of our customers alarm. If your seeing this ‘warning’ in your Cloud-server control panel, don’t fret!

Building” “Server build complete. Installing & configuring software.

It’s just automation!

When you build a cloud-server and select the two tick boxes at the bottom of the build server page (scroll right down), this instructs rackspace automation to attempt to install the Rackspace monitoring & Rackspace Backup agent.

When the server finishes building, these are usually applied by the automation, but sometimes it may have an issue logging into the server and doesn’t run as expected.

Since this warning only indicates the monitoring and cloud backup auto-install failed, these can still be installed by yourselves manually at the below location (please note these links may become out of date use docs.rackspace.com and support.rackspace.com for more detail):

# Manually Install Monitoring (if required)
https://support.rackspace.com/how-to/install-and-configure-the-rackspace-monitoring-agent/

# Manually Install Cloud Backup (if required)
https://support.rackspace.com/how-to/rackspace-cloud-backup-install-the-agent-on-linux/

To summarise and clarify, the notification ‘”Server build complete. Installing & configuring software.’ indicates that your server environment built OK, and that the server is waiting for automation to install the additional 2 Rackspace products.

If you see this notification again, it is safe to ignore in terms of the functioning of the cloud-server, and is intended as a warning so you know Rackspace monitoring and cloud backup were not additionally installed by the automation. I have reset the state of your server and you can consider this situation resolved.

If this is causing you concern, it’s actually possible to correct this yourself by installing supernova and novaclient. Please take special care when using admin resources such as nova and API. It’d be difficult to break something if you don’t follow these instructions, but still…take care!

# Install using Python pip the supernova nova wrapper and the rackspace-novaclient
pip install supernova rackspace-novaclient
# Remove the 'rax_service_level_automation' metadata from this server
supernova customer meta serveruuidgoeshere delete rax_service_level_automation

Simples fix. Please note that you will need to configure supernova. This is explained in the supernova category of this blog, and also at:

 

https://developer.rackspace.com/blog/supernova-managing-openstack-environments-made-easy/
https://github.com/major/supernova
https://media.readthedocs.org/pdf/supernova/latest/supernova.pdf

Cheers &

Best wishes,
Adam

HOWTO: Rackspace Automation, Using BASH with API (to validate conditions to perform conditional tasks)

Posted on by

In the previous article, I showed how to wipe clean the windows password from a broken Virtual Machine that you were locked out of by rescuing with a Linux image. In this article I explain steps of how you would automate this with a bash script, that looked at the STATE of the server, and accepts commandline arguments.

It’s quite a simple script;

#!/bin/bash
# Adam Bull
# April 28 2016
# This script automates the resetting of windows passwords
# Arguments $1 == instanceuuid
# Arguments $2 == username
# Arguments $3 == apikey

PASSWORD=mypassword

# Provide an instance uuid to rescue and reset windows password

USERNAME=$1
APIKEY=$2
DDI=$3
INSTANCE=$4


nova  --os-username $USERNAME --os-auth-system=rackspace  --os-tenant-name $DDI --os-auth-url https://lon.identity.api.rackspacecloud.com/v2.0/ --os-password $APIKEY --insecure rescue --password mypassword --image 7fade26a-0cca-415f-a988-49c021768fca $INSTANCE

The above script takes the arguments I give the executable script on the commandline, in this case the first argument passed is $1, the Rackspace mycloud username. The second argument the apikey. etc. This basically puts the server into rescue. But.. what if we wanted to run some automation AFTER it rescued? We don’t want to try and let the automation ssh to the box and run the automation early, so we could use a supernova show to find whether the VM state has changed to ‘rescue’. Whilst its initiating the state will be rescuing. So we have the option of using when !rescueing logic, or, when == equal to rescue. Lets use when equal to rescue in our validation loop.

This loop will continue until the task state changes to the desired value. Here is how we achieve it

#!/bin/bash
# Initialize Variable
STATE=0
# Validate $STATE variable, looping UNTIL $STATE == rescued
until [[ $STATE == rescued ]]; do
echo "start rescue check"
# 'show' the servers data, and grep for rescued and extract only the correct value if it is found
STATE=`nova --os-username $USERNAME --os-auth-system=rackspace  --os-tenant-name $DDI --os-auth-url https://lon.identity.api.rackspacecloud.com/v2.0/ --os-password $APIKEY --insecure show $INSTANCE | grep rescued | awk '{print $4}'`

# For debugging
echo "STATE =" $STATE
echo "sleeping.."

# For API Limit control
sleep 5
# Exit the loop once until condition satisfied
done

# Post Rescue
echo "If you read this, it means that the program detected a rescued state"

It’s quite a simple script to use. We just provide the arguments $1, $2, $3 and $4. 

 
./rescue.sh mycloudusername mycloudapikey 10010101 e744af0f-6643-44f4-a63f-d99db1588c94

Where 10010101 is the tenant id and e744af0f-6643-44f4-a63f-d99db1588c94 is the UUID of your server.

It’s really quite simple to do! But this is not enough we want to go a step further. Let’s move the rescue.sh to /bin

# WARNING /bin is not a playground this is for demonstration purposes of how to 'install' bin system applications
cp rescue.sh /bin/rescue.sh

Now you can call the command ‘rescue’.

rescue mycloudusername mycloudapikey mycustomerid mycloudserveruuidgoeshere

nice, and quite simple too. Obviously ‘post rescue’ in the script I can upload a script via ssh to the server, and then execute it remotely to perform the password reset.

Resizing a Rackspace Performance Server

Posted on by

It’s possible for the customer to do this thru the API, but it is without express warantee. It’s not possible to resize performance servers thru the mycloud control panel, so, to do it you will need to use curl API, or what I like to use, supernova wrapper for nova or nova. It’s quite simple really;

The below example is how to resize a performance server to 4 gigs (this was from 2 gigs)

supernova customer resize --poll uuidgoeshere performance1-4

Booting an Image in specific cell/region

Posted on by

This particular oneliner uses NOVA API to boot an image with the id=9876fa2-99df-4be3-989f-eec1e8c08afd and the flavor=general purpose 4GB RAM and the hint ensures that the server reaches the correct cell and hypervisor host.

supernova customer boot --image 9876fa2-99df-4be3-989f-eec1e8c08afd --flavor general1-4 --hint target_cell='lon!z0001' --hint 0z0ne_target_host=c-10-0-12-119 myservername