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
Currently cm is designed around a single user.env configuration file that defines 1 ClusterPool host and the namespace on that host to use for ClusterClaims and ClusterPools.
Some users might want to use multiple ClusterPool hosts.
Option 1
Add a global option to specify the configuration file, for example:
cm -o demo.env list pools
Add a variable in the configuration file and parameterize the name of the context for the ClusterPool host, which is normally cm, so in demo.env the user would set up the existing variables plus one new one:
CLUSTERPOOL_CONTEXT=demo
Then a user would create an alias like:
alias cm:demo="cm -o demo.env"
Finally, the user can use cm:demo for interacting with clusters from their demo pool.
Option 2
If a user wanted to be able to interact with clusters across all their ClusterPool hosts with the same command, this would require a much larger redesign of the configuration file format to allow defining multiple ClusterPool hosts. Most commands would likely need updates to make them loop through all the defined ClusterPool hosts, which would hurt performance, but only for people using multiple ClusterPool hosts. Option 1 seems like a much simpler option, and probably the most value for effort, since I do not anticipate many users needing access to multiple ClusterPool hosts, but I may be mistaken.
The text was updated successfully, but these errors were encountered:
Currently
cm
is designed around a singleuser.env
configuration file that defines 1 ClusterPool host and the namespace on that host to use for ClusterClaims and ClusterPools.Some users might want to use multiple ClusterPool hosts.
Option 1
Add a global option to specify the configuration file, for example:
Add a variable in the configuration file and parameterize the name of the context for the ClusterPool host, which is normally
cm
, so indemo.env
the user would set up the existing variables plus one new one:Then a user would create an alias like:
Finally, the user can use
cm:demo
for interacting with clusters from their demo pool.Option 2
If a user wanted to be able to interact with clusters across all their ClusterPool hosts with the same command, this would require a much larger redesign of the configuration file format to allow defining multiple ClusterPool hosts. Most commands would likely need updates to make them loop through all the defined ClusterPool hosts, which would hurt performance, but only for people using multiple ClusterPool hosts. Option 1 seems like a much simpler option, and probably the most value for effort, since I do not anticipate many users needing access to multiple ClusterPool hosts, but I may be mistaken.
The text was updated successfully, but these errors were encountered: