-
Notifications
You must be signed in to change notification settings - Fork 14
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
base: master
Are you sure you want to change the base?
Allow overriding the uaa-cli config directory with an environment variable #40
Conversation
✅ Hey AP-Hunt! The commit authors and yourself have already signed the CLA. |
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.
d39a74d
to
199a2e3
Compare
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? |
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. |
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. |
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 I already have similar setup for the So VMware fellows, please consider this pull request, as it would positively impacts the productivity of real-life platform operators! Best, |
By default, uaa-cli config file will be stored in
$HOME/.uaa/config.json
, butif the environment variable
UAA_HOME
is set, then the config file will bestored 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.