knife rackspace server delete <server_name> fails

Details

  • Type: Improvement Improvement
  • Status: Reopened Reopened
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: rackspace-0.5.12
  • Fix Version/s: None
  • Component/s: knife-rackspace
  • Labels:
  • Environment:

    Mac OS X 10.7.3, Ubuntu 10.04.4, and fog 1.1.2

Description

This issue was brought up before in issue:

https://tickets.opscode.com/browse/CHEF-1811

but the reporter "Nathan L Smith" only wanted the documentation updated accordingly.

I actually think allowing the command to be able to delete a rackspace node based on <server name> would be helpful, so that we can run something like this:

#!/bin/sh

INST=$1

yes | knife rackspace server delete $INST
yes | knife node delete $INST
yes | knife client delete $INST

where we are passing the <server name> to this script. This is of course after using -N <server name> and -S <server name> when creating the instance.

But come to think of it, it would be even better if the knife command had an option to delete the node and client on its own.

I know that the Edmund's Knife-Cloudstack gem attempts to do that, even though it does have bugs.

It would be great if one command (knife rackspace server delete ...) could do all the "deleting" since one command (knife rackspace server create ...) does all the creating.

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. CHEF-1811 knife rackspace server delete <server_name> fails

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Nathaniel R. Ben-Attar added a comment -

I advise against this. Rackspace does not require that a server name be unique. The truly unique identifier should be the Instance ID. If this is instituted, I recommend a check to see if the Name is unique amongst instances and if not, prompt the user for the Instance ID. Or just KISS and use the Instance ID like we have all been doing thus far.

Show
Nathaniel R. Ben-Attar added a comment - I advise against this. Rackspace does not require that a server name be unique. The truly unique identifier should be the Instance ID. If this is instituted, I recommend a check to see if the Name is unique amongst instances and if not, prompt the user for the Instance ID. Or just KISS and use the Instance ID like we have all been doing thus far.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

btw, knife has a '-y' option, which can be used instead of 'yes | knife'

Show
Bryan McLellan [Opscode] added a comment - btw, knife has a '-y' option, which can be used instead of 'yes | knife'
Hide
Permalink
Julian C. Dunn [Opscode] added a comment -

I'm going to suggest that this be closed as WONTFIX, for the following reasons:

  • Contrary to the subject line, this does work if you specify the instance ID of the machine, which is the only globally unique identifier. I believe this is the intended behavior.
  • The node and client objects can be delete from the Chef Server by specifying --purge to the "knife rackspace server delete" command.

Thoughts, Matt Ray?

Show
Julian C. Dunn [Opscode] added a comment - I'm going to suggest that this be closed as WONTFIX, for the following reasons: Contrary to the subject line, this does work if you specify the instance ID of the machine, which is the only globally unique identifier. I believe this is the intended behavior. The node and client objects can be delete from the Chef Server by specifying --purge to the "knife rackspace server delete" command. Thoughts, Matt Ray ?
Hide
Permalink
Matt Ray added a comment -

We're closing this because rackspace server delete works with the rackspace ID, but not the name.

Show
Matt Ray added a comment - We're closing this because rackspace server delete works with the rackspace ID, but not the name.
Hide
Permalink
Matt Ray added a comment -

We'll leave it open to discuss with the knife-cloud refactoring. Checking for the name as non-unique might be acceptable.

Show
Matt Ray added a comment - We'll leave it open to discuss with the knife-cloud refactoring. Checking for the name as non-unique might be acceptable.

People

  • Assignee:
    Unassigned
    Reporter:
    Damian Fuentes
Vote (0)
Watch (3)

Dates

  • Created:
    Updated: