Replace first | operator in secrets functions with ||

[uberspot]

Currently as discussed in #131 the first | operator in secrets is semantically different than the rest of then.
Given ${<ref_type>:<file_path>:<hash_digest>|<func_str|func2|func3>}
the first operator checks if the filepath exists, and only executes func_str/2/3 etc if that file doesn't exist. The other operators after that are always executed if the first check passes.
This isn't clear in the secrets reference structure.
Something like
${<ref_type>:<file_path>:<hash_digest>||<func_str|func2|func3>} would make it easier to understand and would act like a logical OR operator (as it currently does).

This is a breaking change, so extra attention needs to be paid either on communicating it or making it work in the interim.

[nikkomega]

Suggestion: with this change, could it also support ?{gkms:password|base64||randomstr|base64} to eliminate the need for pre-base64-ing text values in Kapitan secrets? Actually that leads me to picture something like ?{(gkms:password||randomstr)|base64}, but then we're getting into a mini expression language for these things that further diverges from the Jinja filter style syntax.

[uberspot]

What is the use case the above might be needed?
Semantically, going towards a mini expression language might be an overkill for how Kapitan should handle secrets.
If you just want to base64 an existing secret before using it (e.g. in kubernetes secrets?) then you can do that already. Look at the password_sha256 here https://github.com/deepmind/kapitan/blob/master/examples/kubernetes/inventory/classes/component/mysql.yml#L31 You can do the same to base64 an existing password. :)

[nikkomega]

Just did a bit of experimenting; I actually misunderstood how the chain in that example works when I first saw it - I was missing the fact that the OR part generated a new secret if it didn't already exist. For this sort of example, where you have one secret derived from another, if you delete the backing secret for password, then recompile, password will get a new secret, but password_sha256 will still be the hash of the old one. You now have a derivation relationship, such that you have to remember to delete the derived secret as well, when what I think I'd want is for the derivation function to just be applied to the revealed source secret at reveal time, and not generate its own secret. (But as I just discovered, I'm probably missing some subtlety here.)

[ramaro]

@nikkomega yes that I exactly how it works and it does suffer from that limitation. You'll need to delete derived secrets as they are only recreated if not existent.
This makes me think - is there space for a dependency feature here? E.g. secretB depends on secretA, therefore if secretA is recreated, secretB is as well.