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

Separate DataStore and TracingStore #3281

Merged
merged 57 commits into from Oct 17, 2018
Merged

Separate DataStore and TracingStore #3281

merged 57 commits into from Oct 17, 2018

Conversation

fm3
Copy link
Member

@fm3 fm3 commented Sep 25, 2018

URL of deployed dev instance (used for testing):

  • https://___.webknossos.xyz

Notes

  • note that tracing related api routes no longer have the data/ prefix
  • note that you might have to refresh your schema so that initialData is inserted again (with tracingStore info)

TODO:

  • adapt frontend to use tracingstore from annotation info
  • offer route to get volume tracing data in tracing store → tracings/volume/:tracingId/data expecting POST JSON body just like binary data loading
  • adapt frontend to that
  • test as standalone
  • adapt docker files
  • remove fossildb from datastore
  • check which config settings are now unused
  • remove obsolete api/tracingstore
  • when initializing volume, set boundingbox, elementclass and largestSegmentId already on wK side
  • trigger tracingstore health check from frontend?
  • adapt the e2e tests to new volumetracing handling
  • is the dataStore field in annotation info api now unused in the frontend? if so, remove it
  • how do we publish tracingstore to dockerhub?

Steps to test:

  • trace some, both in volume and skeleton
  • set up tracingStore as standalone app (→setup), should still be able to trace both with skeleton + volume
  • download + reupload volume tracing

Issues:


@fm3 fm3 added the frontend label Sep 25, 2018
@fm3 fm3 changed the title [WIP] Tracingstore Module [WIP] Separate DataStore and TracingStore Sep 26, 2018
@fm3
Copy link
Member Author

fm3 commented Oct 5, 2018

@jstriebel @normanrz do you know what needs to be done so that we can publish the tracingstore image to dockerhub?

@fm3 fm3 changed the title [WIP] Separate DataStore and TracingStore Separate DataStore and TracingStore Oct 5, 2018
@fm3 fm3 mentioned this pull request Oct 8, 2018
@fm3 fm3 requested a review from daniel-wer October 9, 2018 08:15
@normanrz
Copy link
Member

normanrz commented Oct 9, 2018

Done https://hub.docker.com/r/scalableminds/webknossos-tracingstore/

Copy link
Member

@daniel-wer daniel-wer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@philippotto I reviewed the frontend part, very good work :)
If I misunderstood something with the datastore/tracingstore url, then nevermind, but I think there are some spots in the tests where the wrong one of the two is used.
Do we know whether having to send two requests instead of one when requesting fallback segmentation data hurts performance much? Did you notice anything?

MIGRATIONS.md Outdated
@@ -6,12 +6,13 @@ User-facing changes are documented in the [changelog](CHANGELOG.md).

## Unreleased
- Some config keys have changed, if you overwrite them in your setup, please adapt: the `oxalis` prefix is renamed to `webKnossos` so the new keys are `webKnossos.user.time.tracingPauseInSeconds`, `webKnossos.tasks.maxOpenPerUser`, `webKnossos.newOrganizationMailingList` as well as `datastore.webKnossos.uri`, `datastore.webKnossos.secured`, `datastore.webKnossos.pingIntervalMinutes` for the datastore.
- There is now a separate module for the tracing store, the datastore is no longer responsible for saving tracings. This module can run as a standalone application, or as a module of webknossos locally. It is recommended that you chose the option that was previously also in place for datastores. In case of a standalone datastore, the local one needs to be disabled in application.conf: `tracingstore.enabled = false` and `play.modules.disabled += "com.scalableminds.braingames.datastore.TracingStoreModule` – and in either case, the adress of the tracingstore (localhost or remote) needs to be inserted in the db in `webknossos.tracingStores`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Either always use tracing store or tracingstore
  • webKnossos instead of webknossos
  • choose instead of chose
  • I would also add a period to the end of the last sentence :)

CHANGELOG.md Outdated
@@ -18,6 +18,7 @@ For upgrade instructions, please check the [migration guide](MIGRATIONS.md).
- The UI for editing experience domains of users was improved. [#3254](https://github.com/scalableminds/webknossos/pull/3254)
- The tracing layout was changed to be more compact. [#3256](https://github.com/scalableminds/webknossos/pull/3256)
- It is no longer possible to draw outside of a viewport with the brush tool in volume tracing. [#3283](https://github.com/scalableminds/webknossos/pull/3283)
- There is now a separate tracingstore module, the datastore is no longer responsible for saving tracings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a period and link this PR

@@ -729,6 +729,7 @@ class DataApi {
const dataset = Store.getState().dataset;

return doWithToken(token => {
// todo: use tracingStore maybe?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this todo still valid? The method description makes it look like the method can be used to download segmentation data as well? Would the request for the segmentation data need to go to the tracing- or the datastore? Or both? ^^ :/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comment. @fm3 and I decided to clarify the api description so that the download only refers to the dataset (and not tracing). I'm not sure whether this api is used anyway. If users voice interest in downloading volume tracings, we can add another option. Merging is hopefully not necessary.

@@ -617,6 +617,7 @@ class DataApi {
const dataset = Store.getState().dataset;

return doWithToken(token => {
// todo: use tracingStore maybe?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment in api_latest.

@@ -150,7 +150,7 @@ async function sendUpdateActions(explorational, queue) {
const skeletonTracingId = explorational.tracing.skeleton;
if (skeletonTracingId == null) throw new Error("No skeleton tracing present.");
return sendRequestWithToken(
`${explorational.dataStore.url}/data/tracings/skeleton/${skeletonTracingId}/update?token=`,
`${explorational.dataStore.url}/tracings/skeleton/${skeletonTracingId}/update?token=`,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be the tracingstore url? But the e2e tests go through successfully - I'm confused ^^

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably because both are the same, right? But the tracingstore url would be semantically correct.

.returns(Promise.resolve({ token: "token2" }));

return requestWithFallback(layer, batch).then(([buffer1, buffer2]) => {
// console.log("buffer1", buffer1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These can probably be removed

@@ -66,7 +66,7 @@ test.beforeEach(t => {
const tracingId = ANNOTATION.tracing[contentType];

Request.receiveJSON
.withArgs(`${ANNOTATION.dataStore.url}/data/tracings/${contentType}/${tracingId}`)
.withArgs(`${ANNOTATION.dataStore.url}/tracings/${contentType}/${tracingId}`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this also be the tracingstore url?

@@ -122,7 +122,7 @@ test("SaveSaga should send request to server", t => {
expectValueDeepEqual(
t,
saga.next(DATASTORE_URL),
call(sendRequestWithToken, `${DATASTORE_URL}/data/tracings/skeleton/1234567890/update?token=`, {
call(sendRequestWithToken, `${DATASTORE_URL}/tracings/skeleton/1234567890/update?token=`, {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename DATASTORE_URL to TRACINGSTORE_URL?

@fm3
Copy link
Member Author

fm3 commented Oct 9, 2018

I updated the changelog + migration guide.
The tests probably run green despite the wrong url, because in the standard case, all three urls (wK, datastore, tracingstore) are localhost:9000.
I could not see any performance problems with the double requests locally, but I guess that does not have to mean too much. But my guess is that it’ll be ok

@fm3 fm3 merged commit d559ee3 into master Oct 17, 2018
@fm3 fm3 deleted the tracingstore branch October 17, 2018 14:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Separate DataStore and TracingStore
5 participants