I would rather recommend to use a role which name reflects the cluster name and apply it to all nodes in the cluster. After that use the same approach as described in the mentioned cookbook but search by cluster name role.
Max
I would rather recommend to use a role which name reflects the cluster name and apply it to all nodes in the cluster. After that use the same approach as described in the mentioned cookbook but search by cluster name role.
Max
On Apr 6, 2012 10:57 AM, "Jay Feldblum" < " target="_blank"> > wrote:Roles as data is OK, depending on what you need and what you're dealing with.Just make sure you've got a good naming scheme so that it's crystal clear which roles are part of your infrastructure's code (and therefore are saved as Ruby files in your Git repository) and which roles are part of your infrastructure's data (and therefore are only known to the Chef Server and then only as pure JSON, and never touch your disk or your Git repository or any of the infrastructure's Ruby code).For example, you could name a role of the second category something like dyna-hosts-cluster-88b639a3, where in this example the prefix dyna- for any role in the example's infrastructure is defined to mean a role of the second category. This is just an example, of course, so pick a naming scheme that works for you.Cheers,Jay FeldblumOn Fri, Apr 6, 2012 at 1:38 PM, Brad Montgomery < " target="_blank"> > wrote:
Just to be clear, I create a single role for the cluster, and specify
all nodes in that role. Then, apply that role to every machine. I'm
not sure I made that clear in my last email, and I'm sure there's
probably a better way to do it. I've also done similar things to what
you've described in a data bag.
Do all of your clusters also need to know about each other?
On Fri, Apr 6, 2012 at 10:27 AM, Van Fossan,Randy < " target="_blank"> > wrote:
> Thanks Brad,
>
> There are some nice things in that cookbook that I may rethink in my hosts cookbook.
>
> However, the issue for specifying all the nodes in a cluster when running the bootstrap on a particular node remains.
>
> The only solution I have come up with is to use a databag that describes each cluster and it's nodes or to create a custom role for each cluster..
>
> Randy
>
> -----Original Message-----
> From: " target="_blank"> [mailto: " target="_blank"> ] On Behalf Of Brad Montgomery
> Sent: Friday, April 06, 2012 11:09 AM
> To: " target="_blank">
> Subject: [chef] Re: multiple clusters and attributes
>
> We've got a recipe to do this... you create a role, and then an attribute that just lists all the hostnames. The recipe then looks up their ip addresses and writes the /etc/hosts file.
>
> There's probably a better way to do this, but this works for us.
>
> You can see our recipe, here:
> https://github.com/coroutine/chef-hosts
>
> On Fri, Apr 6, 2012 at 9:05 AM, Van Fossan,Randy < " target="_blank"> > wrote:
>> How are you guys handling attributes for multiple systems (like clusters)??
>>
>>
>>
>> For example, in cluster, I need to be able to add all nodes in the
>> cluster to the /etc/hosts file on each cluster node. I am not sure
>> of the best method for setting / adding attributes for these entries
>> without creating something like a separate role for each cluster.
>>
>>
>>
>> I already have a hosts cookbook to add additional entries if the
>> attribute has data. I just do not know how to populate that array
>> differently for different clusters.
>>
>>
>>
>> Anyone have any suggestions or ideas?
>>
>>
>>
>> Thanks
>> Randy
>
>
Archive powered by MHonArc 2.6.16.