Skip to content
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

Add persistence layer #249

Open
DaCAPNcrunch opened this issue Apr 22, 2019 · 1 comment
Open

Add persistence layer #249

DaCAPNcrunch opened this issue Apr 22, 2019 · 1 comment

Comments

@DaCAPNcrunch
Copy link

DaCAPNcrunch commented Apr 22, 2019

Dealing with a server restart isn't a big deal for simple deployments of Toxiproxy with a couple proxies and toxics. However, as the environment grows to dozens of proxies things become problematic as a restart will take down every API until they are all setup again. The /populate endpoint takes care of a lot of this since it can be called when starting, but someone needs to maintain that JSON array.

I would like to propose a persistence layer that will save all proxies and toxics and populate them on application start to eliminate all manual work of maintaining the JSON. My thoughts on implementation would be to have an interface and create an implementation for MySQL where others could follow with additional implementations as required. The selection of the implementation would be done on application start and could have a predefined schema for RDBMS implementations.

What are your thoughts on this project? Are you all interested or have any special requirements?

I am willing to be the author for this issue.

Edit: clarity

@jpittis
Copy link
Contributor

jpittis commented Apr 24, 2019

Thanks for opening an issue @DaCAPNcrunch. I may be misunderstanding your problem so feel free to clarify. :)

Dealing with a server restart

I don't fully understand what you're referring to. Generally we populate Toxiproxy once on boot in development (on docker-compose up or whatever) or once on CI container boot.

a restart will take down every API

Generally we don't restart Toxiproxy until we shutdown our development environment or finish running a CI container. At this point there is no API to take down if you get what I mean.

Persistence

I'm generally against the idea of having a MySQL persistence layer but I don't see anything wrong with persisting configuration to a file and passing it as a parameter to Toxiproxy on boot. (I feel like that's been discussed before.)

It's important to remember that different users have different needs when configuring Toxiproxy. Some might really benefit from persistent file load. Other large apps (many at Shopify) dynamically generate Toxiproxy configuration programatically which means persistence is less useful.

If we do add a persistence layer, it might be cool to also add /dump endpoint which would return an auto generated persistence layer based on the current state of the proxy. We could add a feature to the cli tool which would hit this endpoint and populate the file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants