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

Use hostname for Baseboard::Pc::identifier field #4937

Merged
merged 2 commits into from
Feb 1, 2024

Conversation

andrewjstone
Copy link
Contributor

Doing this allows easier testbed setup and usage since we identify new sleds to add via their baseboard. In case we can't get a hostname we revert to using a UUID, as in the prior version of code.

Doing this allows easier testbed setup and usage since we identify
new sleds to add via their baseboard. In case we can't get a hostname
we revert to using a UUID, as in the prior version of code.
@davepacheco
Copy link
Collaborator

I don't know enough to know if this change would create any problems. I think all the stuff I've done explicitly ignores non-Oxide hardware so I don't think that'll care. But it seems like this punts the uniqueness requirement to the deployer, who needs to ensure that hostnames are set properly and unique. I wonder if @jmpesp or @smklein has an opinion here?

@@ -10,6 +10,7 @@ anyhow.workspace = true
camino.workspace = true
cfg-if.workspace = true
futures.workspace = true
gethostname = "0.4.3"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm somewhat shocked that this isn't built in. Would it be better to use to use nix's implementation (since we're already using nix I think)?

Either way, I'd think we'd want to add this to the workspace-level deps.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. I'll use nix's impl!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out we are not using nix. It is a transitive dep though.

@jclulow
Copy link
Collaborator

jclulow commented Jan 31, 2024

I think you probably want to try and use the SMBIOS UUID for this?

 $ smbios -t 1
ID    SIZE TYPE
1     79   SMB_TYPE_SYSTEM (type 1) (system information)

  Manufacturer: TYAN
  Product: B8036T65AV4E24HR
  Version: empty
  Serial Number: TCK2118F0004

  UUID: 00008036-4354-4245-3244-4b3033303031
  Wake-Up Event: 0x6 (power switch)
  SKU Number: empty
  Family: empty

It is often a unique property of the physical or virtual system on which you are running.

@rmustacc
Copy link

@jclulow we can't today due to it missing from Propolis (oxidecomputer/propolis#628). Which means that Falcon and co. don't have it.

@jclulow
Copy link
Collaborator

jclulow commented Jan 31, 2024

Ah! Very well.

@andrewjstone
Copy link
Contributor Author

I don't know enough to know if this change would create any problems. I think all the stuff I've done explicitly ignores non-Oxide hardware so I don't think that'll care. But it seems like this punts the uniqueness requirement to the deployer, who needs to ensure that hostnames are set properly and unique. I wonder if @jmpesp or @smklein has an opinion here?

I tagged @jmpesp because he does the same thing for his petfood cluster in northern america.

Copy link
Contributor

@jmpesp jmpesp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🐶 🥫 approved

@andrewjstone andrewjstone merged commit f4c7a8d into main Feb 1, 2024
22 checks passed
@andrewjstone andrewjstone deleted the pc-baseboard-hostname-serial branch February 1, 2024 15:37
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.

5 participants