Hi.
Thanks for the answer but there seems to be a little misunderstanding.
What I was mostly complaining about was that I want to separate the AWS specific things from the definition of what machines I want to build.
In other words, I want to be able to build a 7 machine cluster and with relative ease, I want to be able to do that on more than one environment (say AWS, our private EC2 compliant cloud, Rackspace, etc).
In your example, you've fixed the driver to aws inside the "machine definition ruby script".
I'm going to play around with what you said about passing attributes into these scripts, If I do that I can probably have a set of attributes for each driver type. But I'm not quite sure how to proceed since my machine building ruby script isn't actually
a recipe, it's just a ruby file that's not a part of a cookbook. Maybe that's part of my problem, should this be an actual recipe?
At any rate, I think the time has come for some documentation about what the proper ways to do chef-provisioning are. At least I haven't been able to find it.
But I'm curious, why should I use the aws_driver instead of fog? Is fog being deprecated? I haven't seen anything about that?
-Stefan Freyr.
From: Tyler Ball <
>
Sent: Monday, April 13, 2015 4:25 PM To: Subject: [chef] Re: chef-provisioning best practices for supporting multiple configurations For creating different types of machines, you can directly set `machine_options` as an attribute on `machine`:
If you are provisioning in AWS, you should also be using chef-provisioning-aws instead of chef-provisioning-fog.
The hash you set on :bootstrap_options can come from an attribute, set at a role or environment level.
Your provisioning run_list looks fine to me - what about running multiple recipes (a base recipe and different recipes for different machine sizes) makes you uncomfortable?
-T
|
Archive powered by MHonArc 2.6.16.