Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow overriding the uaa-cli config directory with an environment variable #40

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

AP-Hunt
Copy link

@AP-Hunt AP-Hunt commented Aug 30, 2019

By default, uaa-cli config file will be stored in $HOME/.uaa/config.json, but
if the environment variable UAA_HOME is set, then the config file will be
stored there instead.

This allows for some flexibility in how users of the tool use it, in the same ways
that cf-cli does. For example, scoping the config of uaa-cli to the lifetime of a subshell. The linked example is using cf-cli, but I think it demonstrates the idea.

@cfdreddbot
Copy link

✅ Hey AP-Hunt! The commit authors and yourself have already signed the CLA.

@cf-gitbot
Copy link

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/168227802

The labels on this github issue will be updated when the story is started.

…iable

By default, uaa-cli config file will be stored in `$HOME/.uaa/config.json`, but
if the environment variable `UAA_HOME` is set, then the config file will be
stored there instead.

This allows for some flexibility in how users of the tool use it, in the same
ways that cf-cli does.
@AP-Hunt AP-Hunt force-pushed the allow_overriding_config_dir_with_env_var branch from d39a74d to 199a2e3 Compare August 30, 2019 19:18
@shamus
Copy link

shamus commented May 21, 2020

Hi there. Thanks for the PR & sorry for the slow response.

I'm unsure if this is a feature we'd want to incorporate in the CLI. I get the need, but we generally think of this cli more as a debugging tool rather than an administration tool.

I'll bring this up with the team. Could you tell me more about how you're using the CLI?

@AP-Hunt
Copy link
Author

AP-Hunt commented Jun 6, 2020

I'll bring this up with the team. Could you tell me more about how you're using the CLI?

Sure! I work with multiple CloudFoundry distributions and have occasions to use the UAA CLI for debugging as you describe. On those occasions, I might need to contact multiple UAA deployments within the lifetime of a single token.

When doing this with the CF CLI, I scope my CloudFoundry session to the lifetime of a subshell. This allows me to be confident in which foundry I'm talking to, and to know that once I exit the subshell I'll be unable to accidentally talk to that foundry (I can talk more about how if you'd like). It also has the added benefit of removing any highly privileged access tokens from my machine as soon as I'm finished with them.

My proposed change enables the same behavior with the UAA CLI, while maintaining the existing behavior.

@ssapra
Copy link

ssapra commented Nov 12, 2020

Our team at VMware is also using this CLI and we're facing an issue where 2 scripts are clobbering the same home directory. It would be great to have the ability to set different config directories.

@bgandon
Copy link

bgandon commented Dec 15, 2020

Hi folks,

Platform operators like me typically need to “debug” many UAAs for each CF foundation they operate: one for BOSH, one for Ops Manager, one for Cloud Foundry, one for Concourse, etc… And we usually operate many foundations for (P)CF customers!

In the typical pattern, we would create one folder per UAA, and we would set the UAA_HOME to $PWD in some .envrc Direnv config in each one of those. So we would end up with specific uaa CLI configs, one per UAA, and and when we would enter one of those folers we would automatically target the correct UAA.

I already have similar setup for the cf CLI with the CF_HOME being locally customized by Direnv.

So VMware fellows, please consider this pull request, as it would positively impacts the productivity of real-life platform operators!

Best,
Benjamin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Waiting for Changes | Open for Contribution
Development

Successfully merging this pull request may close these issues.

6 participants