Brightbox makes building cloud servers, load balancers, SQL instances and other infrastructure components really easy. The knife cuts both ways though and deleting them is easy too - perhaps a little too easy.
Our web-based Brightbox Manager has some user interface safeguards against accidental deletions, such as modal confirmation dialog boxes while our command line interface requires you to explicitly specify each resource identifier when deleting, which makes accidental deletions far less likely.
However, on an account with a high turnover of resources, especially when involving scripted systems interacting directly via our API, it’s difficult to mitigate the risk of accidental deletion.
To solve this, we’ve added the ability to lock resources to prevent deletion. Attempts to delete a resource that has been locked will be refused; whether the attempt is via the GUI, the CLI or our API. This gives you one consistent way to prevent accidental deletion.
To delete a locked resource, you first have to explicitly unlock it with another API call. A bit like a safety catch on a gun - a HTTP API controlled safety catch.
Resource locking is meant to protect against irreversible actions (currently just deletions). Locked resources can still be moved in and out of groups, have Cloud IPs mapped to and from them, have firewall policies applied to them etc. All those actions are reversible, so you don’t need as much protection from them :)
You can lock Cloud Servers, Server Images, Load Balancers, SQL Instances and SQL Snapshots.
The Brightbox CLI version 1.30 and above has the new lock and unlock commands, and the Brightbox Manager has those actions exposed in the action menus. The new additions to the API are covered in the API docs.
So, if you’re in the business of building systems worth protecting from deletion, then give Brightbox a try ;)
