Gyorgy Nadaban

The current implementation only supports a single source per application to sync/subscribe to, which may arguably be the most common/important use-case where everything from chart to values files are in...

> As I understand it, subscribing to an official chart repository for templates and default values and to a git repo for value overrides was the main driver behind multi-source...

@akolacz , can you provide an example for your use-case, and let me know if what @krancour is advocating for is a requirement for you, eg. do you have an...

> Isn't the example you gave, which you say is common (and I agree, it is) an instance of what you claimed to be an anti-pattern? Namely, "where manifests/charts/resources of...

> So you seem only to care whether you're synced as you expect to the repo containing your values file. > In the context of subscribing to a single Git...

@krancour I understand your position of wanting to enforce good, robust solutions, I'm just not sure why this particular PR is expected to address every single edge-case all at once....

Hi @mpalmi, I saw your [comment](https://github.com/hashicorp/vault/issues/28792#issuecomment-2445390836) on #28792 that you will work on this. Have you had a chance to look into this?

@bonifaido : Creating the Vault you shared with a service account and role like this still ends up removing the `veleroEnabled` setting. Tried: ```yaml apiVersion: v1 kind: ServiceAccount metadata: name:...

@bonifaido : Apparently we were using an older operator, using the latest with the 1.3.2 Helm chart resolved the issue, feel free to close this PR.

@jessesuen, I would caution against having token issuer/validator features in Kargo itself. If you're looking for an API for service account token creation with TTL, I've done this in our...