Open nickcharlton opened 5 years ago
I would expect at some Landrush trace to be in the log, provided of course the configuration hooks for Fusion get triggered - https://github.com/vagrant-landrush/landrush/blob/e10f684481e0ba7ced27903def976949664861ce/lib/landrush/plugin.rb#L36
A couple of things I would try:
$ VAGRANT_LOG=debug vagrant up
vagrant plugin uninstall landrush && vagrant plugin install landrush
) to see whether this makes a differenceYeah, I was thinking the same. So I ran with DEBUG
(you can see the full log output in this gist) and it looks approximately like the following:
[...]
==> default: Machine booted and ready!
INFO warden: Calling IN action: #<Landrush::Action::InstallPrerequisites:0x000000010226a090>
DEBUG ssh: Checking whether SSH is ready...
[...]
INFO warden: Calling OUT action: #<Landrush::Action::InstallPrerequisites:0x000000010226a090>
[...]
[successfully booted box; end]
centos/7
, which I don't normally use) and since on several I generate myself.The one thing I haven't done yet is replicating the whole situation on a completely different host machine.
So it seems these hooks are working at least. What version of VMWare Fusion are you using and more importantly which Vagrant plugin do you have installed? Do you use the latest vagrant-vmware-desktop plugin?
As far as I understand there have been some changes on how VMware and Vagrant integrate - https://www.hashicorp.com/blog/introducing-the-vagrant-vmware-desktop-plugin. It might be that due to the new plugin further changes are needed to get Landrush working again.
Unfortunately, support for Fusion has always been best effort, since one needs licences for VMWare as well as the Vagrant plugin. For the latter there is not even a trial version available.
Looking at the gist, I am wondering whether the Landrush hooks run too early, but that's atm just a guess.
I looked at this again just now to see if it was still an issue with the collection of moving parts. I can confirm that it's still an issue with:
VMWare Fusion: 10.1.6 Vagrant: 2.2.5 Vagrant VMWare Utility: 1.0.7 Vagrant VMWare Plugin: 2.0.3 Landrush: 1.3.2
Can you suggest somewhere I could go looking to see if I can solve this?
I'm happy to say I've worked out what the problem is here. It is related to the renaming of the Vagrant VMware Plugin, which explains why the hooks just never get called, see:
These are now in the HashiCorp::VagrantVMwareDesktop
namespace and so defined?
always returns false and we never register the two hooks we need.
The solution here is to rename those constants. We'll also need to rename the constant in here too: https://github.com/vagrant-landrush/landrush/blob/bfef5eb61773c0fdc7041402653288396957af99/lib/landrush/action/common.rb#L8
A pull request would be great! :)
I'm not aware of the same issue on Parallels, can you verify please?
Great! I'll get on with that.
I'm not able to test with Parallels, and I'd expect that to be unrelated to this particular issue.
The interesting bit with Parallels is how it writes a warning to the user; any change we make would likely be breaking unless the end-user upgraded all of Vagrant from when it was a Fusion specific provider. What do you think?
Sorry @nickcharlton , I didn't see your comment here before.
The warning you mentioned is this?
Ah yes, that's the one. I think I mentioned this on #358, but it's been long enough I think we can get away with not doing this (I'm happy to make a change if you think otherwise, of course.)
A warning like that would make sense.
I just went to look into adding that warning and hit a snag. Looking at: https://github.com/vagrant-landrush/landrush/blob/bfef5eb61773c0fdc7041402653288396957af99/lib/landrush/action/common.rb#L45-L47
This will now catch the lack of support, but with an error like:
The landrush plugin does not support the HashiCorp::VagrantVMwarefusion::Provider provider yet!
Which wouldn't strictly be true, we do, you just need to upgrade to the one with a new name. I'm thinking here that we could:
What do you think?
@nickcharlton I honestly don't know.
Leaving it as is will probably result in some user being confused. On the other hand, splitting the function will increase the complexity without a good reason, IMHO.
My suggestion: leave it as is, but document this somewhere else. Maybe the README?
@hferentschik do you want to weight in on this?
Hah yeah, I had the same problem!
I think it's reasonable to document it, so I'll wait if there's another reply before just doing that on the PR.
I ended in the unfortunate situation where I uninstalled the old vmware plugin trying to fix an issue only to find I can't re-install and have had to use the new desktop plugin. I was using vmware-hostmanager which is similarly afflicted, but there is no activity there. I found landrush this evening but found it wasn't working, and now I know why. I will be very happy if you release a new version soon that works with the new vmware-desktop plugin.
I've been tearing my hair out for days :)
Tony.
I documented the change in the README, in the install section as that seemed a good way to go about it. Let me know if there's a better way to do this!
When bring up a basic Vagrant box using VMWare Fusion, Landrush doesn't appear to start (at all). I am able to start the daemon manually, but when doing that, the IP/hostname isn't configured.
I've confirmed that to bring up the same configuration on VirtualBox (5.2.20) works successfully.
This has worked in the past, so I figure it's a regression somewhere. What do you recommend I look into?
Box:
Log output:
Vagrant: 2.2.0 VMWare Fusion: 10.1.2 Landrush version: 1.3.0 OS: macOS Mojave (10.14.1)