-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Define APIs for scoped connector definitions #11244
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
Changes from 6 commits
f7433f2
ff61ece
84b35ed
1acbc47
9431fcb
4c97d37
3df0873
0bcc6e0
d6cbc19
f72e21c
00a9186
c902119
8192aff
3e11a1a
3a3b4cd
d362ff8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -296,6 +296,11 @@ paths: | |
- source_definition | ||
summary: List all the sourceDefinitions the current Airbyte deployment is configured to use | ||
operationId: listSourceDefinitions | ||
requestBody: | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/WorkspaceIdRequestBody" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I do wonder if it would make sense to support a If we don't have a use-case for the workspace-agnostic version of the route, maybe we don't worry about it. @cgardens what do you think? Are there situations where we think we'd want to list all of the default, public definitions for the current Airbyte instance without requiring a workspace ID? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. good call. i think it's valuable to have that functionality for us as administrators of cloud. so yeah i think i would keep both, but change the permission so it was only usable by instance admins. also worth noting that this might make our lives easier for the sake of migration. right now if we merge this PR, the app will break because the UI isn't ready for it. ideally we could merge this PR without having to coordinate with the UI team. i.e.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like the idea of having this PR only make non-breaking changes. And similarly to the list apis, I think we could also add new endpoints for creating custom definitions for a specific workspace and leave the existing create endpoints for admins only to create private non-custom definitions (i.e. the definitions that are grantable to workspaces). Also a slight tangent, but my initial thought for defining these new endpoints with more restful routes would be something like
but it looks like we don't actually use restful routes in this app, which is fine but I'm just curious about how we decided on the naming convention we use for routes? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The description at the top explains WHAT the convention is a bit. In terms of the WHY... it was inspired by how slack does it. If I were to start again, I would just go with REST because the fact that this approach is unfamiliar to most engineers is enough to make it not really worth it. It does iron over some parts of REST that are annoying and I liked the idea of modeling things in a more RPC style. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Gotcha, I do actually kinda like the current approach and I can see how it's convenient to always have all args come from the post body too. Just takes me a bit more effort to come up with sensible names for the routes 😄 |
||
responses: | ||
"200": | ||
description: Successful operation | ||
|
@@ -317,6 +322,66 @@ paths: | |
application/json: | ||
schema: | ||
$ref: "#/components/schemas/SourceDefinitionReadList" | ||
/v1/source_definitions/list_opt_in: | ||
post: | ||
tags: | ||
- source_definition | ||
summary: List all opt-in sourceDefinitions along with the current workspace's opt-in statuses | ||
git-phu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
operationId: listSourceDefinitionOptIns | ||
git-phu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
requestBody: | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/WorkspaceIdRequestBody" | ||
responses: | ||
"200": | ||
description: Successful operation | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/SourceDefinitionOptInReadList" | ||
git-phu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/v1/source_definitions/grant_definition: | ||
post: | ||
tags: | ||
- source_definition | ||
summary: Opt in to a non-public, non-custom sourceDefinition | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm unsure on whether or not we actually want to specify 'non-custom' for this route. I could see a scenario where, for instance, an admin logs into somebody's workspace and adds a custom connector definition, verifies that it works, and then wants to add the same custom connector to another workspace. In that case, we might want it to be possible for the instance admin to hit this API endpoint to grant access to the 2nd workspace, instead of forcing them to add it as a duplicate custom connector, or needing to add it to the catalog as a What do you think? @cgardens also curious about your opinion on this. I think there's potentially some risk in allowing instance admins to create grants for custom connectors that aren't in our catalog, but maybe it's worth it if there's enough utility? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah i think either could work. I believe @cgardens had mentioned a scenario to me before that we'd want to avoid, which is: we don't want a custom connector that is specifically built for one workspace (possibly even with workspace specific secrets baked into the connector definition) to accidentally appear in other workspaces. Maybe if we included some indicator of which private connectors were custom or not, that could help alleviate this concern. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. interesting point. i think since we don't have a notion of an "owner" for a connector definition, what peter said about not allowing this for custom connectors makes sense. otherwise if someone got ahold of the definition id for a custom connector that wasn't theirs they could add it to their own workspace. so either for custom connectors we need to introduce some concept of owners (it makes my head hurt to think about how we would actually model it) or we don't allow granting access to custom connectors in the api. i think i'm inclined to stick with the ladder for now and we can build more features into the schema in the future if we need it. lmk if i'm overestimating the definition ownership piece. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Cool, that makes sense to me! I think we're good to leave this as-is then |
||
operationId: createSourceDefinitionOptIn | ||
git-phu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
requestBody: | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/SourceDefinitionOptInUpdate" | ||
required: true | ||
responses: | ||
"200": | ||
description: Successful operation | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/SourceDefinitionOptInRead" | ||
git-phu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
"404": | ||
$ref: "#/components/responses/NotFoundResponse" | ||
"422": | ||
$ref: "#/components/responses/InvalidInputResponse" | ||
/v1/source_definitions/revoke_definition: | ||
post: | ||
tags: | ||
- source_definition | ||
summary: Opt out of a non-public, non-custom sourceDefinition | ||
operationId: deleteSourceDefinitionOptIn | ||
git-phu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
requestBody: | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/SourceDefinitionOptInUpdate" | ||
required: true | ||
responses: | ||
"204": | ||
description: The resource was deleted successfully. | ||
"404": | ||
$ref: "#/components/responses/NotFoundResponse" | ||
"422": | ||
$ref: "#/components/responses/InvalidInputResponse" | ||
/v1/source_definitions/get: | ||
post: | ||
tags: | ||
|
@@ -654,6 +719,11 @@ paths: | |
- destination_definition | ||
summary: List all the destinationDefinitions the current Airbyte deployment is configured to use | ||
operationId: listDestinationDefinitions | ||
requestBody: | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/WorkspaceIdRequestBody" | ||
responses: | ||
"200": | ||
description: Successful operation | ||
|
@@ -675,6 +745,66 @@ paths: | |
application/json: | ||
schema: | ||
$ref: "#/components/schemas/DestinationDefinitionReadList" | ||
/v1/destination_definitions/list_opt_in: | ||
git-phu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
post: | ||
tags: | ||
- destination_definition | ||
summary: List all opt-in destinationDefinitions along with the current workspace's opt-in statuses | ||
operationId: listDestinationDefinitionOptIns | ||
requestBody: | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/WorkspaceIdRequestBody" | ||
responses: | ||
"200": | ||
description: Successful operation | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/DestinationDefinitionOptInReadList" | ||
/v1/destination_definitions/grant_definition: | ||
post: | ||
tags: | ||
- destination_definition | ||
summary: Opt in to a non-public, non-custom destinationDefinition | ||
operationId: createDestinationDefinitionOptIn | ||
requestBody: | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/DestinationDefinitionOptInUpdate" | ||
required: true | ||
responses: | ||
"200": | ||
description: Successful operation | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/DestinationDefinitionOptInRead" | ||
"404": | ||
$ref: "#/components/responses/NotFoundResponse" | ||
"422": | ||
$ref: "#/components/responses/InvalidInputResponse" | ||
/v1/destination_definitions/revoke_definition: | ||
post: | ||
tags: | ||
- destination_definition | ||
summary: Opt out of a non-public, non-custom destinationDefinition | ||
operationId: deleteDestinationDefinitionOptIn | ||
requestBody: | ||
content: | ||
application/json: | ||
schema: | ||
$ref: "#/components/schemas/DestinationDefinitionOptInUpdate" | ||
required: true | ||
responses: | ||
"204": | ||
description: The resource was deleted successfully. | ||
"404": | ||
$ref: "#/components/responses/NotFoundResponse" | ||
"422": | ||
$ref: "#/components/responses/InvalidInputResponse" | ||
/v1/destination_definitions/get: | ||
post: | ||
tags: | ||
|
@@ -2108,11 +2238,14 @@ components: | |
SourceDefinitionCreate: | ||
type: object | ||
required: | ||
- workspaceId | ||
- name | ||
- dockerRepository | ||
- dockerImageTag | ||
- documentationUrl | ||
properties: | ||
workspaceId: | ||
$ref: "#/components/schemas/WorkspaceId" | ||
name: | ||
type: string | ||
dockerRepository: | ||
|
@@ -2177,6 +2310,35 @@ components: | |
type: array | ||
items: | ||
$ref: "#/components/schemas/SourceDefinitionRead" | ||
SourceDefinitionOptInRead: | ||
type: object | ||
required: | ||
- sourceDefinition | ||
- optIn | ||
properties: | ||
sourceDefinition: | ||
$ref: "#/components/schemas/SourceDefinitionRead" | ||
optIn: | ||
type: boolean | ||
SourceDefinitionOptInReadList: | ||
type: object | ||
required: | ||
- sourceDefinitionOptIns | ||
properties: | ||
sourceDefinitionOptIns: | ||
type: array | ||
items: | ||
$ref: "#/components/schemas/SourceDefinitionOptInRead" | ||
SourceDefinitionOptInUpdate: | ||
type: object | ||
required: | ||
- sourceDefinitionId | ||
- workspaceId | ||
properties: | ||
sourceDefinitionId: | ||
$ref: "#/components/schemas/SourceDefinitionId" | ||
workspaceId: | ||
$ref: "#/components/schemas/WorkspaceId" | ||
# SOURCE SPECIFICATION | ||
SourceDefinitionSpecification: | ||
description: The specification for what values are required to configure the sourceDefinition. | ||
|
@@ -2392,11 +2554,14 @@ components: | |
DestinationDefinitionCreate: | ||
type: object | ||
required: | ||
- workspaceId | ||
- name | ||
- dockerRepository | ||
- dockerImageTag | ||
- documentationUrl | ||
properties: | ||
workspaceId: | ||
$ref: "#/components/schemas/WorkspaceId" | ||
name: | ||
type: string | ||
dockerRepository: | ||
|
@@ -2461,6 +2626,35 @@ components: | |
type: array | ||
items: | ||
$ref: "#/components/schemas/DestinationDefinitionRead" | ||
DestinationDefinitionOptInRead: | ||
type: object | ||
required: | ||
- destinationDefinition | ||
- optIn | ||
properties: | ||
destinationDefinition: | ||
$ref: "#/components/schemas/DestinationDefinitionRead" | ||
optIn: | ||
type: boolean | ||
DestinationDefinitionOptInReadList: | ||
type: object | ||
required: | ||
- destinationDefinitionOptIns | ||
properties: | ||
destinationDefinitionOptIns: | ||
type: array | ||
items: | ||
$ref: "#/components/schemas/DestinationDefinitionOptInRead" | ||
DestinationDefinitionOptInUpdate: | ||
type: object | ||
required: | ||
- destinationDefinitionId | ||
- workspaceId | ||
properties: | ||
destinationDefinitionId: | ||
$ref: "#/components/schemas/DestinationDefinitionId" | ||
workspaceId: | ||
$ref: "#/components/schemas/WorkspaceId" | ||
# DESTINATION DEFINITION SPECIFICATION | ||
DestinationDefinitionSpecification: | ||
description: The specification for what values are required to configure the destinationDefinition. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment should probably be tweaked slightly, maybe 'List all the sourceDefinitions the indicated workspace is configured to use'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we decided not to modify the params of the existing endpoints, when implementing the new endpoint behaviors I will also update the summaries of the existing actor definition endpoints to reflect their new behavior.