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.
About Attributes
I hope that helps.
--
[ Julian C. Dunn jdunn@aquezada.com * Sorry, I'm ]
[ WWW: Julian Dunn's Blog - Commentary on media, technology, and everything in between. * 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