Replies: 1 comment
-
Some of the stuff we discussed today: It should be safe to assume that Faults are only ever resolved inside of items (e.g., while rendering a file template, while executing an In other words, the true values of Faults are only needed inside of items. Or when manually inspecting them using commands like However:
Here, a Fault is being referenced in So, we can’t simply do this: “Have all calls to Also: How would It would be cleaner to not allow partial strings:
I think it would be doable to enforce this requirement, but I’m not sure if it’s practical. If we did allow partial strings, though, then why not replace all magic strings in the rendered file item? This can be tricky due to collisions, of course. |
Beta Was this translation helpful? Give feedback.
-
Faults for a long time have been both necessary and a pain to handle.
Why do we need Faults?
Why are Faults painful?
Where might Faults need to be resolved?
This boils down to a list of places where
node.metadata
can be used:1) Reactors
When returning partial metadata here, we don't need secrets resolved.
2) items.py
We may need some secrets here that we end up formatting into action commands. But insisting on resolving all secrets here would mean that users without access to all secrets won't even be able to generate a list of items (and thus lose the ability to even apply items they have access to).
3) File templates and k8s manifests
We need the secret here, but if we fail to get it, we know what item it's for and can just skip that item.
4) CLI node lambda selectors
Users would probably expect access to secrets here, but rarely actually use them.
5) bw metadata
Dumping metadata to JSON resolves Faults. This isn't always desirable because it makes it hard to find out where Faults are actually being used (they look like regular strings here).
What can we do about it?
The solution most likely involves magic strings of some sort. Without magic strings, secret retrieval has to happen explicitly in every place a secret might be needed (i.e. inside a file template).
For a more general approach that requires no extra logic in templates, we need a way to retroactively insert secrets into metadata. This is where magic strings come in.
The difficulty with magic strings is finding the best time to resolve them. Faults have the benefit of only being resolved when they are actually used. With magic strings, this might be impossible.
Let's try and find a reasonable set of points where magic strings would be resolved for a node. We need to modify the logic behind
node.metadata
to not resolve magic strings in: reactors, node selectors,bw metadata
. Accessingnode.metadata
from items.py or file templates will resolve all magic strings for a node. This means that it is no longer possible to apply a node when you don't have all the secrets. But at least you don't need secrets to every node. Might be a reasonable compromise.Beta Was this translation helpful? Give feedback.
All reactions