initial support for local connectors #1195
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Local connectors are parsed correctly and that's about it. This commit does not add any support for actually running local connectors (that's coming). Also handle derivation images within the `agent`, which had been omitted.
We'd like them to be available in local contexts, like `flowctl` and also local stacks, while being disabled in production deployments.
Add DebugJson newtype for wrapping serde::Serialize types with a debug formatter that outputs styled, colorized JSON if stderr is a terminal.
Support for local connectors largely mirrors image connectors. We unseal and unnest its endpoint configuration, then start the configured program and drive it using its configured protocol. Also relax unsealing (sops decryption) to pass through non-object documents, which can happen if the config wasn't resolved (for example, because it's being generated).
Also expand the perview of `flowctl generate` to also generate endpoint config and resource config stubs for captures and materializations where the indicate files are missing. This is a replacement for the two-step "discover" workflow we've previously had, where the first stage would write a config and the second would actually do discover. That doesn't work with local connectors (because we need a proper capture spec in order to know what connector to discover from).
williamhbaker
approved these changes
Sep 25, 2023
| @@ -27,6 +27,7 @@ import ( | |||
| type FlowConsumerConfig struct { | |||
| runconsumer.BaseConfig | |||
| Flow struct { | |||
| AllowLocal bool `long:"allow-local" description:"Allow local connectors. True for local stacks, and false otherwise."` | |||
There was a problem hiding this comment.
Are we setting this to true for local stacks somewhere? I would think we could add the configuration to the Tiltfile
There was a problem hiding this comment.
Right, I haven't yet. I was mainly focused on making sure that they'd be disallowed everywhere unless specifically opted in, and I opted in within flowctl but not Tiltfile.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds initial support for local connectors for captures, derivations, and materializations. Local connectors are a lot like images, but instead are a command line that can be run on the local machine, optionally with an environment. They're intended for development use-cases only -- including full Tilt local stacks -- but are disabled in production settings.
flowctlis re-worked accordingly:generatecommand is expanded to also generate configuration stubs for endpoint and resource configs of captures & materializations.raw discoverandraw capturecommands are updated to use theruntimecrate to drive connectors, which handles details of image vs local vs other connector flavors.sopsunsealing is also supported for local connectors. I'm thinking we should use this, paired with a CI KMS key, to facilitate easier connector development with configured SaaS API credentials and representative account fixtures, subject to a developer or CI workflow having permission to the applicable CI KMS.This PR pairs with estuary/connectors#970 and is required to run connectors of the latter.
Workflow steps:
(How does one use this feature, and how has it changed)
Documentation links affected:
(list any documentation links that you created, or existing ones that you've identified as needing updates, along with a brief description)
Notes for reviewers:
(anything that might help someone review this PR)
This change is