'profile activate' and 'profile list' commands

[jrperritt]

No description provided.

[jrperritt]

for #386

[jrperritt]

$ ./rack profile list
[DEFAULT]
username = $USERNAME$
api-key = $APIKEY$
region = DFW
enabled = true

[ord]
username = $USERNAME$
api-key =  $APIKEY$
region = ORD

$ ./rack servers instance list --fields name
Name
pt-w2
pt-w5
pt-w4
pt-w2
tp-l

$ ./rack profile activate --name ord
Successfully activated profile [ord]

$ ./rack profile list
[DEFAULT]
username = $USERNAME$
api-key = $APIKEY$
region = DFW

[ord]
enabled = true
username = $USERNAME$
api-key =  $APIKEY$
region = ORD

$ ./rack servers instance list --fields name
Name
rack-upload-test
gophercloud-test-stack-2-hello_world-kfajpt7nztxa
gophercloud-test-stack-2-hello_world-e35hznbhw6js

$ ./rack servers instance list --fields name --region iad
Name
deconst-docs-staging-blue-001
deconst-docs-build-blue-001

[kenperkins]

My first reaction is we should really consider displaying the used profile in this context. I could see a number of cases where you forgot which profile was active and did "bad things".

i.e.

$ rack profile activate --name ord
Successfully activated profile [ord]

$ rack profile list
[DEFAULT]
username = $USERNAME$
api-key = $APIKEY$
region = DFW

[ord]
enabled = true
username = $USERNAME$
api-key =  $APIKEY$
region = ORD

$ rack servers instance list --fields name
Using Profile: ord
Name
rack-upload-test
gophercloud-test-stack-2-hello_world-kfajpt7nztxa
gophercloud-test-stack-2-hello_world-e35hznbhw6js

[jrperritt]

--log info will tell you where the values come from:

$ ./rack servers instance list --fields name --log info
INFO[0000] Global Options:
log: info (from command-line)
output: table (from default value)


INFO[0000] Authentication Credentials:
region: ORD (from config file (profile: ord))
auth-url: https://identity.api.rackspacecloud.com/v2.0/ (from default value)
...

Are you thinking that isn't enough? I'm hesitant to log things without getting the log flag because users not using the command-line to run rack will be getting information they didn't ask for (namely, other than the result of the command) and may not know how to parse it.

[kenperkins]

I think I'm ok with this as is. I've thought about it, and the risk of destructive mistakes is low as deleting a resource by id will fail on the wrong profile as the resources likely have a different ID.

[jrperritt]

deleting a resource by id will fail on the wrong profile as the resources likely have a different ID

True, but you're right about the possibility of confusing users. I'll add some verbiage to the command usage string about that.

[jrperritt]

I also added a rack profile deactivate command for deactivating any active profile.

[kenperkins]

What does that do for default?

[jrperritt]

No change. Default is always considered. If a profile is active, rack looks for config values in the following order:

1. command-line options
2. the active profile
3. the default profile
4. environment variables

[jrperritt]

Running rack profile deactivate just removes step 2 above

[jrperritt]

From the help output:

$ ./rack profile deactivate --help
...
DESCRIPTION: Deactivates all profiles. After running this command, only the default
        profile will be searched for configuration values, unless specified on the command-line
...

[jrperritt]

The most recent commit removes the profile deactivate command (I thought it was a bit too confusing).

In addition, it only lets users run the activate profile command if they've set an admin = true entry in their DEFAULT profile. This is mostly because, as was @kenperkins concern, I'd prefer not to give users the opportunity to accidentally do things. Also, most users likely won't use the activate profile command. Those who want to can edit their config file once, and then always have all the commands.

Does this sound reasonable @kenperkins ? If so, I'll add a section about it to the advanced configuration section of the docs.

Note: The admin-only functionality will exist for some features/commands that few users will need ( #371 ). I don't know if this is one of them, but I thought it could at least start out that way, and maybe change pending further interest.

[jrperritt]

The flag in the default profile for enabling profile activation has been changed from "admin" to "enable-profile-activate". For now, it must be added manually.

[rackernexus]

👀 Preview

[rackernexus]

🔎 Preview