can someone explain me difference of normal attributes in lwrp with state
attributes and a good example ?
I have not used state attribute yet, but my assumption is its supposed to
be reflexing the current state ? how is that diffrent with normal attribute
, both of them can be accessed outside and both can be changed if you want
to …
On Thursday, February 19, 2015 at 2:45 PM, Medya wrote:
can someone explain me difference of normal attributes in lwrp with state attributes and a good example ?
I have not used state attribute yet, but my assumption is its supposed to be reflexing the current state ? how is that diffrent with normal attribute , both of them can be accessed outside and both can be changed if you want to ...
State attributes just declare which attributes in a resource actually describe the state of the underlying system. Consider for example, a package resource. It has a package name and a version. Installing a package changes the state of the version from “null” (not installed) to some version number. Upgrading and downgrading change the version from one version number to a different version number. The package resource has bunch of other attributes that don’t describe the actual desired state of the system but instead give Chef hints about how to transition from one state to another. For example, the timeout attribute tells Chef how long it should wait before assuming a package install operation got stuck. But whether the timeout is 5 seconds or 5 hours has nothing to do with the package’s state. There are lots of other examples, such as customizing the start and stop commands of a service, the atomic update stuff for files, and so on; all of these only tell chef how to change your system from one state to another, but do not describe the state of the system.
The list of state attributes is used by the reporting system in Chef (1) so that only meaningful information about system changes is sent to the reporting service (which is a paid add-on to the server, though there are free alternatives like foreman that re-use the client code).
Note also that the identity attribute has a similar function, it says which attribute of a resource uniquely identifies the actual thing on the system it represents. For a file, it’s the path, for package it’s the name, etc.
HTH
--
Daniel DeLeo
Thanks for the reply Daniel,
but cant I have the same effect with normal attributes?
like the case of the package, if I run action install on a package, I can
change the a normal attribute to the version of the installed version ?
why do I have to declare it as state attribute?
and another question ,
how can I access a state attribute ? can I access them through node objects
? are they stored on the chef server or on the client side ?
On Thu, Feb 19, 2015 at 5:21 PM, Daniel DeLeo dan@kallistec.com wrote:
On Thursday, February 19, 2015 at 2:45 PM, Medya wrote:
can someone explain me difference of normal attributes in lwrp with
state attributes and a good example ?I have not used state attribute yet, but my assumption is its supposed
to be reflexing the current state ? how is that diffrent with normal
attribute , both of them can be accessed outside and both can be changed if
you want to ...State attributes just declare which attributes in a resource actually
describe the state of the underlying system. Consider for example, a
package resource. It has a package name and a version. Installing a package
changes the state of the version from “null” (not installed) to some
version number. Upgrading and downgrading change the version from one
version number to a different version number. The package resource has
bunch of other attributes that don’t describe the actual desired state of
the system but instead give Chef hints about how to transition from one
state to another. For example, the timeout attribute tells Chef how long it
should wait before assuming a package install operation got stuck. But
whether the timeout is 5 seconds or 5 hours has nothing to do with the
package’s state. There are lots of other examples, such as customizing the
start and stop commands of a service, the atomic update stuff for files,
and so on; all of these only tell chef how to change your system from one
state to another, but do not describe the state of the system.The list of state attributes is used by the reporting system in Chef (1)
so that only meaningful information about system changes is sent to the
reporting service (which is a paid add-on to the server, though there are
free alternatives like foreman that re-use the client code).Note also that the identity attribute has a similar function, it says
which attribute of a resource uniquely identifies the actual thing on the
system it represents. For a file, it’s the path, for package it’s the name,
etc.HTH
--
Daniel DeLeo
On Thursday, February 19, 2015 at 6:36 PM, Medya wrote:
Thanks for the reply Daniel,
but cant I have the same effect with normal attributes?
like the case of the package, if I run action install on a package, I can change the a normal attribute to the version of the installed version ? why do I have to declare it as state attribute?
State attributes are just an annotation. For example if you look at the package resource here: https://github.com/chef/chef/blob/master/lib/chef/resource/package.rb
We define the ‘version’ attribute (the long way, with a method definition) here: https://github.com/chef/chef/blob/a7f5c92960aedf8d5bfc71abbce430ab075e016a/lib/chef/resource/package.rb#L53
But we also have to specify that it’s a state attribute here: https://github.com/chef/chef/blob/a7f5c92960aedf8d5bfc71abbce430ab075e016a/lib/chef/resource/package.rb#L28
What happens behind the scenes is that the resource class (in this case Chef::Resource::Package) just keeps an array of the things we told it are ‘state attributes.’
In a LWRP, you’d have to use attribute to define the attribute method and also call state_attrs to add the attribute to the array.
For example: https://github.com/opscode-cookbooks/aws/blob/master/resources/ebs_volume.rb
and another question ,
how can I access a state attribute ? can I access them through node objects ? are they stored on the chef server or on the client side ?
Hopefully it’s clear from the above that a ’state attribute’ is just a regular attribute that happens to have its name in an array called “state_attrs.”
As I noted in the previous email, the client side reporting code loops over the state attributes to convert a resource to a hash, keeping only the data relevant to changes chef made to the system. If you have the reporting add-on installed, the reporting server will store it so you can keep track of every change made by chef to any system it manages.
More about reporting/analytics here: http://docs.chef.io/server/reporting.html
As I noted, the server side component is a premium feature, though you can install it for free for up to 25 nodes (or use the free trial of hosted chef to play around with it), though there are open source tools that use Chef’s client side reporting code to store data to custom server/data store.
--
Daniel DeLeo