Nodes not showing up in search


#1

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


#2

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


#3

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


#4

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


#5

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


#6

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:

  1. 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?

  2. 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?

  3. 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?

  4. 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