These are chat archives for spring-cloud/spring-cloud

31st
Mar 2017
Tommy Ludwig
@shakuzen
Mar 31 2017 01:00

@aabutaleb @dsyer The priority of sources in Spring Cloud Config you were discussing is the intended behavior, I believe. Though it was unexpected to me initially too.

In short, more specific property sources win. In the example given, /application-uat.yml is a profile-specific property source, so it overrides /myservice/uat/myservice.yml which is the default property source for the myservice application. It’s maybe a little unique here because that path is reached using the profile, but the file (property source) itself is still the default profile. If you had a /myservice/uat/myservice-uat.yml I would expect that to override anything in /application-uat.yml.

So, currently, any properties defined in application-{profile}.yml will override values in application-specific default property sources, from my understanding.
Amin Abu-Taleb
@aabutaleb
Mar 31 2017 08:30
Thanks @shakuzen that worked as well, I would've expected the priorities to be based on how specific the service name is vs the general word application but what you said about the profiles makes total sense
DarkEdges
@darkedges
Mar 31 2017 08:35
Evening. Is there any good pattern available for supporting multiple service versions with zuul? i.e use metadata to define the version of the service and route to different versions via zuul i.e /v1/xxx and /v2/xxx
Tommy Ludwig
@shakuzen
Mar 31 2017 08:36
@aabutaleb I also expected the same thing as you originally. I know others in my department have been confused by this as well. It could probably be better documented.
Dave Syer
@dsyer
Mar 31 2017 08:54
Yeah, I guess {profile} is maybe not a very useful placeholder layout.
If someone wants to document it and explain why it might be a bad idea, pull requests are always welcome
Tommy Ludwig
@shakuzen
Mar 31 2017 09:15
In my case, I’m not using the profile in the directory structure, but intuitively (to me) I originally thought that an application’s specific configuration (say, myapp.yml) would take precedent over the shared (but profiled) configuration in say application-dev.yml, but this is not the case.
Dave Syer
@dsyer
Mar 31 2017 09:17
That's just the way Spring Boot defines it isn't it?
You could argue it's wrong or surprising still, but better to have that discussion in a Spring Boot issue.
Unless you think we could change it in Spring Cloud
I assumed it was just Spring Boot choosing the priority, but if we have any control here maybe we should look into it.
Tommy Ludwig
@shakuzen
Mar 31 2017 09:19
Spring Boot doesn’t know about shared (application-dev.yml) versus application-specific (myapp.yml) because that is specific to Spring Cloud, right?
Amin Abu-Taleb
@aabutaleb
Mar 31 2017 09:19
Maybe if the search path, like in my case, already includes {profile} that should be equivalent to having -{profile} as part of the filename. Are search paths for configserver Spring cloud?
Dave Syer
@dsyer
Mar 31 2017 09:20
Spring Boot has a spring.config.name feature
That's what we use in Cloud
It's possible we can manipulate the order there
Tommy Ludwig
@shakuzen
Mar 31 2017 09:20
Ah, I see. That makes sense
Dave Syer
@dsyer
Mar 31 2017 09:22
@aabutaleb I prefer to keep the rule simple: it's the same as Spring Boot. You just need to define the mapping from searchPath and {name}/{profile}/{label} to spring.config.name and spring.config.location.
If we want to we can change the mapping.
But I wouldn't want to change the way that Boot creates the property sources
We should document the mapping more clearly as a first step I guess.
Amin Abu-Taleb
@aabutaleb
Mar 31 2017 09:23
I see, fair enough
Josh Fix
@joshfix
Mar 31 2017 13:16
i just setup security on actuator with the following properties management.security.enabled: true endpoints.health.sensitive: false. the sensitive endpoints give me a 401 if i'm not logging in and work successfully if i do log in. but i'm seeing peculiar behaviour with the health endpoint -- no matter if i'm logged in or not, it's giving me the status only version... just a one-liner saying status is up
not sure what i might be missing to get the full health response
Dave Syer
@dsyer
Mar 31 2017 13:20
That's a Spring Boot question really
Josh Fix
@joshfix
Mar 31 2017 13:53
ah sorry, wrong channel. but per that table dave, with security enabled and the health endpoint not sensitive, unauthenticated should be status only and authenticated should be the full content
when i'm authenticated i'm still getting status only
Dave Syer
@dsyer
Mar 31 2017 13:54
I guess that means your're not authenticated
Josh Fix
@joshfix
Mar 31 2017 13:57
our auth uses an api key in the url. when i use it, i can get to all the actuator endpoints, when i take it out, all the other actuator endpoints give me a 401
that pretty much tells me the auth is working. but no matter what, health only gives me status only
i even wrote my own little test controller to check if the security context sees me as authenticated and it does
Dave Syer
@dsyer
Mar 31 2017 13:59
Is your user in the right role?
Josh Fix
@joshfix
Mar 31 2017 14:00
yes, i changed the role to a custom role and made sure it's being assigned properly. the other endpoints are working when i authenticate and don't work when i'm not authenticated
Dave Syer
@dsyer
Mar 31 2017 14:01
The health endpoint has its own access decision internally
You have to tell it what roles you are using separately I think, if it's not the default
Josh Fix
@joshfix
Mar 31 2017 14:05
ah ok
i'll dig into that
can't seem to find where health is treated differently
any tips on where the config is or what the config properties are?
Dave Syer
@dsyer
Mar 31 2017 15:20
Look in HealthMvcEndpoint
Josh Fix
@joshfix
Mar 31 2017 16:16
seems to be some disconnect with security for some reason. i'm stepping through with a debugger -- the role i defined is in the roles list, but the principal shows up as null...
DarkEdges
@darkedges
Mar 31 2017 19:35
Found a solution using PatternServiceRouteMapper to my versioning question
Josh Fix
@joshfix
Mar 31 2017 20:56
i'm guessing my issue stems from me using a preauthentication filter and actuator having it's own filter chain... it recognizes my user role and everything will fail if the role is not present, however when the invoke method of HealthMvcEndpoint is called, the Principal object is null