Respect Existing Docker Config Location #218

chucknelson · 2020-04-07T14:57:17Z

When setting the docker proxy config, the plugin seems to force a docker config location of /etc/docker, even changing it to that if it's already configured to some other location.

Not sure if there are any other impacts, but would it be possible to look for an existing setting per DOCKER_CONFIG before defaulting to /etc/docker?

The text was updated successfully, but these errors were encountered:

adespain · 2020-04-09T20:11:09Z

This may solve my issue as well:
#219

chucknelson · 2020-04-17T20:17:58Z

@tmatilai, @codylane - Would you guys accept a PR for this? Not sure if what seems like an issue is actually done for a reason.

codylane · 2020-04-17T20:33:07Z

Hi @chucknelson and @adespain,

Thank you for reporting this issue.

I do think this would be worth while to expose a config variable that passes through the vagrantproxy plugin as you suggest and I believe that is supported by docker itself. That I do think is worth while, but the one thing I'm having a hard time trying to grasp is the need to change the standard config? I think it might help if I had some examples to support reasons to add this behavior.

I don't think this feature would be a lot of work to implement. The only problem we would have is permissions since there could be sensitive info in the config.json and the docker daemon may enforce special permissions when reading configs. However, at the moment, I don't know if that is the case.

codylane · 2020-04-17T20:49:57Z

Also, the link provided that references DOCKER_CONFIG

per DOCKER_CONFIG befor

Is for the docker client not the docker daemon. Which is the reason I would like to see some examples for changing the default daemon config from /etc/docker/config.json

chucknelson · 2020-04-19T01:36:10Z

Thanks @codylane.

Sorry for any confusion, but I think the client config is what this issue and #219 are referencing.

It looks like the client DOCKER_CONFIG value is changed to /etc/docker regardless of any existing value that may have been there. I only noticed this when I set it explicitly to another path in my VM home directory, but it was mysteriously changing back to /etc/docker on vagrant up.

Maybe I'm still confusing the various config settings or something?

codylane · 2020-04-19T20:50:21Z

Gotcha, no worries and honestly I think this confusion is all faults of my own. I haven't touched this code in a while so I think I might see what the problem is now.

However, before I make a speculation of what I think the fix might be. I'm wondering if you can put together a small gist, or screen shot (copy and paste is fine) of ways I can try to reproduce this on my own. I think I might still be a little confused.

If you could please provide the following:

A copy of your Vagrantfile and your provisioning script.
The output of the following command vagrant plugin list
The put of the following command vagrant --version
The output of the first time run when. I.E. (vagrant destroy -f && vagrant up)
An example of your custom ~/.docker/config.json and what should be in there before you run vagrant provision

I assume this is happening when you have modified or created your own ~/.docker/config.json and after you have run vagrant provision our plugin is forcing the client to read values from /etc/docker/config.json instead of merging your defaults with /etc/docker/config.json?

Please provide what the desired state should be in this case including files and their contents as well as permissions.

I'm hoping once I have this information I'll be able to reproduce this on my own without trying to make a bunch of guesses.

I realize that what I've asked for might be very time consuming but I do appreciate your time and I know others will too if we can find a solution to this problem. Thanks again for reporting and I do look forward to hearing back from you with the information I've requested.

samdbmg · 2020-04-24T17:41:06Z

I'm affected by this too, so I put together an example as requested. See https://gist.github.com/samdbmg/8b1ed08dd1d81882c12b0c7df50414dc for the Vagrantfile and config files (obviously I've redacted the username and password, although it's username:password base64 encoded)

Software Versions

samn@RD011386$ vagrant --version
Vagrant 2.2.7
samn@RD011386$ vagrant plugin list
vagrant-proxyconf (2.0.7, global)
vagrant-vbguest (0.23.0, global)
samn@RD011386$ VBoxManage --version
6.0.14r133895

Behaviour in Vagrant box

vagrant@vagrant:~$ docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: ^C
vagrant@vagrant:~$ env | grep DOCKER
DOCKER_CONFIG=/etc/docker
vagrant@vagrant:~$ # That's not what I wanted, lets try and fix it
vagrant@vagrant:~$ unset DOCKER_CONFIG
vagrant@vagrant:~$ docker login
Authenticating with existing credentials...
WARNING! Your password will be stored unencrypted in /home/vagrant/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
vagrant@vagrant:~$ # That's better

My use case is using Vagrant in CI behind a proxy, where we need to log into the Docker registry. Jenkins creates a temporary config.json file with credentials which we mount at /home/vagrant/.docker/config.json, so merging the user's config.json with proxy options would work I think.

chucknelson · 2020-04-24T20:13:36Z

Thanks @samdbmg - thorough example and the scenario of using the default Docker client config location (as opposed to having a set DOCKER_CONFIG) is nice and straightforward.

codylane · 2020-04-24T21:09:47Z

Thank you all for the very detailed information. This helps me better understand what I need to do to replicate it on my own, re-read the docs and come up with something. I really appreciate the time spent here and for these really helpful responses. Let's make this thing better together!

Anyway, I plan to look at this over the weekend if I have some free time and I hope to respond before Monday with a solution.

Thanks again!

codylane · 2020-04-25T02:32:35Z

https://elegantinfrastructure.com/docker/ultimate-guide-to-docker-http-proxy-configuration/

Really nice explanation of how docker client vs docker daemon works. As promised I'll spend some more time getting more intimate with the docs to see what I need to fix. Hang tight folks.

codylane · 2020-04-26T02:09:15Z

OK, so I have a feeling I added the DOCKER_CONFIG=/etc/docker when I was doing the initial refactor sometime last year. When I was doing this, I thought after reading the documentation that all I needed to do was set the proxy config inside the *clients configuration and therefore I hard coded it to /etc/docker/config.json for a security reason to lock it down and keep normal users from modifying it, (also that is the default location).

That said, I don't think the client even cares about the proxy configuration and should instead make only REST API calls to the daemon, which as of the latest release, the daemon is configured to use the proxy.

So that all out of the way I think this is what I need to do to fix the problem. Again, I appreciate your help here providing all the examples and helpful explanations of the situation.

Test Scenario

Create a test CI test environment using a client, server environment. There will be two hosts, one is a vagrant box configured as a docker host and all docker stuff will be performed on this host. The second, is a transparent proxy that I use when testing other features of this plugin so I'll just reuse that box.
I'll remove the docker_client_config sections from https://github.com/tmatilai/vagrant-proxyconf/blob/master/lib/vagrant-proxyconf/action/configure_docker_proxy.rb#L60-L91
I'll run some example tests, then i'll create some unit tests to mimic this behavior and ensure that nothing else regresses.
I'll rinse and repeat until I can get things working again and I'll report my status and I hope that one of you will be able to test this configuration on your machines before I release it as an official bug fix.

samdbmg · 2020-04-26T17:26:18Z

Having poked around the documentation a bit more, I think the time when the proxy config matters to the client is when building/running a container that wants to access the Internet over a proxy; in my case that might be running apt install inside a container inside a Vagrant box on the corporate network. In that case, setting the proxy on the client means the http_proxy and https_proxy variables are automatically set when containers are run, so attempts to reach the Internet "just work"

To summarise my understanding:

The daemon needs proxy config so that it can pull images from places like https://index.docker.io when behind a proxy. You configure this with a systemd dropin, as in https://docs.docker.com/config/daemon/systemd/#httphttps-proxy
The client needs proxy config so that the proxy environment variables are set when launching containers, which allows the containers access to the Internet. You configure that with config.json, as in https://docs.docker.com/network/proxy/#configure-the-docker-client

Which makes this a tad harder to solve, as I think you have to write a proxies block in config.json when behind a proxy but remove it when not. Interestingly a quick experiment shows that on my Mac you don't have to configure any client proxy settings and no env vars get set in the container, it just works by some network magic in Docker for Mac. However on my Ubuntu desktop you do need both the systemd dropin and a config.json.

I'm very happy to test a fix when you've got one and thank you, this plugin is a lifesaver in avoiding a huge tangled mess of scripting in annoying corporate proxy environments

codylane · 2020-04-27T21:34:43Z

Thanks @samdbmg, I'll take the information you provided into account as well as I'm going through my testing and refactoring. Thank you so much for taking the time to provide validation that this isn't an easy or straight forward fix.

FWIW - I've spent a few hours today trying to get my test environment working again due to upstream bugs preventing me from running my tests on actual VMs. I believe I have a work around in place that is working nicely for now. Once Vagrant releases 2.2.8 (crossing fingers) this bug goes away and I we can get back to normal.

Here is the link to the upstream bug that I'm tracking: #209 that is causing me the headache since vagrant 2.2.5 was released.

codylane · 2020-04-29T00:16:21Z

Ok, tests are passing as well as my integration tests.

Test Scenarios:

This was tested on the 2.2.0.5 docker desktop for Mac + Virtualbox and it passed.
This was tested on a Debian Stretch + VirtualBox with docker version 19.03.8 and it also passed.

All tests scenarios were performed on the docker host, where the docker client also resides and talks directly to docker via /var/run/docker.sock.

The feature basically just comments out the docker_client config entirely from vagrant-proxyconf so that it is not longer managed by this plugin and no longer hard codes anything to /etc/docker/config.json. The daemon is still configured via systemd to work behind a proxy and since the client just makes REST calls to the daemon, everything just works at least on my two systems.

I'd love to have a few of you guys check out this commit and test this on your machines and make sure it works. If you need help figuring out how to bootstrap your environment just let me know.

samdbmg · 2020-05-01T17:09:09Z

I've tested this, and I think it fixes one problem but creates a new gotcha. Docker can pull container images through the proxy because the systemd dropin is there, but because the proxies are no longer set in the client config, their environment variables aren't set inside the container so stuff like apt update doesn't work.

I've used the same Vagrantfile as before, this time on my Ubuntu 16.04 desktop which can only access the Internet through a proxy:

vagrant@vagrant:~$ env | grep DOCKER_CONFIG
vagrant@vagrant:~$ docker login
Authenticating with existing credentials...
WARNING! Your password will be stored unencrypted in /home/vagrant/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
vagrant@vagrant:~$ # Yay! Let's try running a container
vagrant@vagrant:~$ docker run -ti ubuntu:18.04
Unable to find image 'ubuntu:18.04' locally
18.04: Pulling from library/ubuntu
23884877105a: Pull complete
bc38caa0f5b9: Pull complete
2910811b6c42: Pull complete
36505266dcc6: Pull complete
Digest: sha256:3235326357dfb65f1781dbc4df3b834546d8bf914e82cce58e6e6b676e23ce8f
Status: Downloaded newer image for ubuntu:18.04
root@45aa068200be:/# apt update
Err:1 http://archive.ubuntu.com/ubuntu bionic InRelease
  Could not connect to archive.ubuntu.com:80 (91.189.88.142), connection timed out Could not connect to archive.ubuntu.com:80 (91.189.88.152), connection timed out
Err:2 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
  Unable to connect to archive.ubuntu.com:http:
<snip>
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease  Could not connect to security.ubuntu.com:80 (91.189.91.39), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.152), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.38), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.142), connection timed out
W: Some index files failed to download. They have been ignored, or old ones used instead.
root@45aa068200be:/# # Ugh. Is that proxies?
root@45aa068200be:/# env | grep proxy
root@45aa068200be:/# export http_proxy=http://www-cache.rd.bbc.co.uk:8080
root@45aa068200be:/# export https_proxy=http://www-cache.rd.bbc.co.uk:8080
root@45aa068200be:/# apt update
Get:1 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
Get:2 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
<snip>
Get:17 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 Packages [8158 B]
Get:18 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages [8286 B]
Fetched 17.9 MB in 2s (9685 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
root@45aa068200be:/#

There's an argument that if you supply your own config.json then that's your problem, although I think before you merged proxy settings into any existing file at /etc/docker/config.json instead of overwriting?

Could the same approach be used, but instead of /etc/docker/config.json make the file configurable, with a default of /home/vagrant/.docker/config.json?

codylane · 2020-05-01T18:17:07Z

@samdbmg - Dude you rock, thanks man! I appreciate your time helping me better understand some of these use cases that I didn't test for yet. This kind of detail helps me out so much!

Solution 1

Indeed, I honestly was thinking about this a couple days ago of just adding a new config variable here and it would be named VAGRANT_DOCKER_DOCKER_CONFIG that defaults to /home/vagrant/.docker/config.json and that variable would be configurable inside the Vagrantfile.

I think that could be a good approach to start out with for sure.

Potential Solution 2 (more complex)

Perhaps we could also have a hierarchy of configuration locations that the config.json file will look for and merge all the matching configs into one file that matches the location of VAGRANT_DOCKER_DOCKER_CONFIG. I don't think we need to get crazy here but perhaps we could set the hierarchy to an array like so

[
  "/etc/docker/config.json",
  "/home/vagrant/.docker/config.json",
]

This could also be a configurable option inside the Vagrantfile with the defaults above.

If the user supplies their own array of paths to look for then the defaults

[
  "/etc/docker/config.json",
  "/home/vagrant/.docker/config.json",
]

will not be merged and the user will be in full control of their destiny. Of course they could also just append to the array as well.

Let me know your thoughts and i'll get started hacking away.

chucknelson · 2020-05-01T18:58:25Z

Along with @codylane, yes, thanks so much @samdbmg for all of this detail - sorry I just created the issue and then proceed to not help much 🙁

@codylane - Instead of worrying about a whole variety of possible config locations, we can just follow the way Docker works, right?

Look in DOCKER_CONFIG if defined.
Otherwise use the docker default of $HOME/.docker.

Whatever path is used, take whatever config.json is there and merge in the proxy settings.

Is there something I'm not considering?

codylane · 2020-05-01T21:29:20Z

No problem @chucknelson. Thanks for your response and the details.

Just confirming this is what the new feature would look like and how it would be configured.

Feature

Expose a new environment variable VAGRANT_DOCKER_DOCKER_CONFIG that defaults to /home/vagrant/.docker/config.json. If the user wants to override this variable they define a different path and add this variable inside the proper scope of their Vagrantfile.

Example `Vagrantfile`

Vagrant.configure("2") do |config|

  config.vm.define 'default' do |c|
    c.vm.box = nil

    if Vagrant.has_plugin?('vagrant-proxyconf')
      c.proxy.enabled = false
    end

    c.vm.provider "docker" do |d|
      d.build_dir = "."
      d.expose = ['8888']
      d.has_ssh = true
      d.ports = ['8888:8888']
    end
  end

  config.vm.define 'docker_host' do |c|
    c.vm.box = "centos/7"
    c.vm.box_check_update = false

    if Vagrant.has_plugin?('vagrant-proxyconf')
      c.proxy.http     = ENV['HTTP_PROXY']
      c.proxy.https    = ENV['HTTPS_PROXY']
      c.proxy.no_proxy = ENV['NO_PROXY']
      c.docker_proxy.docker_config = "/my/special/foobar/config.json"
    end

    c.vm.provision "docker"
  end

end

OR perhaps the ENV var approach with a different default which would first look for the environment variable VAGRANT_DOCKER_DOCKER_CONFIG and if defined it would pass this through to vagrant-proxyconf otherwise, if VAGRANT_DOCKER_DOCKER_CONFIG is not defiend the default location for vagrant-proxyconf would look in /some/path/to-app/config.json

ENV['VAGRANT_DOCKER_DOCKER_CONFIG'] = ENV.fetch('VAGRANT_DOCKER_DOCKER_CONFIG', "/some/path/to-app/config.json")

Vagrant.configure("2") do |config|

  config.vm.define 'default' do |c|
    c.vm.box = nil

    if Vagrant.has_plugin?('vagrant-proxyconf')
      c.proxy.enabled = false
    end

    c.vm.provider "docker" do |d|
      d.build_dir = "."
      d.expose = ['8888']
      d.has_ssh = true
      d.ports = ['8888:8888']
    end
  end

  config.vm.define 'docker_host' do |c|
    c.vm.box = "centos/7"
    c.vm.box_check_update = false

    if Vagrant.has_plugin?('vagrant-proxyconf')
      c.proxy.http     = ENV['HTTP_PROXY']
      c.proxy.https    = ENV['HTTPS_PROXY']
      c.proxy.no_proxy = ENV['NO_PROXY']
    end

    c.vm.provision "docker"
  end

end

Before I start implementing this change I'd like to get a at least 2 out of 3 thumbs ups since 3 people have reported this issue.

codylane · 2020-05-03T03:20:38Z

+1 from me. @chucknelson? Thoughts?

Also, thanks for your patients folks. I promise to get this in quickly.

chucknelson · 2020-05-04T15:24:45Z

@codylane - Sure, +1 from me, let's try it.

I'm still a little confused why we need a separate environment variable and/or setting instead of just relying on whatever the guest machine has set for DOCKER_CONFIG, but I think I might just have tunnel vision with my usage of Vagrant! :)

codylane · 2020-05-04T17:50:55Z

Thanks folks, I'll get started on this today.

@chucknelson - That is a good point, I don't want to increase complexity either and introduce performance limitations. I have a hunch that it may take longer to configure the plugin if we first have to detect if DOCKER_CONFIG is set (and if not, we would have to set the state somewhere perhaps to /home/vagrant/.docker/config.json), and there may not be an easy to way to check for the existenance of this variable since a tty may not be allocated when we are talking with the VM through the provisioner.

I'll certainly give it a shot though and see what is the easiest to do and not break something else or create a performance degradation.

It might take me a few days to test out these idea(s).

codylane · 2020-05-05T13:43:38Z

FYI - Vagrant 2.2.8 was released which finally gives me the ability to integration tests again. We were unable to reliably test vagrant versions 2.2.5 - 2.2.7 without patching parts of vagrant. Yeehaw we are back to normal again.

I'll be writing this new feature against vagrant 2.2.8.

codylane · 2020-05-05T17:40:54Z

Linking new bug report found on Vagrant 2.2.8. hashicorp/vagrant#11580

codylane · 2020-05-06T21:47:45Z

The vagrant bug has been patched in master, but I still need to work around it until it is officially in a release. That said, it's not holding me up so I've just begun testing this new feature again.

I hope to have this done before the end of the week.

codylane · 2020-05-08T00:40:52Z

Heck yeah, hashicorp just released Vagrant 2.2.9 with the fix we put in. That is good news folks. I'll bump our tests to use 2.2.9 and cross fingers we are back to normal testing without additional patching.

I'll provide a status tomorrow. Again, I appreciate your patience while this is sorted out.

codylane · 2020-05-09T18:36:46Z

Howdy!

I've been testing what would be the quickest MVP (with tests) to fix this small bug with the proposed new feature. Additionally this new feature will also try to auto detect if DOCKER_CONFIG is set for the vagrant user when the plugin is provisioning the VM via this plugin. That auto detect logic isn't perfect but it should work and give you the ability to use what is set in the VM. You can override this location as well in your Vagrantfile. I plan to also update the documentation with this new feature and I'll try to provide some different examples when this is more official. I just wanted to first call out this new/additional feature that will go into 2.0.8

However..... with this great news that things are working we have some downsides:

While testing, I confirmed that we have some missing test coverage for how variables are set in the Vagrantfile and the docker_proxy provisioner. While I have we have a working example, I'm not comfortable releasing this without additional tests to ensure I don't break the plugin in a different way.

Please bare with me a few more days until I have time to sort this out.

codylane · 2020-05-12T21:16:55Z

Just providing a quick status update as it's been a few days.....

I'm still ironing out testing problems and ensuring we have proper test coverage as needed. I've had to end up refactoring a large portion of our test suite and I'm hoping all this work will create a more reliable and dependepadle release.

What's left you might ask?

[In Progress] - I'm cleaning up and refactoring the unit tests for latest feature mentioned above.
- I need to update the documentation for the new feature.
- I need to make sure all our unit tests run in travis
- I need to update the Gemfile to use vagrant 2.2.9
- I need to update our base ruby to 2.6.6. as that is what vagrant 2.2.9 uses and clean up anything that falls out from this upgrade.

I'll create a new task board and link it to this thread so that's easier to see whats going on.

FYI - This is my full time job until it's sorted out. Again, I appreciate your time and patience.

codylane · 2020-05-17T23:08:46Z

Adding additional tasks to feature board:

- Needed to refactor some tests in pear_proxy, git_proxy as they were causing some weird test behaviors and failing only sometimes. This needs to be more reliable and considerable amount of time and troubleshooting maybe needed to resolve this issue as it will be difficult to fix.
[IN PROGRESS] - The docker_proxy tests were hard to follow and because we really are only testing code path behavior via unit tests, we end up needing to mock quite a few things in order for our tests to to follow the correct code paths. This needs to be refactored, rethought and cleaned up if others are going to contribute to this plugin down the road. All this said, there are a lot of code smells that I created and I plan to fix and refactor and hope to make it more manageable. This will also be difficult and time consuming to fix.

2020-05-22 - Quick update. Continued efforts to refactor broken/missing tests is still in progress and getting cleaned up nicely. Finally, a way to do some shared resources in tests and still have clarity (Crossing fingers) when reading and writing new tests. I am also going through each of the tests and ensuring we are testing for the right things and right outcomes. Once the unit tests are completed, I'll move onto the integration tests. It's hard at this point to say how much is left but I'm making good progress. If I had to guess it will be another week or so.

2020-05-27 - UPDATE

Still refactoring the test suit for the docker proxy. I've added some ~56+ new tests to cover missing test coverage. I've also started prepping some integration tests and the code is working nicely, but I'm still missing some tests to verify the code paths are still the same and did not introduce a regression. I've largely refactored the core and base library at this point and I'm just ensuring that the code still works the same as it did. Hopefully, this refactor will make it a lot easier for us to add new integrations down the road.
Also, I'm doing all this refactor in my personal home git repo which is the reason why you are not seeing any of the new code yet. I hope to get this on github in the next week or so.

Hang tight folks, good things to come for sure.

2020-06-03 - UPDATE

Needed to take care of some house projects the last week and needed to take a break away from this refactor. That said, I'm energized to start back up tomorrow and hopefully finalize some of the remaining unit tests and I'm finally starting to see the light from this refactored effort. It's still hard to quantify the time it will take to get this released but as promised, I'll continue updates once or twice a week as I have them but for sure at least once a week.

chucknelson · 2020-06-04T19:27:52Z

@codylane - Not exactly related to this issue, but related to the latest Vagrant versions 2.2.8 and 2.2.9 that were apparently causing problems for you earlier in this issue. They both have some erratic behavior that often causes my VMs to abandon creation and/or startup during the Docker proxy action.

Do you know if any of the changes made in Vagrant 2.2.8 would cause some issue during the Docker proxy step and cause Vagrant to panic and just destroy the VM?

Example stack trace:

...
==> default: Running provisioner: bashrc_custom (file)...
    default: resources/.bashrc_custom => ./.bashrc_custom_template
==> default: Configuring proxy for Docker...
==> default: Configuring proxy for Git...
==> default: Configuring proxy for npm...
==> default: Running provisioner: config_bash_preferences (shell)...
    default: Running: inline script
==> default: Configuring proxy for Docker...
==> default: Forcing shutdown of VM...
==> default: Destroying VM and associated drives...
Traceback (most recent call last):
        122: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/batch_action.rb:86:in `block (2 levels) in run'
        121: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/machine.rb:198:in `action'
        120: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/machine.rb:198:in `call'
        119: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/environment.rb:613:in `lock'
        118: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/machine.rb:212:in `block in action'
        117: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/machine.rb:240:in `action_raw'
        116: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `run'
        115: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/util/busy.rb:19:in `busy'
        114: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `block in run'
        113: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builder.rb:116:in `call'
        112: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
        111: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/check_virtualbox.rb:26:in `call'
        110: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
        109: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/call.rb:53:in `call'
        108: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `run'
        107: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/util/busy.rb:19:in `busy'
        106: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `block in run'
        105: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builder.rb:116:in `call'
        104: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
        103: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:107:in `block in finalize_action'
        102: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
        101: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
        100: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         99: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:107:in `block in finalize_action'
         98: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         97: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
         96: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         95: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/call.rb:53:in `call'
         94: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `run'
         93: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/util/busy.rb:19:in `busy'
         92: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `block in run'
         91: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builder.rb:116:in `call'
         90: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         89: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:107:in `block in finalize_action'
         88: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         87: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
         86: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         85: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/customize.rb:40:in `call'
         84: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         83: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/prepare_clone.rb:15:in `call'
         82: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         81: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/prepare_clone_snapshot.rb:17:in `call'
         80: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         79: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/import.rb:13:in `call'
         78: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/import.rb:78:in `import'
         77: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         76: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/discard_state.rb:15:in `call'
         75: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         74: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/match_mac_address.rb:22:in `call'
         73: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         72: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:107:in `block in finalize_action'
         71: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         70: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/check_virtualbox.rb:26:in `call'
         69: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         68: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
         67: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         66: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/box_check_outdated.rb:92:in `call'
         65: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         64: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/call.rb:53:in `call'
         63: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `run'
         62: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/util/busy.rb:19:in `busy'
         61: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `block in run'
         60: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builder.rb:116:in `call'
         59: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         58: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:107:in `block in finalize_action'
         57: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         56: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/call.rb:53:in `call'
         55: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `run'
         54: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/util/busy.rb:19:in `busy'
         53: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `block in run'
         52: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builder.rb:116:in `call'
         51: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         50: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:107:in `block in finalize_action'
         49: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         48: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/call.rb:53:in `call'
         47: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `run'
         46: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/util/busy.rb:19:in `busy'
         45: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `block in run'
         44: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builder.rb:116:in `call'
         43: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         42: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:107:in `block in finalize_action'
         41: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         40: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
         39: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         38: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/clean_machine_folder.rb:26:in `call'
         37: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         36: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/set_name.rb:50:in `call'
         35: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         34: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/providers/virtualbox/action/clear_forwarded_ports.rb:15:in `call'
         33: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         32: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/provision.rb:103:in `call'
         31: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/provision.rb:103:in `each'
         30: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/provision.rb:126:in `block in call'
         29: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/provision.rb:126:in `call'
         28: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/environment.rb:525:in `hook'
         27: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `run'
         26: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/util/busy.rb:19:in `busy'
         25: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `block in run'
         24: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builder.rb:116:in `call'
         23: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         22: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:108:in `block in finalize_action'
         21: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         20: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builtin/call.rb:53:in `call'
         19: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `run'
         18: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/util/busy.rb:19:in `busy'
         17: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/runner.rb:89:in `block in run'
         16: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/builder.rb:116:in `call'
         15: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         14: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:107:in `block in finalize_action'
         13: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/lib/vagrant/action/warden.rb:48:in `call'
         12: from C:/Users/D108059/development/olb-vagrant/.vagrant/plugins/gems/2.6.6/gems/vagrant-proxyconf-2.0.7/lib/vagrant-proxyconf/action/base.rb:28:in `call'
         11: from C:/Users/D108059/development/olb-vagrant/.vagrant/plugins/gems/2.6.6/gems/vagrant-proxyconf-2.0.7/lib/vagrant-proxyconf/action/configure_docker_proxy.rb:23:in `configure_machine'
         10: from C:/Users/D108059/development/olb-vagrant/.vagrant/plugins/gems/2.6.6/gems/vagrant-proxyconf-2.0.7/lib/vagrant-proxyconf/action/configure_docker_proxy.rb:141:in `update_docker_systemd_config'
          9: from C:/Users/D108059/development/olb-vagrant/.vagrant/plugins/gems/2.6.6/gems/vagrant-proxyconf-2.0.7/lib/vagrant-proxyconf/action/configure_docker_proxy.rb:141:in `tap'
          8: from C:/Users/D108059/development/olb-vagrant/.vagrant/plugins/gems/2.6.6/gems/vagrant-proxyconf-2.0.7/lib/vagrant-proxyconf/action/configure_docker_proxy.rb:144:in `block in update_docker_systemd_config'
          7: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/communicators/ssh/communicator.rb:307:in `upload'
          6: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/communicators/ssh/communicator.rb:740:in `scp_connect'
          5: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/communicators/ssh/communicator.rb:391:in `connect'
          4: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/communicators/ssh/communicator.rb:742:in `block in scp_connect'
          3: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/communicators/ssh/communicator.rb:337:in `block in upload'
          2: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/communicators/ssh/communicator.rb:329:in `block (2 levels) in upload'
          1: from C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/communicators/ssh/communicator.rb:329:in `open'
C:/HashiCorp/Vagrant/embedded/gems/2.2.8/gems/vagrant-2.2.8/plugins/communicators/ssh/communicator.rb:329:in `initialize': No such file or directory @ rb_sysopen - C:/Users/D108059/AppData/Local/Temp/vagrant20200604-8884-ipqxj6 (Errno::ENOENT)

codylane · 2020-06-04T21:51:59Z

Hey @chucknelson,

Ugh, I'm sorry to hear that you are experiencing some weird behaviors with the newer versions of vagrant and this plugin. I won't lie, I'm also having a hard time trying to determine what the heck has changed since Vagrant 2.2.4, and as far as I'm concerned that is the latest stable release that continues to work for me, at least in my environments at home. Before I point the finger though, I'd like to make sure there isn't something wonky that I created by accident. Give me a few days to investigate.

Also for what it's worth vagrant 2.2.8 was released and then patched with at least 3 criticals from what I could see and released with 2.2.9 in less then a week. Mind installing vagrant 2.2.9? I have a feeling this problem will still remain but I'd love to know either way.

Thanks again for reporting your findings. Hopefully in the next couple of weeks all this will behind us and we will get back to normal behaviors. I've made some pretty good progress today but still not worthy of posting on GH yet.

codylane · 2020-06-04T22:03:56Z

Upon closer inspection of the log that you posted which is awesome by the way, the problem appears to be related to how the tempfile implementation works. I'll need to investigate how this is supposed to work on Windows. It looks as though you are using Windows? if so, can you please tell me which version? I'd like to setup a test environment on my own with the same version and see if I can find a solution. That said, this seems like a different issue. I'll create a new issue and link it to this one. Just for convenience.

chucknelson · 2020-06-05T13:42:21Z

Thanks @codylane - moved the conversation for the Tempfile error to #220.

codylane · 2020-06-09T18:08:02Z

FYI - I'm putting this into a stalled state for as I have not had the time to work on this as much as I'd like and I wanted to provide a status update as to the delays. I promise this will get done, I just need to focus on my some more important priorities at the moment. If nothing else, I'll check in the current state of my branch into this repo: https://github.com/codylane/vagrant-proxyconf by the end of the week.

codylane · 2020-06-20T03:05:53Z

As promised I've pushed the stalled code to my local github branch.

codylane · 2020-06-26T20:00:18Z

Howdy and happy friday at least on my side of the world.

I still apologize for the long delay on getting back to this. I woke up this morning and was on mission to fix broken things so I decided to make an attempt to fix this issue. I have got this staged in my personal repo and it's currently going through travis tests. If they pass, I'll open a pull request here and at least get this into the master branch.

@chucknelson - If you have time, once this merged to tmatilai/vagrant-proxyconf I'd welcome some feedback and testing if you have the time? I'll let you know when it's ready for testing.

codylane mentioned this issue Apr 19, 2020

vagrant won't read user profile config ~./docker/config.json #219

Closed

codylane self-assigned this Apr 28, 2020

codylane added bug docker-proxy enhancement labels Apr 28, 2020

codylane added this to the 2.0.8 milestone Apr 28, 2020

codylane mentioned this issue Jun 4, 2020

tempfile implementation on windows doesn't always seem to work #220

Closed

codylane modified the milestones: 2.0.8, 2.0.9 Jun 10, 2020

codylane mentioned this issue Jun 26, 2020

Bugfix/pre release for gh issue 218 #223

Merged

codylane modified the milestones: 2.0.9, 2.0.10 Jul 3, 2020

codylane linked a pull request Jul 3, 2020 that will close this issue

prep 2.0.10 release #225

Merged

codylane closed this as completed in #225 Jul 3, 2020

Respect Existing Docker Config Location #218

Respect Existing Docker Config Location #218

Comments

chucknelson commented Apr 7, 2020

adespain commented Apr 9, 2020

chucknelson commented Apr 17, 2020

codylane commented Apr 17, 2020

codylane commented Apr 17, 2020

chucknelson commented Apr 19, 2020

codylane commented Apr 19, 2020

samdbmg commented Apr 24, 2020

chucknelson commented Apr 24, 2020

codylane commented Apr 24, 2020

codylane commented Apr 25, 2020

codylane commented Apr 26, 2020

Test Scenario

samdbmg commented Apr 26, 2020

codylane commented Apr 27, 2020

codylane commented Apr 29, 2020 • edited Loading

Test Scenarios:

samdbmg commented May 1, 2020

codylane commented May 1, 2020 • edited Loading

Solution 1

Potential Solution 2 (more complex)

chucknelson commented May 1, 2020 • edited Loading

codylane commented May 1, 2020 • edited Loading

Feature

Example Vagrantfile

codylane commented May 3, 2020

chucknelson commented May 4, 2020

codylane commented May 4, 2020

codylane commented May 5, 2020

codylane commented May 5, 2020

codylane commented May 6, 2020 • edited Loading

codylane commented May 8, 2020 • edited Loading

codylane commented May 9, 2020 • edited Loading

codylane commented May 12, 2020 • edited Loading

codylane commented May 17, 2020 • edited Loading

Adding additional tasks to feature board:

chucknelson commented Jun 4, 2020

codylane commented Jun 4, 2020

codylane commented Jun 4, 2020

chucknelson commented Jun 5, 2020

codylane commented Jun 9, 2020

codylane commented Jun 20, 2020

codylane commented Jun 26, 2020

codylane commented Apr 29, 2020 •

edited

Loading

codylane commented May 1, 2020 •

edited

Loading

chucknelson commented May 1, 2020 •

edited

Loading

codylane commented May 1, 2020 •

edited

Loading

Example `Vagrantfile`

codylane commented May 6, 2020 •

edited

Loading

codylane commented May 8, 2020 •

edited

Loading

codylane commented May 9, 2020 •

edited

Loading

codylane commented May 12, 2020 •

edited

Loading

codylane commented May 17, 2020 •

edited

Loading