Added execution functions to work with base64 encoded files; added state function to manage base64 encoded files

[whiteinge]

Still needs:

• permission handling on destination file
• tests
• better minion-side Pillar integration
• better master-side Pillar integration

Existing minion-side Pillar integration looks like this:

write_base64_encoded_string_to_a_file:
  file.decode:
    - name: /tmp/new_file
    - encoding_type: base64
    - encoded_data: |
        {{ salt.pillar.get('path:to:data') | indent(8) }}

Existing master-side Pillar integration looks like this:

path:
  to:
    data: |
      {{ salt.hashutil.base64_encodefile('/path/to/binary_file') | indent(6) }}

[whiteinge]

One way to better the minion-side integration is to just add a contents_pillar argument (ala file.managed). It would be a two-line change. Another way would be to introduce something like a pillar://path:to:data construct. I prefer the latter but it deviates from existing Salt patterns (e.g., contents_pillar) and it also steals the pillar:// namespace which may be unfortunate if we ever decide to add better Pillar-based file transfers (i.e., without resorting to base64 encoding).

Thoughts?

[whiteinge]

I think the best way to better master-side integration is to wrap this with an ext_pillar module. Syntax could look like this:

ext_pillar:
  - base64_encode:
      path:to:data1: /path/to/file1
      path:to:data2: /path/to/file2

Available via a pillar.get('path:to:data2') call, where data2 would be clobbered if it already existed in Pillar.

[thatch45]

Yes, I think that we should stick with contents_pillar, and lean on the file.managed stuff as much as possible

[whiteinge]

Roger that. I can't re-use file.managed for this but I will add a
contents_pillar to the new file.decode state module.

On Thu Jan 22 2015 at 1:41:54 PM Thomas S Hatch notifications@github.com
wrote:

Yes, I think that we should stick with contents_pillar, and lean on the
file.managed stuff as much as possible

—
Reply to this email directly or view it on GitHub
#19935 (comment).

[whiteinge]

More commits incoming...

On Thu Jan 22 2015 at 1:44:00 PM Seth House seth@eseth.com wrote:

Roger that. I can't re-use file.managed for this but I will add a
contents_pillar to the new file.decode state module.

On Thu Jan 22 2015 at 1:41:54 PM Thomas S Hatch notifications@github.com
wrote:

Yes, I think that we should stick with contents_pillar, and lean on the
file.managed stuff as much as possible

—
Reply to this email directly or view it on GitHub
#19935 (comment).

[thatch45]

@whiteinge what is the status here?

[whiteinge]

Swamped with business-needs work. Still need to get this done.

On Fri, Feb 6, 2015 at 10:19 AM, Thomas S Hatch notifications@github.com
wrote:

@whiteinge https://github.com/whiteinge what is the status here?

—
Reply to this email directly or view it on GitHub
#19935 (comment).

[cachedout]

Bump @whiteinge. Just looking for a status update here. Thanks!

[whiteinge]

Thanks for the ping. I'm realistically four weeks out before I can return to this at best. :-/

I'll reopen this at that time.

[baniobloom]

@whiteinge Hello, any progress on this feature?

[whiteinge]

@baniobloom I don't have any time to work on the bullets listed above. That said the execution and state module are perfectly functional. I've opened #26690 with the contents_pillar addition. We can augment and add features to these functions over time.