Attribute precedence and Persistence issue


#1

Hello,

I am working on a requirement which states that a particular version of a
software needs to be installed on a VM and the version could be changed as
per the user requirement.

I thought to put the default value in attribute and let it be overridden by
the JSON attrib which can be passed on run time. It works fine but it
starts cribbing the moment i dont pass the the JSON attrib in next run, in
the ideal scenario the attribute should fall back to Attribute file to take
the value.
But in this case it is taking up the value persisted on node which we
passed in the JSON attrib.

I tried to use normal and override in attribute file but in that case it
ignores the JSON attribs.

Can someone please guide me.

Warm Regards,

Mrigesh Priyadarshi
Mob:-+91-720-402-2510


#2

On Thu, Nov 21, 2013 at 10:51 PM, Mrigesh Priyadarshi
mrigeshpriyadarshi@gmail.com wrote:

I am working on a requirement which states that a particular version of a
software needs to be installed on a VM and the version could be changed as
per the user requirement.

I thought to put the default value in attribute and let it be overridden by
the JSON attrib which can be passed on run time. It works fine but it starts
cribbing the moment i dont pass the the JSON attrib in next run, in the
ideal scenario the attribute should fall back to Attribute file to take the
value.

But in this case it is taking up the value persisted on node which we passed
in the JSON attrib.

Attributes are always persisted to the node object.

I’m not totally clear on your use case. Chef is for policy compliance.
If software X needs to be installed at version Y on a system, it will
continue ensuring that version Y will be on the system.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#3

Hey Julian,

our use case is That we have a service portal and we want end users to
provision their instance with custom config

Warm Regards,

Mrigesh Priyadarshi
Mob:-+91-720-402-2510

On Fri, Nov 22, 2013 at 9:38 PM, Julian C. Dunn jdunn@aquezada.com wrote:

On Thu, Nov 21, 2013 at 10:51 PM, Mrigesh Priyadarshi
mrigeshpriyadarshi@gmail.com wrote:

I am working on a requirement which states that a particular version of a
software needs to be installed on a VM and the version could be changed
as
per the user requirement.

I thought to put the default value in attribute and let it be overridden
by
the JSON attrib which can be passed on run time. It works fine but it
starts
cribbing the moment i dont pass the the JSON attrib in next run, in the
ideal scenario the attribute should fall back to Attribute file to take
the
value.

But in this case it is taking up the value persisted on node which we
passed
in the JSON attrib.

Attributes are always persisted to the node object.

I’m not totally clear on your use case. Chef is for policy compliance.
If software X needs to be installed at version Y on a system, it will
continue ensuring that version Y will be on the system.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#4

Hey Julian,

Our use case is that we have a service portal and we want end users to
provision their instance with custom configuration. We want to have a
default configuration in cookbook so, if the user doesnt select any custom
config for the installs the service portal will not generate any json file.
And will run the chef-client with default values defined in cookbook but if
they select any configuration chef-client should include those with the
json file.

In this scenario, what ever value we pass through the attrib file gets
persisted as normal type and doesnt get reset in the next run if the json
file is not passed.

Warm Regards,

Mrigesh Priyadarshi
Mob:-+91-720-402-2510

On Fri, Nov 22, 2013 at 9:38 PM, Julian C. Dunn jdunn@aquezada.com wrote:

On Thu, Nov 21, 2013 at 10:51 PM, Mrigesh Priyadarshi
mrigeshpriyadarshi@gmail.com wrote:

I am working on a requirement which states that a particular version of a
software needs to be installed on a VM and the version could be changed
as
per the user requirement.

I thought to put the default value in attribute and let it be overridden
by
the JSON attrib which can be passed on run time. It works fine but it
starts
cribbing the moment i dont pass the the JSON attrib in next run, in the
ideal scenario the attribute should fall back to Attribute file to take
the
value.

But in this case it is taking up the value persisted on node which we
passed
in the JSON attrib.

Attributes are always persisted to the node object.

I’m not totally clear on your use case. Chef is for policy compliance.
If software X needs to be installed at version Y on a system, it will
continue ensuring that version Y will be on the system.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#5

On Sat, Nov 23, 2013 at 12:15 AM, Mrigesh Priyadarshi
mrigeshpriyadarshi@gmail.com wrote:

Our use case is that we have a service portal and we want end users to
provision their instance with custom configuration. We want to have a
default configuration in cookbook so, if the user doesnt select any custom
config for the installs the service portal will not generate any json file.
And will run the chef-client with default values defined in cookbook but if
they select any configuration chef-client should include those with the json
file.

In this scenario, what ever value we pass through the attrib file gets
persisted as normal type and doesnt get reset in the next run if the json
file is not passed.

Hi Mrigesh,

You might need to take a different approach then. As I mentioned, you
can think of Chef as being a “desired state” system, so persistence is
designed into it.

It would be better if, through your service portal, the user’s
instance were assigned a certain Chef Role that contains all the
attributes pertinent to that role. Then, through the magic of
attribute precedence, those values will be the ones used by the system
instead of the defaults you defined in the cookbook.

http://docs.opscode.com/essentials_cookbook_attribute_files.html

I hope that helps.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#6

Hey Julian,

We considered that option but with that we would need to create all sort of
permutation and combination with versions of different components in CHEF
as roles. And that would restrict the options available to end user as well
as create a bottleneck for us.
That why we were considering this option.
Can we reset the persisted data at end of chef-client run??

Warm Regards,

Mrigesh Priyadarshi
Mob:-+91-720-402-2510

On Sat, Nov 23, 2013 at 10:48 PM, Julian C. Dunn jdunn@aquezada.com wrote:

On Sat, Nov 23, 2013 at 12:15 AM, Mrigesh Priyadarshi
mrigeshpriyadarshi@gmail.com wrote:

Our use case is that we have a service portal and we want end users to
provision their instance with custom configuration. We want to have a
default configuration in cookbook so, if the user doesnt select any
custom
config for the installs the service portal will not generate any json
file.
And will run the chef-client with default values defined in cookbook but
if
they select any configuration chef-client should include those with the
json
file.

In this scenario, what ever value we pass through the attrib file gets
persisted as normal type and doesnt get reset in the next run if the json
file is not passed.

Hi Mrigesh,

You might need to take a different approach then. As I mentioned, you
can think of Chef as being a “desired state” system, so persistence is
designed into it.

It would be better if, through your service portal, the user’s
instance were assigned a certain Chef Role that contains all the
attributes pertinent to that role. Then, through the magic of
attribute precedence, those values will be the ones used by the system
instead of the defaults you defined in the cookbook.

http://docs.opscode.com/essentials_cookbook_attribute_files.html

I hope that helps.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#7

Hi Mrigesh,

I’ve been in a similar scenario in past roles. You don’t need to create
every possible permutation. It’s possible to grant your users access to be
able to create their own roles. If you’re using Enterprise Chef, you can
allow your users to manage their own roles without granting access to any
cookbooks or other data you don’t want them to modify. You can then use
attribute merge precedence as Julian describes.

Alternately, if you’re already creating a JSON file with unique attributes
for the node, there’s no reason you can’t continue to pass that file during
every chef-client run. Make sure your bootstrap process persists that file
to a predictable location and configure chef-client to run with ‘-j
/path/to/file.json’ every time it runs. This is less desirable since you
now have configuration that is not stored anywhere other than this one
node. But that may get you the result you’re looking for.

HTH,


George Miranda
Consultant, Evangelist, Trainer, : | Opscode Inc.
gmiranda@opscode.com | (512) 481-2876
Twitter, IRC, GitHub, Most IMs: gmiranda23

On Sat, Nov 23, 2013 at 11:27 AM, Mrigesh Priyadarshi <
mrigeshpriyadarshi@gmail.com> wrote:

Hey Julian,

We considered that option but with that we would need to create all sort
of permutation and combination with versions of different components in
CHEF as roles. And that would restrict the options available to end user as
well as create a bottleneck for us.
That why we were considering this option.
Can we reset the persisted data at end of chef-client run??

Warm Regards,

Mrigesh Priyadarshi
Mob:-+91-720-402-2510

On Sat, Nov 23, 2013 at 10:48 PM, Julian C. Dunn jdunn@aquezada.comwrote:

On Sat, Nov 23, 2013 at 12:15 AM, Mrigesh Priyadarshi
mrigeshpriyadarshi@gmail.com wrote:

Our use case is that we have a service portal and we want end users to
provision their instance with custom configuration. We want to have a
default configuration in cookbook so, if the user doesnt select any
custom
config for the installs the service portal will not generate any json
file.
And will run the chef-client with default values defined in cookbook
but if
they select any configuration chef-client should include those with the
json
file.

In this scenario, what ever value we pass through the attrib file gets
persisted as normal type and doesnt get reset in the next run if the
json
file is not passed.

Hi Mrigesh,

You might need to take a different approach then. As I mentioned, you
can think of Chef as being a “desired state” system, so persistence is
designed into it.

It would be better if, through your service portal, the user’s
instance were assigned a certain Chef Role that contains all the
attributes pertinent to that role. Then, through the magic of
attribute precedence, those values will be the ones used by the system
instead of the defaults you defined in the cookbook.

http://docs.opscode.com/essentials_cookbook_attribute_files.html

I hope that helps.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


George Miranda
Consultant, Evangelist, Trainer, : | Opscode Inc.
gmiranda@opscode.com | (512) 481-2876
Twitter, IRC, GitHub, Most IMs: gmiranda23


#8

Hello George,

Yes, We are able to generate and pass the json file as per the components
selected by end user but we want if the user doesnt select any particular
version, the cookbooks should fall back on Default values listed in
Attribute file.

This is where the value persisted node object takes precedence over the
default value and beats our expectation.

Warm Regards,

Mrigesh Priyadarshi
Mob:-+91-720-402-2510

On Sun, Nov 24, 2013 at 5:38 AM, George Miranda gmiranda@opscode.comwrote:

Hi Mrigesh,

I’ve been in a similar scenario in past roles. You don’t need to create
every possible permutation. It’s possible to grant your users access to be
able to create their own roles. If you’re using Enterprise Chef, you can
allow your users to manage their own roles without granting access to any
cookbooks or other data you don’t want them to modify. You can then use
attribute merge precedence as Julian describes.

Alternately, if you’re already creating a JSON file with unique attributes
for the node, there’s no reason you can’t continue to pass that file during
every chef-client run. Make sure your bootstrap process persists that file
to a predictable location and configure chef-client to run with ‘-j
/path/to/file.json’ every time it runs. This is less desirable since you
now have configuration that is not stored anywhere other than this one
node. But that may get you the result you’re looking for.

HTH,


George Miranda
Consultant, Evangelist, Trainer, : | Opscode Inc.
gmiranda@opscode.com | (512) 481-2876
Twitter, IRC, GitHub, Most IMs: gmiranda23

On Sat, Nov 23, 2013 at 11:27 AM, Mrigesh Priyadarshi <
mrigeshpriyadarshi@gmail.com> wrote:

Hey Julian,

We considered that option but with that we would need to create all sort
of permutation and combination with versions of different components in
CHEF as roles. And that would restrict the options available to end user as
well as create a bottleneck for us.
That why we were considering this option.
Can we reset the persisted data at end of chef-client run??

Warm Regards,

Mrigesh Priyadarshi
Mob:-+91-720-402-2510

On Sat, Nov 23, 2013 at 10:48 PM, Julian C. Dunn jdunn@aquezada.comwrote:

On Sat, Nov 23, 2013 at 12:15 AM, Mrigesh Priyadarshi
mrigeshpriyadarshi@gmail.com wrote:

Our use case is that we have a service portal and we want end users to
provision their instance with custom configuration. We want to have a
default configuration in cookbook so, if the user doesnt select any
custom
config for the installs the service portal will not generate any json
file.
And will run the chef-client with default values defined in cookbook
but if
they select any configuration chef-client should include those with
the json
file.

In this scenario, what ever value we pass through the attrib file gets
persisted as normal type and doesnt get reset in the next run if the
json
file is not passed.

Hi Mrigesh,

You might need to take a different approach then. As I mentioned, you
can think of Chef as being a “desired state” system, so persistence is
designed into it.

It would be better if, through your service portal, the user’s
instance were assigned a certain Chef Role that contains all the
attributes pertinent to that role. Then, through the magic of
attribute precedence, those values will be the ones used by the system
instead of the defaults you defined in the cookbook.

http://docs.opscode.com/essentials_cookbook_attribute_files.html

I hope that helps.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


George Miranda
Consultant, Evangelist, Trainer, : | Opscode Inc.
gmiranda@opscode.com | (512) 481-2876
Twitter, IRC, GitHub, Most IMs: gmiranda23


#9

Mrigesh,

You’re describing the expected behavior. There must be something odd about
the implementation. This will be difficult to troubleshoot without you
providing specifics.

At a bare minimum, I would need to see the contents of the json file, the
attributes in the cookbook, and the values in the node object. You should
provide all of those in both the case where a user selects some values and
where a user selects no values.

Or maybe I’m not understanding the use case. I’ve made this situation work
in the past. Somewhere, somehow, your process must be setting higher
precedence values in an unexpected manner.

On Sun, Nov 24, 2013 at 9:20 PM, Mrigesh Priyadarshi <
mrigeshpriyadarshi@gmail.com> wrote:

Hello George,

Yes, We are able to generate and pass the json file as per the components
selected by end user but we want if the user doesnt select any particular
version, the cookbooks should fall back on Default values listed in
Attribute file.

This is where the value persisted node object takes precedence over the
default value and beats our expectation.

Warm Regards,

Mrigesh Priyadarshi
Mob:-+91-720-402-2510

On Sun, Nov 24, 2013 at 5:38 AM, George Miranda gmiranda@opscode.comwrote:

Hi Mrigesh,

I’ve been in a similar scenario in past roles. You don’t need to create
every possible permutation. It’s possible to grant your users access to be
able to create their own roles. If you’re using Enterprise Chef, you can
allow your users to manage their own roles without granting access to any
cookbooks or other data you don’t want them to modify. You can then use
attribute merge precedence as Julian describes.

Alternately, if you’re already creating a JSON file with unique
attributes for the node, there’s no reason you can’t continue to pass that
file during every chef-client run. Make sure your bootstrap process
persists that file to a predictable location and configure chef-client to
run with ‘-j /path/to/file.json’ every time it runs. This is less
desirable since you now have configuration that is not stored anywhere
other than this one node. But that may get you the result you’re looking
for.

HTH,


George Miranda
Consultant, Evangelist, Trainer, : | Opscode Inc.
gmiranda@opscode.com | (512) 481-2876
Twitter, IRC, GitHub, Most IMs: gmiranda23

On Sat, Nov 23, 2013 at 11:27 AM, Mrigesh Priyadarshi <
mrigeshpriyadarshi@gmail.com> wrote:

Hey Julian,

We considered that option but with that we would need to create all sort
of permutation and combination with versions of different components in
CHEF as roles. And that would restrict the options available to end user as
well as create a bottleneck for us.
That why we were considering this option.
Can we reset the persisted data at end of chef-client run??

Warm Regards,

Mrigesh Priyadarshi
Mob:-+91-720-402-2510

On Sat, Nov 23, 2013 at 10:48 PM, Julian C. Dunn jdunn@aquezada.comwrote:

On Sat, Nov 23, 2013 at 12:15 AM, Mrigesh Priyadarshi
mrigeshpriyadarshi@gmail.com wrote:

Our use case is that we have a service portal and we want end users to
provision their instance with custom configuration. We want to have a
default configuration in cookbook so, if the user doesnt select any
custom
config for the installs the service portal will not generate any json
file.
And will run the chef-client with default values defined in cookbook
but if
they select any configuration chef-client should include those with
the json
file.

In this scenario, what ever value we pass through the attrib file gets
persisted as normal type and doesnt get reset in the next run if the
json
file is not passed.

Hi Mrigesh,

You might need to take a different approach then. As I mentioned, you
can think of Chef as being a “desired state” system, so persistence is
designed into it.

It would be better if, through your service portal, the user’s
instance were assigned a certain Chef Role that contains all the
attributes pertinent to that role. Then, through the magic of
attribute precedence, those values will be the ones used by the system
instead of the defaults you defined in the cookbook.

http://docs.opscode.com/essentials_cookbook_attribute_files.html

I hope that helps.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


George Miranda
Consultant, Evangelist, Trainer, : | Opscode Inc.
gmiranda@opscode.com | (512) 481-2876
Twitter, IRC, GitHub, Most IMs: gmiranda23


George Miranda
Consultant, Evangelist, Trainer, : | Opscode Inc.
gmiranda@opscode.com | (512) 481-2876
Twitter, IRC, GitHub, Most IMs: gmiranda23