New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider multiple spring-cloud-config-uris for high availability #87

Closed
cnagel opened this Issue Feb 17, 2015 · 15 comments

Comments

Projects
5 participants
@cnagel

cnagel commented Feb 17, 2015

Hi Spring Cloud Team,

Last week I had a short but nice chat with Oliver Gierke on the microXchg in Berlin about Spring Cloud.
Looking on the architecture, all components can work in a parallel fashion to offer high availability.
With a remote configuration source like git, it is even possible to run multiple synchronized config servers.
But having a look on the documentation, it is only possible to pass one spring-cloud-config-uri. In my eyes this is a bottle neck, as the only one defined server could crash and a application can't load any properties even if a second config server is running.
Managing the replication with Eureka is mentioned in the documentation, but not an option in every project.

What about the possibility to define multiple _spring-cloud-config-uri_s separated by comma?

Thanks for the nice project,
Christoph.

@dsyer

This comment has been minimized.

Show comment
Hide comment
@dsyer

dsyer Feb 18, 2015

Contributor

Sounds like a reasonable suggestion, so pull requests welcome. But not particularly urgent IMO because you will commonly use the config server in an environment where there is a front end load balancer anyway, so a single URL is already highly available.

Contributor

dsyer commented Feb 18, 2015

Sounds like a reasonable suggestion, so pull requests welcome. But not particularly urgent IMO because you will commonly use the config server in an environment where there is a front end load balancer anyway, so a single URL is already highly available.

@indraneelb1903

This comment has been minimized.

Show comment
Hide comment
@indraneelb1903

indraneelb1903 Apr 9, 2018

Contributor

Sorry for re-opening a old thread. Was this enhancement ever added?
If it wasnt, would it be reasonable to add this enhancement where we can give a list of urls.

Contributor

indraneelb1903 commented Apr 9, 2018

Sorry for re-opening a old thread. Was this enhancement ever added?
If it wasnt, would it be reasonable to add this enhancement where we can give a list of urls.

@indraneelb1903

This comment has been minimized.

Show comment
Hide comment
@indraneelb1903

indraneelb1903 Apr 9, 2018

Contributor

Maybe iterate over the list of comma-separated urls and then depending upon which is UP( this can be subjective), decide the url to fetch properties from.
Also I was thinking maybe have the flexibility to specify configServer(url) specific username-password credentials.

Contributor

indraneelb1903 commented Apr 9, 2018

Maybe iterate over the list of comma-separated urls and then depending upon which is UP( this can be subjective), decide the url to fetch properties from.
Also I was thinking maybe have the flexibility to specify configServer(url) specific username-password credentials.

@indraneelb1903

This comment has been minimized.

Show comment
Hide comment
@indraneelb1903

indraneelb1903 Apr 9, 2018

Contributor

So for example if explicit credentials have been provided -
spring.cloud.config.username and spring.cloud.config.password. Then it does not matter which url we try to fetch our properties from and if any embedded credentials are present in the url, the one mentioned explicily will take precedence. But, if there are not mentioned explicitly, and are only present in the url. Then we can have per configServer username-password credentials.

For example-

spring:
         cloud:
                  config:
                            uri: http://user:pass@localhost:8888, http://user1:pass1@localhost:8889
                            username: abcd
                            password: abcd1

Here abcd will be applied as username and abcd1 will be applied as password, regardless of which url is chosen to fetch properties from.

spring:
         cloud:
                  config:
                            uri: http://user:pass@localhost:8888, http://user1:pass1@localhost:8889

If explicit credentials are not present, then apply what is embedded in the url.

Contributor

indraneelb1903 commented Apr 9, 2018

So for example if explicit credentials have been provided -
spring.cloud.config.username and spring.cloud.config.password. Then it does not matter which url we try to fetch our properties from and if any embedded credentials are present in the url, the one mentioned explicily will take precedence. But, if there are not mentioned explicitly, and are only present in the url. Then we can have per configServer username-password credentials.

For example-

spring:
         cloud:
                  config:
                            uri: http://user:pass@localhost:8888, http://user1:pass1@localhost:8889
                            username: abcd
                            password: abcd1

Here abcd will be applied as username and abcd1 will be applied as password, regardless of which url is chosen to fetch properties from.

spring:
         cloud:
                  config:
                            uri: http://user:pass@localhost:8888, http://user1:pass1@localhost:8889

If explicit credentials are not present, then apply what is embedded in the url.

@ryanjbaxter

This comment has been minimized.

Show comment
Hide comment
@ryanjbaxter

ryanjbaxter Apr 9, 2018

Contributor

Please learn how to format code on GitHub.

It has not been added

Contributor

ryanjbaxter commented Apr 9, 2018

Please learn how to format code on GitHub.

It has not been added

@indraneelb1903

This comment has been minimized.

Show comment
Hide comment
@indraneelb1903

indraneelb1903 Apr 10, 2018

Contributor

My apologies.
I have updated my comment. Should I create a new issue, highlighting this potential enhancement?

Contributor

indraneelb1903 commented Apr 10, 2018

My apologies.
I have updated my comment. Should I create a new issue, highlighting this potential enhancement?

@spencergibb

This comment has been minimized.

Show comment
Hide comment
@spencergibb

spencergibb Apr 10, 2018

Member

This issue is still open, no need to open another.

Member

spencergibb commented Apr 10, 2018

This issue is still open, no need to open another.

@indraneelb1903

This comment has been minimized.

Show comment
Hide comment
@indraneelb1903

indraneelb1903 Apr 16, 2018

Contributor

Does the above seem like a reasonable suggestion?

Contributor

indraneelb1903 commented Apr 16, 2018

Does the above seem like a reasonable suggestion?

@ryanjbaxter

This comment has been minimized.

Show comment
Hide comment
@ryanjbaxter

ryanjbaxter Apr 16, 2018

Contributor

Seems fine to me

Contributor

ryanjbaxter commented Apr 16, 2018

Seems fine to me

@indraneelb1903

This comment has been minimized.

Show comment
Hide comment
@indraneelb1903

indraneelb1903 May 17, 2018

Contributor

If Config Server urls are located using Service Discovery like eureka and multiple urls are found, should it consider each one of them?
I see right now, we are considering only the first one.
Will submit a pull request soon.

Contributor

indraneelb1903 commented May 17, 2018

If Config Server urls are located using Service Discovery like eureka and multiple urls are found, should it consider each one of them?
I see right now, we are considering only the first one.
Will submit a pull request soon.

@ryanjbaxter

This comment has been minimized.

Show comment
Hide comment
@ryanjbaxter

ryanjbaxter May 17, 2018

Contributor

Yes, each one

Contributor

ryanjbaxter commented May 17, 2018

Yes, each one

@indraneelb1903

This comment has been minimized.

Show comment
Hide comment
@indraneelb1903

indraneelb1903 May 24, 2018

Contributor

Any additions required in the documentation, referencing this enhancement?

Contributor

indraneelb1903 commented May 24, 2018

Any additions required in the documentation, referencing this enhancement?

@ryanjbaxter

This comment has been minimized.

Show comment
Hide comment
@ryanjbaxter

ryanjbaxter May 24, 2018

Contributor

yes we will need documentation, good point

Contributor

ryanjbaxter commented May 24, 2018

yes we will need documentation, good point

@indraneelb1903

This comment has been minimized.

Show comment
Hide comment
@indraneelb1903

indraneelb1903 May 24, 2018

Contributor

Are u guys planning to add docs or should I have a stab at it in the same pull request?
If u guys are close to a release, and want to squeeze this enhancement in it, go ahead, if not, i can try adding it myself, only issue being , i have not added documentation before to any open source project, so could take some time going back and forth.

Contributor

indraneelb1903 commented May 24, 2018

Are u guys planning to add docs or should I have a stab at it in the same pull request?
If u guys are close to a release, and want to squeeze this enhancement in it, go ahead, if not, i can try adding it myself, only issue being , i have not added documentation before to any open source project, so could take some time going back and forth.

@ryanjbaxter

This comment has been minimized.

Show comment
Hide comment

@ryanjbaxter ryanjbaxter added this to the 2.0.0.RC3 milestone May 29, 2018

@spencergibb spencergibb added this to To do in Finchley.RELEASE via automation May 31, 2018

@spencergibb spencergibb moved this from To do to Done in Finchley.RELEASE May 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment