What is the point of Consul storing the routes information?

[Gooseman]

I've been playing around with Consul. I haven't yet been able to get it to work with load balancing, but it works fine if I'm just routing to a single instance of a service. It works great if I change the location of that service from the host and/or port configured in the ocelot.json.

What I don't understand is why Consul bothers to store the Ocelot route configuration. I can make changes there - adding a new route, for instance - that are then reflected in the running instance of the gateway service. However, if I restart the gateway service the route information is overwritten, so any changes made in Consul are lost. That new route I added is gone. Is the only reason Consul stores the route information so that temporary dynamic changes can be made, or is there some other reason?

[ggnaegi]

@Gooseman What's important here is that you don't need to restart ocelot to load the information from the consul KV store. You could, for example, implement your own logic using the consul API, inject routes, modify parameters programmatically or save your configuration at regular intervals.

https://github.com/ggnaegi/SwizlyPeasy.Gateway/blob/master/SwizlyPeasy.Consul/KeyValueStore/KeyValueService.cs
https://developer.hashicorp.com/consul/api-docs/kv

[raman-m]

Good point regarding Ocelot restart!
Moreover, even multiple restarts should not affect solution integrity.
I'm pretty sure, all well-developed solutions should be stable even after multiple restarts (in Docker environments for example).
Also, long living Ocelot instance should be integral and stable. So, service discovery by Consul should work perfectly for long lasting Ocelot instances.
Regarding custom store of Ocelot config... Well... I'm not expert, but we can check the code, and I guess it is in-memory store, right?
Is Consul KV tool in-memory solution?

[raman-m]

I believe the author wants to have persistent KV storage with perfect integrity, right?

[raman-m]

@Gooseman Welcome to Ocelot world! 😉

[Gooseman]

Yes, that is what I was expecting - that the updating of a value in the KV store via the Consul interface would not be destroyed by an instance of Ocelot that uses the corresponding key restarting. If multiple instances use the key and one restarts after a change has been made in Consul, it overwrites the value for wall insurances using that key, losing any changes that were made.

…

On Thu, 16 Nov 2023 at 18:09, Raman Maksimchuk ***@***.***> wrote: I believe Craigus wants to have persistent KV storage with perfect integrity, right? — Reply to this email directly, view it on GitHub <#1772 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6QMOFI3YEKJN7FE24UZADYEZJFZAVCNFSM6AAAAAA6ZYGUDGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKOJRGIZTQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ggnaegi]

Ok @Gooseman, so you would like to have:

• A custom key name for your instances?
• When shutting the IHostedService down that the ocelot.json file is updated and saved?
• Or maybe that the KV-Value store is not updated when starting an instance?

Unfortunately, your use cases are not implemented, so you could fork the repo, have a look at these two classes: https://github.com/ThreeMammals/Ocelot/blob/develop/src/Ocelot.Provider.Consul/ConsulFileConfigurationRepository.cs ,
https://github.com/ThreeMammals/Ocelot/blob/develop/src/Ocelot/Configuration/Repository/FileConfigurationPoller.cs
implement the logic for your needs and create a PR. We are in the process of reviewing the providers but it's unfortunately not top of the list right now.

[raman-m]

Yeap! @Gooseman Please fork the Ocelot repository! Your repos are empty now!
As a .NET developer, you could research Ocelot's code base. It is definitely a good dev challenge. 😉