"Bind mount check failed" error on non-EC2 infrastructure

[mikegreiling]

opsworks_deploy_dir produces Bind mount check failed for xxxxx errors when node[:opsworks][:instance][:infrastructure_class] is not set to "ec2".

https://github.com/aws/opsworks-cookbooks/blob/b0b56ff/deploy/definitions/opsworks_deploy_dir.rb#L9

This appears to be due to the bind_mounts recipe not being called within opsworks_initial_setup.

https://github.com/aws/opsworks-cookbooks/blob/b0b56f/opsworks_initial_setup/recipes/default.rb#L8

[workeitel]

Good catch. We will change bash["Check for bind mounts before creating the deploy directory"] to verify infrastructure_class.

One question: Does this fail the complete chef run or just produce a error and move on?

[mikegreiling]

Just produces an error message and moves on, so fixing this is more for the sake of cleaning up my logs and reducing confusion.

[duttski]

Hi,

There is a pull request related to this: #342

However...

I wondered if rather than disabling the ability to check this bind mount presence, it should be removed from the default attribute configuration. E.g.

in opsworks_initial_setup/attributes/defaults.rb:

if infrastructure_class?('ec2')
  default[:opsworks_initial_setup][:bind_mounts][:mounts] = {
   "/var/log/mysql" => "#{node[:opsworks_initial_setup][:ephemeral_mount_point]}/var/log/mysql",
   '/srv/www' => "#{node[:opsworks_initial_setup][:ephemeral_mount_point]}/srv/www",
   '/var/www' => "#{node[:opsworks_initial_setup][:ephemeral_mount_point]}/var/www",
  }
  case node[:platform]
  when 'redhat','centos','fedora','amazon'
    default[:opsworks_initial_setup][:bind_mounts][:mounts]['/var/log/httpd'] = "#{node[:opsworks_initial_setup][:ephemeral_mount_point]}/var/log/apache2"
  when 'debian','ubuntu'
    default[:opsworks_initial_setup][:bind_mounts][:mounts]['/var/log/apache2'] = "#{node[:opsworks_initial_setup][:ephemeral_mount_point]}/var/log/apache2"
  end
end

Not sure if people want to use the bind mount checks in non-EC2 scenarios and the above PR would both leave the configuration kicking about and stop people from using this functionality where needed.

Note that it's not just ugly logs, it also has a sleep in the loop checking (and trying again) so it will add unnecessary time to deploys. (18-24s, , depending setup).

Also note that if non-EC2 people happen to be relying on this check but haven't explicitly implemented the check/configuration then this could become a breaking change for them (and one that will bite some-time-later). Guessing this should be made clear in any release notes.

~

Happy to set up a PR if the above is preferred in the community, but want to check with the experts first!