Support vagrant on windows #39
Conversation
According to the 1.6 installation instructions for Vagrant, the ansible-galaxy install should be done on the host system before running 'vagrant up'. However, this isn't possible on Windows, since Ansible doesn't run on Windows. So this patch adds Vagrant options which do the ansible-galaxy install during the provisioning process on the guest system. "https://www.archivematica.org/en/docs/archivematica-1.6/admin-manual/ installation/installation/#automated-ubuntu-github-install" Note that this is useful for both :ansible and :ansible_local provisioning.
This patch makes Vagrant set the provisioner to :ansible_local instead of :ansible if you're on a Windows host. This means that Ansible will run locally within the guest OS instead of running from the host OS into the guest OS. WARNING: Running Vagrant on Windows will only work if you're a Windows Administrator or if you have the privilege to create symlinks*. If you don't meet these criteria, the symlinks in the Git working directory will become regular files containing the name of the symlink target as its text content. This is a problem both at the initial 'git clone' time, as well as while Ansible is running, since it will checkout code in the shared folder which runs on the Windows system. *If you're on Windows 10, you can grant the 'create symlinks' privilege by going to "Local Policies" then "User Rights Assignment" then right clicking on "Create symbolic links" and choosing "Properties" then choosing "Add User or Group" then entering the desired user or group and finally clicking "Apply". For the privilege to apply, you will need to log out and log back into your Windows account again.
There was a problem hiding this comment.
@minusdavid, your changes make sense to me. I like that you made it so ansible_local is only used when using Windows. Should we also update the README file to reflect that the roles are going to be downloaded automatically by Vagrant? Thank you!
playbooks/archivematica/Vagrantfile
Outdated
| @@ -1,11 +1,24 @@ | |||
| # -*- mode: ruby -*- | |||
| # vi: set ft=ruby : | |||
|
|
|||
| module OS | |||
| # Try detecting Windows | |||
There was a problem hiding this comment.
Ah, nice one. I'll fix that.
|
@sevein I've fixed the whitespace and removed the line in README.md about running ansible-galaxy. Is that what you had in mind? |
|
Awesome! My personal machines are Linux, but we use Windows at work for workstations. I've been curious what other devs must be doing... are you on OS X or Linux? |
Both! |
I imagine there must be more devs using Macs then I thought then! |
|
On a side note, I just installed the Windows Subsystem for Linux on my Windows 10 machine today. It would be interesting to see how that works with deploy-pub... |
|
Is there anything else I need to do to move this one along? |
There was a problem hiding this comment.
This is fantastic, very happy to see it. I have tested this out by testing changes to the ansible-archivematica-src role on windows 10. This is the first time it has ever seemed practical to me for someone to do Archivematica development work from a windows machine.
Very useful contribution, thank you.
This works for me and looks good to merge
👍
@axfelix you should check this out.
@minusdavid my only two comments are
- to maybe add a line to the readme about needing to run this as a Windows Administrator.
- add a quick note about git and symlinks on windows. I think you mentioned this in another github thread.
But I think it is fine to merge even without that update. Both of those notes could go into the archivematica getting started page, in a new 'archivematica on windows' section, which I will look into starting.
|
+++ |
|
One other detail, @minusdavid , before we can merge this PR, you would need to sign the Archivematica Contributor License Agreement. Let me know, public or private, if you have any questions about the CLA. |
|
Cheers @jhsimpson! I've added those details to the README.md and I'll push the commit in a moment. Thanks for looking at starting a 'archivematica on windows' section. While I use Linux at home, my office workstations are always on Windows. |
|
@jhsimpson, as for the Contributor License Agreement, I filled that out and emailed it to '[email protected]' late last week. Please let me know if I should resend it or send it somewhere else. |
|
Just noticed something weird (due to #40). The symlinks appear correctly on Windows, but - in the VM - git is saying that the files have been modified. vagrant@am-local:/vagrant/src/archivematica$ git status Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") I'm investigating this on #40 but it might be worth holding off on pushing this one until it's figured out. |
|
Ah, it looks like using symlinks on a shared folder with Git on a Windows host/Linux guest combination isn't going to work. The symlinks are generated correctly, but Git seems to get confused and thinks that the files have been modified. This seems to prevent checking out remote branches due to a bug in Ansible where check outs of remote branches aren't forced. You could probably workaround that a bit by creating local branches after the first "vagrant provision" failure, but I don't think that's a reasonable expectation of users. So I probably want to abandon this pull request while "deploy-pub" uses symlinks in the shared folder. I did my best, but I without diving further into Git's internals, I think I'm stuck. |
|
Then again... maybe this doesn't have to be an "end of the world" kind of thing. The problem for Windows users is that /vagrant/src is used for archivematica_src_dir. But there's no reason we couldn't use a different directory that isn't on a vboxsf share. I notice the default in deploy-pub is actually "/opt/archivematica". And if you look at https://wiki.archivematica.org/Getting_started#How_do_I_update_or_reset_an_ansible_install.3F, you can see someone is using "/srv". So maybe I'll try that instead... |
|
I've removed the archivematica_src_dir option from the Vagrantfile and that seems to help, although I'm still running into what I think may be a bug in archivematica-storage-service I'm going to try on stable/1.x to see how it works without archivematica_src_dir in any case. |
|
After removing archivematica_src_dir from the Vagrant file, I was able to successfully "vagrant up" using vars-singlenode-1.6.yml. However, I haven't tested the actual deployment beyond confirming that Ansible completed without error. I might wait to see if you folk can make sense of the error I encountered while trying vars-singlenode-qa.yml In any case, would it be acceptable to remove archivematica_src_dir from the Vagrantfile or change it to /opt/archivematica? Or do it just based on the Windows condition? While it is a bit less convenient than having it in the Virtualbox shared folder, it would be great for Windows users to be able to have a development environment for Archivematica. |
|
@minusdavid your contributor agreement did get received, sorry about that, I didn't check properly before posting. I filed an issue on the Archivematica repo about the symlink problem: artefactual/archivematica#704 I think we can remove all symlinks from the Archivematica repo, which will get rid of the issue entirely. We don't really need to be using symlinks, at least not in qa/1.x any more, as that branch is not using git submodules anymore I think this PR in deploy-pub can get merged now, @sevein, I think the changes you requested have been addressed? |
|
@jhsimpson I'd wait until we close artefactual/archivematica#704 because this PR mentions the problem with symlinks. @minusdavid if you have a chance, can you clean up the history? See our contribution guide for more details. |
|
Sure, I'll wait until artefactual/archivematica#704 is resolved, and then I'll fix and squash the commits to try to agree with the contribution guide. |
|
As per my comments on artefactual/archivematica#704, there are still more issues preventing the playbook from working. Mainly the symlinks in the stable branches are causing the playbook to fail. That can be worked around by working around an Ansible bug... but then I think there's a problem with either the other Ansible playbooks or with the qa branch for archivematica-storage-service... |
|
I think once there are no more symlinks in the qa or stable branches, then support for Windows could happen. That said, I don't really have time to work on Archivematica anymore, so I think perhaps this might just sit open for a while unless someone else adopts the issue or if we revisit Archivematica in the future here at Prosentient. |
This branch makes 2 changes to the Vagrantfile to enable it to work on a Windows host.
The first is to run ansible-galaxy inside the guest OS using Vagrant rather than running it manually in the host OS, since one cannot run ansible-galaxy in Windows typically. I think this change is actually useful to everyone, so I haven't wrapped it in Windows detection. In the event that a Linux user does do ansible-galaxy manually before running 'vagrant up' or 'vagrant provision', it shouldn't matter as it's idempotent. (As part of this change, it's necessary to install Git in the guest OS since it's needed when ansible-galaxy fetches from Git sources.)
The second change is to detect Windows and to change from :ansible to :ansible_local in that case, and to exclude the host checking option in that case since it's incompatible with ansible_local.
These are pretty simple changes which shouldn't make any real difference for anyone on a non-Windows system.
It's worth noting (here, there, everywhere) that Vagrant will only work on Windows with 'deploy-pub' if the user is running as an Administrator or if the user has the "create symbolic links" privilege granted via "Local Security Policy" (ie secpol.msc). I think I might need to revise my commit message a bit to mention the part about opening "Local Security Policy" or secpol.msc, but before I do that...I'll just see what you all think!