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

Progress Bar API Changes. #18953

Merged
merged 2 commits into from
Nov 4, 2022
Merged

Conversation

davinchia
Copy link
Contributor

@davinchia davinchia commented Nov 4, 2022

What

API changes to support the progress bar.

  1. The eventual idea is for the save_stats route to be called by the workers during replication. Workers will save stats for a job id and attempt number.
  2. Make modifications to the /jobs/list and the /jobs/get_debug_info routes to also return estimated bytes/records.

We need both estimated metadata, as well as running states to calculate progress bar and throughput.

How

  • add the save_stats route. This is the route that will be called by workers. I've done my best to reuse existing openapi bodies to reduce duplication.
  • add the estimatedRecords and estimatedBytes fields to the AttemptStats body. This is part of the AttemptRead and the AttemptStreamStats objects. This eventually filters up to the jobs/list and jobs/get_debug_info objects. This also adds these to all the endpoints that were previously returning stats information. I think the duplicated data is a small issue and don't think it's worth splitting out a new api objects, though I will gladly do so if folks feel strongly.
  • minor changes to the AttemptApiController to support the new route.
  • I've stubbed out the handlers for now since the backend is not yet implemented.

Recommended reading order

  1. config.yaml for the main changes.
  2. AttemptApiController.java for the override changes.

🚨 User Impact 🚨

Are there any breaking changes? What is the end result perceived by the user? If yes, please merge this PR with the 🚨🚨 emoji so changelog authors can further highlight this if needed.

Pre-merge Checklist

Expand the relevant checklist and delete the others.

New Connector

Community member or Airbyter

  • Community member? Grant edit access to maintainers (instructions)
  • Secrets in the connector's spec are annotated with airbyte_secret
  • Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
  • Code reviews completed
  • Documentation updated
    • Connector's README.md
    • Connector's bootstrap.md. See description and examples
    • docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
    • docs/integrations/README.md
    • airbyte-integrations/builds.md
  • PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

  • Create a non-forked branch based on this PR and test the below items on it
  • Build is successful
  • If new credentials are required for use in CI, add them to GSM. Instructions.
  • /test connector=connectors/<name> command is passing
  • New Connector version released on Dockerhub by running the /publish command described here
  • After the connector is published, connector added to connector index as described here
  • Seed specs have been re-generated by building the platform and committing the changes to the seed spec files, as described here
Updating a connector

Community member or Airbyter

  • Grant edit access to maintainers (instructions)
  • Secrets in the connector's spec are annotated with airbyte_secret
  • Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
  • Code reviews completed
  • Documentation updated
    • Connector's README.md
    • Connector's bootstrap.md. See description and examples
    • Changelog updated in docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
  • PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

  • Create a non-forked branch based on this PR and test the below items on it
  • Build is successful
  • If new credentials are required for use in CI, add them to GSM. Instructions.
  • /test connector=connectors/<name> command is passing
  • New Connector version released on Dockerhub and connector version bumped by running the /publish command described here
Connector Generator
  • Issue acceptance criteria met
  • PR name follows PR naming conventions
  • If adding a new generator, add it to the list of scaffold modules being tested
  • The generator test modules (all connectors with -scaffold in their name) have been updated with the latest scaffold by running ./gradlew :airbyte-integrations:connector-templates:generator:testScaffoldTemplates then checking in your changes
  • Documentation which references the generator is updated as needed

Tests

Unit

Put your unit tests output here.

Integration

Put your integration tests output here.

Acceptance

Put your acceptance tests output here.

@github-actions github-actions bot added area/api Related to the api area/documentation Improvements or additions to documentation area/platform issues related to the platform area/server labels Nov 4, 2022
@davinchia davinchia temporarily deployed to more-secrets November 4, 2022 05:31 Inactive
import io.airbyte.api.model.generated.SetWorkflowInAttemptRequestBody;
import io.airbyte.server.handlers.AttemptHandler;
import javax.ws.rs.Path;

@Path("/v1/attempt/set_workflow_in_attempt")
@Path("/v1/attempt/")
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've made this a less restrictive path so this will continue to override 2 different routes.

This works since the path, while less restrictive, is still more restrictive than the general V1 path in the ConfigurationApi class.

@davinchia davinchia changed the title API Changes to support Save Stats. Progress Bar API Changes. Nov 4, 2022
@davinchia davinchia marked this pull request as ready for review November 4, 2022 05:49
@davinchia
Copy link
Contributor Author

davinchia commented Nov 4, 2022

PTAL @jdpgrailsdev @benmoriceau @mfsiega-airbyte

  • Let me know how the api routes look.
  • I would appreciate pointers on configuring the AttemptApiController. Benoit/Jonathan, I know there is work here to split out these, so please lmk if there is a better pattern.
  • I am hoping to merge the api routes unimplemented for now. I see this as low risk since everything here is additive, and I plan to implement these in the next few days. I wanted to work on the api routes first since this links up with the FE work. If people disagree, I am happy to leave this open. Just stating my preference.

Please look at https://github.com/airbytehq/airbyte/pull/18630/files#diff-8d2a55215b7d1dbfdb14f80e5fb444c9b940be967bdfb8cfbf1e24703579095e for a taste on how the routes here will be used!

@davinchia davinchia temporarily deployed to more-secrets November 4, 2022 05:58 Inactive
Copy link
Contributor

@mfsiega-airbyte mfsiega-airbyte left a comment

Choose a reason for hiding this comment

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

API update looks reasonable to me! Don't have context on what's going on with the AttemptApiController so left it alone.

@jdpgrailsdev
Copy link
Contributor

PTAL @jdpgrailsdev @benmoriceau @mfsiega-airbyte

  • Let me know how the api routes look.
  • I would appreciate pointers on configuring the AttemptApiController. Benoit/Jonathan, I know there is work here to split out these, so please lmk if there is a better pattern.
  • I am hoping to merge the api routes unimplemented for now. I see this as low risk since everything here is additive, and I plan to implement these in the next few days. I wanted to work on the api routes first since this links up with the FE work. If people disagree, I am happy to leave this open. Just stating my preference.

Please look at https://github.com/airbytehq/airbyte/pull/18630/files#diff-8d2a55215b7d1dbfdb14f80e5fb444c9b940be967bdfb8cfbf1e24703579095e for a taste on how the routes here will be used!

@davinchia This is fine for now. We (mostly @benmoriceau ) are working on the pre-step of creating separate classes for each endpoint domain, but without the changes needed to work with Micronaut/dependency injection. That will come in a later step, so what you have is fine for now.

Copy link
Contributor

@jdpgrailsdev jdpgrailsdev left a comment

Choose a reason for hiding this comment

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

:shipit:

@davinchia davinchia merged commit 7bb3241 into master Nov 4, 2022
@davinchia davinchia deleted the davinchia/setup-progress-bar-api branch November 4, 2022 17:05
@@ -362,6 +363,11 @@ public void revokeSourceDefinitionFromWorkspace(final SourceDefinitionIdWithWork
});
}

@Override
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: could you add a comment about where the implementation lives?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oh yes! will do that real quick in a follow up

davinchia added a commit that referenced this pull request Nov 11, 2022
Follow up to #18953.

Implement all the DB migrations required for a progress bar.

The main change here is to support saving:

the estimated records/bytes at the sync level
the estimated records/bytes and emitted records/bytes at the stream level
After this, I'll put up a PR for the persistence layer changes, which will writing to and reading from these columns.

Finally, I'll wire this into the API changes, which are currently stubs.

- add the estimated_records and estimated_bytes columns to the SyncStats table.
- create a stream_stats table
  - estimated and emitted records/bytes column
  - contains attempt_id and stream_name columns. Unique constraints on these two columns.
  - foreign key to the attempt_id table.
  - this table hopefully sets us up for the parallel sync work.
akashkulk pushed a commit that referenced this pull request Dec 2, 2022
Follow up to #18953.

Implement all the DB migrations required for a progress bar.

The main change here is to support saving:

the estimated records/bytes at the sync level
the estimated records/bytes and emitted records/bytes at the stream level
After this, I'll put up a PR for the persistence layer changes, which will writing to and reading from these columns.

Finally, I'll wire this into the API changes, which are currently stubs.

- add the estimated_records and estimated_bytes columns to the SyncStats table.
- create a stream_stats table
  - estimated and emitted records/bytes column
  - contains attempt_id and stream_name columns. Unique constraints on these two columns.
  - foreign key to the attempt_id table.
  - this table hopefully sets us up for the parallel sync work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Related to the api area/documentation Improvements or additions to documentation area/platform issues related to the platform area/server
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants