The docs are possibly incorrect on debian install

[chuxau]

Without poking into the innerds of the system yet, it seems that valkyrie-update is trying to establish an NFS connection from the VM to the host - going by the error messages thrown up. However, the docs say only nfs-common needs to be installed ..

For the host to serve as an NFS server, we need to install nfs-server on the host, and possibly run valkyrie with sudo so it can make changes as root.

However, running valkyrie-update with sudo fails to locate the drush command. Running it with 'sudo -E', I get:

$sudo -EP drush valkyrie-update
Update the Valkyrie code in this project (at '.valkyrie/valkyrie') with the latest from /home/uza/.drush/valkyrie? (y/n): y
Valkyrie code updated.                                                                                                  [ok]
Reloading VM and running provisioners.                                                                                  [ok]
==> valkyrie: VM not created. Moving on...
==> valkyrie: Checking Drush alias integration.
    valkyrie: Found drushrc file (/home/uza/.drushrc.php).
    valkyrie: Found Valkyrie drushrc include file (/home/uza/.valkyrie.drushrc.php).
    valkyrie: Found Valkyrie drushrc include statement in drushrc file (/home/uza/.drushrc.php).
    valkyrie: Found project alias path in Valkyrie drushrc include file (/home/uza/.valkyrie.drushrc.php).

So, it does seem as if it's not intended to be run under sudo .. So, how can we get it to install an NFS server (if the package is absent) and create a share as a non-root user? .. Just seeking clarification.

If setting up for nfs is required, then we will need to update the docs ..

[chuxau]

I just deployed successfully on osx and logged into the UI ok .. kudos for the amazing efforts. As one gets familiar with the setup, it will be easier to figure things out and contrib docs or code.

[ergonlogic]

Perhaps we need nfs-kernel-server, then.

[laymonk]

yeah, and sudo to prompt for privileged ops .. That's the difference between the osx install and the debian install. The osx installs prompts for sudo at appropriate times .. but the debian install never does, which is why it fails ..

If it's an ansible run, perhaps we need to run the tasks/role with sudo .. oh, i see this has been considered already here issue #1

[ergonlogic]

We don't handle installation of dependencies on the host machine. Vagrant will prompt when it requires sudo.

[laymonk]

Yeah, I see this now .. and that implies that it wont install the nfs packages, but will use them if they are there .. the sudo entries are just to save one from repeated password prompts

I will try this out tomorrow and come back with some feedback ..

[laymonk]

If I sort this out, what's the process for updating the docs ?

[ergonlogic]

A PR against https://github.com/GetValkyrie/valkyrie-docs is the best bet. I'll be stripping out all but the README from Valkyrie itself shortly. This repo generates http://docs.getvalkyrie.com

[chuxau]

OK .. will do that. Thanks.

Yeah, the nfs server needed installing, which turned out surprisingly challenging on debian wheezy (with so many little bugs besetting the nfs related debian packages due to a move from portmapper to rpcbind) .. Had to resort to modifying the /etc/init.d scripts to remove the LSB dependency the scripts had on a $portmapper that has been deprecated .. Certainly worth documenting ..

There is also an implied assumption that ansible is already installed on the host, although I still get the ansible-playbook: command not found error when I run valkyrie-update, even after installing ansible and ensuring the command is accessible in my $PATH .. perhaps the error is from the VM side which means we will need to take care of deploying ansible on the VM before trying to use playbooks ? .. Not sure .. Need to investigate that later.

One final thing to be aware of is that vagrant was actually successfully updating the /etc/exports file .. and it creates repeat entries each time drush valkyrie-update or drush vnew valkyrie is re-run .. so, expect nfs server restarts to complain about duplicate entries. Wonder how to try and deal with that ..

[ergonlogic]

Ansible is not run on the host. It is deployed on the VM as part of the NFS setup. So if NFS failed, then it's very possible that the Ansible install never happened. Rebuild your VM from scratch (vagrant destroy -f && vagrant up)

drush vnew creates a new project/vm, and so is expected to add new entries in /etc/export/. drush vup should not, unless perhaps you're upgrading from 0.3.x. If you can confirm that this is repeatable, please file a separate bug.

[ergonlogic]

Also, bear in mind that only one Valkyrie VM should be up at a time. halt or destroy any other that you aren't using.

[chuxau]

Thanks for the clarification. However, I have not ever been able to bring up valkyrie on debian .. so repeated runs of 'update' have been required because of failures .. It is also possible I tried a few repeated 'vnew' sessions and that caused the repeat /etc/exports ..

Have vagrant destroyed and upped again, and this time the whole process has worked fine .. your reasoning on why the ansible error came about is correct: nfs failure meant failed ansible install on the vm

[chuxau]

Couple of questions:

1. Regarding the design decision to run only one instance of valkyrie vm, would that not prevent developing against multi-server aegir? I think that is a useful target to be able to develop/test against .. No?
2. When I access the shared source tree from an IDE, I only see /var/aegir/platforms, and the valkyrie sources. Ideally I would like to have access to the aegir sources. Is there any reason why that would be a bad idea ?
3. Finally, where does rune come into this setup? How would one typically integrate rune?

[ergonlogic]

valkyrie-update is intended to update the Valkyrie code in a project. It won't help much with a failure, except that it'll reload the VM, and (iirc) run provisioning. So, while it could help, that's not what it's designed for.

There's nothing stopping you from adding additional VMs, to emulate a cluster environment, for example. However, Valkyrie is designed specifically to make development of Drupal sites fast and easy, as opposed to Aegir infrastructure modelling. We write Drush aliases on the host (@v and @vm), and broadcast mDNS via Avahi (or vagrant-dns on OSX) to provide automatic domain resolution. These would be greatly complicated by trying to support multiple projects simultaneously.

That said, I use Valkyrie to develop for Aegir all the time now. While I don't think mounting the Aegir code base (and Drush, for that matter), is a good idea for a default install, it shouldn't be too hard to implement. Try dropping a file in the root of your project called config.yml, with the following content:

nfs_paths:
  /var/aegir/hostmaster-7.x-3.x: hostmaster
  /var/aegir/.drush/provision: provision

You'll need to then rebuild the VM (vagrant destroy -f && vagrant up).

[chuxau]

Awesome .. thanks for the tips ..

I understand about the concerns around mounting aegir, but this is a sandboxed VM seen only by the host, and seeing the aegir sources is vital for me for quickly comprehending aegir code base.

For multi-aegir, perhaps one can complicate things a bit, but injecting an aegir docker container in the VM, seen only from the VM network with /var/aegir running off a VM directory .. :-) .. When I get more comfortable with how this is setup, I will have a go at that.

Thanks again for a great tool, and the prompt support.

[ergonlogic]

No problem. Please do submit a PR to the docs project for any of the above that you feel would be helpful to other new users.

[chuxau]

Thanks. I have done so .. probably need to tidy it up a bit, and make it more complete ..

[chuxau]

Sent you a pr for the docs .. I hope my additions are useful .. will add more as I go along. Thanks