Windows provisioning hangs ... #101
Comments
|
@danryu - Can you do a |
|
I destroyed the vm and am doing another "up" right now ... and it has hung at the same point (about 10 minutes so far) ... Strange that the output actually cuts at the same point as before ... Either way, I'm stumped ... and also blocked from using this vm, which I was hoping to build into another project right now ... |
|
Even though the output has stopped, it seems that the vm is (partially) running ... Then I tried a in another terminal - so indeed there is a connectivity problem. (You should be able to reproduce this now, I believe!) If I clone that repo with the https protocol, it works fine, and other github repos work fine with git/ssh - so I don't know what the issue with recursion-context.git is exactly ... Anyway - I'd like to resolve this connectivity/ssh-vs-https issue, and the git role replication issue - I'm trying to build a slimmed-down version (ie no mysql/java/pimpmylog...) of drupal-vm in a Docker image - so any advice about how to achieve this would be gratefully received. |
|
@danryu - I'm able to clone that repository without issue from a few different network/geo locations. It seem you might have a local connectivity issue; a proxy, a firewall, ISP filtering, something like that. Can you try again today to see if it might've been a momentary problem? As far as moving Drupal VM to a Docker image, I'm planning on working on containerizing everything in version 2.0; but I'm going to wait a little longer so the rest of the VM can stabilize more before going down that route. |
|
Thanks for the response. It seems the problem was with using the native git url (git://github.com/sebastianbergmann/recursion-context.git) rather than the ssh option (git@github.com:sebastianbergmann/recursion-context.git). Which resolves the connectivity issue :) I've tried looking at alternative ways to install current stable Drush (ie v7 or recent v6.x) using Composer and other means ... but keep on running into this classic problem: which I'm guessing might be the reason you chose to install Drush as you did in your Drush ansible role? |
|
@danryu I started seeing the same "hanging" behaviour that you describe after installing the vagrant-winnfsd plugin. Ironically I found that plugin after being intrigued by the NFS entries in your logfile in this issue 😄 |
|
@danryu - Thanks for the additional information, it really helps! That particular git command is run as part of the process of installing composer, so it's completely outside the control of my playbooks, and if anything, would be a bug against composer's own install process. This should've been fixed by composer/composer#3542, which references the PR with a fix: composer/composer#3651 It may also be related to your use of the |
|
No, @JorisVanEijden, unfortunately that's not it :( .... The MAIN problem is that most commonly on corporate networks, the git daemon port (9148) is blocked. (Please read the last paragraph of https://git-scm.com/book/ch4-1.html for the background here.) As it happens, @geerlingguy 's ansible-role-drush does EVENTUALLY complete, but for each repo referenced in the drush repo (eg git://github.com/sebastianbergmann/recursion-context.git), it only times out after perhaps 10-15 minutes PER REPO before defaulting to the "https://github.com/XXX" style url .... which means that after a dozen or so repos, a few hours has passed before drush is even installed! I'm now looking at replacing the ansible-role-drush with a more simple playbook based on the install docs at docs.drush.org/en/master/install/ ... |
|
Thanks, @geerlingguy, I've just noticed your last comment, had my comment open for ages while I was debugging :) Yes, I see your drush ansible role is fairly "vanilla" and thus shouldn't be adding to the problem ... perhaps it's ansible itself which causes the much longer timeouts ... still unsure at this point ... |
|
@danryu - Please keep digging if you can—it's possible I can make the drush and/or composer roles more flexible to allow you to specify different git URLs, different install methods, etc. But one thing I've so far been pretty inflexible on (and will likely continue to be) is modifying things just so they work behind corporate proxies/firewalls. Since every corporation is different—and nearly all do things that would make roles nightmarishly complex, I vote to use standard methods (like using git URLs by default, for speed, efficiency, and sanity) over making everything work through ports 80 and 443 ;) I'd much rather we push for corporations to do the right thing and open up git access... since about 99% of the modern OSS development world uses git at this point. |
|
@geerlingguy - yes I agree on going standard where possible. As it happens, though, the https:// and git@github.com (ie ssh) are the standard methods - even github themselves make these the two easily referenced methods on each and every repo page ... Who knows why composer installs default to git:// style urls to start with ... !! |
|
@danryu - true, true... and you may want to file an issue in the composer project to ask them to use the https git URLs for install, specifically to make install work behind restrictive firewalls. |
|
@geerlingguy - so after a little further digging, it seems that this has reared its head with others in the past. This stackoverflow shows a couple of solutions that have been implemented: But perhaps the more useful is to tell the git client itself to change all git:// addresses to https:// addresses: This seems to be more sensible, as it covers all the potential problematic use case scenarios. (I still can't quite understand how using your -drush role ends up cloning what must be about 30-40 github repos, compared to the handful that seem to happen when I do the procedure at docs.drush.org/en/master/install/ - but hey it works and I've really spent way too long on this already) |
|
@danryu - Thanks SO MUCH for all your debugging work. I think it might be safe to at least set the composer config differently for it's own installation. That would probably also fix the drush installation process, since almost all the activity in the drush installation goes through composer/github pulls! Do you think you could open a ticket in the https://github.com/geerlingguy/ansible-role-composer repository to ask for this config change, with the reasoning from this ticket? |
|
@geerlingguy - No worries, I hope this will prove useful. Just to be clear, all existing references to addresses of type
|
|
it lags after TASK: [Update apt cache if needed.] ******************************************* TASK: [Get software for Python-based control.] ******************************** |
|
@dwaghmare - Did running an Ansible role requirements installation with |
|
I'm stuck on almost the same place after "Ansible role requirements installation with --force" :( TASK [geerlingguy.solr : Set solr_filename for Solr 4.x.] ********************** TASK [geerlingguy.solr : Set solr_filename for Solr 3.x.] ********************** TASK [geerlingguy.solr : Download Solr.] *************************************** staing on the last line for like un hour... And that's the second time I'm trying. |
|
After 2 destroys and lots of reading, the 3-rd one happened to succeed. |
|
@kadiiskiFFW - Yeah, depending on your geographical location, the Solr download can take a really long time—but you can override for a faster download by finding a mirror closer to your location—see https://github.com/geerlingguy/ansible-role-solr, specifically the documentation under |
Having followed the readme precisely, and just set up default config ... my provisioning is just hanging for about 30-40 minutes after "vagrant up".
For clarity I'll include the whole output... Any ideas on this?
The text was updated successfully, but these errors were encountered: