| activity | item | |
|---|---|---|
|
Nov 05
|
Question Edited |
hosts file for oracle rac nodes
Fellow chefs
First I thought I could use search to find them based on a role for each cluster so they get updated automatically if I add a rac node but it appears ohai currently doesn’t grab IPs on multi-homed nodes correctly or if it does there is too much guesswork. Furthermore the virtuals are IP aliases which I don’t think ohai grabs at all. On top of that all interfaces are bonded and I haven’t even tried that with ohai. Most software has trouble with that as well. There is also a 3rd bonding interface for storage with another private address. So search seems risky for me at this point since these hostsfiles must be stable so I tried a simple, next-best approach. I created cook book “hosts” with the following: Attributes : #
Role: #
Default recipe: #
Template: #
It’s based on the idea that a normal host just gets the 2 localhost lines but a host that has the “devdbc01” role assigned gets the rac_members array of hashes expanded as well. It works well but I’m wondering whether there is something fundamentally wrong with this approach ? This is how I currently understand the use of roles and templates but I had some questions. The chef wiki templates section defines 2 default attributes and then passes them explicitly into the template via the “variables” option. If found that I didn’t have to do that since the template automatically expands node objects and a role is a node object is it not ? This extra step appears redundant. Am I missing something here ? Some folks argue that there should not be any ruby statements in templates for readability but opscode seems to encourage that. I’d think this is simply enough to place into the base template. Any input is appreciated and thank you for a great product ! thx |
|
Nov 05
|
Question Edited |
hosts file for oracle rac nodes
Fellow chefs
First I thought I could use search to find them based on a role for each cluster so they get updated automatically if I add a rac node but it appears ohai currently doesn’t grab IPs on multi-homed nodes correctly or if it does there is too much guesswork. Furthermore the virtuals are IP aliases which I don’t think ohai grabs at all. On top of that all interfaces are bonded and I haven’t even tried that with ohai. Most software has trouble with that as well. There is also a 3rd bonding interface for storage with another private address. So search seems risky for me at this point since these hostsfiles must be stable so I tried a simple, next-best approach. I created cook book “hosts” with the following: Attributes : #
Role: #
Default recipe: #
Template: #
It’s based on the idea that a normal host just gets the 2 localhost lines but a host that has the “devdbc01” role assigned gets the rac_members array of hashes expanded as well. It works well but I’m wondering whether there is something fundamentally wrong with this approach ? This is how I currently understand the use of roles and templates but I had some questions. The chef wiki templates section defines 2 default attributes and then passes them explicitly into the template via the “variables” option. If found that I didn’t have to do that since the template automatically expands node objects and a role is a node object is it not ? This extra step appears redundant. Am I missing something here ? Some folks argue that there should not be any ruby statements in templates for readability but opscode seems to encourage that. I’d think this is simply enough to place into the base template. Any input is appreciated and thank you for a great product ! thx |
|
Nov 05
|
Question Edited |
hosts file for oracle rac nodes
Fellow chefs
First I thought I could use search to find them based on a role for each cluster so they get updated automatically if I add a rac node but it appears ohai currently doesn’t grab IPs on multi-homed nodes correctly or if it does there is too much guesswork. Furthermore the virtuals are IP aliases which I don’t think ohai grabs at all. On top of that all interfaces are bonded and I haven’t even tried that with ohai. Most software has trouble with that as well. There is also a 3rd bonding interface for storage with another private address. So search seems risky for me at this point since these hostsfiles must be stable so I tried a simple, next-best approach. I created cook book “hosts” with the following: Attributes : #
Role: #
Default recipe: #
Template: #
It’s based on the idea that a normal host just gets the 2 localhost lines but a host that has the “devdbc01” role assigned gets the rac_members array of hashes expanded as well. It works well but I’m wondering whether there is something fundamentally wrong with this approach ? This is how I currently understand the use of roles and templates but I had some questions. The chef wiki templates section defines 2 default attributes and then passes them explicitly into the template via the “variables” option. If found that I didn’t have to do that since the template automatically expands node objects and a role is a node object is it not ? This extra step appears redundant. Am I missing something here ? Some folks argue that there should not be any ruby statements in templates for readability but opscode seems to encourage that. I’d think this is simply enough to place into the base template. Any input is appreciated and thank you for a great product ! thx |
|
Nov 05
|
Following Question |
hosts file for oracle rac nodes
Fellow chefs
First I thought I could use search to find them based on a role for each cluster so they get updated automatically if I add a rac node but it appears ohai currently doesn’t grab IPs on multi-homed nodes correctly or if it does there is too much guesswork. Furthermore the virtuals are IP aliases which I don’t think ohai grabs at all. On top of that all interfaces are bonded and I haven’t even tried that with ohai. Most software has trouble with that as well. There is also a 3rd bonding interface for storage with another private address. So search seems risky for me at this point since these hostsfiles must be stable so I tried a simple, next-best approach. I created cook book “hosts” with the following: Attributes : #
Role: #
Default recipe: #
Template: #
It’s based on the idea that a normal host just gets the 2 localhost lines but a host that has the “devdbc01” role assigned gets the rac_members array of hashes expanded as well. It works well but I’m wondering whether there is something fundamentally wrong with this approach ? This is how I currently understand the use of roles and templates but I had some questions. The chef wiki templates section defines 2 default attributes and then passes them explicitly into the template via the “variables” option. If found that I didn’t have to do that since the template automatically expands node objects and a role is a node object is it not ? This extra step appears redundant. Am I missing something here ? Some folks argue that there should not be any ruby statements in templates for readability but opscode seems to encourage that. I’d think this is simply enough to place into the base template. Any input is appreciated and thank you for a great product ! thx |
|
Nov 05
|
New Question |
hosts file for oracle rac nodes
Fellow chefs
First I thought I could use search to find them based on a role for each cluster so they get updated automatically if I add a rac node but it appears ohai currently doesn’t grab IPs on multi-homed nodes correctly or if it does there is too much guesswork. Furthermore the virtuals are IP aliases which I don’t think ohai grabs at all. On top of that all interfaces are bonded and I haven’t even tried that with ohai. Most software has trouble with that as well. There is also a 3rd bonding interface for storage with another private address. So search seems risky for me at this point since these hostsfiles must be stable so I tried a simple, next-best approach. I created cook book “hosts” with the following: Attributes : #
Role: #
Default recipe: #
Template: #
It’s based on the idea that a normal host just gets the 2 localhost lines but a host that has the “devdbc01” role assigned gets the rac_members array of hashes expanded as well. It works well but I’m wondering whether there is something fundamentally wrong with this approach ? This is how I currently understand the use of roles and templates but I had some questions. The chef wiki templates section defines 2 default attributes and then passes them explicitly into the template via the “variables” option. If found that I didn’t have to do that since the template automatically expands node objects and a role is a node object is it not ? This extra step appears redundant. Am I missing something here ? Some folks argue that there should not be any ruby statements in templates for readability but opscode seems to encourage that. I’d think this is simply enough to place into the base template. Any input is appreciated and thank you for a great product ! thx |
|
Jun 19
|
Question Edited |
Grouping similar OS types once instead of multiple times
Chefs when “redhat”,“centos”,“fedora”,“scientific” package “ntp” do
end and when “redhat”,“centos”,“fedora”,“scientific” # ntpstats dir doesn’t exist on RHEL/CentOS else and then again in the cookbook attributes : case platform when “ubuntu”,“debian” default[:ntp][:service] = “ntp” when “redhat”,“centos”,“fedora”,“scientific” default[:ntp][:service] = “ntpd” Wouldn’t it make more sense to define this grouping once (maybe in a data bag?) and then pull it from anywhere whenever you need it ? Any thoughts would be appreciated. |
|
Jun 19
|
New Question |
Grouping similar OS types once instead of multiple times
Chefs when “redhat”,“centos”,“fedora”,“scientific” package “ntp” do
end and when “redhat”,“centos”,“fedora”,“scientific” # ntpstats dir doesn’t exist on RHEL/CentOS else and then again in the cookbook attributes : case platform when “ubuntu”,“debian” default[:ntp][:service] = “ntp” when “redhat”,“centos”,“fedora”,“scientific” default[:ntp][:service] = “ntpd” Wouldn’t it make more sense to define this grouping once (maybe in a data bag?) and then pull it from anywhere whenever you need it ? Any thoughts would be appreciated. |
|
Jun 19
|
Following Question |
Attributes in metadata.rb
Fellow chefs It appears all cookbooks set attributes in metadata.rb eventhough as per documentation chef ignores those. Example from metadata.rb from the ntp cookbook: attribute “ntp/servers”, :display_name => “NTP Servers”, :description => “Array of servers we should talk to”, :type => “array”, :default => [“0.pool.ntp.org”, “1.pool.ntp.org” ] I did a test by removing all other places where this attribute is set. In this case chef fails since ntp servers is not defined so this confirms that chef doesn’t read these. It looks like there is one cloudprovider named Rightscale that forces you to duplicate your attributes into metadata.rb for their dashboard. My assumption is that this is why official cookbooks have this added by default. Can anyone confirm deny that Rightscale is currently the only provider that requires this ? thx |
|
Jun 19
|
New Question |
Attributes in metadata.rb
Fellow chefs It appears all cookbooks set attributes in metadata.rb eventhough as per documentation chef ignores those. Example from metadata.rb from the ntp cookbook: attribute “ntp/servers”, :display_name => “NTP Servers”, :description => “Array of servers we should talk to”, :type => “array”, :default => [“0.pool.ntp.org”, “1.pool.ntp.org” ] I did a test by removing all other places where this attribute is set. In this case chef fails since ntp servers is not defined so this confirms that chef doesn’t read these. It looks like there is one cloudprovider named Rightscale that forces you to duplicate your attributes into metadata.rb for their dashboard. My assumption is that this is why official cookbooks have this added by default. Can anyone confirm deny that Rightscale is currently the only provider that requires this ? thx |
