Refresh configuration without restart, but behind load balanced URL

[maxwell-ryan]

I am currently using Steeltoe in an environment which is behind a load balanced URL, and looking for a means to refresh the configuration without restarting. The load balancer directs traffic to several different Cloud Foundry environments, each of which could have 1 to many instances of the app running via autoscaler.

I've read through previously reported issues and noted this issue which mentions IOptionsSnapshot and the /reload endpoint, as well as IConfigurationRoot.Reload. Based on my current understanding, Steeltoe users with a similar load balanced environment may have an issue with finding a way to reload configs across all environments, for all app instances, as a call to the /reload endpoint would only hit a single environment/instance. Hopefully I am overlooking a solution to this issue.

If not, I noticed that perhaps the ideal solution is in the backlog. I am not intimately familiar with the Steeltoe source code yet, but is this a feasible addition, or is this a serious undertaking? I would love to help contribute to implementing this, but thought I would first check if others have looked into it already and noticed significant blockers.

[TimHess]

Hey, thanks for your interest - however, this probably wouldn't be a first great project as we're expecting there to be a dependency on Spring-Cloud-Bus compatible functionality. As I understand it, the way Spring Cloud Config Server communicates that config has changed is via a queue rather than HTTP, so we're missing a building block or two before being able to do server-initiated config reload.

[hanserya]

@TimHess

It seems like the only thing we'd need to do is to provide tooling that pub/subs to the appropriate topic in RabbitMQ as well as a client-side actuator. Is the perceived difficulty rooted in the current client-side configuration options supported in the Java offering?

@maxwell-ryan

I am going to be working on some PR's to address some other things related to parity between dotnet and java. Hoping to find some time this evening and this weekend. If you're open to looking into this as well, then I can collaborate with you should you run into any road blocks - but it should be relatively straight forward.

[jkonicki]

@hanserya Our plan was to build a messaging abstraction (similar to Spring Cloud Stream) and a messaging Bus that will support RabbitMQ and Kafka. This will be the first building blocks for the refresh messaging. We plan on beginning the message abstraction for our 2.2 release currently in progress.
We are also interested in hearing what you had in mind, if you would like to contribute or collaborate with the team. Thanks.

[mzakrzewski]

@jkonicki Would your messaging abstraction support the pub/sub capabilities within Redis? That's what we used to provide this functionality so it'd be great if we could just switch to a framework supported component.

[jkonicki]

@mzakrzewski First step is us getting the Messaging abstraction framework in place. This is no small task and is being worked on now for our 3.0 release. At first we are going to be supporting RabbitMQ and Kafka. We can discuss adding Redis as a third option. Thanks for your request.

[macsux]

What you want is bus-refresh feature which exists in Spring. While you're waiting for necessary building blocks to be added to spring, you can find the code necessary to do what you want here, as it implements subset of needed features to make this work. https://github.com/macsux/spa-buildpack

[antonpopov]

@TimHess do you plan on implementing this feature anytime soon? My team is using Steeltoe's refresh actuator which works good but soon we are starting a project where microservice instances will self register to a Netflix Eureka discovery server. Would you suggest an approach for refreshing the configuration of multiple instances of a microservice. Thanks!

[TimHess]

@antonpopov I'm so sorry, I thought I responded to this message last week - this is still on the roadmap, but Bus builds on Streams, which builds on Messaging...

We're pretty confident that Messaging is ready for consumption, and a good chunk of the Streams work is there now, but Bus hasn't been started. So we've made progress, but we're not there yet