VMWare Fusion issues

[chrisrikli]

Trying to get vlad working using VMWare Fusion. The install runs fine until it hits the following:

TASK: [php | change php apache2 memory_limit] *********************************
failed: [192.168.100.110] => {"failed": true, "rc": 257}
msg: Destination /etc/php5/apache2/php.ini does not exist !

FATAL: all hosts have already failed -- aborting

PLAY RECAP ********************************************************************
           to retry, use: --limit @/Users/chrisrikli/site.retry

192.168.100.110            : ok=60   changed=40   unreachable=0    failed=1

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

[dixhuit]

That could well be Ansible just having a bad day. Have you managed to recreate this more than once?

I'm not sure how familiar you are with Vagrant but if you bump into an error like this after running vagrant up you can re-attempt to provision the current, "all ready up" box by running vagrant provision. If the initial error was down to Ansible just wigging out (I get this sometimes with sketchy rural broadband) then this can often push past that problem and finish provisioning the box.

Let us know either way though. If you're still having problems, please share your Vlad settings file via Pastebin or similar.

[chrisrikli]

Thanks for the response Dan; apologize for not including more initial detail.

This has occurred every time I've tried to use Vlad with VMWare Fusion.

I'd run vagrant provision a couple of times hoping that it would push though as I've seen it do when using Virtualbox, but to no avail.

When I vagrant ssh into the box the symptom complaint is indeed valid: there is no /etc/php5/apache2/php.ini file. In fact there is no /etc/php5/apache2 directory.

Here's a link to my settings.yml: http://pastebin.com/hT3UFZhx

The only changes are the hostname, IP address, and toggling node and ruby to true.

[dixhuit]

Do you know which version of Vlad you're running?

[chrisrikli]

Did a git clone yesterday. :)

[dixhuit]

Have you ever had it working with VMware fusion before?

[chrisrikli]

I have not; yesterday was the first attempt. The shared directory with VirtualBox as so...slow...even with NFS and the read performance with VMWare was reported to be superior.

[dixhuit]

I just pulled the trigger on a VMware license so I'll be able to test this later when I've finished downloading the VMware precise64 box: 3 HOURS! DAMN YOU RURAL BROADBAND!

[chrisrikli]

Wow Dan that's above and beyond. Let me sustain at least half of that cost. My email is chrisrikli at google's popular email service. Also if doing a screenshare or something would help or save you time let me know.

[dixhuit]

Haha, I didn't buy it just to debug this issue :) I've been meaning to get it for a while.

[dixhuit]

I've now managed to recreate the exact same error as described @chrisrikli using VMware Fusion 7.

Sure enough, /etc/php5/apache2/php.ini doesn't exist. In fact, /etc/php5/apache2/ doesn't even exist.

@philipnorton42 Do you have any ideas about this? I'm confused as to why it would be missing if using a certain provider.

[philipnorton42]

Very strange. My first thought is that PHP hasn't installed correctly. As there are PHP version and OS version checks in place I would start there and make sure that they are producing the correct results. Try printing out the ansible_os_family variable because if that isn't populated correctly then PHP won't install at all.

• debug: var=ansible_os_family

[dixhuit]

@chrisrikli Regarding your VM's slow performance, are you using npm and/or bower anywhere in your site's codebase? Perhaps in your theme?

[chrisrikli]

@danbohea I am indeed using npm in the theme as well as grunt

Edit: I should expand on that a bit. The codebase I was working on had been moved to the Vagrant ./docroot from a local DocumentRoot. So the node_modules were already in place. I ran grunt watch on the host not the guest (using VirtualBox as the provider).

[dixhuit]

OK. Would you mind trying the following if safe to do so (presuming you have a Vlad instance running using VirtualBox):

1. Run whatever tasks you're using grunt for to do an up to date build using your node modules.
2. Delete the node_modules directory from your theme. You should be able to get it back later by running npm install in the theme directory - if you're unsure of this make a backup of node_modules and place it outside of your drupal codebase.
3. Clear your caches.
4. Navigate around your site (including admin pages) and see if it feels any faster.
5. Comment here to let me know how you got on (you can put your node_modules directory back now if you like).

[chrisrikli]

@danbohea I did not observe any difference with page load times when having node_modules present in the theme directory vs having the directory removed. The load times are either higher than 20 seconds or around 4 seconds. No inbetween (it's strange).

There also seems to be a relationship between page load time and how long it's been since a page was loaded. In other words if I loaded a page a few seconds ago, the load time is more likely to be 4 second(ish). If I've been messing with code or something that creates some time between loads, then the load time is more likely to be 20 seconds or greater.

[dixhuit]

OK, thanks for the info. I've recently noticed a very strong link between the extent of node deps in node_modules and general D7 performance (likely due to node_modules usually having highly nested subdirectories and Drupal wanting to scan every file within its codebase seemingly all the fricking time).

Related: https://www.drupal.org/node/2329453

I thought it probably best to try to rule that out as the cause of your perf problems first; I also first thought it might be an issue with Vagrant/Vlad/VirtualBox when I noticed I wasn't experiencing the same issues in production on the same site.

Back to the drawing board!

[dixhuit]

There also seems to be a relationship between page load time and how long it's been since a page was loaded. In other words if I loaded a page a few seconds ago, the load time is more likely to be 4 second(ish). If I've been messing with code or something that creates some time between loads, then the load time is more likely to be 20 seconds or greater.

This sounds cache related. Not my area of expertise. I notice you're not running Redis or Memcached.

[chrisrikli]

Yeah, we generally don't run memcached in really active dev environments.

I'm going to try loading up Vlad in VirtualBox and then doing a git checkout against the repo to get the codebase and then rsync the files dir. I had done it the lazy way and just cp -red from the local DocumentRoot to the ./docroot so maybe I introduced something there.

[zxaos]

Regarding the ansible issue, it might be os version specific - I was unable to reproduce running VMWare Fusion 7.1.2 on an ubuntu 14.04 host, vlad master (2015-07-16)

[dixhuit]

This needs to be retested now that #256 has now been merged. As per @zxaos 's comment above, Matt's PR may well have fixed the root cause here.

[chrisrikli]

Ok, I'll retest this evening and report back.

[chrisrikli]

Failure and attendant messages unchanged. :( OSX 10.10.3 (14D136) VMWare Fusion 7.1.1

[dixhuit]

Boooo!

[zxaos]

@chrisrikli When you tested was this a clean box install? (Just trying to confirm whether it spun up a new box that exhibited this issue, or whether the issue just persisted across Vagrantfile changes).

[chrisrikli]

@zxaos It was a completely clean install. Cloned the vlad repo, created a completely new settings.yml file, etc.