Chef is installing things out of order

[Wyatt Barnett]

I think this is more of a chef issue than a vagrant issue -- as they say vagrant is easy, provisioning is the hard part. 

I'm not sure if chef/vagrant questions are permissible but in case they are the problem we are running into is that, even though we have apache and mysql well down the build chain, they seem to pop to the top and execute before we want them to, specifically before we get the repo updates in. I've tried just about every way of specifying order, down to removing the references to the cookbooks and calling them from later cookbooks, etc, but nothing seems to stop apache2 from installing first. 

Meaty part of the vagrantfile is:

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "CentOS-6.4-x86_64-v20130731"

  config.vm.box_url = "http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130731.box"

  config.vm.network :forwarded_port, guest: DEVELOPMENT_PORT, host: DEVELOPMENT_PORT

  config.vm.network :forwarded_port, guest: 3306, host: DEVELOPMENT_PORT + 1

  config.vm.network :private_network, ip: DEVELOPMENT_IP

  

  config.vm.synced_folder "src", SITES_FOLDER + '/' + SITE_NAME, id: "src"

  config.vm.synced_folder "content", SITES_FOLDER + '/' + SITE_NAME + "/content-source"

  config.vm.provider :virtualbox do |vb|  

    vb.customize ["modifyvm", :id, "--memory", "2048", "--cpus", "2"]

  end

  

  

  config.vm.provision :chef_solo do |chef|

      

    chef.cookbooks_path = "chef/cookbooks"

    chef.json = { 

    :listen_ports => [DEVELOPMENT_PORT],

    :sitename => SITE_NAME,

:sitemode => SITE_MODE,

:sitesfolder => SITES_FOLDER,

:dbfolder => SITES_FOLDER + '/' + SITE_NAME + '/content-source',

:db_server => DB_SERVER,

:siteurl => 'http://localhost:' + DEVELOPMENT_PORT.to_s,

:remote_root_user => ROOT_DB_USER,

:remote_root_password => ROOT_DB_PASSWORD,

:wordpress_db_user => SITE_DB_USER,

:wordpress_db_password => SITE_DB_PASSWORD,

:mysql => {

:server_root_password => ROOT_DB_PASSWORD,

:server_repl_password => ROOT_DB_PASSWORD,

:server_debian_password => ROOT_DB_PASSWORD

}

    }

chef.add_recipe "company-baseline-linux-server::enterprise-linux"

chef.add_recipe "company-baseline-linux-server"

chef.add_recipe "company-php-server"

    chef.add_recipe "company-mysql-server"

    chef.add_recipe "company-php-server::setup-website"

chef.add_recipe "company-wordpress-app"

chef.add_recipe "company-wordpress-app::copy-assets"

chef.add_recipe "company-wordpress-app::load-wordpress-db"

  end

end

The company-php-server::default recipe looks like:

#set apache ports

node.default['apache']['listen_ports'] = node['listen_ports']

#setup apache default modules

node.default['apache']['default_modules'] = %w(status alias rewrite headers deflate dir env mod_proxy mod_proxy_http mime negotiation setenvif authz_default authz_host log_config logio)

include_recipe "apache2"

include_recipe "apache2::mod_ssl"

#set apache to autostart

execute "auto start apache" do

command "chkconfig httpd on"

end

#add php

include_recipe "php"

include_recipe "apache2::mod_php5"

include_recipe "php::module_mysql"

#disable iptables for now

include_recipe "iptables::disabled"

#kill default site

apache_site "default" do

  enable false

end

and the company-mysql-server looks like:

node.default["mysql"]["remove_anonymous_users"] = true

include_recipe "mysql::server"

#setup remote database user

include_recipe "database"

include_recipe "database::mysql"

mysql_connection_info = {

  :host => node['dbserver'],

  :username => 'root',

  :port => node['mysql']['port'],

  :password => node['mysql']['server_root_password']

}

dbuser = node['remote_root_user']

dbpassword = node['remote_root_password']

mysql_database_user dbuser do

  connection    mysql_connection_info

  password      dbpassword

  host '%'

  grant_option true

  action        :grant

  only_if { node['remote_root_user'] }

end

mysql_database_user dbuser do

  connection    mysql_connection_info

  password      dbpassword

  host 'localhost'

  grant_option  true

  action        :grant

  only_if { node['remote_root_user'] }

end

Any idea what I'm doing wrong? 

[Simon McCartney]

Yeah, this is a chef issue, made cloudy by Chef's lack of a sensible
dependency model & two-phase compile/execute things.

I'm not sure how or where you are managing your repos, but you can force
a repo update at compile time by putting something like this one of your
recipes:


execute "compile-time-apt-get-update" do
command "apt-get update"
ignore_failure true
action :nothing
end.run_action(:run)

This means that before any packages are attempted to be installed, the
repo update will have occurred (assuming you're not using a similar hack
to install packages at a certain point ;))

(obviously "apt-get update" is for Debian/Ubuntu, replace with "yum
update" or whatever works for you.)


Simon.

> --
> You received this message because you are subscribed to the Google
> Groups "Vagrant" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to vagrant-up+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Simon McCartney
si...@mccartney.ie
+44 7710 836 915

[Wyatt Barnett]

Thanks for confirming my suspicions. Do you know of a good chef oriented place to ask this question? 

I'm guessing that end.run_action(:run) would force execution when it is hit rather than going through chef's murky pipeline? So if we were to slap that all over the company-baseline-linux cookbooks that would force execution in the proper order?

I'm also guessing based on your comments a concept like we are using where we've got infrastructure cookbooks then stuff that runs on top of it won't quite work?

[Wyatt Barnett]

Also, this is the output of the 1st part of the chef run. Once it gets back into our cookbooks it does the right thing, and the EPEL is at the beginning of our cookbooks

[2013-11-29T00:53:48+00:00] INFO: Forking chef instance to converge...

[2013-11-29T00:53:48+00:00] INFO: *** Chef 11.6.0 ***

[2013-11-29T00:53:48+00:00] INFO: Setting the run_list to ["recipe[company-baseline-linux-server::enterprise-linux]", "recipe[company-baseline-linux-server]", "recipe[company-php-server]", "recipe[company-mysql-server]", "recipe[company-php-server::setup-website]", "recipe[company-wordpress-app]", "recipe[company-wordpress-app::copy-assets]", "recipe[company-wordpress-app::load-wordpress-db]"] from JSON

[2013-11-29T00:53:48+00:00] INFO: Run List is [recipe[company-baseline-linux-server::enterprise-linux], recipe[company-baseline-linux-server], recipe[company-php-server], recipe[company-mysql-server], recipe[company-php-server::setup-website], recipe[company-wordpress-app], recipe[company-wordpress-app::copy-assets], recipe[company-wordpress-app::load-wordpress-db]]

[2013-11-29T00:53:48+00:00] INFO: Run List expands to [company-baseline-linux-server::enterprise-linux, company-baseline-linux-server, company-php-server, company-mysql-server, company-php-server::setup-website, company-wordpress-app, company-wordpress-app::copy-assets, company-wordpress-app::load-wordpress-db]

[2013-11-29T00:53:48+00:00] INFO: Starting Chef Run for localhost

[2013-11-29T00:53:48+00:00] INFO: Running start handlers

[2013-11-29T00:53:48+00:00] INFO: Start handlers complete.

[2013-11-29T00:53:49+00:00] WARN: Cloning resource attributes for service[apache2] from prior resource (CHEF-3694)

[2013-11-29T00:53:49+00:00] WARN: Previous service[apache2]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/apache2/recipes/default.rb:24:in `from_file'

[2013-11-29T00:53:49+00:00] WARN: Current  service[apache2]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/apache2/recipes/default.rb:210:in `from_file'

[2013-11-29T00:53:49+00:00] WARN: Cloning resource attributes for file[/etc/httpd/conf.d/ssl.conf] from prior resource (CHEF-3694)

[2013-11-29T00:53:49+00:00] WARN: Previous file[/etc/httpd/conf.d/ssl.conf]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/apache2/recipes/default.rb:84:in `block in from_file'

[2013-11-29T00:53:49+00:00] WARN: Current  file[/etc/httpd/conf.d/ssl.conf]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/apache2/recipes/mod_ssl.rb:28:in `from_file'

[2013-11-29T00:53:49+00:00] WARN: Cloning resource attributes for template[/etc/httpd/ports.conf] from prior resource (CHEF-3694)

[2013-11-29T00:53:49+00:00] WARN: Previous template[/etc/httpd/ports.conf]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/apache2/recipes/default.rb:185:in `from_file'

[2013-11-29T00:53:49+00:00] WARN: Current  template[/etc/httpd/ports.conf]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/apache2/recipes/mod_ssl.rb:34:in `from_file'

[2013-11-29T00:53:49+00:00] WARN: Cloning resource attributes for execute[a2dissite default] from prior resource (CHEF-3694)

[2013-11-29T00:53:49+00:00] WARN: Previous execute[a2dissite default]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/apache2/definitions/apache_site.rb:34:in `block in from_file'

[2013-11-29T00:53:49+00:00] WARN: Current  execute[a2dissite default]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/apache2/definitions/apache_site.rb:34:in `block in from_file'

[2013-11-29T00:53:49+00:00] WARN: Cloning resource attributes for directory[/var/lib/mysql] from prior resource (CHEF-3694)

[2013-11-29T00:53:49+00:00] WARN: Previous directory[/var/lib/mysql]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/mysql/recipes/server.rb:117:in `block in from_file'

[2013-11-29T00:53:49+00:00] WARN: Current  directory[/var/lib/mysql]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/mysql/recipes/server.rb:117:in `block in from_file'

[2013-11-29T00:53:49+00:00] WARN: Cloning resource attributes for template[/etc/my.cnf] from prior resource (CHEF-3694)

[2013-11-29T00:53:49+00:00] WARN: Previous template[/etc/my.cnf]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/mysql/recipes/server.rb:134:in `from_file'

[2013-11-29T00:53:49+00:00] WARN: Current  template[/etc/my.cnf]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/mysql/recipes/server.rb:194:in `from_file'

[2013-11-29T00:53:49+00:00] INFO: Could not find previously defined grants.sql resource

[2013-11-29T00:54:36+00:00] INFO: package[mysql] installing mysql-5.1.69-1.el6_4 from updates repository

[2013-11-29T00:54:47+00:00] INFO: package[mysql-devel] installing mysql-devel-5.1.69-1.el6_4 from updates repository

[2013-11-29T00:55:18+00:00] WARN: Cloning resource attributes for mysql_database_user[wordpress-dba] from prior resource (CHEF-3694)

[2013-11-29T00:55:18+00:00] WARN: Previous mysql_database_user[wordpress-dba]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/company-mysql-server/recipes/default.rb:27:in `from_file'

[2013-11-29T00:55:18+00:00] WARN: Current  mysql_database_user[wordpress-dba]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/company-mysql-server/recipes/default.rb:36:in `from_file'

[2013-11-29T00:55:18+00:00] WARN: Cloning resource attributes for link[/etc/httpd/sites-enabled/cabletechtalk] from prior resource (CHEF-3694)

[2013-11-29T00:55:18+00:00] WARN: Previous link[/etc/httpd/sites-enabled/cabletechtalk]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/company-php-server/recipes/setup-website.rb:14:in `from_file'

[2013-11-29T00:55:18+00:00] WARN: Current  link[/etc/httpd/sites-enabled/cabletechtalk]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/company-php-server/recipes/setup-website.rb:19:in `from_file'

[2013-11-29T00:55:18+00:00] WARN: Cloning resource attributes for link[/srv/websites/cabletechtalk/webroot/wp-config.php] from prior resource (CHEF-3694)

[2013-11-29T00:55:18+00:00] WARN: Previous link[/srv/websites/cabletechtalk/webroot/wp-config.php]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/company-wordpress-app/recipes/default.rb:13:in `from_file'

[2013-11-29T00:55:18+00:00] WARN: Current  link[/srv/websites/cabletechtalk/webroot/wp-config.php]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/company-wordpress-app/recipes/default.rb:18:in `from_file'

[2013-11-29T00:55:18+00:00] WARN: Cloning resource attributes for service[httpd] from prior resource (CHEF-3694)

[2013-11-29T00:55:18+00:00] WARN: Previous service[httpd]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/company-php-server/recipes/setup-website.rb:23:in `from_file'

[2013-11-29T00:55:18+00:00] WARN: Current  service[httpd]: /tmp/vagrant-chef-1/chef-solo-1/cookbooks/company-wordpress-app/recipes/default.rb:22:in `from_file'

[2013-11-29T00:55:18+00:00] INFO: Adding RPM-GPG-KEY-EPEL-6 GPG key to /etc/pki/rpm-gpg/

[2013-11-29T00:55:18+00:00] INFO: remote_file[/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6] created file /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

[2013-11-29T00:55:23+00:00] INFO: remote_file[/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6] updated file contents /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

[2013-11-29T00:55:23+00:00] INFO: remote_file[/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6] mode changed to 644

[2013-11-29T00:55:23+00:00] INFO: remote_file[/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6] sending run action to execute[import-rpm-gpg-key-RPM-GPG-KEY-EPEL-6] (immediate)

[2013-11-29T00:55:24+00:00] INFO: execute[import-rpm-gpg-key-RPM-GPG-KEY-EPEL-6] ran successfully

[2013-11-29T00:55:24+00:00] INFO: Adding epel repository to /etc/yum.repos.d/epel.repo

[2013-11-29T00:55:24+00:00] INFO: template[/etc/yum.repos.d/epel.repo] created file /etc/yum.repos.d/epel.repo

[2013-11-29T00:55:24+00:00] INFO: template[/etc/yum.repos.d/epel.repo] updated file contents /etc/yum.repos.d/epel.repo

[2013-11-29T00:55:24+00:00] INFO: template[/etc/yum.repos.d/epel.repo] mode changed to 644

[2013-11-29T00:55:24+00:00] INFO: template[/etc/yum.repos.d/epel.repo] sending run action to execute[yum-makecache-epel] (immediate)

[Chris Fordham]

Don't pollute vagrant with your chef problems.

The default recipe of the apt cookbook does effecitvely apt-get update for you.

Chef has many channels to seek support - irc, mailing lists, forums, bug tracker, etc. use those.

[Simon McCartney]

Wyatt Barnett wrote:
> Thanks for confirming my suspicions. Do you know of a good chef oriented
> place to ask this question?

The Chef community is supposed to be Awesome! (tm), have you tried
around #chef on freenode?

> I'm guessing that end.run_action(:run) would force execution when it is
> hit rather than going through chef's murky pipeline? So if we were to
> slap that all over the company-baseline-linux cookbooks that would force
> execution in the proper order?

That would force that resource to be executed during the compile phase,
and the ordering should be pretty straightforward at that stage (i.e.
the runlist being built from your roles & recipes etc).

> I'm also guessing based on your comments a concept like we are using
> where we've got infrastructure cookbooks then stuff that runs on top of
> it won't quite work?

The wrapped cookbook model? That's what we use, it works pretty well,
if feeling a little verbose at times (as in we pull in a public nginx
cookbook & then wrap it in a nginx_ours cookbook, so we only ever use
recipes from nginx_ours & nginx_ours includes the generic bits we want.

These articles are some of the ones we used to figure our way through this:

*
http://realityforge.org/code/2012/11/19/role-cookbooks-and-wrapper-cookbooks.html
* http://dougireton.com/blog/2013/02/16/chef-cookbook-anti-patterns/
* http://red-badger.com/blog/2013/06/24/berkshelf-application-cookbooks/
*
http://devopsanywhere.blogspot.co.uk/2012/11/how-to-write-reusable-chef-cookbooks.html

Also, if you're not already using Berkshelf, I throughly recommend you do :)

[Simon McCartney]

Wyatt Barnett wrote:
> I'm also guessing based on your comments a concept like we are using
> where we've got infrastructure cookbooks then stuff that runs on top of
> it won't quite work?

I've just re-read what you wrote & I misunderstood you the first time :)

So yeah, the infrastructure cookbooks running first and then your app
stuff running on top should be fine, it just trips up every now & then,
the runlist ordering is supposed to be maintained.

[Wyatt Barnett]

Thanks -- the wrapped cookbook model is exactly what we are aiming for here. Little easier to have a layer of indirection in ruby than trying to figure out how to do it with node attributes. The links were a great read. I wish I had found berkeshelf six weeks ago . . .

Now to force this run list to run in order. Off to IRC . . . 

[Wyatt Barnett]

Thanks again for all the help Simon, I ventured into Chef's IRC chatroom and someone helped me find the answer. The underlying issue was that I was using the opscode database cookbook to pull in some of the mysql parts. Said cookbook forced the install of the mysql ruby gem which in turn forced mysql to get installed early on. Removing the cancer [database cookbook] and using some shell scripts to create users solved all.

[Chris Fordham]

On Tue, Dec 3, 2013 at 12:45 AM, Wyatt Barnett <wyatt....@gmail.com> wrote:

Thanks again for all the help Simon, I ventured into Chef's IRC chatroom and someone helped me find the answer. The underlying issue was that I was using the opscode database cookbook to pull in some of the mysql parts. Said cookbook forced the install of the mysql ruby gem which in turn forced mysql to get installed early on. Removing the cancer [database cookbook] and using some shell scripts to create users solved all.

Except shell scripts is not how you do chef :)
 

On Sunday, December 1, 2013 11:03:16 AM UTC-5, Wyatt Barnett wrote:

Thanks -- the wrapped cookbook model is exactly what we are aiming for here. Little easier to have a layer of indirection in ruby than trying to figure out how to do it with node attributes. The links were a great read. I wish I had found berkeshelf six weeks ago . . .

Now to force this run list to run in order. Off to IRC . . . 

On Friday, November 29, 2013 11:40:52 AM UTC-5, Simon McCartney wrote:

Wyatt Barnett wrote:
> I'm also guessing based on your comments a concept like we are using
> where we've got infrastructure cookbooks then stuff that runs on top of
> it won't quite work?


I've just re-read what you wrote & I misunderstood you the first time :)

So yeah, the infrastructure cookbooks running first and then your app
stuff running on top should be fine, it just trips up every now & then,
the runlist ordering is supposed to be maintained.

--
Simon McCartney
si...@mccartney.ie
+44 7710 836 915

--
You received this message because you are subscribed to a topic in the Google Groups "Vagrant" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vagrant-up/RAya-5pe9lQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vagrant-up+...@googlegroups.com.

[Wyatt Barnett]

Fair point. Then again most of the recipies I've seen aren't much more than wrappers around shell commands perhaps with a case statement to differentiate by platform. 

How would you have solved it?

[Chris Fordham]

On Thu, Dec 5, 2013 at 12:16 AM, Wyatt Barnett <wyatt....@gmail.com> wrote:

Fair point. Then again most of the recipies I've seen aren't much more than wrappers around shell commands perhaps with a case statement to differentiate by platform. 

How would you have solved it?

This isn't the place for Chef support and help, but there is a user and group resource as well as a users cookbook. You must be looking at poorly designed cookbooks.

[Wyatt Barnett]

Thanks, those were really handy to create system users. They didn't help create us mysql users unless I missed something.

All the cookbooks were the official opscode ones and appeared to be regularly maintained examples of those, if those are poorly designed where should one go?

[Chris Fordham]

On Thu, Dec 5, 2013 at 2:37 PM, Wyatt Barnett <wyatt....@gmail.com> wrote:

Thanks, those were really handy to create system users. They didn't help create us mysql users unless I missed something.

For database users, there is an LWRP in the database cookbook, see https://github.com/opscode-cookbooks/database#database_user

All the cookbooks were the official opscode ones and appeared to be regularly maintained examples of those, if those are poorly designed where should one go?

I think you were generalising too much and didn't cite examples of 'wrappers around shell commands'. Sometimes using an execute or script resource is the best practice, but these are not wrappers, they are called resources and they have meaning.

[Wyatt Barnett]

Gotcha. I'm not really horribly philosophical about those things myself. 

Anyhow, that was exactly the cookbook that was causing us problems because it insists on installing MySql::Ruby way, way up front. 

[Chris Fordham]

On Fri, Dec 6, 2013 at 12:20 AM, Wyatt Barnett <wyatt....@gmail.com> wrote:

Gotcha. I'm not really horribly philosophical about those things myself. 

Anyhow, that was exactly the cookbook that was causing us problems because it insists on installing MySql::Ruby way, way up front.

It may of been causing problems because you designed things wrongly. Alas, this isn't a Chef channel.