You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 20, 2024. It is now read-only.
when you run mixcoatl CLI command in the case where there are both no env variables for DCM_* and no existing config you get prompted to answer a number of questions for example:
(mixcoatl)➜ mixcoatl dcm-list-servers
No config file(s) found. Let us generate one now:
What API endpoint would you like to connect to (Example: http[s]://api.endpoint.domain/api/enstratus/<api version>)?
https://dcm.enstratius.com/api/enstratus/2015-08-03
What is the API Access Key?
<snip>
What is the API Secret Key?
<snip>
Would you like to disable SSL verification (Y/N)?
Y
What would you like to call this connection (No spaces allowed in name)?
saas
two identical config files are created one in ~/.mixcoatl/saas.config and ~/.mixcoatl/default . If the user comes back to edit the config they will tend to edit named config not realizing that the default file is what is read by the CLI. Thanks to @theburi for discovering this trap.
We either need to symlink the default to the named config file (which would change how this is implemented) or have the default just be a setting. We could also implement this with a proper python config parser where the single config file could contain multiple endpoint definitions. Some thought is needed.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
when you run mixcoatl CLI command in the case where there are both no env variables for
DCM_*
and no existing config you get prompted to answer a number of questions for example:two identical config files are created one in
~/.mixcoatl/saas.config
and~/.mixcoatl/default
. If the user comes back to edit the config they will tend to edit named config not realizing that the default file is what is read by the CLI. Thanks to @theburi for discovering this trap.We either need to symlink the default to the named config file (which would change how this is implemented) or have the default just be a setting. We could also implement this with a proper python config parser where the single config file could contain multiple endpoint definitions. Some thought is needed.
The text was updated successfully, but these errors were encountered: