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

fix: set boot source labels for DVs created by windows pipelines #845

Merged
merged 1 commit into from Jan 25, 2024

Conversation

ksimon1
Copy link
Member

@ksimon1 ksimon1 commented Jan 18, 2024

What this PR does / why we need it:
fix: set boot source labels for DVs created by windows pipelines

Set default instanceType and preferences labels to result DVs created by windows pipelines. With this fix, preferences will have default windows boot source when user triggers pipeline.

Which issue(s) this PR fixes:
Fixes https://issues.redhat.com/browse/CNV-34661

Release note:

fix: set boot source labels for DVs created by windows pipelines

@kubevirt-bot kubevirt-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. labels Jan 18, 2024
@ksimon1 ksimon1 requested a review from 0xFelix January 18, 2024 11:27
@@ -44,6 +44,10 @@ spec:
description: Namespace of the base DataVolume which is created.
type: string
default: kubevirt-os-images
- default: windows.10
description: The result DV will be set as default boot source for given preference.
Copy link
Member

Choose a reason for hiding this comment

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

Basically it works the other way round. You set a given instancetype/preference to be the default of the DV. There can be multiple DVs using the same default instancetype/preference. Also I think both should be configurable.

@@ -44,6 +44,11 @@ spec:
description: Name of Windows ISO datavolume
name: isoDVName
type: string
- default: windows.11.virtio
description: Name of the preference which will be used for this DV by default.
name: defaultPreferenceLabel
Copy link
Contributor

Choose a reason for hiding this comment

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

Why cannot preferenceName be reused instead of introducing defaultPreferenceLabel?

Copy link
Member Author

Choose a reason for hiding this comment

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

preferenceName parameter is used for information about VM which is created to install the iso. The defaultPreferenceLabel is used for result DV. These two parameters might be different. E.g. for installation you want to use windows-11-some-fency-feature-enabled, but the result you want to use with different preference (e.g. windows-11-regular-user-disk)

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that the two parameters are technically different, but it might be simple and intuitive to the user, if the DV would reflect the instancetype and preference which were used to create the DV. Avoiding the additional parameter would also keep the "surface" to the user smaller. Since this pipeline targets users who starts learning about kubevirt-tekton-tasks, I would vote to keep it as simple as possible, even at the price of flexibility.

@ksimon1
Copy link
Member Author

ksimon1 commented Jan 22, 2024

/retest

@ksimon1 ksimon1 force-pushed the windows-default-boot-source branch 2 times, most recently from 52e368a to 98e82a7 Compare January 23, 2024 11:11
@@ -55,6 +71,11 @@ spec:
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
labels:
Copy link
Member

Choose a reason for hiding this comment

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

What do you think about conditionally adding the kind, only if the param was set? The default will always be clusterwide.

description: Name of the instance type which will be used for this DV by default.
name: defaultInstancetypeLabel
type: string
- default: virtualmachineclusterinstancetype
Copy link
Member

Choose a reason for hiding this comment

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

You could make this an optional param without a default value.

@ksimon1 ksimon1 force-pushed the windows-default-boot-source branch 2 times, most recently from 940a80e to e9b32ca Compare January 24, 2024 09:46
Set default instanceType and preferences labels to result DVs created
by windows pipelines. With this fix, DVs will have default preferences
when user triggers pipeline. Default values will be taken from already
existing parameters instanceTypeName, instanceTypeKind, preferenceName,
virtualMachinePreferenceKind

Signed-off-by: Karel Simon <ksimon@redhat.com>
Copy link

sonarcloud bot commented Jan 24, 2024

Quality Gate Passed Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

@ksimon1
Copy link
Member Author

ksimon1 commented Jan 25, 2024

/retest

Copy link
Member

@0xFelix 0xFelix left a comment

Choose a reason for hiding this comment

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

/approve

Thanks

@kubevirt-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 0xFelix

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubevirt-bot kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 25, 2024
@akrejcir
Copy link
Collaborator

/lgtm

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Jan 25, 2024
@kubevirt-bot kubevirt-bot merged commit 14f49ea into kubevirt:main Jan 25, 2024
15 checks passed
@ksimon1
Copy link
Member Author

ksimon1 commented Jan 25, 2024

/cherry-pick release-v0.18
/cherry-pick release-v0.19

@kubevirt-bot
Copy link
Contributor

@ksimon1: new pull request created: #859

In response to this:

/cherry-pick release-v0.18
/cherry-pick release-v0.19

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@ksimon1
Copy link
Member Author

ksimon1 commented Jan 25, 2024

/cherry-pick release-v0.19

@kubevirt-bot
Copy link
Contributor

@ksimon1: new pull request created: #860

In response to this:

/cherry-pick release-v0.19

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/S
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants