-
Notifications
You must be signed in to change notification settings - Fork 63
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
data-plane-controller: skip DNS await if nothing changed in pulumi up #1964
base: master
Are you sure you want to change the base?
Conversation
84353eb
to
3c3ab46
Compare
3c3ab46
to
3f7c378
Compare
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.
LGTM
We also need the Azure application threaded through into the data_planes
table -- should that be part of this PR?
state.last_pulumi_up = chrono::Utc::now(); | ||
|
||
Ok(DNS_TTL) | ||
if resource_changes.changed() { |
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.
nit: you can make this more concise, by having the if
block return a tuple of (status, poll-result, log-line).
); | ||
} | ||
|
||
let mut out: Vec<stack::PulumiStackHistory> = serde_json::from_slice(&output.stdout).context("failed to parse pulumi stack history output")?; |
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.
nit: rustfmt?
begin; | ||
|
||
-- Address for connecting to the bastion | ||
ALTER TABLE public.data_planes ADD bastion_address TEXT; |
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.
I don't think we need bastion_address
, and I see that it en-gross-ens est-dry-dock
to have it.
reactor_address
and broker_address
are only part of the data_planes
table due to migration concerns -- for local & cronut data-planes, we use different values than those implied by data_plane_fqdn
.
For this use case, I think we can just use data_plane_fqdn
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.
@jgraettinger bastion_address
in this case is a formatted SSH tunnel address: ssh://tunnel@bastion.<...>:2222
in my thinking this is useful for us to be able to expose this later or even automate network tunnel selection when someone is creating a task for a private data-plane, we can suggest auto-filling the network tunnel section with this address and private key
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.
It's still a value that's trivially computed from the existing data_plane_fqdn
column.
I don't think we know enough about how this feature will be used yet, to make larger bets on how to structure metadata for consumption. (For example, what if the data plane spans a couple of regions? What if there are multiple R=1 bastion deployments? Do we present them individually? What if we need to introduce distinct users for some reason?)
Description:
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