[root@headnode (us-west-0) ~]# vmadm delete 0<TAB><ENTER>
Oh the tails of lost systems gone by. Don’t fret, though, because if you accidentally delete a crucial zone, so long as its not the sole datastore in use by Triton, that is manatee, you’ll be fine. Remember to keep backups!
Alright, so lets get to restoring whatever it is that’s been deleted. First, the Triton service api is still going to have record of whatever has been deleted, and that has to be deleted before we can redeploy it. Once you’ve logged into the headnode, test to make sure that that sapi is still accessible.
You should get a large JSON dump that lists admin network IP addresses, UUIDs, services, etc. Now check for the instance you just deleted:
# Replace $UUID with the UUID of the instance you deleted. sdc-sapi /instances/$UUID
If you get data back, it will be a short JSON blurb describing the information
about the instance that provides this service. If you get information back,
then you’ll have to delete it. If you don’t, you can skip right to redeploying
the instance using
# Replace $UUID with the UUID of the instance you deleted. sdc-sapi /instances/$UUID -X DELETE
Once you’ve deleted the erroneous service instance record, you can begin redeploying.
# Replace $service with whatever service you've accidentally deleted sdcadm post-setup $service -s headnode
The new service instance should setup. It will have a new IP address, but as
long as that isn’t an issue, you should be good. Otherwise, you’ll have to use
sdc-sapi to update the IP addresses of the service records, and
to update the actual nics themselves.