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

virtctl: Add create vm command #8878

Merged
merged 2 commits into from
Jan 19, 2023
Merged

Conversation

0xFelix
Copy link
Member

@0xFelix 0xFelix commented Nov 29, 2022

What this PR does / why we need it:

This adds the 'create' / 'create vm' command to virtctl, which allows to
create simple VM manifests via the CLI. Certain fields of the VM
definition can be set with according flags.

Fixes #7760

Release note:

Add 'create vm' command to virtctl

@kubevirt-bot
Copy link
Contributor

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@kubevirt-bot kubevirt-bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. 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. size/L labels Nov 29, 2022
@0xFelix 0xFelix changed the title [WIP] virtctl: Add create vm command virtctl: Add create vm command Nov 30, 2022
@0xFelix 0xFelix marked this pull request as ready for review November 30, 2022 13:32
@kubevirt-bot kubevirt-bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 30, 2022
@0xFelix
Copy link
Member Author

0xFelix commented Nov 30, 2022

/cc @lyarwood

@0xFelix 0xFelix force-pushed the virtctl-create-vm branch 2 times, most recently from e8c90ad to 0927681 Compare November 30, 2022 13:52
Copy link
Member

@davidvossel davidvossel left a comment

Choose a reason for hiding this comment

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

I think cloud-init needs to be taken into account here as well since it's often used as the entry point for injecting the credentials necessary to access a VM.

Comment on lines 90 to 92
cmd.Flags().StringVar(&c.pvc, PvcFlag, c.pvc, "Specify the PVC of the VirtualMachine.")
cmd.Flags().StringVar(&c.dataVolume, DatavolumeFlag, c.dataVolume, "Specify the DataVolume of the VirtualMachine.")
cmd.MarkFlagsMutuallyExclusive(PvcFlag, DatavolumeFlag)
Copy link
Member

Choose a reason for hiding this comment

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

Users typically don't specify the PVC or DataVolume they want, instead they specify the source image they want to use for the VM which then gets imported into a pvc using the DataVolume flow.

Rather than a --pvc or --datavolume flag, i think a --image-src flag would make more sense. If the image source starts with an http://|https:// then it's a http import, if it starts with a docker:// then its a container disk import... We could come up with other options as well like perhaps a pvc:// prefix for pvc cloning

Copy link
Member Author

Choose a reason for hiding this comment

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

I added a --image-source flag but it works a bit differently than you described. I think we should discuss this a bit further.

Copy link
Member

Choose a reason for hiding this comment

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

Just as a counter point to David's initial suggestion, we already have a command to orchestrate the upload of an image into the cluster, IMHO this command just needs to handle the creation of the VirtualMachine itself assuming the image is already present as a DataSource and/or PVC.

pkg/virtctl/create/vm.go Outdated Show resolved Hide resolved
pkg/virtctl/create/vm.go Outdated Show resolved Hide resolved
@fabiand
Copy link
Member

fabiand commented Nov 30, 2022

Awesome to see this work!

@0xFelix in order to understand the user impact better, do you mind adding user documentation first to show how you envision the workflow?
I mainly want to stress how we provide the dvs or rather PVCs.

My problem is that the use of datavolumetemplate and pvcs lead to totally different code paths. maybe this is not an issue... seeing the user documentation would at least show how tihs would look for a user.

Can we also try to keep in mind that we might want to add great support for volume populators down the road. IOW let's try to think about how populator parameter would look if we'd add them to kubevirt., i.e. virtctl create vm mine --volume anewvol --populated-with rhel9 m1.large or along the lines

@lyarwood
Copy link
Member

lyarwood commented Dec 1, 2022

I mainly want to stress how we provide the dvs or rather PVCs.

My problem is that the use of datavolumetemplate and pvcs lead to totally different code paths. maybe this is not an issue... seeing the
user documentation would at least show how tihs would look for a user.

I really think we should focus on the simple existing storage resource cases first in this PR and maybe follow up with something more complex targeting the dynamic DataVolumeTemplates flow later.

Can we also try to keep in mind that we might want to add great support for volume populators down the road. IOW let's try to think
about how populator parameter would look if we'd add them to kubevirt., i.e. virtctl create vm mine --volume anewvol --populated-with rhel9 m1.large or along the lines

+1 to keeping this as abstract as possible going forward, otherwise we could easily end up in the same situation as OpenStack having to expose every API tunable for storage, for example --block-device-mapping:

https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#cmdoption-openstack-server-create-block-device-mapping

--block-device-mapping <dev-name=mapping>
Deprecated Create a block device on the server. Block device mapping in the format <dev-name>=<id>:<type>:<size(GB)>:<delete-on-terminate> <dev-name>: block device name, like: vdb, xvdc (required) <id>: Name or ID of the volume, volume snapshot or image (required) <type>: volume, snapshot or image; default: volume (optional) <size(GB)>: volume size if create from image or snapshot (optional) <delete-on-terminate>: true or false; default: false (optional) Replaced by –block-device

@0xFelix 0xFelix changed the title virtctl: Add create vm command [WIP] virtctl: Add create vm command Dec 2, 2022
@kubevirt-bot kubevirt-bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Dec 2, 2022
@0xFelix
Copy link
Member Author

0xFelix commented Dec 2, 2022

I pushed a new revision of this PR which adds the --image-source and --direct-image-source flag. WDYT? It's a WIP and there are still tests and docs missing.

@0xFelix
Copy link
Member Author

0xFelix commented Dec 2, 2022

Possible uses of --image-src in this revision:

Clone the source before using it:

--image-src=pvc/my-pvc
--image-src=pvc/my-pvc.my-ns

--image-src=dv/my-dv
--image-src=dv/my-dv.my-ns

--image-src=ds/my-ds
--image-src=ds/my-ds.my-ns

Use the source directly:

--direct-image-src=pvc/my-pvc
--direct-image-src=dv/my-dv

Copy link
Member

@lyarwood lyarwood left a comment

Choose a reason for hiding this comment

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

Thanks Felix, I'm not a fan of the new switches, I'd rather we expose more specific switches for each Volume chain we currently support.

pkg/virtctl/create/vm.go Outdated Show resolved Hide resolved
pkg/virtctl/create/vm.go Outdated Show resolved Hide resolved
pkg/virtctl/create/vm.go Outdated Show resolved Hide resolved
vm.Spec.DataVolumeTemplates[0].Spec.SourceRef.Namespace = &namespace
}

vm.Spec.Template.Spec.Volumes = []v1.Volume{
Copy link
Member

Choose a reason for hiding this comment

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

I assumed we'd be chaining these switches togther to allow multiple volumes to be defined?

Copy link
Member Author

Choose a reason for hiding this comment

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

How to determine the boot order? The order in which the switches were defined?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, the ordering is then retained if we generate a list of disks in the VMI mutation webhook.

Copy link
Member Author

@0xFelix 0xFelix Dec 5, 2022

Choose a reason for hiding this comment

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

There are four switches, their order is:

--volume-dvt-ds
--volume-dvt-pvc
--volume-dv
--volume-pvc  

Each switch can be specified multiple times, the order in which it was specified will be kept.

Example 1:

virtctl create vm --volume-dvt-ds my-ds1,my-ds2 --volume-dv my-dv1 --volume-dv my-dv2
-->
vm.Spec.Template.Spec.Volumes = my-ds1,my-ds2,my-dv1,my-dv2

Example 2:

virtctl create vm --volume-dv my-dv1 --volume-dv my-dv2 --volume-dvt-pvc my-ns/my-pvc
-->
vm.Spec.Template.Spec.Volumes = my-ns/my-pvc,my-dv1,my-dv2

Copy link
Member

@davidvossel davidvossel left a comment

Choose a reason for hiding this comment

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

/approve

excellent work!

@kubevirt-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: davidvossel

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 18, 2023
@0xFelix
Copy link
Member Author

0xFelix commented Jan 18, 2023

@dhiller Could you override the failing pull-kubevirt-fossa?

@kubevirt-commenter-bot
Copy link

/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

3 similar comments
@kubevirt-commenter-bot
Copy link

/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

@kubevirt-commenter-bot
Copy link

/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

@kubevirt-commenter-bot
Copy link

/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

@dhiller
Copy link
Contributor

dhiller commented Jan 19, 2023

/override pull-kubevirt-fossa

@kubevirt-bot
Copy link
Contributor

@dhiller: Overrode contexts on behalf of dhiller: pull-kubevirt-fossa

In response to this:

/override pull-kubevirt-fossa

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.

@0xFelix
Copy link
Member Author

0xFelix commented Jan 19, 2023

/hold Need to check something about containerdisk image names.

@kubevirt-bot kubevirt-bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 19, 2023
@kubevirt-bot kubevirt-bot removed the lgtm Indicates that a PR is ready to be merged. label Jan 19, 2023
@0xFelix
Copy link
Member Author

0xFelix commented Jan 19, 2023

/hold cancel

Removed the docker:// prefix from containerdisks.

@kubevirt-bot kubevirt-bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 19, 2023
@opokornyy
Copy link
Contributor

/lgtm

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Jan 19, 2023
This adds the 'create' / 'create vm' command to virtctl which, allows to
create simple VM manifests via the CLI. Certain fields of the VM
definition can be set with according flags.

Signed-off-by: Felix Matouschek <fmatouschek@redhat.com>
@kubevirt-bot kubevirt-bot removed the lgtm Indicates that a PR is ready to be merged. label Jan 19, 2023
@opokornyy
Copy link
Contributor

/lgtm

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Jan 19, 2023
@codingben
Copy link
Member

/lgtm

@0xFelix
Copy link
Member Author

0xFelix commented Jan 19, 2023

/retest

@kubevirt-bot
Copy link
Contributor

kubevirt-bot commented Jan 19, 2023

@0xFelix: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
pull-kubevirt-fossa 7e268b6 link false /test pull-kubevirt-fossa

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. I understand the commands that are listed here.

@kubevirt-bot kubevirt-bot merged commit 92bc324 into kubevirt:main Jan 19, 2023
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/XXL
Projects
None yet
Development

Successfully merging this pull request may close these issues.

virtctl create vm based on flavor proposal
10 participants