Export Policyfile as Chef Zero-compatible repo

[danielsdeleo]

Export a policy as a Chef Zero compatible repo. The immediate goal for this work is to enable policyfiles to be run in TK via a TK provisioner (will be created after this is merged), but it also enables chef-solo-style workflows to be used by packaging and distributing policy repos via an out-of-band mechanism and running chef-client in local mode.

Looking for feedback on the force option: is it too strict? Should --force only be required if a cookbooks and/or data_bags directory is present? Should the cleanup that --force implies only affect those directories?

@opscode/client-engineers

[tyler-ball]

I'm confused - shouldn't this cause an error because the method call is being completed with )before the multi-line-string delimiter is reached?

[danielsdeleo]

Ruby's grammar allows you to pass a heredoc string to a method using this syntax. It's definitely a little weird looking.

BTW, I think the syntax you'd expect actually doesn't work, e.g., I think this isn't valid:

method_call(<<-HERE_DOC
some text
HERE_DOC)

[tyler-ball]

Gotcha - The syntax I am familiar with doesn't use parens

method_call <<-HERE_DOC
some text
HERE_DOC

[tyler-ball]

I think your use of --force LGTM. The use case I see for that is a user rapidly developing locally. They are constantly making changes to a cookbook, packaging it into a policy and converging a node against a locally running chef zero instance. In this case I don't think the user cares what else is in the target directory, so a full wipe makes sense.

In the TK use case I think it also makes sense to nuke the entire target directory.

What else could be in that directory that chef-zero would read? Roles?

[danielsdeleo]

@tyler-ball I'm thinking that you might have data bag items (other than policyfile ones), or you could have nodes from previous chef-zero runs. It probably won't be an issue when using TK, so it's something we could revisit later if it's an issue...

[tyler-ball]

If you needed to write to the directory and keep those contents around, users can have their CI tool (or whatever is using this export logic) export to timestamped directories. Or some pattern of unique directories.

To me, it seems a question of workflows. If more workflows will keep around these exported directories, we should add tooling to make it easier to perform this workflow. But if more workflows do not need this complexity lets make the consumer responsible for it. There is nothing here that prevents them from reusing these exported directories.

[danielsdeleo]

I think this should be good to go now. I opted not to extract the data bag item code to a shared location because it only exists for compatibility mode, which is slated to be removed once we have "native" policyfile support in the Chef Server.

As for the behavior of the --force option, I think it's good enough for now, if a user reports a use case that requires a more careful conflict check, we can deal with that then.

[tyler-ball]

👍