@lamont if you have an initial spec in mind let us
know :-) . We can introduce a chef computed attribute like
`recipes` or `roles` as part of the run list expansion (may be
`cookbooks`).
The status information per-cookbook doesn't make sense
with chef's model since if any ruby code fails at
compile time or a resource fails at run time it'll fail
the entire run. That's better done with a chef handler
that reports the exception. The reporting premium
feature does this, but its not very difficult to
recreate and I believe there's examples out there of
doing it yourself.
The cookbook versions don't currently get serialized to
node data, that's another thing that would be relatively
easy to do. Getting it into core chef is starting to
get near to the top of my list of things I'd like to
address now that we're post-12.0.0 release, but I
haven't found the time yet.
On 2/7/15 10:37 AM, Roman Naumenko wrote:
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 status
cb1 1.2.4 linux1
clean
cb1 1.2.4 linux5
failed
cb_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) .
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.
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.
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.
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 status
cb1
1.2.4
linux1 clean
cb1
1.2.4
linux5 failed
cb_base 1.0.1
linux2
failed
cb_base
1.0.1
linux4 clean
cb_base
1.0.2
linux5 clean
cb_base
1.0.2
linux6 clean
and 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.