Marko Mikulicic
Marko Mikulicic
Perhaps I'm holding it wrong. This is my use case: I have flag that takes a file path. I want this flag to default to foo.txt if the file foo.txt...
Yes I know I can use a custom type but I hoped I could not force this custom type to the body of the commands.
Also, with flag types the logic can only handle one flag at a time
I don't understand why can't those structs get the context. I guess usually there will be multiple instances of them, since they will be declared as values. Sure, they could...
Can you share the resulting sealed secrets (the one that works and the one that doesn't)?
I'm a little bit confused about this use case. I'd really like to better understand what problem are you trying to solve. Here is how I think about the problem...
Thanks! This is actually similar to an issue reported with spinnaker: https://github.com/bitnami-labs/sealed-secrets/issues/62#issuecomment-516915077 Perhaps we can find a way to address both issues
that would require teaching the core secretGenerator plugin about sealed secrets. A possible horrible hack we could do is to literally create a Secret with fake items containing encrypted data...
yeah I was glossing over that. We might just put the output of `kubeseal` into a file and `files` to load it: ```bash | kubeseal >sealedsecret_unseal_here.yaml ``` ``` secretGenerator: -...
it was just an idea; there is nothing in the controller right now that would act that way.