Vagrant: Feature Request: vagrant global-status format

[jchook]

Vagrant version

Vagrant 2.2.0

Hey so, vagrant global-status is fantastic and incredibly useful to other scripts.

Currently my scripts require grep '^[0-9a-f]' to access the VM lines.

Personally I think the column order, etc appears obvious and requires zero additional lines of output, such as the header and long explanation.

If we can't clean-up the default output, could we at least have some kind of argument like --interop or something that allows other programs or scripts to easily use/interpret the results of this command?

For example, say that vagrant global-status yields:

id       name    provider   state    directory                           
-------------------------------------------------------------------------
6f499e8  dev-vm  virtualbox running  /home/jchook/projects/by      
a5ff8a8  virtu   virtualbox poweroff /home/jchook/projects/virtu         
4bfd46f  default virtualbox poweroff /home/jchook/projects/rps           
456a9d0  default virtualbox poweroff /home/jchook/dev/wireguard          

The above shows information about all known Vagrant environments
on this machine. This data is cached and may not be completely
up-to-date (use "vagrant global-status --prune" to prune invalid
entries). To interact with any of the machines, you can go to that
directory and run Vagrant, or you can use the ID directly with
Vagrant commands from any directory. For example:
"vagrant destroy 1a2b3c4d"

Perhaps vagrant global-status --interop would return:

6f499e8  dev-vm  virtualbox running  /home/jchook/projects/by       
a5ff8a8  virtu   virtualbox poweroff /home/jchook/projects/virtu         
4bfd46f  default virtualbox poweroff /home/jchook/projects/rps           
456a9d0  default virtualbox poweroff /home/jchook/dev/wireguard          
 ```

For example, here is a script I use to quickly ssh into vagrant VMs without `cd`:

!/usr/bin/env bash

VAGPATHS=$(vagrant global-status | grep '^[0-9a-f]' | awk '{ print $5 }')
for dir in $VAGPATHS; do
base="$(basename $dir)"
if [ "$1" == "$base" ]; then
cd "$dir"
shift
vagrant "$@"
exit 0
fi
done
echo "Unable to find VM called $1 :("
exit 1
```

[paco3346]

You want the --machine-readable flag.

vagrant global-status
1546285649,,ui,info,id       
1546285649,,ui,info,name    
1546285649,,ui,info,provider   
1546285649,,ui,info,state   
1546285649,,ui,info,directory                                                        
1546285649,,ui,info,
1546285649,,ui,info,-----------------------------------------------------------------------------------------------------
1546285649,,ui,info,0f3346c  
1546285649,,ui,info,default 
1546285649,,ui,info,virtualbox 
1546285649,,ui,info,running 
1546285649,,ui,info,/home/johndoe/vagrant/test-box
1546285649,,ui,info,

The first set of rows defines columns. This allows for dynamic output if the format changes in the future.

[jchook]

Excellent thank you! I missed it in the docs.

[jchook]

Unfortunately I think the output still suffers from the basic problem:

• Includes headers
• Includes footer text for the user

In addition, the columnar data no longer appears in column format lol.

[GregJPreece]

I'd like to throw my hat into the ring on this one also. I've been writing a Phing wrapper for Vagrant and while the machine-readable flag is very useful, it's also a little inconsistent (as the docs admit). I'd like to suggest a reformatting of this command, as such:

1546285649,default,machine-id,0f3346c  
1546285649,default,provider-name,virtualbox 
1546285649,default,machine-home,/home/johndoe/vagrant/test-box
1546285649,default,state,running 
1546285649,default,state-human-short,running
1546285649,default,state-human-long,The VM is running. To stop this VM%!(VAGRANT_COMMA) you can run `vagrant halt` to\nshut it down forcefully%!(VAGRANT_COMMA) or you can run `vagrant suspend` to simply\nsuspend the virtual machine. In either case%!(VAGRANT_COMMA) to restart it again%!(VAGRANT_COMMA)\nsimply run `vagrant up`.

This would bring it in line with the rest of the CLI. For example, here's the output from a vagrant status --machine-readable run in one of my local environments:

1559059184,one,metadata,provider,virtualbox
1559059184,one,provider-name,virtualbox
1559059184,one,state,running
1559059184,one,state-human-short,running
1559059184,one,state-human-long,The VM is running. To stop this VM%!(VAGRANT_COMMA) you can run `vagrant halt` to\nshut it down forcefully%!(VAGRANT_COMMA) or you can run `vagrant suspend` to simply\nsuspend the virtual machine. In either case%!(VAGRANT_COMMA) to restart it again%!(VAGRANT_COMMA)\nsimply run `vagrant up`.
1559059185,,ui,info,Current machine states:\n\none                       running (virtualbox)\n\nThe VM is running. To stop this VM%!(VAGRANT_COMMA) you can run `vagrant halt` to\nshut it down forcefully%!(VAGRANT_COMMA) or you can run `vagrant suspend` to simply\nsuspend the virtual machine. In either case%!(VAGRANT_COMMA) to restart it again%!(VAGRANT_COMMA)\nsimply run `vagrant up`.

I am willing to undertake this work, if people think it appropriate. I have several other suggestions for consistency improvements in the machine-readable output, discovered while building my Phing wrapper. Would a Git issue be the best place to propose these also?

[GregJPreece]

OK, now I've looked through the code I know what's going on. The vagrant/ui/vagrant.rb library has several log types - "ui", "machine", etc. Most plugins log more than one type, but the global-status plugin logs only "ui" types.

When "ui" log types are outputted in machine-readable mode, they're escaped and smushed into a single "ui" type line, as in my previous example. That's what's we're getting from the global-status plugin.

Given that machine output types are ignored in anything other than machine-readable mode, I'm going to add some to global-status. Additionally, I don't think the "ui" lines are useful at all in machine-readable mode, so I'm going to propose we filter them out automatically. Wherever possible, nobody should be using them to do any kind of matching or parsing.

[GregJPreece]

@jchook My PR was accepted and merged to master yesterday. This ticket can probably be closed off.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.