Add --override-attributes option to override node attributes for a single chef run.

[andruby]

A working prototype that allows overriding node attributes from the command line.

Usage Example:

knife solo cook <node> --override-attributes '{"mysql": {"server_root_password": "<passwd>"}}'

I want this so I can share my kitchen and keep sensitive attributes out of the node.json file. My cookbooks only run certain resources when the attributes needed are set. (eg: only install and configure mysql when the node['mysql']['server_root_password'] is set)

The code is a little hacky, but it works. Any ideas for improvement are welcome.

[matschaffer]

Can I get some more info on your use case? I get the feeling the shared attributes could be handled by a cookbook then the node configs could be .gitignore'd for sharing purposes. Is there a reason that approach wouldn't cut it?

[andruby]

Hi Mat,

The node configs contain client specific configuration. Our product is customized for each client. They all get a dedicated server/node. We use two sets of databags for environment-data and project-data, and the node.json sets which environment and project the node should run. So the node config needs to be shared. I can't think of a way where we could eliminate the need to share node specific configuration.

The thing that I like about my solution is that I can share the kitchen with external consultants. They can run chef-solo to deploy new versions of our application without having access to the mysql root password. Meanwhile, if there is a change that requires mysql root privileges (creating new databases, changing users or permissions), I can easily run the same knife command with a single appended node attribute. In certain circumstances, we can share the password ad-hoc with the consultants if needed. (eg: If bad things happen while I'm on vacation).

I do like being able to run chef in two modes (privileged and unprivileged).

[matschaffer]

What about keeping the passwords in an optional data bag? The cookbook
could pull that in as attributes if it exists (which it would on your
machine) or ignore it if it doesn't.

My hesitance is that (afaik) vanilla chef-solo and chef-client don't have
an extra overrides beyond the dna.json file. That would put this
feature somewhere outside my goals for knife-solo. Let me know if I'm
mistaken.

On Tuesday, August 13, 2013, Andrew Fecheyr wrote:

Hi Mat,

The node configs contain client specific configuration. Our product is
customized for each client. They all get a dedicated server/node. We use
two sets of databags for environment-data and project-data, and the
node.json sets which environment and project the node should run. So the
node config needs to be shared. I can't think of a way where we could
eliminate the need to share node specific configuration.

The thing that I like about my solution is that I can share the kitchen
with external consultants. They can run chef-solo to deploy new versions of
our application without having access to the mysql root password.
Meanwhile, if there is a change that requires mysql root privileges
(creating new databases, changing users or permissions), I can easily run
the same knife command with a single appended node attribute. In certain
circumstances, we can share the password ad-hoc with the consultants if
needed. (eg: If bad things happen while I'm on vacation).

I do like being able to run chef in two modes (privileged and
unprivileged).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/275#issuecomment-22617981
.

-Mat

about.me/matschaffer

[tmatilai]

Just a quick drive-by noting that this is related with #232.

[andruby]

The optional databag is a good idea. It allows running chef in two modes, but it is less explicit. It also needs a file on disk. I understand your hesitance though and I would prefer adding this to chef-solo too.

@tmatilai: I actually expected the existing --json-attributes option to add/override node attributes on top of node.json.

[tmatilai]

@andruby Yeah, but historical reasons etc... =)

[matschaffer]

Is there a way we could code this to benefit #232 as well? Supporting node search is a great use case. Passing mysql passwords as command line options is not something I'm excited about supporting especially given security concerns.

[andruby]

I can adapt the code so that it merges attributes passed with --json-attributes in stead of using --override-attributes so that it benefits #232 as well. Is that something that would get merged into master?

Using this behavior with the application resource makes it easy to override the default :deploy action with :force_deploy from the command line.

[matschaffer]

Actually encountered this at a recent client. The use case there is using command line args to feed in a deployment tag for continuous deployment. I like that better than server passwords so I'm down for this feature :)

[adagios]

Any update on this? I would really like this feature. Is it something that's inline with current project ideas or should I look for another solution?

[matschaffer]

@adagios I'm all for it one-off inline control, but I'm unsure the PR is exactly what we're looking for here.

Some tests would be good at least, but I'm also curious if we should integrate this with the existing -j option. Seems like there's been some conversation on that front in other related tickets.