All this has been uploaded to the chef server. However, when the client
runs, it can’t find the data from the eu2-prod environment.
Looking at the chef GUI, I’m still confused. The cookbook itself doesn’t
show the environments/ directory, but rather has a drop-down at the top
which lets me select which environment I am looking at. No matter which
environment I pick, ‘None’, ‘_default’ or ‘eu2-prod’ I can’t see any of the
data from the environments/eu2-prod.json file.
If I go over to the Environments global section in the UI, also there’s no
data there. I wouldn’t expect to see any data there anyway, as I imagine
that’s environment data that’s, err… global in scope.
All this has been uploaded to the chef server. However, when the client
runs, it can’t find the data from the eu2-prod environment.
Looking at the chef GUI, I’m still confused. The cookbook itself doesn’t
show the environments/ directory, but rather has a drop-down at the top
which lets me select which environment I am looking at. No matter which
environment I pick, ‘None’, ‘_default’ or ‘eu2-prod’ I can’t see any of the
data from the environments/eu2-prod.json file.
If I go over to the Environments global section in the UI, also there’s no
data there. I wouldn’t expect to see any data there anyway, as I imagine
that’s environment data that’s, err… global in scope.
All this has been uploaded to the chef server. However, when the client
runs, it can't find the data from the eu2-prod environment.
Looking at the chef GUI, I'm still confused. The cookbook itself doesn't
show the environments/ directory, but rather has a drop-down at the top
which lets me select which environment I am looking at. No matter which
environment I pick, 'None', '_default' or 'eu2-prod' I can't see any of the
data from the environments/eu2-prod.json file.
If I go over to the Environments global section in the UI, also there's no
data there. I wouldn't expect to see any data there anyway, as I imagine
that's environment data that's, err... global in scope.
From your email it sounded like you were putting your environment file inside a cookbook? I might've misunderstood you , but if that's the case,
that's probably not right. Most people keep their environments in a
directory in their
chef-repohttp://docs.opscode.com/essentials_repository.htmland then
they're uploaded using knife
environment from file
All this has been uploaded to the chef server. However, when the client
runs, it can't find the data from the eu2-prod environment.
Looking at the chef GUI, I'm still confused. The cookbook itself doesn't
show the environments/ directory, but rather has a drop-down at the top
which lets me select which environment I am looking at. No matter which
environment I pick, 'None', '_default' or 'eu2-prod' I can't see any of the
data from the environments/eu2-prod.json file.
If I go over to the Environments global section in the UI, also there's
no data there. I wouldn't expect to see any data there anyway, as I imagine
that's environment data that's, err... global in scope.
Since we have one chef-repo per cookbook, it seemed to make perfect sense
to put the environment into the cookbook. I've since realised that's not
going to work as updating the environment from one cookbook blows updates
from the previous one away.
I'm trying to find a way to decouple the attributes between cookbooks. See
my subsequent post on that. It seems like environments are no better than
roles for that. We need one big nasty json file in our main per location.
Doug.
On Fri, Feb 14, 2014 at 2:28 PM, Matthew Moretti werebus@gmail.com wrote:
From your email it sounded like you were putting your environment file inside a cookbook? I might've misunderstood you , but if that's the
case, that's probably not right. Most people keep their environments in a
directory in their chef-repohttp://docs.opscode.com/essentials_repository.htmland then they're uploaded using knife
environment from file
All this has been uploaded to the chef server. However, when the client
runs, it can't find the data from the eu2-prod environment.
Looking at the chef GUI, I'm still confused. The cookbook itself doesn't
show the environments/ directory, but rather has a drop-down at the top
which lets me select which environment I am looking at. No matter which
environment I pick, 'None', '_default' or 'eu2-prod' I can't see any of the
data from the environments/eu2-prod.json file.
If I go over to the Environments global section in the UI, also there's
no data there. I wouldn't expect to see any data there anyway, as I imagine
that's environment data that's, err... global in scope.
You're usually the one talking about (or bitching about) corner cases in Chef Infra (archive). I think what you might need to do is take a step back, itemize your
goals, and ask the best way to achieve them. Because it seems like you're
trying to fit a round peg in a square hole, and the solution isn't just to
hammer at it, it's to see if you need to change your approach.
Comments from someone who had you on ignore for a while because you
couldn't get past the fact that Chef was written in Ruby. You're asking
more reasonable questions these days, but I'm not sure you're using chef in
ways it's intended for.
Since we have one chef-repo per cookbook, it seemed to make perfect sense
to put the environment into the cookbook. I've since realised that's not
going to work as updating the environment from one cookbook blows updates
from the previous one away.
I'm trying to find a way to decouple the attributes between cookbooks. See
my subsequent post on that. It seems like environments are no better than
roles for that. We need one big nasty json file in our main per location.
Doug.
On Fri, Feb 14, 2014 at 2:28 PM, Matthew Moretti werebus@gmail.comwrote:
From your email it sounded like you were putting your environment file inside a cookbook? I might've misunderstood you , but if that's the
case, that's probably not right. Most people keep their environments in a
directory in their chef-repohttp://docs.opscode.com/essentials_repository.htmland then they're uploaded using knife
environment from file
All this has been uploaded to the chef server. However, when the client
runs, it can't find the data from the eu2-prod environment.
Looking at the chef GUI, I'm still confused. The cookbook itself doesn't
show the environments/ directory, but rather has a drop-down at the top
which lets me select which environment I am looking at. No matter which
environment I pick, 'None', '_default' or 'eu2-prod' I can't see any of the
data from the environments/eu2-prod.json file.
If I go over to the Environments global section in the UI, also there's no
data there. I wouldn't expect to see any data there anyway, as I imagine
that's environment data that's, err... global in scope.
Less attempts would be made to try and fit square pegs into square holes if
I had a body of knowledge to learn from. Some published best practices
would be most beneficial.
One of the problems I am trying to solve is to make cookbooks less fragile.
Cookbook development is in a high state of flux. An attribute defined in a
role may be used by more than one cookbook. Changing that reference has the
potential to break multiple cookbooks.What is the correct approach here? Is
the best practice to make single references to some common attributes or to
duplicate them? Again, some best practices guidelines would be helpful.
I'll use the example of a mysql server. Currently it's defined once per
location, because that made the most sense at the time. If I change it name
in the role, the cookbooks that use it break. I could use chef search
instead but that doesn't work with vagrant and chef solo as far as I know.
If I tested in a full chef server environment, I would need to bring up the
mysql server and every other node required just to test that the attributes
were filled out correctly.
You could of course say 'don't do that'. Don't touch the mysql attribute.
Ok, but it's just an example of how the cookbooks are coupled. The same
mistake could easily be made with any other attribute at any time. I am
trying to decouple the cookbooks.
Another issue is that test kitchen, as far as I can tell again, does not
work with roles. You must take all the attributes from your role and
manually transcribe it into the kitchen.yml file, which in my mind ins't a
very good test. That is not going to catch errors like the mysql example
mentioned above.
You're usually the one talking about (or bitching about) corner cases in Chef Infra (archive). I think what you might need to do is take a step back, itemize your
goals, and ask the best way to achieve them. Because it seems like you're
trying to fit a round peg in a square hole, and the solution isn't just to
hammer at it, it's to see if you need to change your approach.
Comments from someone who had you on ignore for a while because you
couldn't get past the fact that Chef was written in Ruby. You're asking
more reasonable questions these days, but I'm not sure you're using chef in
ways it's intended for.
Since we have one chef-repo per cookbook, it seemed to make perfect sense
to put the environment into the cookbook. I've since realised that's not
going to work as updating the environment from one cookbook blows updates
from the previous one away.
I'm trying to find a way to decouple the attributes between cookbooks.
See my subsequent post on that. It seems like environments are no better
than roles for that. We need one big nasty json file in our main per
location.
Doug.
On Fri, Feb 14, 2014 at 2:28 PM, Matthew Moretti werebus@gmail.comwrote:
From your email it sounded like you were putting your environment file inside a cookbook? I might've misunderstood you , but if that's the
case, that's probably not right. Most people keep their environments in a
directory in their chef-repohttp://docs.opscode.com/essentials_repository.htmland then they're uploaded using knife
environment from file
All this has been uploaded to the chef server. However, when the client
runs, it can't find the data from the eu2-prod environment.
Looking at the chef GUI, I'm still confused. The cookbook itself doesn't
show the environments/ directory, but rather has a drop-down at the top
which lets me select which environment I am looking at. No matter which
environment I pick, 'None', '_default' or 'eu2-prod' I can't see any of the
data from the environments/eu2-prod.json file.
If I go over to the Environments global section in the UI, also there's
no data there. I wouldn't expect to see any data there anyway, as I imagine
that's environment data that's, err... global in scope.
Another issue is that test kitchen, as far as I can tell again, does not
work with roles. You must take all the attributes from your role and
manually transcribe it into the kitchen.yml file, which in my mind ins't a
very good test. That is not going to catch errors like the mysql example
mentioned above.
I have not personally used it, but just the other day I stumbled across the
fact that test-kitchen does actually support roles, although its not
clearly documented (that I found):
Again, you're focusing on how to get there rather than stating where you
need to go and why.
And yes, the tooling around Chef is in flux. Best practices are still
evolving. This is something Chef is aware of and aiming to address via gap
coverage and documentation as they head towards Chef 12. The Chef 10
standard of knife cookbook upload clearly doesn't cut it-- but. Chef
doesn't maintain any of the extra tools currently, they are all third
party. (And I think for the most part, that's the way they intend it to
maintain but they may contribute resources to shore up projects.) Again,
that's something they want to nail down process wise for 12, where a clear
process for uploading and testing can be defined, abstracted from the
tooling used (ie, librarian vs berkshelf, vagrant vs chef-zero vs vagabond,
BAtS vs chefspec, etc),
In the meantime, the bigger picture you can convey, the better quality
architectural advice you will be given.
Less attempts would be made to try and fit square pegs into square holes
if I had a body of knowledge to learn from. Some published best practices
would be most beneficial.
One of the problems I am trying to solve is to make cookbooks less
fragile. Cookbook development is in a high state of flux. An attribute
defined in a role may be used by more than one cookbook. Changing that
reference has the potential to break multiple cookbooks.What is the correct
approach here? Is the best practice to make single references to some
common attributes or to duplicate them? Again, some best practices
guidelines would be helpful.
I'll use the example of a mysql server. Currently it's defined once per
location, because that made the most sense at the time. If I change it name
in the role, the cookbooks that use it break. I could use chef search
instead but that doesn't work with vagrant and chef solo as far as I know.
If I tested in a full chef server environment, I would need to bring up the
mysql server and every other node required just to test that the attributes
were filled out correctly.
You could of course say 'don't do that'. Don't touch the mysql attribute.
Ok, but it's just an example of how the cookbooks are coupled. The same
mistake could easily be made with any other attribute at any time. I am
trying to decouple the cookbooks.
Another issue is that test kitchen, as far as I can tell again, does not
work with roles. You must take all the attributes from your role and
manually transcribe it into the kitchen.yml file, which in my mind ins't a
very good test. That is not going to catch errors like the mysql example
mentioned above.
You're usually the one talking about (or bitching about) corner cases in Chef Infra (archive). I think what you might need to do is take a step back, itemize your
goals, and ask the best way to achieve them. Because it seems like you're
trying to fit a round peg in a square hole, and the solution isn't just to
hammer at it, it's to see if you need to change your approach.
Comments from someone who had you on ignore for a while because you
couldn't get past the fact that Chef was written in Ruby. You're asking
more reasonable questions these days, but I'm not sure you're using chef in
ways it's intended for.
Since we have one chef-repo per cookbook, it seemed to make perfect sense
to put the environment into the cookbook. I've since realised that's not
going to work as updating the environment from one cookbook blows updates
from the previous one away.
I'm trying to find a way to decouple the attributes between cookbooks. See
my subsequent post on that. It seems like environments are no better than
roles for that. We need one big nasty json file in our main per location.
Doug.
On Fri, Feb 14, 2014 at 2:28 PM, Matthew Moretti werebus@gmail.comwrote:
From your email it sounded like you were putting your environment file inside a cookbook? I might've misunderstood you , but if that's the
case, that's probably not right. Most people keep their environments in a
directory in their chef-repohttp://docs.opscode.com/essentials_repository.htmland then they're uploaded using knife
environment from file
Environments are solely global in nature, so that file needs to go in your top-level environments directory (and uploaded to your Chef server). I think you’re looking at them backwards. Environments are containers (think development, staging, production) where you may want to have different versions of a cookbook, or different attributes. Typical use cases are things like having a different set of hostnames or credentials that you use in staging vs. production, or locking your production environment to a specific version of a cookbook so that you don’t inadvertently release something before it’s been tested thoroughly.
All this has been uploaded to the chef server. However, when the client runs, it can’t find the data from the eu2-prod environment.
Looking at the chef GUI, I’m still confused. The cookbook itself doesn’t show the environments/ directory, but rather has a drop-down at the top which lets me select which environment I am looking at. No matter which environment I pick, ‘None’, ‘_default’ or ‘eu2-prod’ I can’t see any of the data from the environments/eu2-prod.json file.
If I go over to the Environments global section in the UI, also there’s no data there. I wouldn’t expect to see any data there anyway, as I imagine that’s environment data that’s, err… global in scope.
And yes, the tooling around Chef is in flux. Best practices are still evolving.
Especially around testing.
Again, that's something they want to nail down process wise for 12, where a clear process for uploading and testing can be defined, abstracted from the tooling used (ie, librarian vs berkshelf, vagrant vs chef-zero vs vagabond, BAtS vs chefspec, etc),
And even more confusing can be the issue where it's not exactly vagrant vs. chef-zero, but maybe vagrant+chef-solo vs. vagrant+chef-zero, or ChefSpec on one platform vs. ChefSpec on another platform, or whatever.
Right now, there's a lot of work you have to do on your own to figure out what will work best in what circumstances -- and you may discover that will change over relatively short periods of time as the tools continue to evolve.
At the time, this statement from the documentation made perfect sense given
that in our environment we have one git repo per chef repo.
"A Ruby file for each non-default environment must exist in the
environments/ subdirectory of the chef-repo. "
I since have realised thats' not quite true. In any case, roles and
environments both don't address the fact that if I define a common
attribute in a role or an environment, that is used by multiple cookbooks,
and I change that attribute name, all the cookbooks that refer to it will
break.
This is why I wanted to contain the attribute (and all it's 'environments'
solely within the cookbook.
For example, let's say I define this in a role somewhere.
Now lets also say 5 cookbooks use this attribute. Change "mysql_server" to
"mysql_host" and those cookbooks all break. Instead, if each cookbook
defined it's own reference to the mysql server for each location, changing
one would not break any others. Following this approach would seem to make
cookbooks a lot less brittle at the expense of a little more duplication of
data.
Until recently I thought test kitchen couldn't use roles. Maybe it can now.
I need to check that. Putting the attributes into the cookbook would also
seem to make test kitchen more reliable, as the attributes would come
directly from the cookbook. You wouldn't need to copy and paste them from a
role.
Environments are solely global in nature, so that file needs to go in your
top-level environments directory (and uploaded to your Chef server). I
think you're looking at them backwards. Environments are containers (think
development, staging, production) where you may want to have different
versions of a cookbook, or different attributes. Typical use cases are
things like having a different set of hostnames or credentials that you use
in staging vs. production, or locking your production environment to a
specific version of a cookbook so that you don't inadvertently release
something before it's been tested thoroughly.
All this has been uploaded to the chef server. However, when the client
runs, it can't find the data from the eu2-prod environment.
Looking at the chef GUI, I'm still confused. The cookbook itself doesn't
show the environments/ directory, but rather has a drop-down at the top
which lets me select which environment I am looking at. No matter which
environment I pick, 'None', '_default' or 'eu2-prod' I can't see any of the
data from the environments/eu2-prod.json file.
If I go over to the Environments global section in the UI, also there's no
data there. I wouldn't expect to see any data there anyway, as I imagine
that's environment data that's, err... global in scope.
No default and no override