opentimestamps-server
opentimestamps-server copied to clipboard
opentimestamps
add a new /state endpoint
The goal here is to be sure stamper is ready to process requests before opening service to clients.
As we use a pool of opentimestamps servers, we would like to be sure that a newly started server is really ready before adding it to the pool and forwarding him clients. Receiving a successful answer from this endpoint prior to adding it to the pool makes it safe.
Check has failed on my second commit because of an error on python 3.3 download and I am not able to retry the build without pushing a dummy modification. If you can, please, retry it. Thanks
Could you just try to do a dummy timestamp operation instead and see if it succeeds? Feels to me that it'd be better to actually test the functionality, rather than rely on a state endpoint that could itself fail.
Timestamps are free, so there's no downside to doing one.
In our usage of things a server generally offers a way to selfcheck. We have a consul cluster on front that will automatically route clients to a newly started opentimestamps server as soon as it is up. Querying port 14788 states that http server is up, but not that timestamping is possible.
Implementation of your suggestion would require a sidekick service issuing timestampings and providing an other webserver to expose opentimestamps state that consul could check. This is way more trouble than just having opentimestamps stating whether or not it has ended its initialization.
Hmm, so you're routing to multiple opentimestamps servers? Are you setting different hostnames on the returned timestamps?
Also, the stamper process doesn't need to be up to successfully create timestamps: the process that adds to the journal is separate from the process that reads the journal and timestamps them. Even if the latter isn't up, it'll catch up when it does finish starting up.
Sorry for not having followed up on this :/
So...
We use service names provided by consul, not machines hostnames. So yes, servers have different names. Goal here is to ensure stamping to be always up and proof queries downtimes as low as possible.
Regarding stamper being up, my problem is not to be able to stamp, it is to verify. As said above we have a pool of servers. Let say there are two and they are accessible through ots0 and ots1. If ots0 server goes down, timestamping is still possible through ots1. Problem is verifying ots0 proofs. As long as the server is down, ots0 does not exist on the network. We can tell clients to retry later. Server comes up quickly, so it is no big deal.
Problem is the period between 14788 port starting HTTP/200 replies and queries to ots0 proofs becoming accessible. The first is the only way I have to check whether service is up and tell consul it can route clients to ots0. But clients requesting proofs stop getting "come back later" answers and start having "this proof does not exist" (or such) answers. Which is obviously not good.
I need an other way to check everything is up, and not only stamping. What I have coded may not be optimal, but from what I observed, It solves my problem : when my new endpoint is http/200 we can stamp and query and so announce our server as back.
Doesn't seem like we made enough progress on this to do anything. You're welcome to open a new pull-req though later!
Though in general, I think "performance-based" tests for availability are better. Eg rather than trusting some endpoint, actually try submitting a digest and see if the server returns something reasonable. If so, consider the server up for the purpose of your load balancing.