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

11th
Aug 2015
Aizhan Toregozhina
@atoregozh
Aug 11 2015 16:04
Hello. it appears that the git branch within spring.cloud.config.label's label property in client's bootstrap.yml (or .properties) must exist. Properties in the next provided git branch in comma separated list of label aren't searched. Is that intended? This is not what is described in the documentation. @spencergibb @dsyer
Spencer Gibb
@spencergibb
Aug 11 2015 16:07
The docs say "Label can also be provided as a comma-separated list, in which case the items in the list are tried on-by-one until one succeeds"
Aizhan Toregozhina
@atoregozh
Aug 11 2015 16:08
but this is not we see @spencergibb
Spencer Gibb
@spencergibb
Aug 11 2015 16:08
so either the docs need to be updated to say the labels must exist or a change to ignore failures
Aizhan Toregozhina
@atoregozh
Aug 11 2015 16:09
@spencergibb change to ignore failures sounds better
Spencer Gibb
@spencergibb
Aug 11 2015 16:10
what if it is a real failure, not a “that label doesn’t exist”?
Aizhan Toregozhina
@atoregozh
Aug 11 2015 16:11
@spencergibb wouldn't it try and search through all git branched provided in label before it would conclude that it's a failure?
@spencergibb maybe I'm not understanding what you mean by real failure
checketts
@checketts
Aug 11 2015 16:21
@spencergibb I just debugged into it, and for the first label returned a 404, throwing a HttpClientErrorException so it kicked flow out of the loop so it didn't try the next label (line 79 of ConfigServicePropertySourceLocator)
Spencer Gibb
@spencergibb
Aug 11 2015 16:24
so we could ignore 404’s
checketts
@checketts
Aug 11 2015 16:25
That would be ideal
Spencer Gibb
@spencergibb
Aug 11 2015 16:25
@atoregozh and @checketts issues and PR’s welcome :-)
Josh Ghiloni
@jghiloni
Aug 11 2015 16:44
Question for the masses about registering an app with Eureka on startup -- if I have eureka.client.service-url.defaultZone set in my application.properties file, the registration works fine, but there doesn't seem to be a way to do it via a system env variable. Am I right there, or is there some voodoo that I'm missing? The source code seems to indicate that eureka.client.serviceUrl.defaultZone would work as well, which would lead me to believe that an env variable called EUREKA_CLIENT_SERVICEURL_DEFAULTZONE would work as well. I'm using Spring Boot 1.2.4.RELEASE and Spring Cloud Eureka 1.0.3.RELEASE
I should clarify the end of that message: the env variable EUREKA_CLIENT_SERVICEURL_DEFAULTZONE does not work, and it defaults to trying to register at http://localhost:8761/eureka
Dave Syer
@dsyer
Aug 11 2015 16:53
eureka.client.service-url is a Map
So it has no way of knowing you want to bind to defaultZone, not DEFAULTZONE
Josh Ghiloni
@jghiloni
Aug 11 2015 16:53
That's a good point, and makes me feel dumb for having asked :)
Dave Syer
@dsyer
Aug 11 2015 16:53
Does it work if your config contains eureka.client.serviceUrl.defaultZone locally (as a hint)?
Josh Ghiloni
@jghiloni
Aug 11 2015 16:54
I'm trying right now just to see, because I was wondering the same thing
Dave Syer
@dsyer
Aug 11 2015 16:54
EUREKA_CLIENT_SERVICEURL_defaultZone might work
Spencer Gibb
@spencergibb
Aug 11 2015 16:56
EUREKA_CLIENT_SERVICEURL_defaultZone doesn’t work
Dave Syer
@dsyer
Aug 11 2015 16:57
Maybe depends on the OS?
Josh Ghiloni
@jghiloni
Aug 11 2015 16:57
Yeah, my app is starting (in oss cloud foundry on a slowwww iaas)
so, fwiw, eureka.client.serviceUrl.defaultZone works when it's in my config
Dave Syer
@dsyer
Aug 11 2015 16:58
Naturally
I guess you need to put in an indirection
eureka.client.serviceUrl.defaultZone=${EUREKA_URI:http://localhost:8761/eureka/}
or something
Josh Ghiloni
@jghiloni
Aug 11 2015 16:59
oh my god
i can't believe i didn't think of that
i do that all over the place
welp, now i feel like a complete idiot, and it's visible for the whole world! :)
thanks for your help, really appreciate it!
checketts
@checketts
Aug 11 2015 18:11
@spencergibb Issue opened: spring-cloud/spring-cloud-config#210
Josh Ghiloni
@jghiloni
Aug 11 2015 19:51
In eureka-registration land, are listing secure and non-secure ports mutually exclusive? In my bootstrap.yml, i have non-secure-port: 80, non-secure-port-enabled: true, secure-port: 443, and secure-port-enabled: true, and the ServiceInstance that's returned has the URI of https://<service url>:80
Just curious if it's a configuration on my part that's out of scope or a bug
Spencer Gibb
@spencergibb
Aug 11 2015 19:53
Is it similar to spring-cloud/spring-cloud-netflix#337
Josh Ghiloni
@jghiloni
Aug 11 2015 19:55
Not quite ... in my case, EurekaServiceInstance.getPort() is returning 80 because if non-secure-port-enabled is true it returns that, regardless of whether secure-port-enabled is true
but isSecure checks to see whether or not secure-port-enabled is true
i see in the comments that it's assuming if the non-secure port is enabled, that's the default
seems like if that's the design decision isSecure should check it too
would be happy to submit a PR if you agree
Spencer Gibb
@spencergibb
Aug 11 2015 19:58
PR are always welcome
Josh Ghiloni
@jghiloni
Aug 11 2015 19:58
OK, will get it to you tonight
Josh Ghiloni
@jghiloni
Aug 11 2015 21:17
spring-cloud/spring-cloud-netflix#485 submitted