data-plane-controller: separate private_links column, restart on change #2063
Conversation
|
|
||
| begin; | ||
|
|
||
| ALTER TABLE public.data_planes ADD config_private_links json[] not null default array[]::json[]; |
There was a problem hiding this comment.
Can we just call this private_links ?
We'll need to populate this column for all existing data-planes. This migration could do it by from current config (or, we could do it by hand, including immediately before a release that cuts over to treating it as authoritative?).
Another possibility is that we introduce this column using GENERATED ALWAYS AS, so it tracks config, and then do an ALTER TABLE which turns it into a regular column.
Eventually I think we'll want to open this up for direct customer interaction, and we should prevent obviously-bad misconfigurations. One way to do that is perhaps a pg_jsonschema constraint.
| state.status = Status::Idle; | ||
| state.pending_converge = true; | ||
|
|
||
| return Ok(Outcome { |
There was a problem hiding this comment.
I think it's incorrect to transition back to Idle on a config change (as in, could possibly break client interactions with a data-plane). For example, if we're polled while in state AwaitDNS2, then it could short-circuit the DNS await.
This is hand-wavy, but I think we want a mechanism where we more-unconditionally update the internal task state's private links based on the current state of the DB row, without actually changing the polling state of the data plane.
Description:
(Describe the high level scope of new or changed features)
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