Re: Re: Re: Re: Re: Reporting: list of nodes with cookbook versions

Chef Infra (archive)
1

I'm tempted to say no, it's not a

cookbook which fail but a resource, which can make the run fail or not.

Seeing the report from the cookbook point of view is a bad path as your concern is the node state, so knowing a node run failed and which resource made it fail is great.

Knowing this cookbook has failed on a node or many is of poor interest, as you'll want to know why it failed.

Moreover if you use wrapper cookbooks (which I highly recommend to keep track of changes) if the wrapper call 4 or 5 cookbooks, you'll want to know which one was falling and why.

In a level 1, level 2 support path, the interesting information is the node state at level 1 and the resource at level 2, the cookbook itself is just part of the resource path.

So for your question it's technically doable, but I'm pretty sure it answers no other use case than yours, so no-one has done it already.

What is great is that you can do it with the preceding informations :wink:

Le 7 févr. 2015 19:37, Roman Naumenko <roman@naumenko.ca> a écrit :

Lets step back to my initial question. Chef is to enforce policy and
keep nodes in defined state. 


Is there a way to get information about node's state, specifically
version cookbooks?




And if there is chef reporting premium feature exists, can it
generelate a list like this?

cookbook version node statuscb1 1.2.4 linux1 cleancb1 1.2.4 linux5 failedcb_base 1.0.1 linux2 failed

Thanks,


--Roman

Tensibai Zhaoying wrote on 07-02-15
13:21:

My opinion: No, it's not its role to store it. Core server's role is to give nodes their described configuration. The last run time is stored in the node attributes natively.

The versions are resolved when the client ask them, we can't rely on this as the version locks may have changed since a node last run.

For the resources. (health) , would you store only the changed one on last run ? Or just the number of updated resources ? Or last time this specific resource was updated ?

Storing all that in the node attributes just make the node object grow and take more time to be retrieved on each run. 

    It's better to keep that in a separate space (still my personal
    opinion) .</p>

And after a while you'll want an history of thoosemail informations , that's why a separate part called reporting exist as an add-on, not everyone have the same expectations, and I really think core Chef-server should stick giving configuration pieces and not start being the repository of node states over time.

Le 7 févr. 2015 00:45, Roman Naumenko
<roman@naumenko.ca> a écrit :

To Tensibai point: isn't it what chef server supposed to do? 
        Ranjib, that's probably the way to do it, but again - why
        that's missing in core functionality? Also, it's version
        reports are useful only in relation to other information:
        health status, last run time etc. Is all this information
        goes to tags as well?




        --Roman

Ranjib Dey wrote on 04-02-15 3:29:

that example can be extend to save the cookbook version info as a node attribute. and a custom knife plugin can show you the data any way you want.

On Wed, Feb 4, 2015 at 12:08
AM, Tensibai <tensibai@iabis.net>
wrote:

I know no direct access from chef server to this, the way we do use is a report handler to populate a DB and then have an interface giving run details with cookbook versions.

There's an exemple ont he doc here: http://docs.chef.io/handlers.html#cookbook-versions

I did adapt an old dashboard named Cuisine (but we don't use it anymore), it's unclean code and I've not done a correct installation cookbook. I may update it on github if you wish to have a look at it and at it's corresponding handler.

Le 2015-02-03 17:03, Roman Naumenko a écrit :

Hi,

Does chef server has capabilities to
generate report of environment status?
Was surprised to see it's not so easy to
generate.

I'm looking to get things like list
of nodes with the particular cookbook
versions, for example:cookbook version node
statuscb1 1.2.4
linux1 cleancb1 1.2.4
linux5 failedcb_base 1.0.1
linux2 failedcb_base 1.0.1
linux4 cleancb_base 1.0.2
linux5 cleancb_base 1.0.2
linux6 cleanand so on

It has to be generated in shell since
the web-interface is pretty much
useless.

I looked at few plugins like lastrun,
knife-audit but none is working with
versions.

Thanks,--Roman