Doing what I read to be a best practice, I just took a bunch of roles that
defined set attributes for specific data centers, and moved them into
cookbooks, one per location, ie:
bc-location-u1
bc-location.eu1
and so on. I just occurred to me that if I do this, then all cookbooks will
need to depend (in the metadata.rb) file on ALL of these location based
cookbooks.
is this correct? What am I missing?
Doug
Doug:
I’m not sure if you’re using EC2, but if so, and you’re launching instances using knife-ec2, you should have node[‘ec2’][‘placement_availability_zone’] available. You could build a single wrapper cookbook, that depends on that attribute’s value, and determines the requisite data center-specific attributes.
–
Jeff Byrnes
@berkleebassist
Operations Engineer
EverTrue
704.516.4628
On March 17, 2014 at 1:54:21 PM, Douglas Garstang (doug.garstang@gmail.com) wrote:
Doing what I read to be a best practice, I just took a bunch of roles that defined set attributes for specific data centers, and moved them into cookbooks, one per location, ie:
bc-location-u1
bc-location.eu1
and so on. I just occurred to me that if I do this, then all cookbooks will need to depend (in the metadata.rb) file on ALL of these location based cookbooks.
is this correct? What am I missing?
Doug
Jeff,
We are using EC2 (and GCE). However, we aren't using knife to provision
systems. We weren't able to get the knife ec2 plugin to work with an ssh
proxy and gave up in the end.
I just tried a different approach, where I have one cookbook, with one
recipe per location. This gets around the issue of having to depend on an
arbitrary list of location cookbooks in the metadata.rb of every cookbook
we write. However, the trade-off is that I have to do this:
include_recipe "bc-location::#{some-special-key-to-determine-location}"
every single time I need to access location data. This is horrid. I simply
can't understand why people keep saying not to use roles. Roles are just so
much more convenient. All the include magic is done automatically for you.
Douglas.
On Mon, Mar 17, 2014 at 11:23 AM, Jeff Byrnes jeff@evertrue.com wrote:
Doug:
I'm not sure if you're using EC2, but if so, and you're launching
instances using knife-ec2, you should have
node['ec2']['placement_availability_zone'] available. You could build a
single wrapper cookbook, that depends on that attribute's value, and
determines the requisite data center-specific attributes.--
Jeff Byrnes
@berkleebassist http://twitter.com/berkleebassist
Operations Engineer
EverTrue http://www.evertrue.com/
704.516.4628On March 17, 2014 at 1:54:21 PM, Douglas Garstang (doug.garstang@gmail.com)
wrote:Doing what I read to be a best practice, I just took a bunch of roles
that defined set attributes for specific data centers, and moved them into
cookbooks, one per location, ie:bc-location-u1
bc-location.eu1and so on. I just occurred to me that if I do this, then all cookbooks
will need to depend (in the metadata.rb) file on ALL of these location
based cookbooks.is this correct? What am I missing?
Doug
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
You don’t need to use knife-ec2 to get those attributes. Create /etc/chef/hints/ec2.json (empty file is fine) and ohai will automatically set a LOT of instance metadata attributes including ec2.placement_availability_zone.
On Monday, March 17, 2014 at 12:51 PM, Douglas Garstang wrote:
Jeff,
We are using EC2 (and GCE). However, we aren't using knife to provision systems. We weren't able to get the knife ec2 plugin to work with an ssh proxy and gave up in the end.
I just tried a different approach, where I have one cookbook, with one recipe per location. This gets around the issue of having to depend on an arbitrary list of location cookbooks in the metadata.rb of every cookbook we write. However, the trade-off is that I have to do this:
include_recipe "bc-location::#{some-special-key-to-determine-location}"
every single time I need to access location data. This is horrid. I simply can't understand why people keep saying not to use roles. Roles are just so much more convenient. All the include magic is done automatically for you.
Douglas.
On Mon, Mar 17, 2014 at 11:23 AM, Jeff Byrnes <jeff@evertrue.com (mailto:jeff@evertrue.com)> wrote:
Doug:
I’m not sure if you’re using EC2, but if so, and you’re launching instances using knife-ec2, you should have node['ec2']['placement_availability_zone'] available. You could build a single wrapper cookbook, that depends on that attribute’s value, and determines the requisite data center-specific attributes.
-- Jeff Byrnes
@berkleebassist (http://twitter.com/berkleebassist)
Operations Engineer
EverTrue (http://www.evertrue.com/)
704.516.4628 (tel:704.516.4628)On March 17, 2014 at 1:54:21 PM, Douglas Garstang (doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)) wrote:
Doing what I read to be a best practice, I just took a bunch of roles that defined set attributes for specific data centers, and moved them into cookbooks, one per location, ie:
bc-location-u1
bc-location.eu1and so on. I just occurred to me that if I do this, then all cookbooks will need to depend (in the metadata.rb) file on ALL of these location based cookbooks.
is this correct? What am I missing?
Doug
--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627
Daniel,
Using Jeff's approach above, I'd still need to use
include_recipe "bc-location::#{some-special-key-to-determine-location}"
in every situation where this data was needed, correct? Am I the only one
that thinks this is ugly?
Doug.
On Mon, Mar 17, 2014 at 12:59 PM, Daniel Condomitti
daniel@condomitti.comwrote:
You don't need to use knife-ec2 to get those attributes. Create
/etc/chef/hints/ec2.json (empty file is fine) and ohai will automatically
set a LOT of instance metadata attributes including
ec2.placement_availability_zone.On Monday, March 17, 2014 at 12:51 PM, Douglas Garstang wrote:
Jeff,
We are using EC2 (and GCE). However, we aren't using knife to provision
systems. We weren't able to get the knife ec2 plugin to work with an ssh
proxy and gave up in the end.I just tried a different approach, where I have one cookbook, with one
recipe per location. This gets around the issue of having to depend on an
arbitrary list of location cookbooks in the metadata.rb of every cookbook
we write. However, the trade-off is that I have to do this:include_recipe "bc-location::#{some-special-key-to-determine-location}"
every single time I need to access location data. This is horrid. I simply
can't understand why people keep saying not to use roles. Roles are just so
much more convenient. All the include magic is done automatically for you.Douglas.
On Mon, Mar 17, 2014 at 11:23 AM, Jeff Byrnes jeff@evertrue.com wrote:
Doug:
I'm not sure if you're using EC2, but if so, and you're launching
instances using knife-ec2, you should have
node['ec2']['placement_availability_zone'] available. You could build a
single wrapper cookbook, that depends on that attribute's value, and
determines the requisite data center-specific attributes.--
Jeff Byrnes
@berkleebassist http://twitter.com/berkleebassist
Operations Engineer
EverTrue http://www.evertrue.com/
704.516.4628On March 17, 2014 at 1:54:21 PM, Douglas Garstang (doug.garstang@gmail.com)
wrote:Doing what I read to be a best practice, I just took a bunch of roles
that defined set attributes for specific data centers, and moved them into
cookbooks, one per location, ie:bc-location-u1
bc-location.eu1and so on. I just occurred to me that if I do this, then all cookbooks
will need to depend (in the metadata.rb) file on ALL of these location
based cookbooks.is this correct? What am I missing?
Doug
--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
I would just include bc-location::default and place the location-detection logic in that recipe based on the EC2 availability zone or the GCE equivalent. You can always swap out how that’s handled (even a huge case statement for now just to get everything working if you’re facing a deadline) with a better approach later. This way you can keep all that ugly logic abstracted away and out of the rest of your cookbooks.
We use a combination of chef searches (service discovery), cookbook attributes (node-specific configuration like users and locations) and data bags (environment-specific configuration data and sensitive stuff like keys) which isn’t perfect but it works well for us.
On Monday, March 17, 2014 at 1:07 PM, Douglas Garstang wrote:
Daniel,
Using Jeff's approach above, I'd still need to use
include_recipe "bc-location::#{some-special-key-to-determine-location}"
in every situation where this data was needed, correct? Am I the only one that thinks this is ugly?
Doug.
On Mon, Mar 17, 2014 at 12:59 PM, Daniel Condomitti <daniel@condomitti.com (mailto:daniel@condomitti.com)> wrote:
You don’t need to use knife-ec2 to get those attributes. Create /etc/chef/hints/ec2.json (empty file is fine) and ohai will automatically set a LOT of instance metadata attributes including ec2.placement_availability_zone.
On Monday, March 17, 2014 at 12:51 PM, Douglas Garstang wrote:
Jeff,
We are using EC2 (and GCE). However, we aren't using knife to provision systems. We weren't able to get the knife ec2 plugin to work with an ssh proxy and gave up in the end.
I just tried a different approach, where I have one cookbook, with one recipe per location. This gets around the issue of having to depend on an arbitrary list of location cookbooks in the metadata.rb of every cookbook we write. However, the trade-off is that I have to do this:
include_recipe "bc-location::#{some-special-key-to-determine-location}"
every single time I need to access location data. This is horrid. I simply can't understand why people keep saying not to use roles. Roles are just so much more convenient. All the include magic is done automatically for you.
Douglas.
On Mon, Mar 17, 2014 at 11:23 AM, Jeff Byrnes <jeff@evertrue.com (mailto:jeff@evertrue.com)> wrote:
Doug:
I’m not sure if you’re using EC2, but if so, and you’re launching instances using knife-ec2, you should have node['ec2']['placement_availability_zone'] available. You could build a single wrapper cookbook, that depends on that attribute’s value, and determines the requisite data center-specific attributes.
-- Jeff Byrnes
@berkleebassist (http://twitter.com/berkleebassist)
Operations Engineer
EverTrue (http://www.evertrue.com/)
704.516.4628 (tel:704.516.4628)On March 17, 2014 at 1:54:21 PM, Douglas Garstang (doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)) wrote:
Doing what I read to be a best practice, I just took a bunch of roles that defined set attributes for specific data centers, and moved them into cookbooks, one per location, ie:
bc-location-u1
bc-location.eu1and so on. I just occurred to me that if I do this, then all cookbooks will need to depend (in the metadata.rb) file on ALL of these location based cookbooks.
is this correct? What am I missing?
Doug
--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627 (tel:%2B1-805-340-5627)--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com (mailto:doug.garstang@gmail.com)
Cell: +1-805-340-5627
Unfortunate that you had issues using knife-ec2 with an SSH gateway; I worked that out like so:
knife ec2 server create
–environment stage
–node-name stage-new-instance
–flavor m1.small
–ssh-gateway user@gateway
–ssh-user ec2-user
–security-group-ids sg-dd0bc0b6
–run-list "recipe[et_base]"
I’d encourage taking one last quick stab at using knife-ec2 for this, as it will simplify a lot of things.
As an aside, eventually, we avoided using an SSH proxy by forking knife-ec2 (see https://github.com/evertrue/knife-ec2) to not handle the initial provision directly, but instead by pushing user data to S3, and using a signed URL to bootstrap the node. See my compatriot’s commits at evertrue/knife-ec2.
–
Jeff Byrnes
@berkleebassist
Operations Engineer
EverTrue
704.516.4628
On March 17, 2014 at 4:12:52 PM, Daniel Condomitti (daniel@condomitti.com) wrote:
I would just include bc-location::default and place the location-detection logic in that recipe based on the EC2 availability zone or the GCE equivalent. You can always swap out how that’s handled (even a huge case statement for now just to get everything working if you’re facing a deadline) with a better approach later. This way you can keep all that ugly logic abstracted away and out of the rest of your cookbooks.
We use a combination of chef searches (service discovery), cookbook attributes (node-specific configuration like users and locations) and data bags (environment-specific configuration data and sensitive stuff like keys) which isn’t perfect but it works well for us.
On Monday, March 17, 2014 at 1:07 PM, Douglas Garstang wrote:
Daniel,
Using Jeff’s approach above, I’d still need to use
include_recipe “bc-location::#{some-special-key-to-determine-location}”
in every situation where this data was needed, correct? Am I the only one that thinks this is ugly?
Doug.
On Mon, Mar 17, 2014 at 12:59 PM, Daniel Condomitti daniel@condomitti.com wrote:
You don’t need to use knife-ec2 to get those attributes. Create /etc/chef/hints/ec2.json (empty file is fine) and ohai will automatically set a LOT of instance metadata attributes including ec2.placement_availability_zone.
On Monday, March 17, 2014 at 12:51 PM, Douglas Garstang wrote:
Jeff,
We are using EC2 (and GCE). However, we aren’t using knife to provision systems. We weren’t able to get the knife ec2 plugin to work with an ssh proxy and gave up in the end.
I just tried a different approach, where I have one cookbook, with one recipe per location. This gets around the issue of having to depend on an arbitrary list of location cookbooks in the metadata.rb of every cookbook we write. However, the trade-off is that I have to do this:
include_recipe “bc-location::#{some-special-key-to-determine-location}”
every single time I need to access location data. This is horrid. I simply can’t understand why people keep saying not to use roles. Roles are just so much more convenient. All the include magic is done automatically for you.
Douglas.
On Mon, Mar 17, 2014 at 11:23 AM, Jeff Byrnes jeff@evertrue.com wrote:
Doug:
I’m not sure if you’re using EC2, but if so, and you’re launching instances using knife-ec2, you should have node[‘ec2’][‘placement_availability_zone’] available. You could build a single wrapper cookbook, that depends on that attribute’s value, and determines the requisite data center-specific attributes.
–
Jeff Byrnes
@berkleebassist
Operations Engineer
EverTrue
704.516.4628
On March 17, 2014 at 1:54:21 PM, Douglas Garstang (doug.garstang@gmail.com) wrote:
Doing what I read to be a best practice, I just took a bunch of roles that defined set attributes for specific data centers, and moved them into cookbooks, one per location, ie:
bc-location-u1
bc-location.eu1
and so on. I just occurred to me that if I do this, then all cookbooks will need to depend (in the metadata.rb) file on ALL of these location based cookbooks.
is this correct? What am I missing?
Doug
–
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
–
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
Hi Douglas,
Our setup may be a bit different than yours but I have opted to use
environment data bag items. A lot of our settings, including the
environment name, flow down from the outputs on the CloudFormation VPC
template we use to launch the environment/vpc. We can setup arbitrary
environments and just generate a databag with specifics after it's up. The
environment name provided into the CloudFormation VPC flows down into other
infrastructure we provision into it. The bootstrap code on the ec2
instances sets the nodes environment based on this, then any recipe that
needs to can grab the environment databag to get endpoints for logging, our
API server, etc.
This has worked well for me with testing locally too. I have a "local"
environment databag item and set the environment to "local" in my Vagrant
file.
-Greg
On Tue, Mar 18, 2014 at 9:18 AM, Jeff Byrnes jeff@evertrue.com wrote:
Unfortunate that you had issues using knife-ec2 with an SSH gateway; I
worked that out like so:knife ec2 server create
--environment stage
--node-name stage-new-instance
--flavor m1.small
--ssh-gateway user@gateway
--ssh-user ec2-user
--security-group-ids sg-dd0bc0b6
--run-list "recipe[et_base]"I'd encourage taking one last quick stab at using knife-ec2 for this, as
it will simplify a lot of things.As an aside, eventually, we avoided using an SSH proxy by forking
knife-ec2 (see GitHub - evertrue/knife-ec2: Opscode Chef knife plug-in for EC2) to not handle the
initial provision directly, but instead by pushing user data to S3, and
using a signed URL to bootstrap the node. See my compatriot's commits at
evertrue/knife-ec2 https://github.com/evertrue/knife-ec2/commits/master.--
Jeff Byrnes
@berkleebassist http://twitter.com/berkleebassist
Operations Engineer
EverTrue http://www.evertrue.com/
704.516.4628On March 17, 2014 at 4:12:52 PM, Daniel Condomitti (daniel@condomitti.com)
wrote:I would just include bc-location::default and place the location-detection
logic in that recipe based on the EC2 availability zone or the GCE
equivalent. You can always swap out how that's handled (even a huge case
statement for now just to get everything working if you're facing a
deadline) with a better approach later. This way you can keep all that ugly
logic abstracted away and out of the rest of your cookbooks.We use a combination of chef searches (service discovery), cookbook
attributes (node-specific configuration like users and locations) and data
bags (environment-specific configuration data and sensitive stuff like
keys) which isn't perfect but it works well for us.On Monday, March 17, 2014 at 1:07 PM, Douglas Garstang wrote:
Daniel,
Using Jeff's approach above, I'd still need to use
include_recipe "bc-location::#{some-special-key-to-determine-location}"
in every situation where this data was needed, correct? Am I the only one
that thinks this is ugly?Doug.
On Mon, Mar 17, 2014 at 12:59 PM, Daniel Condomitti <daniel@condomitti.com
wrote:
You don't need to use knife-ec2 to get those attributes. Create
/etc/chef/hints/ec2.json (empty file is fine) and ohai will automatically
set a LOT of instance metadata attributes including
ec2.placement_availability_zone.On Monday, March 17, 2014 at 12:51 PM, Douglas Garstang wrote:
Jeff,
We are using EC2 (and GCE). However, we aren't using knife to provision
systems. We weren't able to get the knife ec2 plugin to work with an ssh
proxy and gave up in the end.I just tried a different approach, where I have one cookbook, with one
recipe per location. This gets around the issue of having to depend on an
arbitrary list of location cookbooks in the metadata.rb of every cookbook
we write. However, the trade-off is that I have to do this:include_recipe "bc-location::#{some-special-key-to-determine-location}"
every single time I need to access location data. This is horrid. I simply
can't understand why people keep saying not to use roles. Roles are just so
much more convenient. All the include magic is done automatically for you.Douglas.
On Mon, Mar 17, 2014 at 11:23 AM, Jeff Byrnes jeff@evertrue.com wrote:
Doug:
I'm not sure if you're using EC2, but if so, and you're launching
instances using knife-ec2, you should have
node['ec2']['placement_availability_zone'] available. You could build a
single wrapper cookbook, that depends on that attribute's value, and
determines the requisite data center-specific attributes.--
Jeff Byrnes
@berkleebassist http://twitter.com/berkleebassist
Operations Engineer
EverTrue http://www.evertrue.com/
704.516.4628On March 17, 2014 at 1:54:21 PM, Douglas Garstang (doug.garstang@gmail.com)
wrote:Doing what I read to be a best practice, I just took a bunch of roles
that defined set attributes for specific data centers, and moved them into
cookbooks, one per location, ie:bc-location-u1
bc-location.eu1and so on. I just occurred to me that if I do this, then all cookbooks
will need to depend (in the metadata.rb) file on ALL of these location
based cookbooks.is this correct? What am I missing?
Doug
--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
For all location data we're using a single versioned cookbook, which keys
off environment & sub-environment names defined as persistent (set/normal)
attributes. This allows a lot of calculation and defaulting to remove
duplication, at the expense of simplicity compared to location databags.
The settings themselves are deep-merged onto the node's attributes, so the
overridden cookbooks can just work with attributes rather than being tied
to a location implementation.
It's a bit more complex than I'd hoped at the start, and I might consider
dropping it in favour of going to location roles (as we don't use roles for
anything else). Perhaps auto-generated to cope with the
duplication/defaulting if I can rely on banning manual editing of the
auto-gen roles. Chef environments are used for cookbook version control
only - I'm hoping Daniel DeLeo policyfile's clear up some of the confusion
for Chef 12.
On 17 March 2014 22:09, Greg Zapp greg.zapp@gmail.com wrote:
Hi Douglas,
Our setup may be a bit different than yours but I have opted to use
environment data bag items. A lot of our settings, including the
environment name, flow down from the outputs on the CloudFormation VPC
template we use to launch the environment/vpc. We can setup arbitrary
environments and just generate a databag with specifics after it's up. The
environment name provided into the CloudFormation VPC flows down into other
infrastructure we provision into it. The bootstrap code on the ec2
instances sets the nodes environment based on this, then any recipe that
needs to can grab the environment databag to get endpoints for logging, our
API server, etc.This has worked well for me with testing locally too. I have a "local"
environment databag item and set the environment to "local" in my Vagrant
file.-Greg
On Tue, Mar 18, 2014 at 9:18 AM, Jeff Byrnes jeff@evertrue.com wrote:
Unfortunate that you had issues using knife-ec2 with an SSH gateway; I
worked that out like so:knife ec2 server create
--environment stage
--node-name stage-new-instance
--flavor m1.small
--ssh-gateway user@gateway
--ssh-user ec2-user
--security-group-ids sg-dd0bc0b6
--run-list "recipe[et_base]"I'd encourage taking one last quick stab at using knife-ec2 for this, as
it will simplify a lot of things.As an aside, eventually, we avoided using an SSH proxy by forking
knife-ec2 (see GitHub - evertrue/knife-ec2: Opscode Chef knife plug-in for EC2) to not handle the
initial provision directly, but instead by pushing user data to S3, and
using a signed URL to bootstrap the node. See my compatriot's commits at
evertrue/knife-ec2 https://github.com/evertrue/knife-ec2/commits/master
.--
Jeff Byrnes
@berkleebassist http://twitter.com/berkleebassist
Operations Engineer
EverTrue http://www.evertrue.com/
704.516.4628On March 17, 2014 at 4:12:52 PM, Daniel Condomitti (daniel@condomitti.com)
wrote:I would just include bc-location::default and place the
location-detection logic in that recipe based on the EC2 availability zone
or the GCE equivalent. You can always swap out how that's handled (even a
huge case statement for now just to get everything working if you're facing
a deadline) with a better approach later. This way you can keep all that
ugly logic abstracted away and out of the rest of your cookbooks.We use a combination of chef searches (service discovery), cookbook
attributes (node-specific configuration like users and locations) and data
bags (environment-specific configuration data and sensitive stuff like
keys) which isn't perfect but it works well for us.On Monday, March 17, 2014 at 1:07 PM, Douglas Garstang wrote:
Daniel,
Using Jeff's approach above, I'd still need to use
include_recipe "bc-location::#{some-special-key-to-determine-location}"
in every situation where this data was needed, correct? Am I the only one
that thinks this is ugly?Doug.
On Mon, Mar 17, 2014 at 12:59 PM, Daniel Condomitti <
daniel@condomitti.com> wrote:You don't need to use knife-ec2 to get those attributes. Create
/etc/chef/hints/ec2.json (empty file is fine) and ohai will automatically
set a LOT of instance metadata attributes including
ec2.placement_availability_zone.On Monday, March 17, 2014 at 12:51 PM, Douglas Garstang wrote:
Jeff,
We are using EC2 (and GCE). However, we aren't using knife to provision
systems. We weren't able to get the knife ec2 plugin to work with an ssh
proxy and gave up in the end.I just tried a different approach, where I have one cookbook, with one
recipe per location. This gets around the issue of having to depend on an
arbitrary list of location cookbooks in the metadata.rb of every cookbook
we write. However, the trade-off is that I have to do this:include_recipe "bc-location::#{some-special-key-to-determine-location}"
every single time I need to access location data. This is horrid. I
simply can't understand why people keep saying not to use roles. Roles are
just so much more convenient. All the include magic is done automatically
for you.Douglas.
On Mon, Mar 17, 2014 at 11:23 AM, Jeff Byrnes jeff@evertrue.com wrote:
Doug:
I'm not sure if you're using EC2, but if so, and you're launching
instances using knife-ec2, you should have
node['ec2']['placement_availability_zone'] available. You could build a
single wrapper cookbook, that depends on that attribute's value, and
determines the requisite data center-specific attributes.--
Jeff Byrnes
@berkleebassist http://twitter.com/berkleebassist
Operations Engineer
EverTrue http://www.evertrue.com/
704.516.4628On March 17, 2014 at 1:54:21 PM, Douglas Garstang (
doug.garstang@gmail.com) wrote:Doing what I read to be a best practice, I just took a bunch of roles
that defined set attributes for specific data centers, and moved them into
cookbooks, one per location, ie:bc-location-u1
bc-location.eu1and so on. I just occurred to me that if I do this, then all cookbooks
will need to depend (in the metadata.rb) file on ALL of these location
based cookbooks.is this correct? What am I missing?
Doug
--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
Le 2014-03-17 18:54, Douglas Garstang a écrit :
Doing what I read to be a best practice, I just took a bunch of roles that defined set attributes for specific data centers, and moved them into cookbooks, one per location, ie:
bc-location-u1
bc-location.eu1and so on. I just occurred to me that if I do this, then all cookbooks will need to depend (in the metadata.rb) file on ALL of these location based cookbooks.
is this correct? What am I missing?
Doug
I restart from original thread as I'll take another way than others
answers.
Moving role to cookbok does not sound that complicated to me.
You 'role-cookbook' has the dependencies and include_recipe to redo
the role-runlist
It has the atributes of your original role
This cookbook is in the node runlist (as the role is in fact)
With this path I can't find something different using a cookbook than a
role for this purpose.
I think wishing to include this cookbook from others to avois specify
them in the node runlist as you had do with a role is thinking bottom
up, or perhaps better said: thinking too far about dependencies.
My 2 cents on the subject, I may be missing something somewhere 