I seem to be hitting an odd glitch with search in that nodes with a role
associated with them aren’t returning when I search based on role:
$ knife search node role:monitored
1 items found
Node Name: lana.###.###
Environment: _default
FQDN: lana.###.###
IP: ###.###.###.###
Run List: recipe[ldap], recipe[chef-client::service], role[monitored]
Roles: monitored
Recipes: ldap, chef-client::service
Platform: centos 6.2
If I do a show for a node I know has this role associated with it:
$ knife node show monitor.###.###
Node Name: monitor.###.###
Environment: _default
FQDN: monitor.###.###
IP: ###.###.###.###
Run List: recipe[chef-client::service], recipe[ntp], recipe[openssh],
recipe[openssl], role[monitored]
Roles: monitored
Recipes: chef-client::service, ntp, openssh, openssl,
Platform: centos 5.8
Anyone have any ideas what might be causing this odd behaviour? I’ve
tried doing “knife index rebuild” and then repeating the process but to
no avail. chef-client has been run on all the relevant servers after
the role has been added.
Paul
On Jun 29, 2012, at 7:41 PM, Paul Graydon wrote:
I seem to be hitting an odd glitch with search in that nodes with a role associated with them aren't returning when I search based on role:
$ knife search node role:monitored
1 items found
Try "roles:" instead of "role:". That will search all inherited roles and run_list items recursively, instead of just the top-level role.
--
Brad Knowles brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu
On Fri, Jun 29, 2012 at 10:05:22PM -0700, Brad Knowles wrote:
On Jun 29, 2012, at 7:41 PM, Paul Graydon wrote:
I seem to be hitting an odd glitch with search in that nodes with a role associated with them aren't returning when I search based on role:
$ knife search node role:monitored
1 items found
Try "roles:" instead of "role:". That will search all inherited roles and run_list items recursively, instead of just the top-level role.
Unfortunately that makes no difference, I see exactly the same result as "role:", just the one server instead of 3 responding.
Paul
Check out http://tickets.opscode.com/browse/CHEF-2346
if your node has a lot of attributes (generally from ohai automatic
attributes) it could exceed the 10000 default limit and not get indexed
properly. The workaround is to increase that limit in Solr.
On Sat, Jun 30, 2012 at 8:40 PM, paul@paulgraydon.co.uk wrote:
On Fri, Jun 29, 2012 at 10:05:22PM -0700, Brad Knowles wrote:
On Jun 29, 2012, at 7:41 PM, Paul Graydon wrote:
I seem to be hitting an odd glitch with search in that nodes with a
role associated with them aren't returning when I search based on role:
$ knife search node role:monitored
1 items found
Try "roles:" instead of "role:". That will search all inherited roles
and run_list items recursively, instead of just the top-level role.
Unfortunately that makes no difference, I see exactly the same result as
"role:", just the one server instead of 3 responding.
Paul
That did the trick, thank you very much.
Paul
On Sun, Jul 01, 2012 at 08:01:36PM +0200, Maxime Brugidou wrote:
Check out http://tickets.opscode.com/browse/CHEF-2346
if your node has a lot of attributes (generally from ohai automatic
attributes) it could exceed the 10000 default limit and not get indexed
properly. The workaround is to increase that limit in Solr.
On Sat, Jun 30, 2012 at 8:40 PM, paul@paulgraydon.co.uk wrote:
On Fri, Jun 29, 2012 at 10:05:22PM -0700, Brad Knowles wrote:
On Jun 29, 2012, at 7:41 PM, Paul Graydon wrote:
I seem to be hitting an odd glitch with search in that nodes with a
role associated with them aren't returning when I search based on role:
$ knife search node role:monitored
1 items found
Try "roles:" instead of "role:". That will search all inherited roles
and run_list items recursively, instead of just the top-level role.
Unfortunately that makes no difference, I see exactly the same result as
"role:", just the one server instead of 3 responding.
Paul
Hi
I think the usage of Chef itself has been pretty well covered in terms
of general good practice etc, and testing is starting to get a lot of
attention too, with quite a few different approaches and tools springing
up. However I wanted to kick off a general discussion of other general
practices and workflows around Chef that people are using, and talk
about some of the non-core issues and challenges around running Chef, to
figure out what others are doing and how we can learn and adopt the best
patterns. In particular:
-
How are you handling emergency changes?
We’ve been all by-the-book and got ourselves a nice little CI pipeline
to push our infra code through. This does mean that if someone says “we
released X feature and its not working because Y configuration value
isn’t in place”, our lead time to be able to deliver that change to the
business is longer if we stick with our standard workflow. So, we stick
with the workflow and the business loses patience, or we ditch the
benefits of the CI pipeline/test and push it live straight away,
possibly breaking something. I guess the issue here is that in a pre-CM
world. you can make the change you want directly and have a high chance
of making the right change quickly. Yes it doesn’t scale and yes it can
lead to drift and every host being a snowflake, but it meets sharp
timescales. Have you had to re-reducate the wider business on why you do
things differently now? Do you have an emergency change procedure inside
or outside of Chef?
-
How are you handling upgrades of Chef itself?
Obviously Chef is now an integral part of your infrastructure… but
how do you manage it? Manually? (wouldn’t that be just as bad as how you
were managing the rest of your infrastructure before?) Via Chef itself
(how meta can you get?). And are you sticking with long release cycles
and older versions or staying on the latest client and server build all
the time, surfing the crest and rolling out fresh new bugs to your
production CM system?
-
What monitoring of the chef server and chef clients do you use?
What are you graphing and what are you alerting on?
This is probably a big one for devops types, and there’s no really nice
built in console for this. What are you monitoring, graphing and
alerting on? Because the system uses pull, not push, some failed runs
may only be visible from the client, so you can’t easily monitor this
from the server (unless you put something custom in place). How are you
handling this?
-
How are you handling training and other issues around Chef passing
from the delivery team through AIS into a legacy/inherited system?
You probably put Chef in yourself or as part of a small team, but your
team may grow or as the product ages in your infrastructure it will
become legacy or at least new to incomers to your team or department.
How are you handling this? Has it itself been a driver for hiring more
"operations coders" than pure sysadmins in that a core piece of tech now
requires coding knowledge and practices? Or are you a dev and found that
you don’t need a sysadmin at all, or found that the devs you are hiring
don’t want to or struggle to work on and understand the platform stuff?
Just interested to hear how people are handling these and other
questions
Many thanks
Dan