Comment From: warroyo
is there a plan to add this in any upcoming releases?
Comment From: ryanjbaxter
Hope so, but havent started work on it yet.
Comment From: warroyo
@ryanjbaxter I just got back into doing some things with the config server and ran into this issue again. has there been any progress on this? looking at the docs It seems like it is still an issue.
Comment From: ryanjbaxter
Trying to remember exactly what was meant by this issue, but it sounds very similar to something we introduced recently http://cloud.spring.io/spring-cloud-static/Finchley.RELEASE/single/spring-cloud.html#composite-environment-repositories
Let me know if that solves your use case.
Comment From: spencergibb
It is, but if there's an exception, later repos won't be queried, iirc.
Comment From: warroyo
it is related to composites, however the issue is that when using vault it always requires a token to be sent for vault otherwise it returns a 400. it is documented per the image below, but this becomes a pain when trying to add vault to an existing config server. If an app does does not pass the vault token it would be nice to maybe just log a warning but return the git or other backend properties.
Comment From: ryanjbaxter
OK I understand now, thanks.
Comment From: shopey
Hi, is this planned to be resolved in any upcoming release? it been hanging around for a while :), This increases the resilience of the environment in general and potentially services that can just work with what is available at that point in time.
Comment From: jaynsuthar
Hello, Is there any plan to add this in near future? It seems to be a security concern to provide the token every time the client wants to query something from config server even though the client only needs to query from the git repository.
Comment From: habuma
I'm working on a PR for this and have considered a few options. Bear in mind that my interest in this is being able to continue to serve Git properties even though the Config Server may have a Vault backend and the client hasn't sent a Vault token on the request.
Two things I've tried and both work (to varying degrees):
- In
CompositeEnvironmentRepository.findOne(), catch any exceptions thrown by callingfindOne()on the subordinate repositories. Thecatchblock I've written doesn't do anything but log the failure. In the end, the failing backend simply doesn't appear in the response. This option's benefit is that it works for any failure case, not just Vault backends. The downside (or, arguably a benefit) is that there's nothing other than the log message to let the client even know that there is another backend that could've provided properties, but it was unreadable for some reason. I was thinking of also adding an emptyPropertySourceto the environment, but at that point in the code there's not much info available to construct a good name for the property source (e.g., something like "vault:myapp"). Of course, one option is to expose agetName()method onEnvironmentRepository, although that's a biggish change for such a small benefit. - In
AbstractVaultEnvironmentRepository.findOne()(and likewise, in other environment repos that might fail), catch any exceptions and add an empty property source with the same name that is used in the success case.
I think that the first option is the one that's probably best, although the second option gives a bit more info to the client. It would also be nice if there were some other property in PropertySource to communicate failure cases. But that's only if it's deemed important to even include an empty property source in the response.
Does anyone have an opinion on this? Either way, I'm quite close to submitting a PR, but am trying to decide what is the best approach.