search

hashicorp / vagrant

Vagrant is a tool for building and distributing development environments.
https://www.vagrantup.com
Other
26.17k stars 4.43k forks source link

Provide cli switch to disable different_target warning #9928

Open d1ss0nanz opened 6 years ago

d1ss0nanz commented 6 years ago

Vagrant version

2.1.1

Host operating system

Not relevant

Guest operating system

Not relevant

Vagrantfile

Not relevant

Debug output

No relevant

Expected behavior

There should be a config option or command line switch to disable the warning login_command.middleware.authentication.different_target and the related 5 second sleep.

Actual behavior

Prints the following text and sleeps 5 seconds:

Vagrant has detected a custom Vagrant server in use for downloading box files. An authentication token is currently set which will be added to the box request. If the custom Vagrant server should not be receiving the authentication token, please unset it.

Known Vagrant server: vagrantcloud.com Custom Vagrant server: otherserver.org

Press ctrl-c to cancel...

Steps to reproduce

export ATLAS_TOKEN and VAGRANT_SERVER_URL where VAGRANT_SERVER_URL != vagrantcloud.com run any vagrant command

References

None

chrisroberts commented 6 years ago

Hi there,

Thanks for reporting this issue, however this is the intended behavior. The warning output and the pause can be disabled by unsetting the token when a custom server URL is in use.

Cheers!

bombadil commented 6 years ago

Hi @chrisroberts,

I think @d1ss0nanz didn't outline the use case for this issue well enough. The use case for this option would be when using a local Vagrant server that requires authentication. One example is given in the Vagrant repository documentation of JFrog's Artifactory, which is available online here: https://www.jfrog.com/confluence/display/RTF/Vagrant+Repositories

Is there a better way than providing an ATLAS_TOKEN to authenticate access to a local Vagrant repository?

Cheers!

chrisroberts commented 6 years ago

Ah, thanks for providing a bit more context on this @bombadil! I still do not want to change the behavior that is currently defined. I think adding a new environment variable for holding a token value to be used when a custom server URL is in use would be the best solution here. Reopening this issue with that being the plan.

Thanks again!