-
Notifications
You must be signed in to change notification settings - Fork 53
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
config: only allow confidential instances on stackit #3463
Conversation
✅ Deploy Preview for constellation-docs canceled.
|
internal/config/validation.go
Outdated
// only allow confidential instances on stackit cloud using QEMU vTPM | ||
if cloud := provider.OpenStack.Cloud; strings.ToLower(cloud) == "stackit" { |
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.
We need an if provider.OpenStack != nil
here, as there's more scenarios where we'll have case variant.QEMUVTPM{}, variant.QEMUTDX{}
, such as MiniConstellation, and else we'd run into a nil panic there here when dereferencing provider.OpenStack
.
We might also want "success" test case for these variants without the OpenStack / STACKIT case here.
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've added a provider check and two test cases. Although I'm not entirely sure which provider Miniconstellation is using, I made an educated guess: ProviderConfig{QEMU: &QEMUConfig{}}
with the variant variant.QEMUTDX{}
.
The failing CI is somewhat expected on your branch, as the required tokens aren't available there. I'll verify that these succeed on my machine once we're ready to merge, so don't worry about fixing that for now. :) |
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.
Thanks a lot!
All tests succeed, merging. |
* cli: only allow confidential instances on stackit * review changes
Context
When creating a confidential Kubernetes cluster on Stackit, customers have occasionally confused confidential flavor IDs with non-confidential ones which resulted in a "stuck" creation period.
Proposed Change(s)
I have implemented an instance type check for the Stackit cloud provider to prevent this confusion.
Related Issue
#3438
Additional Info
I have rebuilt the Constellation CLI and confirmed that the change works correctly on a Linux x86 machine.
Using
bazel build //cli:cli_oss
Checklist