tahoe-lafs/trac

readiness status API for clients #2844

New issue

Open

opened 2016-11-14 19:36:29 +00:00 by david415 · 4 comments

david415 commented

2016-11-14 19:36:29 +00:00

We need an API that can be used to determine when a Tahoe client is connected to enough storage servers to do something useful and retrieve a file from the storage grid.

Similarly there should be a way to determine the readiness of storage nodes and introducers.

There are potentially many uses for such an API, for instance the integration tests should use it as should any Tahoe GUI we build.

We need an API that can be used to determine when a Tahoe client is connected to enough storage servers to do something useful and retrieve a file from the storage grid. Similarly there should be a way to determine the readiness of storage nodes and introducers. There are potentially many uses for such an API, for instance the integration tests should use it as should any Tahoe GUI we build.

david415 added the

labels 2016-11-14 19:36:29 +00:00

david415 added this to the undecided milestone 2016-11-14 19:36:29 +00:00

david415 commented

2016-11-15 19:08:56 +00:00

Author

i don't know much about writing http APIs but i was thinking to write a polling http api that outputs JSON and it looks like i could copy a lot of code from the magic folder status http api; anyway i wrote this is_ready method for Clients to determine if at least k storage servers are connected:
https://github.com/david415/tahoe-lafs/commits/2844.add_readiness_api.0

maybe this readiness doesn't make sense for storage servers? or would they be ready after they have announced themselves to at least one introducer or all introducers?

also, what would it mean for an introducer to be ready? they are always ready so perhaps this isn't meaningful for introducers.

i don't know much about writing http APIs but i was thinking to write a polling http api that outputs JSON and it looks like i could copy a lot of code from the magic folder status http api; anyway i wrote this is_ready method for Clients to determine if at least k storage servers are connected: <https://github.com/david415/tahoe-lafs/commits/2844.add_readiness_api.0> maybe this readiness doesn't make sense for storage servers? or would they be ready after they have announced themselves to at least one introducer or all introducers? also, what would it mean for an introducer to be ready? they are always ready so perhaps this isn't meaningful for introducers.

meejah commented

2016-11-20 15:39:33 +00:00

The following is purely for the integration tests use-case (but I think also applies to e.g. Docker images etc).

The "is ready" is mostly about "are all the ports open and listening now" (for all non-client servers). That is, when we spawnProcess, that returns fairly rapidly -- such that if we spawn an Introducer and (without waiting) spawn a storage server, it will fail to connect to the Introducer. There are lots of different ways of tackling this (e.g. the integration tests could keep polling the ports they care about on the Introducer). Another way is what I'm doing currently: waiting for the "introducer running" (or similar) to appear in the stdout logs.

Maybe there's really no better way than trolling stdout (in "some" defense this is one way systemd works -- waiting for READY=1 to be printed by the launched process). I'm also kind of hoping there's "A Good Way" that people do this already...

In any case, it would be good to standardize on something (the "introducer running" is a bit fragile-feeling, and the string changes depending on what kind of tahoe you launched).

A JSON API would let us return more-interesting statuses -- and then e.g. for an integration-test use-case, the tests would have to rapidly poll the API (and keep re-trying on connection errors etc).

The following is purely for the integration tests use-case (but I think also applies to e.g. Docker images etc). The "is ready" is mostly about "are all the ports open and listening now" (for all non-client servers). That is, when we `spawnProcess`, that returns fairly rapidly -- such that if we spawn an Introducer and (without waiting) spawn a storage server, it will fail to connect to the Introducer. There are lots of different ways of tackling this (e.g. the integration tests could keep polling the ports they care about on the Introducer). Another way is what I'm doing currently: waiting for the "introducer running" (or similar) to appear in the stdout logs. Maybe there's really no better way than trolling stdout (in "some" defense this is one way systemd works -- waiting for `READY=1` to be printed by the launched process). I'm also kind of hoping there's "A Good Way" that people do this already... In any case, it would be good to standardize on something (the "introducer running" is a bit fragile-feeling, and the string changes depending on what kind of tahoe you launched). A JSON API would let us return more-interesting statuses -- and then e.g. for an integration-test use-case, the tests would have to rapidly poll the API (and keep re-trying on connection errors etc).

meejah commented

2016-11-29 19:49:06 +00:00

We just discussed this in Ops meeting Nov 29, and concluded:

we just need a "twisted" API for e.g. "spawn_client"
this takes the requested configuration and returns a Deferred
the Deferred either errbacks, or succeeds when the client is "ready"
to determine "readiness" we add an HTTP API
under the hood, the "spawn_client()" talks via the above HTTP API (polling until it connects)
the API has a /v0/ready or similar path, which only returns (ends the request) when the client is ready (i.e. a "put" will "probably" work -- the client has connected to enough storage-servers)

We just discussed this in Ops meeting Nov 29, and concluded: - we just need a "twisted" API for e.g. "spawn_client" - this takes the requested configuration and returns a Deferred - the Deferred either errbacks, or succeeds when the client is "ready" - to determine "readiness" we add an HTTP API - under the hood, the "spawn_client()" talks via the above HTTP API (polling until it connects) - the API has a /v0/ready or similar path, which only returns (ends the request) when the client is ready (i.e. a "put" will "probably" work -- the client has connected to enough storage-servers)

david415 commented

2016-11-30 00:59:40 +00:00

Author

ok i made the http api work and unit tested as well:
https://github.com/david415/tahoe-lafs/tree/2844.add_readiness_api.1

i have not yet written the client side http API...
i'll do that soon. next.

ok i made the http api work and unit tested as well: <https://github.com/david415/tahoe-lafs/tree/2844.add_readiness_api.1> i have not yet written the client side http API... i'll do that soon. next.

Sign in to join this conversation.

No labels

c/code-dirnodes

c/code-encoding

c/code-frontend

c/code-frontend-cli

c/code-frontend-ftp-sftp

c/code-frontend-magic-folder

c/code-frontend-web

c/code-nodeadmin

c/code-peerselection

c/dev-infrastructure

kw:AttributeError

kw:DataUnavailable

kw:DeadReferenceError

kw:GetLastError

kw:IFinishableConsumer

kw:LeastAuthority

kw:RIStorageServer

kw:UncoordinatedWriteError

kw:access-control

kw:accessibility

kw:accounting-crawler

kw:anti-censorship

kw:api_auth_token

kw:authentication

kw:availability

kw:backward-compatibility

kw:blocks-cloud-deployment

kw:blocks-cloud-merge

kw:blocks-magic-folder-merge

kw:blocks-merge

kw:blocks-release

kw:brians-opinion-needed

kw:build-helpers

kw:cloud-backend

kw:coding-standards

kw:coding-tools

kw:coding_tools

kw:compatibility

kw:confidentiality

kw:configuration

kw:configuration.txt

kw:connectivity

kw:control.furl

kw:coordination

kw:coveralls.io

kw:create-container

kw:cryptography

kw:cryptography-lib

kw:denial-of-service

kw:desert-island

kw:desert-island-build

kw:design-review-needed

kw:dev-infrastructure

kw:directory-page

kw:disk-backend

kw:earth-dragon

kw:erasure-coding

kw:excess-authority

kw:extensibility

kw:file-descriptor

kw:floatingpoint

kw:forward-compatibility

kw:forward-secrecy

kw:garbage-collection

kw:google-cloud-storage

kw:google-drive-backend

kw:grid-manager

kw:illustration

kw:inlineCallbacks

kw:integration-test

kw:interoperability

kw:interstellar-exploration

kw:introduction

kw:key-value-store

kw:magic-folder

kw:manual-test-needed

kw:more-info-needed

kw:mountain-lion

kw:multiuser-gateway

kw:needs-review

kw:notification

kw:notifyOnDisconnect

kw:openitp-packaging

kw:operation-helpers

kw:optimization

kw:organization

kw:otf-magic-folder-objective1

kw:otf-magic-folder-objective2

kw:otf-magic-folder-objective3

kw:otf-magic-folder-objective4

kw:otf-magic-folder-objective5

kw:otf-magic-folder-objective6

kw:peer-selection

kw:pkg_resources

kw:preservation

kw:pycrypto-lib

kw:pyfilesystem

kw:random-access

kw:raspberry-pi

kw:release-blocker

kw:removable-disk

kw:reserved_space

kw:response-needed

kw:response-time

kw:review-needed

kw:self-contained

kw:servers-of-happiness

kw:setup_requires

kw:setuptools_darcs

kw:simultaneous

kw:space-efficiency

kw:static-analysis

kw:stats_gatherer

kw:tahoe-add-alias

kw:tahoe-archive

kw:tahoe-backup

kw:tahoe-create-alias

kw:tahoe-create-introducer

kw:tahoe-deep-check

kw:tahoe-deepcheck

kw:tahoe-lafs-trac-stream

kw:tahoe-list-aliases

kw:tahoe-magic-folder

kw:tahoe-manifest

kw:tahoe-restart

kw:tahoe-unlink

kw:tahoe-webopen

kw:test-and-set

kw:test-from-egg

kw:ticket999-s3-backend

kw:to-be-closed-on-2011-08-01

kw:tor-protocol

kw:transparency

kw:tub.location

kw:twisted-trial

kw:uncoordinated-writes

kw:unfinished-business

kw:unhandled-error

kw:upload-helper

kw:visualization

kw:volunteergrid2

kw:warners-opinion-needed

kw:welcome-page

kw:windows-related

kw:world-domination

kw:write-enabler

kw:zookos-opinion-needed

kw:zope.interface

p/supercritical

r/cannot reproduce

r/somebody else's problem

r/was already fixed

v/1.9.0-s3branch

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac#2844

No description provided.