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

data-plane-controller: skip DNS await if nothing changed in pulumi up #1964

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

mdibaiee
Copy link
Member

@mdibaiee mdibaiee commented Feb 24, 2025

Description:

  • Skip DNS await if nothing changed. Tested this by running data-plane-controller locally
  • add bastion info columns

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 Reviewable

@mdibaiee mdibaiee force-pushed the mahdi/skip-dns-await branch 2 times, most recently from 84353eb to 3c3ab46 Compare February 24, 2025 18:39
Copy link
Member

@jgraettinger jgraettinger left a 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() {
Copy link
Member

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")?;
Copy link
Member

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;
Copy link
Member

@jgraettinger jgraettinger Feb 25, 2025

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

Copy link
Member Author

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

Copy link
Member

@jgraettinger jgraettinger Feb 25, 2025

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?)

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

Successfully merging this pull request may close these issues.

2 participants