Error deploying simple drupal site

[Conzar]

The code below produces an error.

package{'php5': }
package{'php5-cli':}
drupal::site { 'localhost':
  core_version => '7.38',
  require      => Package['php5','php5-cli']
}

==> default: Error: Could not find dependency File[/var/cache/puppet/archives] for Archive[drush-6.6.0] at /tmp/vagrant-puppet/modules-238003d1b18ca55794974c17ab4e2b78/drupal/manifests/install.pp:73

It seems that the drupal class needs to be declared but I don't see this in any documentation. Is this correct, if so, can you provide an example of how the drupal class should be declared?

[tohuwabohu]

An example would be

  file { ['/var/cache/puppet', '/var/cache/puppet/archives']:
    ensure  => directory,
    require => Package['puppet']
  }

I agree this is not ideal and should at least be documented - unless there is a better solution to this.

[tohuwabohu]

Also please note there is issue #3: at the moment, the module is unable to provision a site from scratch; it only works if there is a site already existing.

[Conzar]

Sorry about reporting this, I think the issue can be closed.

[tohuwabohu]

No need to close it - the issue is still valid. I only wanted to express that this is a 'known issue' and should eventually be fixed in the future. Not everyone has an existing site to be managed.

[tohuwabohu]

Fixed in version 1.2.1.

[kentr]

This issue is still there for me in v1.2.1.

Adding the following to my manifest solved it. The additional package resource was required because the Package['puppet'] requirement also failed.:

package { 'puppet': }

file { ['/var/cache/puppet', '/var/cache/puppet/archives']:
  ensure  => directory,
  require => Package['puppet']
}

I'm definitely using 1.2.1:

$ puppet module list
/etc/puppet/modules
└── tohuwabohu-drupal (v1.2.1)

[tohuwabohu]

So yeah - this is a tricky issue. As mentioned above I've documented this in the limitations section.

I'm not sure what the expectation is: the files need to be stored somewhere. The current archive module doesn't provide a generic place on its own and other usable modules (like staging or the successor puppet-archive) were not in a usable state when I checked last time. I'm open for suggestions on how to improve it.

[kentr]

Ah, I thought misunderstood that this issue was reported fixed in 1.2.1.

What do you think about putting the package and file resources in the project's manifests?

[kentr]

Or, do the files need to be preserved? What about putting them in /tmp?

[tohuwabohu]

Or, do the files need to be preserved? What about putting them in /tmp?

Yeah, they should stay. The camptocamp-archive module assumes those files stay on disk even after the actual file has been extracted. If not it will download them again. You can put them in /tmp but then I'm sure programs like tmpreaper will clean them up from time to time and hence the module will download them again.

What do you think about putting the package and file resources in the project's manifests?

Sure, this could be done. Currently the assumption is that those resources are defined globally and just used by various modules. Defining them in multiple modules will result in collisions. I understand this won't happen in your case.

Long term I would like to replace the camptocamp-archive module with puppet-archive as it completely avoids this problem. Last time I checked there wasn't a release on the forge but now there is so changing to the other module should fix the issue.

[kentr]

Thx. Perhaps another model to consider would be using drupal console for the download & installation of Drupal core. I ended up going that route (through Puppet).

[tohuwabohu]

I had a quick look at drupal console and it appears to do the same thing as drush. Could you please give me an example where using drupal console would solve this problem in a better way?

[kentr]

Could you please give me an example where using drupal console would solve this problem in a better way?

I used it to circumvent the need for the archive module when installing from scratch (to download the code and install a site). Drush might do this as well, but it wasn't working for me.

Something like this:

sudo drupal site:new INSTALL_DIRECTORY 8.0.3 --no-interaction

sudo drupal site:install --site-name=default --db-type=mysql --db-host=localhost --db-port=3306 --db-name=DB_NAME --db-user=DB_USER --db-pass=DB_PASS --account-name=ACCOUNT_NAME --account-mail=ACCOUNT_EMAIL --site-mail=SITE_EMAIL --account-pass=ACCOUNT_PASSWORD --langcode=en standard

It could be wrapped in a guard to test whether a site is already installed, like checking whether INSTALL_DIRECTORY already exists.