pentaho::i_am_the_nfs_server_for_pentaho

gistfile1.txt

# register with cluster_service_discovery
provide_service("nfs-server-for-pentaho")

include_recipe "nfs::server"

# I think there's the potential for a chicken-and-egg issue here, where the NFS server doesn't 
# know who to set up exports for, and the clients fail mounting an NFS share that has no permissions.

searchenv = node[:pentaho][:nfs_environment] ? node[:pentaho][:nfs_environment] : nil
nfs_clients = all_provider_private_ips_services("nfs-client-for-pentaho", :ignore_cluster => true, searchenv.to_a)
Chef::Log.info "I found #{nfs_clients.count} NFS clients."
nfs_clients.count > 0 ? allowed = nfs_clients.join(" ") : allowed = "*"

nfs_export node[:pentaho][:export_dir] do
  allowed allowed
  options "rw,no_root_squash"
end

Notice the searchenv parameter that gets passed into the all_provider_private_ips_services method. I think, when I patched up the cluster_service_discovery library (site-cookbooks/cluster_service_discovery/libraries/cluster_service_discovery.rb), I...

caught the many-to-one relationship (many NFS clients needing to talk to one NFS server)
but I missed the one-to-many relationship that is also possible (one NFS server serving servers in many environments).

Maybe looping through the override_environment attribute with each would fix the one-to-many relationship?

I think that if I were to loop through override_environment with each, I would do it in the build_cluster_query method.