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

22nd
Jul 2015
Aizhan Toregozhina
@atoregozh
Jul 22 2015 16:56
Hello, I wanted to provide multiple git branch names in spring-cloud-config client bootstrap.yml (as spring.cloud.config.label=master,test) to pull configurations from, but it doesn't seem to work for me. When I provide comma separated values of git branches, I'm not even getting the config values from the default master. The doc says 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. This can be useful when working on a feature branch, for instance, when you might want to align the config label with your branch, but make it optional (e.g. spring.cloud.config.label=myfeature,develop). Could someone please explain why it doesn't work for me? @dsyer @spencergibb
Dave Syer
@dsyer
Jul 22 2015 17:12
Well, "master" always exists so I would expect you would always get that data
Is that what happens?
Aizhan Toregozhina
@atoregozh
Jul 22 2015 17:34
@dsyer no, as I said, when I wrote master,test in client, it didn't go back to master. It just had some hardcoded value I was passing that was outside of the git repo entirely
Dave Syer
@dsyer
Jul 22 2015 17:35
Maybe a bug then?
You are using 1.0.2 or better?
Aizhan Toregozhina
@atoregozh
Jul 22 2015 17:37
when I try hitting the config server I see this: There was an unexpected error (type=Not Found, status=404). No such label: master,test_0.1
@dsyer I'm using 1.0.2.RELEASE
Dave Syer
@dsyer
Jul 22 2015 17:38
Where does the _0.1 come from?
Aizhan Toregozhina
@atoregozh
Jul 22 2015 17:39
mm it was part of the git branch name I created
Dave Syer
@dsyer
Jul 22 2015 17:39
Period is probably a bad idea
But that wouldn't explain why you didn't see master
Aizhan Toregozhina
@atoregozh
Jul 22 2015 17:40
ok I could delete that branch and try again
Dave Syer
@dsyer
Jul 22 2015 17:41
The server is 1.0.2?
Underscores are bad too
Aizhan Toregozhina
@atoregozh
Jul 22 2015 17:43
mm but how should we name the branches if we want to name them according to release versions, like 0.1.1, 0.1.2, etc?
Dave Syer
@dsyer
Jul 22 2015 17:43
But you knew about the mapping from _ to / right?
Aizhan Toregozhina
@atoregozh
Jul 22 2015 17:43
server is 1.0.2.RELEASE
yeah read that in docs
so i understand now that I need to avoid underscores
so how would you advice naming branches then?
Dave Syer
@dsyer
Jul 22 2015 17:45
If you use a "/" in the branch name it needs to be "_" in the resource path (is all I remember)
Maybe you could configure it as "/" and get it translated to "_" by the client
(That might be a new feature request)
I definitely see the code in the client for the comma-separated labels
Aizhan Toregozhina
@atoregozh
Jul 22 2015 17:48
i renamed my git branch to just test and I'm seeing the same error
Dave Syer
@dsyer
Jul 22 2015 17:54
Can you put a break point in your client and see why?
Aizhan Toregozhina
@atoregozh
Jul 22 2015 18:01
oh sorry I was actually using 1.0.0.RELEASE of config-client
Dave Syer
@dsyer
Jul 22 2015 18:02
That would explain it
checketts
@checketts
Jul 22 2015 18:31
@dsyer The underscore escaping seems like a potential surprise (as @atoregozh just hit) Would a double underscore be better? ie _ = _ and __ = / ?
Dave Syer
@dsyer
Jul 22 2015 18:33
Yeah maybe. I really tried hard to find a character that wasn't used in git branch names
checketts
@checketts
Jul 22 2015 18:34
I hear you. Jenkins struggles with / as well. So I just always use hyphens
Dave Syer
@dsyer
Jul 22 2015 18:34
I wanted to make it a single character. But I guess it could be a sequence.
Even make it configurable
checketts
@checketts
Jul 22 2015 20:54
@dsyer Further feedback on the config client: Labels grabs the first one that matches, but application/profile the last one takes precedence
Dave Syer
@dsyer
Jul 22 2015 20:54
That was intentional
One is "find one" the other is "merge all"
Different strategies
Seemed to fit the use case that prompted it (there's an issue in github somewhere)
checketts
@checketts
Jul 22 2015 20:56

If I have the following:

spring:
  application:
    name: shared,myApp  #most specific must be last
  cloud:
    config:
      profile: dev
      label: master,release1 #most specific must be first

I get the merged values from shared and myApp, but if a new value appears in myApp it wins out. However the opposite occurs with the label

I understand they are different strategies. I just wanted to express how I'd interpreted it and gotten 'surprised'
In my mind 'most specific' should be consistent
Dave Syer
@dsyer
Jul 22 2015 21:04
Why is your spring.application.name comma separated? That's weird.
checketts
@checketts
Jul 22 2015 21:05
2 application names: 'shared' and 'myApp'
Dave Syer
@dsyer
Jul 22 2015 21:05
Not a very obvious service id if you register with eureka (for instance) or send metrics to NewRelic etc
I don't think an app should have 2 names
You can try and get config from 2 places, but don't be schizophrenic
checketts
@checketts
Jul 22 2015 21:06
I'm trying to solve the need of having a hierarchy of settings, and that seemed to meet that need
Dave Syer
@dsyer
Jul 22 2015 21:06
Have an identity
It's just that spring.application.name is used in other ways.
checketts
@checketts
Jul 22 2015 21:07
Where can i learn more about the 'identity'?
Dave Syer
@dsyer
Jul 22 2015 21:07
Nothing to stop you doing it I guess. But surely there's a better way?
I don't think it's documented (probably deserves a paragraph at least)
checketts
@checketts
Jul 22 2015 21:08
I'd love to find a better way. In fact the spike work right is to understand the 'best way' for us to use config server/client
Dave Syer
@dsyer
Jul 22 2015 21:08
It gets used as a default for a bunch of things (including but not limited to the config client name)
checketts
@checketts
Jul 22 2015 21:08
(My service discovery/eureka spike will be next)
Dave Syer
@dsyer
Jul 22 2015 21:08
Sounds like a useful spike
You don't want to throw away the first one when you get to the second
spring.cloud.config.name is what you mean
it just defaults to ${spring.application.name}
Look at where the @ConfigurationProperties are coming from
I know it means reading the source code, but honestly, it's worth it.
Source code is your friend.
We can get a long list of config properties in the docs (it's automatable) but it won't tell you anything more or any faster than just looking at the source and/or the /configprops endpoint
checketts
@checketts
Jul 22 2015 21:15
This message was deleted
So you are recommending this approach?
spring:
  application:
    name: myApp
  cloud:
    config:
      name: shared,myApp  #most specific must be last
      profile: dev
      label: master,release1 #most specific must be first
(Believe me I'm digging in the source code, debugging the config service, etc)
Dave Syer
@dsyer
Jul 22 2015 21:22
Yes that's more like it. Why do you need "shared"? Is it an independent group of apps?
I always found that the default shared group "application" worked
Maybe in bigger systems you could use more which is why the option is there).
checketts
@checketts
Jul 22 2015 21:23
Good point about using the default shared group of 'application'
Dave Syer
@dsyer
Jul 22 2015 21:23
This message was deleted
Well have fun. I have to knock off now.
checketts
@checketts
Jul 22 2015 21:24
Thanks a ton for the help