vagrant service-manager should be runnable from any directory

[hferentschik]

Given that the CDK provides a general purpose dev environment for potentially multiple projects on the host system, the user should be able to run service-manager commands in any directory. Atm one can only run the commands in the directory containing the Vagrantfile. In this case no additional parameter is needed. In other directories the user will need to specify the box id as determines by vagrant global-status, eg vagrant service-manager env docker 32869cf.

Some of the built-in Vagrant commands already allow for passing of the id. Also when service-manager is called outside of the directory containing the Vagrantfile we currently get:

A Vagrant environment or target machine is required to run this
command. Run `vagrant init` to create a new Vagrant environment. Or,
get an ID of a target machine from `vagrant global-status` to run
this command on. A final option is to change to a directory with a
Vagrantfile and to try again. 

[navidshaikh]

+1

[navidshaikh]

In other directories the user will need to specify the box id as determines by vagrant global-status, eg vagrant service-manager env docker 32869cf.

About providing the machine-id, I think specifying the machine-id as last parameter to command might be confusing, for options like vagrant service-manager env docker --force-copy (for forced copy of the certs from box to host, TBD). I'll vote for having an option to each command as --machine-id=32869cf, if not given look for current working directory. @bexelbie thoughts?

[brgnepal]

+1 for --machine-id option as user will have clear understanding of it for "what to do with option?". Moreover, we can also document it well.

[brgnepal]

Based on my discussion with @hferentschik , we have come up with following ideas:

• When ADB vm starts, the service-manager hook get executes which writes some metadata into ~/.vagrant/data/service-manager folder. Metadata will be name of the box (eg adb/cdk) and the vagrant machine id. Vagrant allows to run commands outside the Vagrantfile directory but one need to specify the machine id.
• Optionally, we could have similar list as vagrant global-status --prune provides as $ vagrant service-manager list machines. It will list all ADB/CDK machines availables.
• On getting machine id, user will access plugin as:

$ vagrant service-manager env docker [--name <vm-name>]
$ vagrant service-manager box version [--name <vm-name>]

name can be provided by user in config. service-manager maps from name to Vagrant machine id. Without a name some sort of default is assumed, eg adb/cdk.

[bexelbie]

I think we need to decide if we want to do this the vagrant way, using the id in vagrant global-status and having it as a bare parm at the end of a command or if we want to do it in a more docker-machine way and use names and a vagrant service-manager list-machines command.

Making that choice is hard, and my gut feeling is that we should go for the vagrant way today unless we strongly believe we will be replacing vagrant as our underlying technology soon.

[hferentschik]

I think we need to decide if we want to do this the vagrant way, using the id in vagrant global-status and having it as a bare parm at the end of a command or if we want to do it in a more docker-machine way and use names and a vagrant service-manager list-machines command.

Just to be clear, under the hood we would use the Vagrant way using the Vagrant ids. I don't want to re-invent the wheel here. However, for a user of the ADB/CDK and the service-manager-plugin these ids are a bit unwieldy. How does the user find them in the first place and how does he remember them. Also the ids change on restarts, but the names would not.

So what I am proposing is that the service-manger keeps a mapping between the user facing names and the underlying Vagrant machine ids. Once a service-manager command is executed outside the scope of a Vagrantfile it does determine the right Vagrant machine id and transparently issues the right command using this id.

[bexelbie]

We can invent our own names and do a translation, however we will need to provide, at a minimum, a list-machines style command.

[hferentschik]

We can invent our own names and do a translation,

we are not inventing names. The user specifies them. If none is specified, we choose a default 'default-cdk/adb'. Same as docker-machine really.

however we will need to provide, at a minimum, a list-machines style command.

+1 sure, there would be a list machines command