-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Conversation
Skipping CI for Draft Pull Request. |
97a5840
to
5f4dd29
Compare
/cc @lyarwood |
e8c90ad
to
0927681
Compare
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 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.
pkg/virtctl/create/vm.go
Outdated
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) |
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.
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
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 added a --image-source
flag but it works a bit differently than you described. I think we should discuss this a bit further.
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.
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
.
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? 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. |
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
+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
|
0927681
to
d87f31b
Compare
I pushed a new revision of this PR which adds the |
Possible uses of Clone the source before using it:
Use the source directly:
|
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 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
vm.Spec.DataVolumeTemplates[0].Spec.SourceRef.Namespace = &namespace | ||
} | ||
|
||
vm.Spec.Template.Spec.Volumes = []v1.Volume{ |
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 assumed we'd be chaining these switches togther to allow multiple volumes to be defined?
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.
How to determine the boot order? The order in which the switches were defined?
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.
Yes, the ordering is then retained if we generate a list of disks in the VMI mutation webhook.
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.
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
d87f31b
to
28b998b
Compare
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.
/approve
excellent work!
[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 |
@dhiller Could you override the failing |
/retest-required |
3 similar comments
/retest-required |
/retest-required |
/retest-required |
/override pull-kubevirt-fossa |
@dhiller: Overrode contexts on behalf of dhiller: pull-kubevirt-fossa In response to this:
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. |
/hold Need to check something about containerdisk image names. |
98d6eaa
to
5624360
Compare
/hold cancel Removed the |
/lgtm |
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>
5624360
to
7e268b6
Compare
/lgtm |
/lgtm |
/retest |
@0xFelix: The following test failed, say
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. |
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: