jantman / vagrant-r10k

UNSUPPORTED - SEEKING MAINTAINER - Vagrant middleware plugin to retrieve puppet modules using r10k.
MIT License
35 stars 12 forks source link

Can't power up a VM if Internet connection is down #16

Closed tremblaysimon closed 9 years ago

tremblaysimon commented 9 years ago

Errors when power up a VM with vagrant-r10k plugin used and Internet connection is down:

==> default: vagrant-r10k: Beginning r10k deploy of puppet modules into /home/tresi02/git/projeqtorquebec/puppet/externalmodules using /home/tresi02/git/projeqtorquebec/puppet/Puppetfile [R10K::TaskRunner - ERROR] Task #R10K::Task::Module::Sync:0x000000019db4e8 failed while running: Couldn't update git cache for https://github.com/saz/puppet-timezone.git: "fatal: unable to access 'https://github.com/saz/puppet-timezone.git/': Could not resolve host: github.com" RuntimeError: Couldn't update git cache for https://github.com/saz/puppet-timezone.git: "fatal: unable to access 'https://github.com/saz/puppet-timezone.git/': Could not resolve host: github.com"

I don't know if it is a limitation of R10K (the version used by vagrant-r10k) or if it is something that we can fix in vagrant-r10k directly.

jantman commented 9 years ago

I'm terribly sorry... somehow I hadn't seen this issue. I've been incredibly busy (~16 hour days) this week trying to get a work project out the door, but I should have some time next week to look into this and try to come up with a solution.

That does seem completely understandable to me... r10k is intended to deploy modules, so I wouldn't expect it to work nicely without connectivity. So I guess it's a limitation of r10k... but I don't really see how things could work otherwise.

The actual "problem" here is that vagrant-r10k treats R10K failures/errors as provisioning failures. I strongly believe this is the right default behavior; if you tell vagrant-r10k to do something (deploy modules) and it can't, it should make you abundantly aware of that, not fail silently.

So the question becomes how to allow a user to tell vagrant-r10k to ignore errors?

  1. simple way: add a config flag to ignore any r10k errors. We could try to get fancy and ignore only the errors that result from DNS not working or inability to connect, but that would require parsing exception strings generated by r10k, which shouldn't really be relied on.
  2. maybe better way: add a command line option to vagrant up to ignore errors, or maybe just to skip r10k.
  3. simply don't run r10k when we don't have connectivity. But aside from trying to get data (i.e. from httpbin.com) and seeing if it works or not, there's no cross-platform way that I know of to determine if we have connectivity.

@tremblaysimon any thoughts on this? Until I get a fix implemented, you can always just comment out the vagrant-r10k config when you're working without connectivity...

tremblaysimon commented 9 years ago

No problem with the delay we all have our priority and I understand that!

I agree with you that R10K failures/errors are provisioning failures too.

Since it is a R10K problem when there is no connectivity I think I will address it to R10K project directly. And of course the best workaround currently is to comment out vagrant-r10k config in Vagrantfile...

And hopefully it isn't a problem that we face often (lack of connectivity).

P.S. I think vagrant-r10k isn't using latest version of R10K ? I will test latest R10K version directly and see if errors happen when there is no connectivity.

tremblaysimon commented 9 years ago

Maybe we should close that issue and just let it there if someone else face the same problem someday.

jantman commented 9 years ago

As of #9 / #23 (not yet released), vagrant-r10k can be completely skipped by running with --no-provision or by commenting out the code.

What remains for this is to, in VagrantPlugins::R10k::Action::Deploy.deploy, catch whatever specific error is raised when a repo can't be accessed, and present that to the user in a cleaner format, suggesting the workaround of (1) ensuring the repo path is right, or (2) either commenting out the vagrant-r10k config or running with --no-provision.