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

bug: failures when creating a workspace via deck sync #783

Open
mklaber opened this issue Oct 26, 2022 · 2 comments
Open

bug: failures when creating a workspace via deck sync #783

mklaber opened this issue Oct 26, 2022 · 2 comments

Comments

@mklaber
Copy link

mklaber commented Oct 26, 2022

In a PostgreSQL-backed hybrid deployment of Kong Gateway 2.8.1.4, the deck sync command fails when the target workspace (either via _workspace in the deck file or the --workspace flag) does not yet exist.

When a deck file has a workspace that does not exist, it successfully creates the workspace and then fails any subsequent actions.

$ deck version
decK v1.15.1 (bb70f8f) 
$ deck sync -s kong/small_workspace.yaml
creating workspace small-workspace
Error: building state: add defaults to plugin 'kafka-log': retrieve schema for kafka-log from Kong: HTTP status 404 (message: "Workspace 'small-workspace' not found")

Re-running the exact same command a moment later successfully syncs the state file.

small_workspace.yaml
_workspace: small-workspace
_format_version: '1.1'
plugins:
  - name: kafka-log
    config:
      producer_async: false
      topic: kongRequestLogRaw
      bootstrap_servers:
        - host: kafka-broker.service.company.com
          port: 9092
  - name: prometheus
    config:
      per_consumer: false

It seems a reasonable solution would be for deck sync to consider the --db-update-propagation-delay flag after creating a workspace here. Based on the description of that flag ("artificial delay (in seconds) that is injected between insert operations for related entities"), it seems like an oversight that it's ignored at all (if not the root of this bug).

(NB: simultaneously reported in support ticket #00030766 but posted here for posterity and for the specific fix suggestion)

@GGabriele
Copy link
Collaborator

Hi @mklaber ,

thanks for opening this issue!

I think your analysis is accurate and the fix you're suggesting may be a reasonable solution. The --db-update-propagation-delay was introduced for some specific use cases, so maybe a different and more targeted flag could help.

@ludovic-pourrat
Copy link
Contributor

Hello,

We are getting hits by this bug too any news / progress in this ?

Best Regards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants