vm spec will use the preference requirements in vm creation test

[RoniKishner]

What this PR does / why we need it:

• Renamed test [test_id:10737] can be created when enough resources are provided to [test_id:TODO] verifies all preferences have at least one compatible instance type
• Added test to create an instance type from the preference requirements and create a VM from the created instance type.

This will help verify the VM can be created using the preference requirements provided, especially important for cases when spread cpu topology is used.
The old test naming wasn't expressing it's intention.

Release note:

NONE

[0xFelix]

This will help verify the VM can boot using the preference requirements provided, especially important for cases when spread cpu topology is used

This test only creates a VM, it does NOT wait for it to be booted. I.e. this is only testing if VMs using these preferences can be created. There is no boot volume attached to the created VMs.

[0xFelix]

I see what you want to achieve now.

Can you rename the existing test case to something like "verify common-instancetypes ships at least one instancetype providing enough resources for a given preference"? So in the end we have both test cases?

[RoniKishner]

Can you rename the existing test case to something like "verify common-instancetypes ships at least one instancetype providing enough resources for a given preference"? So in the end we have both test cases?

I don't understand the name change you suggested, we don't verify any shipping of instancetypes in the test, if we want to verify the deployment of instancetypes, I think it should be done in a different test.
right now the name is:
VirtualMachine using a preference with resource requirements can be created when enough resources are provided
I think it reflects the test.

Did you mean you want to create an extra test to verify we deployed the u1 instance types?

[0xFelix]

I want you to create an extra test with the proposed name or a similar one that keeps the behavior of the test case you are changing. In the end we should have two test cases, one that verifies the requirements provided by a preference are correct and a second one that verifies we ship at least one instancetype in common-instancetypes that provides sufficient resources to create a VM with a given preference.

[0xFelix]

/retest

[0xFelix]

/test ?

[kubevirt-bot]

@0xFelix: The following commands are available to trigger required jobs:

• /test pull-build-common-instancetypes-builder
• /test pull-common-instancetypes
• /test pull-common-instancetypes-kubevirt-functest
• /test pull-common-instancetypes-kubevirt-functest-centos-7
• /test pull-common-instancetypes-kubevirt-functest-centos-stream-8
• /test pull-common-instancetypes-kubevirt-functest-centos-stream-9
• /test pull-common-instancetypes-kubevirt-functest-fedora
• /test pull-common-instancetypes-kubevirt-functest-opensuse-leap
• /test pull-common-instancetypes-kubevirt-functest-opensuse-tumbleweed
• /test pull-common-instancetypes-kubevirt-functest-ubuntu
• /test pull-common-instancetypes-kubevirt-functest-validation-os

The following commands are available to trigger optional jobs:

• /test pull-common-instancetypes-kubevirt-functest-centos-stream-arm64
• /test pull-common-instancetypes-kubevirt-functest-fedora-arm64
• /test pull-common-instancetypes-kubevirt-functest-opensuse-leap-arm64
• /test pull-common-instancetypes-kubevirt-functest-ubuntu-arm64

Use /test all to run the following jobs that were automatically triggered:

• pull-common-instancetypes
• pull-common-instancetypes-kubevirt-functest
• pull-common-instancetypes-kubevirt-functest-centos-7
• pull-common-instancetypes-kubevirt-functest-centos-stream-8
• pull-common-instancetypes-kubevirt-functest-centos-stream-9
• pull-common-instancetypes-kubevirt-functest-centos-stream-arm64
• pull-common-instancetypes-kubevirt-functest-fedora
• pull-common-instancetypes-kubevirt-functest-fedora-arm64
• pull-common-instancetypes-kubevirt-functest-opensuse-leap
• pull-common-instancetypes-kubevirt-functest-opensuse-leap-arm64
• pull-common-instancetypes-kubevirt-functest-opensuse-tumbleweed
• pull-common-instancetypes-kubevirt-functest-ubuntu
• pull-common-instancetypes-kubevirt-functest-ubuntu-arm64
• pull-common-instancetypes-kubevirt-functest-validation-os

In response to this:

/test ?

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-sigs/prow repository.

[0xFelix]

/test all

[0xFelix]

/retest-required

[0xFelix]

Use DryRunAll in CreateOptions

[lyarwood]

That might be better as a follow up given the current tests don't use that.

[0xFelix]

@RoniKishner Can you create an issue/PR for it?

[0xFelix]

/lgtm

[lyarwood]

/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lyarwood

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:

• OWNERS [lyarwood]

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