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
Issue for discussion of what, if any, support and relationship rig should have with docker-machine active
docker-machine active reports which machine is active based on the DOCKER_HOST environmental variable setting.
rig config is used to set environmental variables, one of which is DOCKER_HOST
rig takes an argument, --name, which makes any commands apply to the named machine rather than the active one based on environmental variables. I've confirmed this is the case with the dns and dashboard commands.
I believe the questions to ask are:
Is there any utility in taking a machine name argument for any command other than rig config?
For commands where it doesn't make sense to use outside of the currently active machine, should they just determine the machine to use via the currently set variables (ie what docker-machine active reports)
Can that be overridden via --name? (does that allow for a use case we don't foresee)
Commands which seem like they may have utility outside of what the current active running machine:
start
status
config
remove
doctor
The text was updated successfully, but these errors were encountered:
kill, data-backup, and data-restore also seem like candidates. It may be easier for this discussion to identify which commands seem like they should automatically use the active machine. But before exploring that, do we only support a single machine? What if a developer wanted to use 2 VMs simultaneously?
Commands which fall into the "useful to lean on active, if there is only one machine":
dns
dns-records
dashboard
project
If we added a helper command such as rig ssh I could see that being on this list as well.
Good question on 2 VMs simultaneously. I don't think this change would preclude that. What it would prevent is someone to be interacting with two different VMs in the same terminal session alternating between one and the other without an intervening command.
If we remove the --name ability one would either:
Interact with two VMs in two different sessions with the desired VM active via the environment variable for that session.
Have to run an eval "$(rig --name DESIRED_VM config)" each time one wanted to switch
Based on the relationship rig config has with docker-machine env any command which doesn't require an actively running machine to operate is a candidate to still get benefit from the --name flag. Perhaps that is a line of distinction? Commands which require a successfully running machine to function should use the machine that docker-machine active reports and others use the --name flag.
I don't recall if there are commands where if the machine isn't running but needed to be we'd start it up automatically. If so, that might blur the proposed demarcation.
Issue for discussion of what, if any, support and relationship rig should have with
docker-machine active
docker-machine active
reports which machine is active based on the DOCKER_HOST environmental variable setting.rig config
is used to set environmental variables, one of which is DOCKER_HOSTrig
takes an argument, --name, which makes any commands apply to the named machine rather than the active one based on environmental variables. I've confirmed this is the case with the dns and dashboard commands.I believe the questions to ask are:
rig config
?docker-machine active
reports)Commands which seem like they may have utility outside of what the current active running machine:
The text was updated successfully, but these errors were encountered: