From a5e506da694b52c9c4277db969ec5b1a6318dad7 Mon Sep 17 00:00:00 2001 From: github-actions Date: Wed, 20 Nov 2024 01:09:38 +0000 Subject: [PATCH] openshift-virtualization-pipelines-tasks: Auto-update tekton tasks resources\n\nURL: https://github.com/openshift-virtualization/openshift-virtualization-pipelines-tasks\nIgnoredVersions: --- .../windows-efi-installer/4.16.4/README.md | 240 ++++++++++++++++++ tasks/cleanup-vm/4.16.4/README.md | 134 ++++++++++ tasks/cleanup-vm/4.16.4/cleanup-vm.yaml | 96 +++++++ tasks/copy-template/4.16.4/README.md | 93 +++++++ tasks/copy-template/4.16.4/copy-template.yaml | 84 ++++++ .../create-vm-from-manifest/4.16.4/README.md | 140 ++++++++++ .../4.16.4/create-vm-from-manifest.yaml | 84 ++++++ .../create-vm-from-template/4.16.4/README.md | 132 ++++++++++ .../4.16.4/create-vm-from-template.yaml | 90 +++++++ tasks/disk-uploader/4.16.4/README.md | 60 +++++ tasks/disk-uploader/4.16.4/disk-uploader.yaml | 83 ++++++ tasks/disk-virt-customize/4.16.4/README.md | 63 +++++ .../4.16.4/disk-virt-customize.yaml | 138 ++++++++++ tasks/disk-virt-sysprep/4.16.4/README.md | 63 +++++ .../4.16.4/disk-virt-sysprep.yaml | 138 ++++++++++ tasks/modify-data-object/4.16.4/README.md | 123 +++++++++ .../4.16.4/modify-data-object.yaml | 100 ++++++++ tasks/modify-vm-template/4.16.4/README.md | 110 ++++++++ .../4.16.4/modify-vm-template.yaml | 155 +++++++++++ .../modify-windows-iso-file/4.16.4/README.md | 41 +++ .../4.16.4/modify-windows-iso-file.yaml | 141 ++++++++++ tasks/wait-for-vmi-status/4.16.4/README.md | 83 ++++++ .../4.16.4/wait-for-vmi-status.yaml | 56 ++++ 23 files changed, 2447 insertions(+) create mode 100644 pipelines/windows-efi-installer/4.16.4/README.md create mode 100644 tasks/cleanup-vm/4.16.4/README.md create mode 100644 tasks/cleanup-vm/4.16.4/cleanup-vm.yaml create mode 100644 tasks/copy-template/4.16.4/README.md create mode 100644 tasks/copy-template/4.16.4/copy-template.yaml create mode 100644 tasks/create-vm-from-manifest/4.16.4/README.md create mode 100644 tasks/create-vm-from-manifest/4.16.4/create-vm-from-manifest.yaml create mode 100644 tasks/create-vm-from-template/4.16.4/README.md create mode 100644 tasks/create-vm-from-template/4.16.4/create-vm-from-template.yaml create mode 100644 tasks/disk-uploader/4.16.4/README.md create mode 100644 tasks/disk-uploader/4.16.4/disk-uploader.yaml create mode 100644 tasks/disk-virt-customize/4.16.4/README.md create mode 100644 tasks/disk-virt-customize/4.16.4/disk-virt-customize.yaml create mode 100644 tasks/disk-virt-sysprep/4.16.4/README.md create mode 100644 tasks/disk-virt-sysprep/4.16.4/disk-virt-sysprep.yaml create mode 100644 tasks/modify-data-object/4.16.4/README.md create mode 100644 tasks/modify-data-object/4.16.4/modify-data-object.yaml create mode 100644 tasks/modify-vm-template/4.16.4/README.md create mode 100644 tasks/modify-vm-template/4.16.4/modify-vm-template.yaml create mode 100644 tasks/modify-windows-iso-file/4.16.4/README.md create mode 100644 tasks/modify-windows-iso-file/4.16.4/modify-windows-iso-file.yaml create mode 100644 tasks/wait-for-vmi-status/4.16.4/README.md create mode 100644 tasks/wait-for-vmi-status/4.16.4/wait-for-vmi-status.yaml diff --git a/pipelines/windows-efi-installer/4.16.4/README.md b/pipelines/windows-efi-installer/4.16.4/README.md new file mode 100644 index 00000000..d38f7d16 --- /dev/null +++ b/pipelines/windows-efi-installer/4.16.4/README.md @@ -0,0 +1,240 @@ +# Windows EFI Installer Pipeline + +This Pipeline installs Windows 10, 11 or Server 2k22 into a new DataVolume. This DataVolume is suitable to be used as a default boot source +or golden image for Windows 10, 11 or Server 2k22 VirtualMachines. + +This example Pipeline is suitable only for Windows 10, 11 or Server 2k22 (or other Windows versions which require EFI - not tested!). When using this example Pipeline always adjust Pipeline parameters for Windows version you are currently using (e.g. different name, different autoattend config map, different base image name, etc.). Each Windows version requires change in autounattendConfigMapName parameter (e.g. using `windows2k22-autounattend` config map will not work with Windows 11 and vice versa - e.g. due to different storage drivers path). + +The Pipeline implements this by modifying the supplied Windows ISO. It extracts all files from the ISO, replaces the prompt bootloader with the no-prompt bootloader and creates a new bootable ISO. +This helps with automated installation of Windows in EFI boot mode. By default Windows in EFI boot mode uses a prompt bootloader, which will not continue with the boot process until a key is pressed. By replacing it with the no-prompt bootloader no key press is required to boot into the Windows installer. Then Task packs updated packages to new ISO, converts it with qemu-img and replaces original ISO file in PVC. + +> [!IMPORTANT] +> If the ISO file does not contain files `efisys_noprompt.bin` and `cdboot_noprompt.efi` located at `efi/microsoft/boot/` +> inside ISO file, the `modify-windows-iso-file` task will exit and whole Pipeline will fail. In case your ISO file has +> different file structure, update `modify-windows-iso-file` task accordingly. + +After the ISO is modified it creates a new VirtualMachine which boots from the modified Windows installation image (ISO file). The installation of Windows is automatically executed and controlled by a Windows answer file. Then the Pipeline will wait for the installation to complete and will delete the created VirtualMachine while keeping the resulting DataSource/DataVolume with the installed operating system. The Pipeline can be customized to support different installation requirements. + +## Prerequisites + +- OpenShift Virtualization `>= v4.15.0` +- OpenShift Pipelines `>= v1.11.0` +- Apply ConfigMaps with Windows sysprep (or select one which you will need) - examples can be found here: https://github.com/kubevirt/kubevirt-tekton-tasks/tree/main/release/pipelines/windows-efi-installer/configmaps + +### Obtain Windows 10 ISO download URL + +1. Go to https://www.microsoft.com/en-us/software-download/windows10ISO. +2. Fill in the edition and `English` language (other languages need to be updated in `windows10-autounattend` ConfigMap) and go to the download page. +3. Right-click on the 64-bit download button and copy the download link. The link should be valid for 24 hours. + +### Obtain Windows 11 ISO download URL + +1. Go to https://www.microsoft.com/en-us/software-download/windows11. +2. Fill in the edition and `English` language (other languages need to be updated in `windows11-autounattend` ConfigMap) and go to the download page. +3. Right-click on the 64-bit download button and copy the download link. The link should be valid for 24 hours. + +### Obtain Windows Server 2022 ISO download URL + +1. Go to https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2022. +2. Right-click Download the ISO button. +3. Fill in all required informations and click on Download now button. +4. Select English (United States) (other languages need to be updated in `windows2k22-autounattend` ConfigMap) - 64-bit edition ISO download. + +### Prepare autounattend.xml ConfigMap + +1. Supply, generate or use the default autounattend.xml. + For information on answer files see [Startup Scripts - KubeVirt User Guide](https://kubevirt.io/user-guide/virtual_machines/startup_scripts/#sysprep). +2. Replace the default example autounattend.xml with your own in the definition of the `windows11-autounattend` ConfigMap in the Pipeline YAML. + Different autounattend.xml can be also passed in a separate ConfigMap with the Pipeline parameter `autounattendConfigMapName` when creating a PipelineRun. + +## Pipeline Description + +``` + import-autounattend-configmaps --- import-win-iso --- modify-windows-iso-file --- create-vm --- wait-for-vmi-status --- create-datasource-root-disk --- cleanup-vm --- delete-imported-configmaps + | + create-vm-root-disk --- +``` +1. `import-autounattend-configmaps` imports ConfigMap with `autounattend.xml` needed for automated installation of Windows. +2. `create-vm-root-disk` creates empty DataVolume which is used for Windows installation. +3. `import-win-iso` creates new DataVolume with Windows ISO file with name defined in `isoDVName` parameter. The DataVolume needs to be in the same namespace as the PipelineRun (because the PVC is mounted into the PipelineRun pod). +4. `modify-windows-iso-file` extracts imported ISO file, replaces prompt bootloader (which is used as a default one when EFI is used) with no-prompt bootloader, pack the updated files back to new ISO, convert the ISO and replaces original ISO with updated one.Replacement of bootloader is needed to be able to automate installation of Windows versions which require EFI. +5. `create-vm` Task creates a VirtualMachine. A DataVolume with the Windows source ISO will be attached as CD-ROM and a second empty DataVolume will be used as installation destination. A third DataVolume with the virtio-win ISO will also be attached (Pipeline parameter `virtioContainerDiskName`). The VirtualMachine has to be created in the same namespace as the DataVolume with the ISO file. In case you would like to run the VirtualMachine in a different namespace, both Datavolumes have to be copied to the same namespace as the VirtualMachine. +6. `wait-for-vmi-status` Task waits until the VirtualMachine shuts down. +7. `create-datasource-root-disk` Task creates a DataSource object, which is used by UI for discovering bootable volumes and links PVC created in `create-vm-root-disk` step. +8. `cleanup-vm` deletes the installer VirtualMachine and all of its DataVolumes. +9. The output artifact will be the `baseDvName`/`baseDvNamespace` DataVolume with the basic Windows installation. It will boot into the Windows OOBE and needs to be setup further before it can be used. +10. `delete-imported-configmaps` deletes imported ConfigMaps. + +## How to run + +Pipeline uses ConfigMaps with `autounattend.xml` file for automated installation of Windows from ISO file. Example ConfigMaps are deployed within the Pipeline. In case you would like to use a different ConfigMap, specify a different URL in the `autounattendXMLConfigMapsURL` parameter and adjust `autounattendConfigMapName` parameter with the correct ConfigMap name. Examples of ConfigMaps can be found [here](https://github.com/kubevirt/kubevirt-tekton-tasks/tree/main/release/pipelines/windows-efi-installer/configmaps). Pipeline automatically removes ConfigMaps at the end of the PipelineRun. If the content available in `autounattendXMLConfigMapsURL` changes during the Pipeline run, Pipeline may not remove all the objects it created. + +> [!IMPORTANT] +> Example PipelineRuns have special parameter acceptEula. By setting this parameter, you are agreeing to the applicable +> Microsoft end user license agreement(s) for each deployment or installation for the Microsoft product(s). In case you +> set it to false, the Pipeline will exit in first task. + +> [!NOTE] +> By default, the Pipeline requires the ServiceAccount `pipeline` to exist. Tekton does not create this ServiceAccount +> in namespaces which name starts with `openshift` or `kube`. In case you would like to run this Pipeline in a namespace which +> starts with `openshift` or `kube`, you have to create the `pipeline` ServiceAccount manually or specify a different ServiceAccount in the PipelineRun. + +Pipeline runs with resolvers: +```yaml +export WIN_IMAGE_DOWNLOAD_URL=$(./getisourl.py) # see paragraph Obtaining a download URL in an automated way + +oc create -f - <- + Run commands in KubeVirt virtual machine. + This task can stop and delete VMs + params: + - description: Name of a VM to execute the action in. + name: vmName + type: string + - description: Namespace of a VM to execute the action in. (defaults to active namespace) + name: vmNamespace + type: string + default: "" + - description: Stops the VM after executing the commands when set to true. + name: stop + type: string + default: "true" + - description: Deletes the VM after executing the commands when set to true. + name: delete + type: string + default: "false" + - description: Timeout for the command/script (includes potential VM start). The VM will be stopped or deleted accordingly once the timout expires. Should be in a 3h2m1s format. + name: timeout + type: string + default: "30m" + - description: Secret to use when connecting to a VM. + name: secretName + type: string + default: "__empty__" + - description: Command to execute in a VM. + name: command + type: array + default: [] + - description: Arguments of a command. + name: args + type: array + default: [] + - description: Script to execute in a VM. + name: script + type: string + default: "" + steps: + - name: execute-in-vm + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-create-datavolume-rhel9:v4.16.4" + command: + - entrypoint + args: + - '--stop' + - $(params.stop) + - '--delete' + - $(params.delete) + - '--timeout' + - $(params.timeout) + - '--' + - $(params.command) + - $(params.args) + env: + - name: COMMAND + value: execute-in-vm + - name: VM_NAME + value: $(params.vmName) + - name: VM_NAMESPACE + value: $(params.vmNamespace) + - name: EXECUTE_SCRIPT + value: $(params.script) + - name: CONNECTION_SECRET_NAME + value: $(params.secretName) + volumeMounts: + - mountPath: /data/connectionsecret/ + name: connectionsecret + readOnly: true + volumes: + - name: connectionsecret + secret: + secretName: $(params.secretName) + optional: true diff --git a/tasks/copy-template/4.16.4/README.md b/tasks/copy-template/4.16.4/README.md new file mode 100644 index 00000000..72b20cc5 --- /dev/null +++ b/tasks/copy-template/4.16.4/README.md @@ -0,0 +1,93 @@ +# Copy okd template Task + +#### Task is deprecated and will be removed in future versions. + +This task copies a KubeVirt Virtual Machine template. +A bundle of predefined templates to use can be found in [Common Templates](https://github.com/kubevirt/common-templates) project. + +### Parameters + +- **sourceTemplateName**: Name of an OpenShift template to copy template from. +- **sourceTemplateNamespace**: Namespace of an source OpenShift template to copy template from. (defaults to active namespace) +- **targetTemplateName**: Name of an target OpenShift template. +- **targetTemplateNamespace**: Namespace of an target OpenShift template to create in. (defaults to active namespace) +- **allowReplace**: Allow replacing already existing template (same combination name/namespace). Allowed values true/false +- **setOwnerReference**: Set owner reference to the new object created by the task run pod. Allowed values true/false + +### Results + +- **name**: The name of a template that was created. +- **namespace**: The namespace of a template that was created. + +### Usage + +Task run using resolver: +``` +apiVersion: tekton.dev/v1 +kind: TaskRun +metadata: + generateName: copy-template-taskrun-resolver- +spec: + params: + - name: sourceTemplateName + value: source-vm-template-example + - name: targetTemplateName + value: target-vm-template-example + taskRef: + params: + - name: catalog + value: kubevirt-tekton-tasks + - name: type + value: artifact + - name: kind + value: task + - name: name + value: copy-template + - name: version + value: v4.16.4 + resolver: hub +``` + +### Usage in different namespaces + +You can use task to do actions in different namespace. To do that, tasks requires special permissions. Apply these RBAC objects and permissions and update accordingly task run object with correct serviceAccount: + +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: copy-template-task +rules: +- apiGroups: + - template.openshift.io + resources: + - templates + verbs: + - get + - list + - watch + - create + - update +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: copy-template-task +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: copy-template-task +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: copy-template-task +subjects: +- kind: ServiceAccount + name: copy-template-task +--- +``` + +### Platforms + +The Task can be run on linux/amd64 platform. diff --git a/tasks/copy-template/4.16.4/copy-template.yaml b/tasks/copy-template/4.16.4/copy-template.yaml new file mode 100644 index 00000000..3341bc1a --- /dev/null +++ b/tasks/copy-template/4.16.4/copy-template.yaml @@ -0,0 +1,84 @@ +--- +apiVersion: tekton.dev/v1 +kind: Task +metadata: + annotations: + tekton.dev/source: "https://github.com/openshift-virtualization/openshift-virtualization-pipelines-tasks" + tekton.dev/deprecated: "true" + tekton.dev/pipelines.minVersion: "0.43.0" + tekton.dev/categories: Automation + tekton.dev/tags: kubevirt + tekton.dev/displayName: "OpenShift Virtualization copy template" + tekton.dev/platforms: "linux/amd64" + artifacthub.io/maintainers: | + - name: KubeVirt Tekton tasks maintainers + email: kubevirt-tekton-tasks@redhat.com + artifacthub.io/provider: Red Hat + artifacthub.io/recommendations: | + - url: https://kubevirt.io/ + artifacthub.io/category: integration-delivery + labels: + app.kubernetes.io/version: v4.16.4 + name: copy-template +spec: + description: >- + Automates the copying of OpenShift template. The task copies original template + and saves it under new name or if parameter allowReplace is true, then it replaces + template with the same name. + params: + - name: sourceTemplateName + description: Name of an OpenShift template to copy template from. + type: string + - name: sourceTemplateNamespace + description: Namespace of an source OpenShift template to copy template from. (defaults to active namespace) + type: string + default: "" + - name: targetTemplateName + description: Name of an target OpenShift template. + type: string + default: "" + - name: targetTemplateNamespace + description: Namespace of an target OpenShift template to create in. (defaults to active namespace) + type: string + default: "" + - name: allowReplace + description: Allow replacing already existing template (same combination name/namespace). Allowed values true/false + type: string + default: "false" + - name: setOwnerReference + description: Set owner reference to the new object created by the task run pod. Allowed values true/false + type: string + default: "false" + results: + - name: name + description: The name of a template that was created. + - name: namespace + description: The namespace of a template that was created. + steps: + - name: copytemplate + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-create-datavolume-rhel9:v4.16.4" + command: + - copy-template + args: + - "--output=yaml" + env: + - name: SOURCE_TEMPLATE_NAME + value: $(params.sourceTemplateName) + - name: SOURCE_TEMPLATE_NAMESPACE + value: $(params.sourceTemplateNamespace) + - name: TARGET_TEMPLATE_NAME + value: $(params.targetTemplateName) + - name: TARGET_TEMPLATE_NAMESPACE + value: $(params.targetTemplateNamespace) + - name: ALLOW_REPLACE + value: $(params.allowReplace) + - name: SET_OWNER_REFERENCE + value: $(params.setOwnerReference) + - name: POD_NAMESPACE + valueFrom: + fieldRef: + fieldPath: metadata.namespace + - name: POD_NAME + valueFrom: + fieldRef: + fieldPath: metadata.name diff --git a/tasks/create-vm-from-manifest/4.16.4/README.md b/tasks/create-vm-from-manifest/4.16.4/README.md new file mode 100644 index 00000000..0693ab1b --- /dev/null +++ b/tasks/create-vm-from-manifest/4.16.4/README.md @@ -0,0 +1,140 @@ +# Create VirtualMachine from Manifest Task + +This task creates a VirtualMachine from YAML manifest + +### Parameters + +- **manifest**: YAML manifest of a VirtualMachine resource to be created. +- **virtctl**: Parameters for virtctl create vm command that will be used to create VirtualMachine. +- **namespace**: Namespace where to create the VM. (defaults to manifest namespace or active namespace) +- **startVM**: Set to true or false to start / not start vm after creation. In case of runStrategy is set to Always, startVM flag is ignored. +- **runStrategy**: Set runStrategy to VM. If runStrategy is set, vm.spec.running attribute is set to nil. +- **setOwnerReference**: Set owner reference to the new object created by the task run pod. Allowed values true/false + +### Results + +- **name**: The name of a VM that was created. +- **namespace**: The namespace of a VM that was created. + +### Usage + +Task run using resolver: +``` +apiVersion: tekton.dev/v1 +kind: TaskRun +metadata: + generateName: create-vm-from-manifest-taskrun-resolver- +spec: + params: + - name: manifest + value: + taskRef: + params: + - name: catalog + value: kubevirt-tekton-tasks + - name: type + value: artifact + - name: kind + value: task + - name: name + value: create-vm-from-manifest + - name: version + value: v4.16.4 + resolver: hub +``` + +As an example for `manifest` parameter, you can use this VM definition: +``` +apiVersion: kubevirt.io/v1 +kind: VirtualMachine +metadata: + generateName: vm-fedora- + labels: + kubevirt.io/vm: vm-fedora +spec: + runStrategy: Halted + template: + metadata: + labels: + kubevirt.io/vm: vm-fedora + spec: + domain: + devices: + disks: + - disk: + bus: virtio + name: containerdisk + - disk: + bus: virtio + name: cloudinitdisk + memory: + guest: 1Gi + volumes: + - containerDisk: + image: quay.io/containerdisks/fedora:latest + name: containerdisk + - cloudInitNoCloud: + userData: '#!/bin/sh + + echo ''printed from cloud-init userdata'' + + ' + name: cloudinitdisk +``` + +### Usage in different namespaces + +You can use task to do actions in different namespace. To do that, tasks requires special permissions. Apply these RBAC objects and permissions and update accordingly task run object with correct serviceAccount: + +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: create-vm-from-manifest-task +rules: +- apiGroups: + - kubevirt.io + resources: + - virtualmachines + - virtualmachineinstances + verbs: + - get + - list + - watch + - create + - update +- apiGroups: + - subresources.kubevirt.io + resources: + - virtualmachines/start + verbs: + - update +- apiGroups: + - '' + resources: + - persistentvolumeclaims + verbs: + - update +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: create-vm-from-manifest-task +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: create-vm-from-manifest-task +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: create-vm-from-manifest-task +subjects: +- kind: ServiceAccount + name: create-vm-from-manifest-task +--- +``` + +### Platforms + +The Task can be run on linux/amd64 platform. diff --git a/tasks/create-vm-from-manifest/4.16.4/create-vm-from-manifest.yaml b/tasks/create-vm-from-manifest/4.16.4/create-vm-from-manifest.yaml new file mode 100644 index 00000000..b5326b84 --- /dev/null +++ b/tasks/create-vm-from-manifest/4.16.4/create-vm-from-manifest.yaml @@ -0,0 +1,84 @@ +--- +apiVersion: tekton.dev/v1 +kind: Task +metadata: + annotations: + tekton.dev/source: "https://github.com/openshift-virtualization/openshift-virtualization-pipelines-tasks" + tekton.dev/pipelines.minVersion: "0.43.0" + tekton.dev/categories: Automation + tekton.dev/tags: kubevirt + tekton.dev/displayName: "OpenShift Virtualization create VM from manifest" + tekton.dev/platforms: "linux/amd64" + artifacthub.io/maintainers: | + - name: KubeVirt Tekton tasks maintainers + email: kubevirt-tekton-tasks@redhat.com + artifacthub.io/provider: Red Hat + artifacthub.io/recommendations: | + - url: https://kubevirt.io/ + artifacthub.io/category: integration-delivery + labels: + app.kubernetes.io/version: v4.16.4 + name: create-vm-from-manifest +spec: + description: >- + Automates creation of the KubeVirt virtual machine. + User can create VM from manifest or with the same parameters as for virtctl. + It is possible to immediatelly start the vm after creation with startVM parameter. + params: + - name: manifest + description: YAML manifest of a VirtualMachine resource to be created. + default: "" + type: string + - name: virtctl + description: "Parameters for virtctl create vm command that will be used to create VirtualMachine." + default: "" + type: string + - name: namespace + description: Namespace where to create the VM. (defaults to manifest namespace or active namespace) + default: "" + type: string + - name: startVM + description: Set to true or false to start / not start vm after creation. In case of runStrategy is set to Always, startVM flag is ignored. + default: "" + type: string + - name: runStrategy + description: Set runStrategy to VM. If runStrategy is set, vm.spec.running attribute is set to nil. + default: "" + type: string + - name: setOwnerReference + description: Set owner reference to the new object created by the task run pod. Allowed values true/false + type: string + default: "false" + results: + - name: name + description: The name of a VM that was created. + - name: namespace + description: The namespace of a VM that was created. + steps: + - name: createvm + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-create-datavolume-rhel9:v4.16.4" + command: + - create-vm + args: + - "--output=yaml" + env: + - name: VM_MANIFEST + value: $(params.manifest) + - name: VM_NAMESPACE + value: $(params.namespace) + - name: VIRTCTL + value: $(params.virtctl) + - name: START_VM + value: $(params.startVM) + - name: SET_OWNER_REFERENCE + value: $(params.setOwnerReference) + - name: RUN_STRATEGY + value: $(params.runStrategy) + - name: POD_NAMESPACE + valueFrom: + fieldRef: + fieldPath: metadata.namespace + - name: POD_NAME + valueFrom: + fieldRef: + fieldPath: metadata.name diff --git a/tasks/create-vm-from-template/4.16.4/README.md b/tasks/create-vm-from-template/4.16.4/README.md new file mode 100644 index 00000000..471ba5a7 --- /dev/null +++ b/tasks/create-vm-from-template/4.16.4/README.md @@ -0,0 +1,132 @@ +# Create VirtualMachine from OKD Template Task + +#### Task is deprecated and will be removed in future versions. + +This task creates a VirtualMachine from OKD Template. +Virtual machines can be described and parametrized in a generic form with these templates. +A bundle of predefined templates to use can be found in [Common Templates](https://github.com/kubevirt/common-templates) project. + +### Parameters + +- **templateName**: Name of an OKD template to create VM from. +- **templateNamespace**: Namespace of an OKD template to create VM from. (defaults to active namespace) +- **templateParams**: Template params to pass when processing the template manifest. Each param should have KEY:VAL format. Eg `["NAME:my-vm", "DESC:blue"]` +- **vmNamespace**: Namespace where to create the VM. (defaults to active namespace) +- **startVM**: Set to true or false to start / not start vm after creation. In case of runStrategy is set to Always, startVM flag is ignored. +- **runStrategy**: Set runStrategy to VM. If runStrategy is set, vm.spec.running attribute is set to nil. +- **setOwnerReference**: Set owner reference to the new object created by the task run pod. Allowed values true/false + +### Results + +- **name**: The name of a VM that was created. +- **namespace**: The namespace of a VM that was created. + +### Usage + +Task run using resolver: +``` +apiVersion: tekton.dev/v1 +kind: TaskRun +metadata: + generateName: create-vm-from-template-taskrun-resolver- +spec: + params: + - name: templateName + value: vm-template-example + - name: templateParams + value: + - NAME:example-vm + - name: ownDataVolumes + value: + - example-dv + taskRef: + params: + - name: catalog + value: kubevirt-tekton-tasks + - name: type + value: artifact + - name: kind + value: task + - name: name + value: create-vm-from-template + - name: version + value: v4.16.4 + resolver: hub +``` + +### Usage in different namespaces + +You can use task to do actions in different namespace. To do that, tasks requires special permissions. Apply these RBAC objects and permissions and update accordingly task run object with correct serviceAccount: + +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: create-vm-from-template-task +rules: +- apiGroups: + - kubevirt.io + resources: + - virtualmachines + - virtualmachineinstances + verbs: + - get + - list + - watch + - create + - update +- apiGroups: + - kubevirt.io + resources: + - virtualmachines/finalizers + verbs: + - get +- apiGroups: + - template.openshift.io + resources: + - templates + verbs: + - get + - list + - watch +- apiGroups: + - template.openshift.io + resources: + - processedtemplates + verbs: + - create +- apiGroups: + - cdi.kubevirt.io + resources: + - datavolumes + verbs: + - create +- apiGroups: + - subresources.kubevirt.io + resources: + - virtualmachines/start + verbs: + - update +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: create-vm-from-template-task +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: create-vm-from-template-task +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: create-vm-from-template-task +subjects: +- kind: ServiceAccount + name: create-vm-from-template-task +--- +``` + +### Platforms + +The Task can be run on linux/amd64 platform. diff --git a/tasks/create-vm-from-template/4.16.4/create-vm-from-template.yaml b/tasks/create-vm-from-template/4.16.4/create-vm-from-template.yaml new file mode 100644 index 00000000..f5fa73d1 --- /dev/null +++ b/tasks/create-vm-from-template/4.16.4/create-vm-from-template.yaml @@ -0,0 +1,90 @@ +--- +apiVersion: tekton.dev/v1 +kind: Task +metadata: + annotations: + tekton.dev/source: "https://github.com/openshift-virtualization/openshift-virtualization-pipelines-tasks" + tekton.dev/pipelines.minVersion: "0.43.0" + tekton.dev/categories: Automation + tekton.dev/tags: kubevirt + tekton.dev/displayName: "OpenShift Virtualization create VM from template" + tekton.dev/platforms: "linux/amd64" + artifacthub.io/maintainers: | + - name: KubeVirt Tekton tasks maintainers + email: kubevirt-tekton-tasks@redhat.com + artifacthub.io/provider: Red Hat + artifacthub.io/recommendations: | + - url: https://kubevirt.io/ + artifacthub.io/category: integration-delivery + tekton.dev/deprecated: "true" + labels: + app.kubernetes.io/version: v4.16.4 + name: create-vm-from-template +spec: + description: >- + Automates creation of the KubeVirt virtual machine. + User can create VM from OpenShift template. + It is possible to immediatelly start the vm after creation with startVM parameter. + params: + - name: templateName + description: Name of an OKD template to create VM from. + type: string + - name: templateNamespace + description: Namespace of an OKD template to create VM from. (defaults to active namespace) + default: "" + type: string + - name: templateParams + description: Template params to pass when processing the template manifest. Each param should have KEY:VAL format. Eg ["NAME:my-vm", "DESC:blue"] + default: [] + type: array + - name: vmNamespace + description: Namespace where to create the VM. (defaults to active namespace) + default: "" + type: string + - name: startVM + description: Set to true or false to start / not start vm after creation. In case of runStrategy is set to Always, startVM flag is ignored. + default: "" + type: string + - name: runStrategy + description: Set runStrategy to VM. If runStrategy is set, vm.spec.running attribute is set to nil. + default: "" + type: string + - name: setOwnerReference + description: Set owner reference to the new object created by the task run pod. Allowed values true/false + type: string + default: "false" + results: + - name: name + description: The name of a VM that was created. + - name: namespace + description: The namespace of a VM that was created. + steps: + - name: createvm + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-create-datavolume-rhel9:v4.16.4" + command: + - create-vm + args: + - "--output=yaml" + - '--template-params' + - $(params.templateParams) + env: + - name: TEMPLATE_NAME + value: $(params.templateName) + - name: TEMPLATE_NAMESPACE + value: $(params.templateNamespace) + - name: VM_NAMESPACE + value: $(params.vmNamespace) + - name: START_VM + value: $(params.startVM) + - name: SET_OWNER_REFERENCE + value: $(params.setOwnerReference) + - name: RUN_STRATEGY + value: $(params.runStrategy) + - name: POD_NAMESPACE + valueFrom: + fieldRef: + fieldPath: metadata.namespace + - name: POD_NAME + valueFrom: + fieldRef: + fieldPath: metadata.name diff --git a/tasks/disk-uploader/4.16.4/README.md b/tasks/disk-uploader/4.16.4/README.md new file mode 100644 index 00000000..d836f717 --- /dev/null +++ b/tasks/disk-uploader/4.16.4/README.md @@ -0,0 +1,60 @@ +# KubeVirt Disk Uploader Task + +Automates the extraction of disk and uploads it to a container registry, to be used in multiple Kubernetes clusters. + +## Prerequisites + +VMExport support must be enabled in the feature gates to be available. The [feature gates](https://kubevirt.io/user-guide/cluster_admin/activating_feature_gates/#how-to-activate-a-feature-gate) field in the KubeVirt Custom Resource (CR) must be expanded by adding the VMExport to it. + +# Example Scenario + +When user runs [KubeVirt Tekton Tasks](https://github.com/kubevirt/kubevirt-tekton-tasks) example pipelines (windows-installer, windows-customize) to prepare Windows disk images - The newly created disk image is only in a single cluster. If user wants to have it in another cluster, then KubeVirt Disk Uploader can be used to push it out of the cluster. + +### Parameters + +- **EXPORT_SOURCE_KIND**: The name of the export source kind +- **EXPORT_SOURCE_NAME**: The name of the export source +- **VOLUME_NAME**: The volume name (If source kind is PVC, then volume name is equal to source name) +- **IMAGE_DESTINATION**: Destination of the image in container registry +- **PUSH_TIMEOUT**: ContainerDisk push timeout in minutes +- **SECRET_NAME**: Name of the secret which holds credential for container registry + +### Usage + +Task run using resolver: +``` +apiVersion: tekton.dev/v1 +kind: TaskRun +metadata: + generateName: disk-uploader-taskrun-resolver- +spec: + params: + - name: EXPORT_SOURCE_KIND + value: vm + - name: EXPORT_SOURCE_NAME + value: example-vm + - name: VOLUME_NAME + value: example-dv + - name: IMAGE_DESTINATION + value: quay.io/kubevirt/example-vm-exported:latest + - name: PUSH_TIMEOUT + value: 120 + taskRef: + params: + - name: catalog + value: kubevirt-tekton-tasks + - name: type + value: artifact + - name: kind + value: task + - name: name + value: disk-uploader + - name: version + value: v4.16.4 + resolver: hub + +``` + +### Platforms + +The Task can be run on linux/amd64 platform. diff --git a/tasks/disk-uploader/4.16.4/disk-uploader.yaml b/tasks/disk-uploader/4.16.4/disk-uploader.yaml new file mode 100644 index 00000000..2e3c169d --- /dev/null +++ b/tasks/disk-uploader/4.16.4/disk-uploader.yaml @@ -0,0 +1,83 @@ +--- +apiVersion: tekton.dev/v1 +kind: Task +metadata: + annotations: + tekton.dev/source: "https://github.com/openshift-virtualization/openshift-virtualization-pipelines-tasks" + tekton.dev/pipelines.minVersion: "0.43.0" + tekton.dev/categories: Automation + tekton.dev/tags: kubevirt, containerdisks + tekton.dev/displayName: "OpenShift Virtualization disk uploader" + tekton.dev/platforms: "linux/amd64" + artifacthub.io/maintainers: | + - name: KubeVirt Tekton tasks maintainers + email: kubevirt-tekton-tasks@redhat.com + artifacthub.io/provider: Red Hat + artifacthub.io/recommendations: | + - url: https://kubevirt.io/ + artifacthub.io/category: integration-delivery + labels: + app.kubernetes.io/version: v4.16.4 + name: disk-uploader +spec: + description: >- + Automates the extraction of disk and uploads it to a container registry, + to be used in multiple Kubernetes clusters. + params: + - name: EXPORT_SOURCE_KIND + description: The name of the export source kind + type: string + - name: EXPORT_SOURCE_NAME + description: The name of the export source + type: string + - name: VOLUME_NAME + description: The volume name (If source kind is PVC, then volume name is equal to source name) + type: string + - name: IMAGE_DESTINATION + description: Destination of the image in container registry + type: string + - name: PUSH_TIMEOUT + description: ContainerDisk push timeout in minutes + type: string + - name: SECRET_NAME + description: Name of the secret which holds credential for container registry + type: string + steps: + - name: disk-uploader-step + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-create-datavolume-rhel9:v4.16.4" + env: + - name: ACCESS_KEY_ID + valueFrom: + secretKeyRef: + name: $(params.SECRET_NAME) + key: accessKeyId + - name: SECRET_KEY + valueFrom: + secretKeyRef: + name: $(params.SECRET_NAME) + key: secretKey + - name: POD_NAMESPACE + valueFrom: + fieldRef: + fieldPath: metadata.namespace + - name: POD_NAME + valueFrom: + fieldRef: + fieldPath: metadata.name + command: ["/usr/local/bin/disk-uploader"] + args: + - "--export-source-kind" + - $(params.EXPORT_SOURCE_KIND) + - "--export-source-name" + - $(params.EXPORT_SOURCE_NAME) + - "--volumename" + - $(params.VOLUME_NAME) + - "--imagedestination" + - $(params.IMAGE_DESTINATION) + - "--pushtimeout" + - $(params.PUSH_TIMEOUT) + computeResources: + requests: + memory: "3Gi" + limits: + memory: "5Gi" diff --git a/tasks/disk-virt-customize/4.16.4/README.md b/tasks/disk-virt-customize/4.16.4/README.md new file mode 100644 index 00000000..ecf8c467 --- /dev/null +++ b/tasks/disk-virt-customize/4.16.4/README.md @@ -0,0 +1,63 @@ +# Disk Virt Customize Task + +This task uses [virt-customize](https://libguestfs.org/virt-customize.1.html) to run a customize script on a target pvc. + +### Parameters + +- **pvc**: PersistentVolumeClaim to run the the virt-customize script in. PVC should be in the same namespace as taskrun/pipelinerun. +- **virtCommands**: virt-customize commands in `--commands-from-file` format. +- **verbose**: Enable verbose mode and tracing of libguestfs API calls. +- **additionalVirtOptions**: Additional options to pass to virt-customize. + +### Usage + +Task run using resolver: +``` +apiVersion: tekton.dev/v1 +kind: TaskRun +metadata: + generateName: disk-virt-customize-taskrun- +spec: + params: + - name: pvc + value: example-pvc + - name: virtCommands + value: install make,ansible + podTemplate: + securityContext: + fsGroup: 107 + runAsUser: 107 + taskRef: + params: + - name: catalog + value: kubevirt-tekton-tasks + - name: type + value: artifact + - name: kind + value: task + - name: name + value: disk-virt-customize + - name: version + value: v4.16.4 + resolver: hub +``` + +#### Common Errors + +- The input PVC disk should not be accessed by a running VM or other tools like virt-customize concurrently. +The task will fail with a generic `...guestfs_launch failed...` message. +Verbose parameter can be set to true for more information. + +- The task can end with error `Permissions denied`. This error means, the disk-virt-customize cannot access the VM image due to wrong permissions set on the file. This issue can be fixed by adding `podTemplate` to the spec of the TaskRun: +``` +spec: + podTemplate: + securityContext: + fsGroup: 107 + runAsUser: 107 +``` + +### OS support + +- Linux: full; all the customize commands work +- Windows: partial; only some customize commands work diff --git a/tasks/disk-virt-customize/4.16.4/disk-virt-customize.yaml b/tasks/disk-virt-customize/4.16.4/disk-virt-customize.yaml new file mode 100644 index 00000000..7307d34a --- /dev/null +++ b/tasks/disk-virt-customize/4.16.4/disk-virt-customize.yaml @@ -0,0 +1,138 @@ +--- +apiVersion: tekton.dev/v1 +kind: Task +metadata: + annotations: + tekton.dev/source: "https://github.com/openshift-virtualization/openshift-virtualization-pipelines-tasks" + tekton.dev/pipelines.minVersion: "0.43.0" + tekton.dev/categories: Automation + tekton.dev/tags: kubevirt + tekton.dev/displayName: "OpenShift Virtualization disk virt customize" + tekton.dev/platforms: "linux/amd64" + artifacthub.io/maintainers: | + - name: KubeVirt Tekton tasks maintainers + email: kubevirt-tekton-tasks@redhat.com + artifacthub.io/provider: Red Hat + artifacthub.io/recommendations: | + - url: https://kubevirt.io/ + artifacthub.io/category: integration-delivery + labels: + app.kubernetes.io/version: v4.16.4 + name: disk-virt-customize +spec: + description: >- + Run virt-customize command on given PVC. Usefull for manipulation with virtual machine's disks. + params: + - name: pvc + description: PersistentVolumeClaim to run the the virt-customize script in. PVC should be in the same namespace as taskrun/pipelinerun. + type: string + - name: virtCommands + description: virt-customize commands in "--commands-from-file" format. + type: string + default: "" + - name: verbose + description: Enable verbose mode and tracing of libguestfs API calls. + type: string + default: 'false' + - name: additionalVirtOptions + description: Additional options to pass to virt-customize. + type: string + default: "" + steps: + - name: run-virt-customize + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-disk-virt-customize-rhel9:v4.16.4" + command: + - entrypoint + args: + - '--verbose' + - $(params.verbose) + env: + - name: COMMAND + value: disk-virt-customize + - name: VIRT_COMMANDS + value: $(params.virtCommands) + - name: ADDITIONAL_VIRT_OPTIONS + value: $(params.additionalVirtOptions) + - name: LIBGUESTFS_BACKEND + value: direct + computeResources: + limits: + devices.kubevirt.io/kvm: '1' + devices.kubevirt.io/tun: '1' + devices.kubevirt.io/vhost-net: '1' + requests: + devices.kubevirt.io/kvm: '1' + devices.kubevirt.io/tun: '1' + devices.kubevirt.io/vhost-net: '1' + volumeMounts: + - mountPath: /mnt/appliance/ + name: guestfsappliance + - mountPath: /mnt/targetpvc/ + name: targetpvc + volumes: + - name: guestfsappliance + emptyDir: {} + - name: targetpvc + persistentVolumeClaim: + claimName: $(params.pvc) + workspaces: + - name: data01 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data01 + - name: data02 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data02 + - name: data03 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data03 + - name: data04 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data04 + - name: data05 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data05 + - name: data06 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data06 + - name: data07 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data07 + - name: data08 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data08 + - name: data09 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data09 + - name: data10 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data10 diff --git a/tasks/disk-virt-sysprep/4.16.4/README.md b/tasks/disk-virt-sysprep/4.16.4/README.md new file mode 100644 index 00000000..216f94f1 --- /dev/null +++ b/tasks/disk-virt-sysprep/4.16.4/README.md @@ -0,0 +1,63 @@ +# Disk Virt Sysprep Task + +This task uses [virt-sysprep](https://libguestfs.org/virt-sysprep.1.html) to run a sysprep script on a target pvc. + +### Parameters + +- **pvc**: PersistentVolumeClaim to run the the virt-sysprep script in. PVC should be in the same namespace as taskrun/pipelinerun. +- **virtCommands**: virt-sysprep commands in `--commands-from-file` format. +- **verbose**: Enable verbose mode and tracing of libguestfs API calls. +- **additionalVirtOptions**: Additional options to pass to virt-sysprep. + +### Usage + +Task run using resolver: +``` +apiVersion: tekton.dev/v1 +kind: TaskRun +metadata: + generateName: disk-virt-sysprep-taskrun- +spec: + params: + - name: pvc + value: example-pvc + - name: sysprepCommands + value: install make,ansible + podTemplate: + securityContext: + fsGroup: 107 + runAsUser: 107 + taskRef: + params: + - name: catalog + value: kubevirt-tekton-tasks + - name: type + value: artifact + - name: kind + value: task + - name: name + value: disk-virt-sysprep + - name: version + value: v4.16.4 + resolver: hub +``` + +#### Common Errors + +- The input PVC disk should not be accessed by a running VM or other tools like virt-sysprep task concurrently. +The task will fail with a generic `...guestfs_launch failed...` message. +A verbose parameter can be set to true for more information. + +- The task can end with error `Permissions denied`. This error means, the disk-virt-sysprep cannot access the VM image due to wrong permissions set on the file. This issue can be fixed by adding `podTemplate` to the spec of the TaskRun: +``` +spec: + podTemplate: + securityContext: + fsGroup: 107 + runAsUser: 107 +``` + +### OS support + +- Linux: full; all the sysprep commands work +- Windows: partial; only some sysprep commands work diff --git a/tasks/disk-virt-sysprep/4.16.4/disk-virt-sysprep.yaml b/tasks/disk-virt-sysprep/4.16.4/disk-virt-sysprep.yaml new file mode 100644 index 00000000..6bb92b4a --- /dev/null +++ b/tasks/disk-virt-sysprep/4.16.4/disk-virt-sysprep.yaml @@ -0,0 +1,138 @@ +--- +apiVersion: tekton.dev/v1 +kind: Task +metadata: + annotations: + tekton.dev/source: "https://github.com/openshift-virtualization/openshift-virtualization-pipelines-tasks" + tekton.dev/pipelines.minVersion: "0.43.0" + tekton.dev/categories: Automation + tekton.dev/tags: kubevirt + tekton.dev/displayName: "OpenShift Virtualization disk virt sysprep" + tekton.dev/platforms: "linux/amd64" + artifacthub.io/maintainers: | + - name: KubeVirt Tekton tasks maintainers + email: kubevirt-tekton-tasks@redhat.com + artifacthub.io/provider: Red Hat + artifacthub.io/recommendations: | + - url: https://kubevirt.io/ + artifacthub.io/category: integration-delivery + labels: + app.kubernetes.io/version: v4.16.4 + name: disk-virt-sysprep +spec: + description: >- + Run virt-sysprep command on given PVC. Usefull for manipulation with virtual machine's disks. + params: + - name: pvc + description: PersistentVolumeClaim to run the the virt-sysprep script in. PVC should be in the same namespace as taskrun/pipelinerun. + type: string + - name: virtCommands + description: virt-sysprep commands in "--commands-from-file" format. + type: string + default: "" + - name: verbose + description: Enable verbose mode and tracing of libguestfs API calls. + type: string + default: 'false' + - name: additionalVirtOptions + description: Additional options to pass to virt-sysprep. + type: string + default: "" + steps: + - name: run-virt-sysprep + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-disk-virt-customize-rhel9:v4.16.4" + command: + - entrypoint + args: + - '--verbose' + - $(params.verbose) + env: + - name: COMMAND + value: disk-virt-sysprep + - name: VIRT_COMMANDS + value: $(params.virtCommands) + - name: ADDITIONAL_VIRT_OPTIONS + value: $(params.additionalVirtOptions) + - name: LIBGUESTFS_BACKEND + value: direct + computeResources: + limits: + devices.kubevirt.io/kvm: '1' + devices.kubevirt.io/tun: '1' + devices.kubevirt.io/vhost-net: '1' + requests: + devices.kubevirt.io/kvm: '1' + devices.kubevirt.io/tun: '1' + devices.kubevirt.io/vhost-net: '1' + volumeMounts: + - mountPath: /mnt/appliance/ + name: guestfsappliance + - mountPath: /mnt/targetpvc/ + name: targetpvc + volumes: + - name: guestfsappliance + emptyDir: {} + - name: targetpvc + persistentVolumeClaim: + claimName: $(params.pvc) + workspaces: + - name: data01 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data01 + - name: data02 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data02 + - name: data03 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data03 + - name: data04 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data04 + - name: data05 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data05 + - name: data06 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data06 + - name: data07 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data07 + - name: data08 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data08 + - name: data09 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data09 + - name: data10 + description: | + An optional workspace that may contain files or secrets to be + used during the virt-customize run. + optional: true + mountPath: /data10 diff --git a/tasks/modify-data-object/4.16.4/README.md b/tasks/modify-data-object/4.16.4/README.md new file mode 100644 index 00000000..0306f6a4 --- /dev/null +++ b/tasks/modify-data-object/4.16.4/README.md @@ -0,0 +1,123 @@ +# Modify Data Object Task + +This task modifies a data object (DataVolumes or DataSources). + +### Parameters + +- **manifest**: YAML manifest of a data object to be created. +- **namespace**: Namespace where to create the data object. (defaults to manifest namespace or active namespace) +- **waitForSuccess**: Set to `true` or `false` if container should wait for Ready condition of the data object. +- **allowReplace**: Allow replacing an already existing data object (same combination name/namespace). Allowed values true/false +- **deleteObject**: Set to `true` or `false` if task should delete the specified DataVolume, DataSource or PersistentVolumeClaim. If set to 'true' the ds/dv/pvc will be deleted and all other parameters are ignored. +- **deleteObjectKind**: Kind of the data object to delete. This parameter is used only for Delete operation. +- **deleteObjectName**: Name of the data object to delete. This parameter is used only for Delete operation. +- **timeout**: When waitForSuccess parameter is set to true, this parameter defines how long the task will wait until it timeouts. Should be in a 3h2m1s format. +- **setOwnerReference**: Set owner reference to the new object created by the task run pod. Allowed values true/false + +### Results + +- **name**: The name of the data object that was created. +- **namespace**: The namespace of the data object that was created. + +### Usage + +Task run using resolver: +``` +apiVersion: tekton.dev/v1 +kind: TaskRun +metadata: + generateName: modify-data-object-taskrun-resolver- +spec: + params: + - name: waitForSuccess + value: 'true' + - name: manifest + value: + taskRef: + params: + - name: catalog + value: kubevirt-tekton-tasks + - name: type + value: artifact + - name: kind + value: task + - name: name + value: modify-data-object + - name: version + value: v4.16.4 + resolver: hub +``` + +As an example for `manifest` parameter, you can use this DV definition: +``` +apiVersion: cdi.kubevirt.io/v1beta1 +kind: DataVolume +metadata: + generateName: example-dv- +spec: + pvc: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 100Mi + volumeMode: Filesystem + source: + blank: {} +``` + +### Usage in different namespaces + +You can use task to do actions in different namespace. To do that, tasks requires special permissions. Apply these RBAC objects and permissions and update accordingly task run object with correct serviceAccount: + +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: modify-data-object-task +rules: +- apiGroups: + - cdi.kubevirt.io + resources: + - datavolumes + - datasources + verbs: + - get + - create + - delete +- apiGroups: + - '' + resources: + - pods + verbs: + - create +- apiGroups: + - '' + resources: + - persistentvolumeclaims + verbs: + - get + - delete +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: modify-data-object-task +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: modify-data-object-task +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: modify-data-object-task +subjects: +- kind: ServiceAccount + name: modify-data-object-task +--- +``` + +### Platforms + +The Task can be run on linux/amd64 platform. diff --git a/tasks/modify-data-object/4.16.4/modify-data-object.yaml b/tasks/modify-data-object/4.16.4/modify-data-object.yaml new file mode 100644 index 00000000..68a00113 --- /dev/null +++ b/tasks/modify-data-object/4.16.4/modify-data-object.yaml @@ -0,0 +1,100 @@ +--- +apiVersion: tekton.dev/v1 +kind: Task +metadata: + annotations: + tekton.dev/source: "https://github.com/openshift-virtualization/openshift-virtualization-pipelines-tasks" + tekton.dev/pipelines.minVersion: "0.43.0" + tekton.dev/categories: Automation + tekton.dev/tags: kubevirt + tekton.dev/displayName: "OpenShift Virtualization modify data object" + tekton.dev/platforms: "linux/amd64" + artifacthub.io/maintainers: | + - name: KubeVirt Tekton tasks maintainers + email: kubevirt-tekton-tasks@redhat.com + artifacthub.io/provider: Red Hat + artifacthub.io/recommendations: | + - url: https://kubevirt.io/ + artifacthub.io/category: integration-delivery + labels: + app.kubernetes.io/version: v4.16.4 + name: modify-data-object +spec: + description: >- + This task modifies a data object (DataVolume or DataSource). It can optionally wait until CDI imports finish. + params: + - name: manifest + description: YAML manifest of a data object to be created. + type: string + default: '' + - name: namespace + description: Namespace where to create the data object. (defaults to manifest namespace or active namespace) + default: "" + type: string + - name: waitForSuccess + description: Set to "true" or "false" if container should wait for Ready condition of the data object. + default: 'false' + type: string + - name: allowReplace + description: Allow replacing an already existing data object (same combination name/namespace). Allowed values true/false + type: string + default: "false" + - name: deleteObject + description: Set to `true` or `false` if task should delete the specified DataVolume, DataSource or PersistentVolumeClaim. If set to 'true' the ds/dv/pvc will be deleted and all other parameters are ignored. + default: 'false' + type: string + - name: deleteObjectKind + description: Kind of the data object to delete. This parameter is used only for Delete operation. + default: "" + type: string + - name: deleteObjectName + description: Name of the data object to delete. This parameter is used only for Delete operation. + default: "" + type: string + - description: When waitForSuccess parameter is set to true, this parameter defines how long the task will wait until it timeouts. Should be in a 3h2m1s format. + name: timeout + type: string + default: "1h" + - name: setOwnerReference + description: Set owner reference to the new object created by the task run pod. Allowed values true/false + type: string + default: "false" + results: + - name: name + description: The name of the data object that was created. + - name: namespace + description: The namespace of the data object that was created. + steps: + - name: modify-data-object + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-create-datavolume-rhel9:v4.16.4" + command: + - modify-data-object + args: + - "--output=yaml" + env: + - name: DATA_OBJECT_MANIFEST + value: $(params.manifest) + - name: DATA_OBJECT_NAMESPACE + value: $(params.namespace) + - name: WAIT_FOR_SUCCESS + value: $(params.waitForSuccess) + - name: ALLOW_REPLACE + value: $(params.allowReplace) + - name: DELETE_OBJECT + value: $(params.deleteObject) + - name: DELETE_OBJECT_KIND + value: $(params.deleteObjectKind) + - name: DELETE_OBJECT_NAME + value: $(params.deleteObjectName) + - name: SET_OWNER_REFERENCE + value: $(params.setOwnerReference) + - name: TIMEOUT + value: $(params.timeout) + - name: POD_NAMESPACE + valueFrom: + fieldRef: + fieldPath: metadata.namespace + - name: POD_NAME + valueFrom: + fieldRef: + fieldPath: metadata.name diff --git a/tasks/modify-vm-template/4.16.4/README.md b/tasks/modify-vm-template/4.16.4/README.md new file mode 100644 index 00000000..0351c6a3 --- /dev/null +++ b/tasks/modify-vm-template/4.16.4/README.md @@ -0,0 +1,110 @@ +# Modify OpenShift template Task + +#### Task is deprecated and will be removed in future versions. + +This task modifies template. +A bundle of predefined templates to use can be found in [Common Templates](https://github.com/kubevirt/common-templates) project. + +### Service Account + +This task should be run with serviceAccount. +Please see [RBAC permissions for running the tasks](../../docs/tasks-rbac-permissions.md) for more details. + +### Parameters + +- **templateName**: Name of an OpenShift template. +- **templateNamespace**: Namespace of an source OpenShift template. (defaults to active namespace) +- **cpuSockets**: Number of CPU sockets +- **cpuCores**: Number of CPU cores +- **cpuThreads**: Number of CPU threads +- **memory**: Number of memory vm can use +- **templateLabels**: Template labels. If template contains same label, it will be replaced. Each param should have KEY:VAL format. Eg [`key:value`, `key:value`]. +- **templateAnnotations**: Template Annotations. If template contains same annotation, it will be replaced. Each param should have KEY:VAL format. Eg [`key:value`, `key:value`] +- **vmLabels**: VM labels. If VM contains same label, it will be replaced. Each param should have KEY:VAL format. Eg [`key:value`, `key:value`]. +- **vmAnnotations**: VM annotations. If VM contains same annotation, it will be replaced. Each param should have KEY:VAL format. Eg [`key:value`, `key:value`]. +- **disks**: VM disks in json format, replace vm disk if same name, otherwise new disk is appended. Eg [{`name`: `test`, `cdrom`: {`bus`: `sata`}}, {`name`: `disk2`}] +- **deleteDisks**: Set to `true` or `false` if task should delete VM disks. New disks (from disks parameter) are applied, after old disks are deleted. +- **volumes**: VM volumes in json format, replace vm volume if same name, otherwise new volume is appended. Eg [{`name`: `virtiocontainerdisk`, `containerDisk`: {`image`: `kubevirt/virtio-container-disk`}}] +- **datavolumeTemplates**: Datavolume templates in json format, replace datavolume if same name, otherwise new datavolume is appended. If deleteDatavolumeTemplate is set, first datavolumes are deleted and then datavolumes from this attribute are added. Eg [{`apiVersion`: `cdi.kubevirt.io/v1beta1`, `kind`: `DataVolume`, `metadata`:{`name`: `test1`}, `spec`: {`source`: {`http`: {`url`: `test.somenonexisting`}}}}] +- **deleteDatavolumeTemplate**: Set to `true` or `false` if task should delete datavolume template in template and all associated volumes and disks. +- **deleteVolumes**: Set to `true` or `false` if task should delete VM volumes. New volumes (from volumes parameter) are applied, after old volumes are deleted. +- **templateParameters**: Definition of template parameters. Eg [{`description`: `VM name`, `name`: `NAME`}] +- **deleteTemplateParameters**: Set to `true` or `false` if task should delete template parameters. New parameters (from templateParameters parameter) are applied, after old parameters are deleted. +- **deleteTemplate**: Set to `true` or `false` if task should delete the specified template. If set to 'true' the template will be deleted and all other parameters are ignored. + +### Results + +- **name**: The name of a template that was updated. +- **namespace**: The namespace of a template that was updated. + +### Usage + +Task run using resolver: +``` +apiVersion: tekton.dev/v1 +kind: TaskRun +metadata: + generateName: modify-vm-template-taskrun-resolver- +spec: + params: + - name: templateName + value: vm-template-example + - name: memory + value: 2G + taskRef: + params: + - name: catalog + value: kubevirt-tekton-tasks + - name: type + value: artifact + - name: kind + value: task + - name: name + value: modify-vm-template + - name: version + value: v4.16.4 + resolver: hub +``` + +### Usage in different namespaces + +You can use task to do actions in different namespace. To do that, tasks requires special permissions. Apply these RBAC objects and permissions and update accordingly task run object with correct serviceAccount: + +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: modify-vm-template-task +rules: +- apiGroups: + - template.openshift.io + resources: + - templates + verbs: + - get + - list + - patch + - delete +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: modify-vm-template-task +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: modify-vm-template-task +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: modify-vm-template-task +subjects: +- kind: ServiceAccount + name: modify-vm-template-task +--- +``` + +### Platforms + +The Task can be run on linux/amd64 platform. diff --git a/tasks/modify-vm-template/4.16.4/modify-vm-template.yaml b/tasks/modify-vm-template/4.16.4/modify-vm-template.yaml new file mode 100644 index 00000000..22b60097 --- /dev/null +++ b/tasks/modify-vm-template/4.16.4/modify-vm-template.yaml @@ -0,0 +1,155 @@ +--- +apiVersion: tekton.dev/v1 +kind: Task +metadata: + annotations: + tekton.dev/source: "https://github.com/openshift-virtualization/openshift-virtualization-pipelines-tasks" + tekton.dev/deprecated: "true" + tekton.dev/pipelines.minVersion: "0.43.0" + tekton.dev/categories: Automation + tekton.dev/tags: kubevirt + tekton.dev/displayName: "OpenShift Virtualization modify VM template" + tekton.dev/platforms: "linux/amd64" + artifacthub.io/maintainers: | + - name: KubeVirt Tekton tasks maintainers + email: kubevirt-tekton-tasks@redhat.com + artifacthub.io/provider: Red Hat + artifacthub.io/recommendations: | + - url: https://kubevirt.io/ + artifacthub.io/category: integration-delivery + labels: + app.kubernetes.io/version: v4.16.4 + name: modify-vm-template +spec: + description: >- + Automates the modifying of OpenShift template with KubeVirt virtual machine. + This task is working only with https://github.com/kubevirt/common-templates. + Other templates will not work. + params: + - name: templateName + description: Name of an OpenShift template. + type: string + - name: templateNamespace + description: Namespace of an source OpenShift template. (defaults to active namespace) + type: string + default: "" + - name: cpuSockets + description: Number of CPU sockets + type: string + default: "0" + - name: cpuCores + description: Number of CPU cores + type: string + default: "0" + - name: cpuThreads + description: Number of CPU threads + type: string + default: "0" + - name: memory + description: Number of memory vm can use + type: string + default: "" + - description: Template labels. If template contains same label, it will be replaced. Each param should have KEY:VAL format. Eg ["key:value", "key:value"]. + name: templateLabels + type: array + default: [] + - description: Template Annotations. If template contains same annotation, it will be replaced. Each param should have KEY:VAL format. Eg ["key:value", "key:value"] + name: templateAnnotations + type: array + default: [] + - description: VM labels. If VM contains same label, it will be replaced. Each param should have KEY:VAL format. Eg ["key:value", "key:value"]. + name: vmLabels + type: array + default: [] + - description: VM annotations. If VM contains same annotation, it will be replaced. Each param should have KEY:VAL format. Eg ["key:value", "key:value"]. + name: vmAnnotations + type: array + default: [] + - description: 'VM disks in json format, replace vm disk if same name, otherwise new disk is appended. Eg [{"name": "test", "cdrom": {"bus": "sata"}}, {"name": "disk2"}]' + name: disks + type: array + default: [] + - name: deleteDisks + description: Set to "true" or "false" if task should delete VM disks. New disks (from disks parameter) are applied, after old disks are deleted. + default: 'false' + type: string + - description: 'VM volumes in json format, replace vm volume if same name, otherwise new volume is appended. Eg [{"name": "virtiocontainerdisk", "containerDisk": {"image": "kubevirt/virtio-container-disk"}}]' + name: volumes + type: array + default: [] + - description: 'Datavolume templates in json format, replace datavolume if same name, otherwise new datavolume is appended. If deleteDatavolumeTemplate is set, first datavolumes are deleted and then datavolumes from this attribute are added. Eg [{"apiVersion": "cdi.kubevirt.io/v1beta1", "kind": "DataVolume", "metadata":{"name": "test1"}, "spec": {"source": {"http": {"url": "test.somenonexisting"}}}}]' + name: datavolumeTemplates + type: array + default: [] + - name: deleteDatavolumeTemplate + description: Set to "true" or "false" if task should delete datavolume template in template and all associated volumes and disks. + default: 'false' + type: string + - name: deleteVolumes + description: Set to "true" or "false" if task should delete VM volumes. New volumes (from volumes parameter) are applied, after old volumes are deleted. + default: 'false' + type: string + - name: templateParameters + description: 'Definition of template parameters. Eg [{"description": "VM name", "name": "NAME"}]' + default: [] + type: array + - name: deleteTemplateParameters + description: Set to "true" or "false" if task should delete template parameters. New parameters (from templateParameters parameter) are applied, after old parameters are deleted. + default: 'false' + type: string + - name: deleteTemplate + description: Set to `true` or `false` if task should delete the specified template. If set to 'true' the template will be deleted and all other parameters are ignored. + default: 'false' + type: string + + results: + - name: name + description: The name of a template that was updated. + - name: namespace + description: The namespace of a template that was updated. + steps: + - name: modifyvmtemplate + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-create-datavolume-rhel9:v4.16.4" + command: + - modify-vm-template + args: + - "--output=yaml" + - "--template-labels" + - $(params.templateLabels) + - "--template-annotations" + - $(params.templateAnnotations) + - "--vm-labels" + - $(params.vmLabels) + - "--vm-annotations" + - $(params.vmAnnotations) + - "--disks" + - $(params.disks) + - "--volumes" + - $(params.volumes) + - "--datavolumeTemplates" + - $(params.datavolumeTemplates) + - "--templateParameters" + - $(params.templateParameters) + env: + - name: TEMPLATE_NAME + value: $(params.templateName) + - name: TEMPLATE_NAMESPACE + value: $(params.templateNamespace) + - name: CPU_SOCKETS + value: $(params.cpuSockets) + - name: CPU_CORES + value: $(params.cpuCores) + - name: CPU_THREADS + value: $(params.cpuThreads) + - name: MEMORY + value: $(params.memory) + - name: DELETE_DATAVOLUME_TEMPLATE + value: $(params.deleteDatavolumeTemplate) + - name: DELETE_DISKS + value: $(params.deleteDisks) + - name: DELETE_VOLUMES + value: $(params.deleteVolumes) + - name: DELETE_TEMPLATE_PARAMETERS + value: $(params.deleteTemplateParameters) + - name: DELETE_TEMPLATE + value: $(params.deleteTemplate) diff --git a/tasks/modify-windows-iso-file/4.16.4/README.md b/tasks/modify-windows-iso-file/4.16.4/README.md new file mode 100644 index 00000000..ffe6c6d6 --- /dev/null +++ b/tasks/modify-windows-iso-file/4.16.4/README.md @@ -0,0 +1,41 @@ +# Modify Windows ISO file + +This tasks is modifying windows iso file. It replaces prompt bootloader with non prompt one. This helps with automation of +windows which requires EFI - the prompt bootloader will not continue with installation until some key is pressed. The non prompt +bootloader will not require any key pres. + +### Parameters + +- **pvcName**: PersistentVolumeClaim which contains windows iso. + + +### Usage + +Task run using resolver: +``` +apiVersion: tekton.dev/v1 +kind: TaskRun +metadata: + generateName: modify-windows-iso-file-taskrun-resolver- +spec: + params: + - name: pvcName + value: w11 + taskRef: + params: + - name: catalog + value: kubevirt-tekton-tasks + - name: type + value: artifact + - name: kind + value: task + - name: name + value: modify-windows-iso-file + - name: version + value: v4.16.4 + resolver: hub +``` + +### Platforms + +The Task can be run on linux/amd64 platform. diff --git a/tasks/modify-windows-iso-file/4.16.4/modify-windows-iso-file.yaml b/tasks/modify-windows-iso-file/4.16.4/modify-windows-iso-file.yaml new file mode 100644 index 00000000..5528c7c1 --- /dev/null +++ b/tasks/modify-windows-iso-file/4.16.4/modify-windows-iso-file.yaml @@ -0,0 +1,141 @@ +--- +apiVersion: tekton.dev/v1 +kind: Task +metadata: + annotations: + tekton.dev/source: "https://github.com/openshift-virtualization/openshift-virtualization-pipelines-tasks" + tekton.dev/pipelines.minVersion: "0.43.0" + tekton.dev/categories: Automation + tekton.dev/tags: kubevirt + tekton.dev/displayName: "OpenShift Virtualization modify Windows iso" + tekton.dev/platforms: "linux/amd64" + artifacthub.io/maintainers: | + - name: KubeVirt Tekton tasks maintainers + email: kubevirt-tekton-tasks@redhat.com + artifacthub.io/provider: Red Hat + artifacthub.io/recommendations: | + - url: https://kubevirt.io/ + artifacthub.io/category: integration-delivery + labels: + app.kubernetes.io/version: v4.16.4 + name: modify-windows-iso-file +spec: + description: >- + This tasks is modifying windows iso file. It replaces prompt + bootloader with non prompt one. This helps with automation of + windows installation which requires EFI - the prompt bootloader will not + continue with installation until some key is pressed. The non prompt + bootloader will not require any key press. This task is used in + combination with KubeVirt. It is part of windows-efi-installer pipeline + https://github.com/kubevirt/kubevirt-tekton-tasks/tree/main/release/pipelines/windows-efi-installer. + params: + - name: pvcName + description: PersistentVolumeClaim which contains windows iso. + type: string + default: "" + steps: + - name: modify-iso-file + securityContext: + allowPrivilegeEscalation: false + capabilities: + drop: + - "ALL" + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-disk-virt-customize-rhel9:v4.16.4" + script: | + #!/bin/bash + set -x + + export LIBGUESTFS_PATH=/usr/local/lib/guestfs/appliance + export ISO_FILES_PATH="/tmp/extracted-iso-files" + export EFI_BOOT="${ISO_FILES_PATH}/efi/microsoft/boot" + export TARGET_IMG_FILE_PATH="tmp/target-pvc/disk.img" + + guestfish -a ${TARGET_IMG_FILE_PATH} -m /dev/sda tar-out / - | tar xvf - -C ${ISO_FILES_PATH} -m --no-overwrite-dir --owner=$(id -u) --group=$(id -g) --no-same-permissions + + echo "ISO file checksum:" $(sha256sum ${TARGET_IMG_FILE_PATH}) + ls -la ${TARGET_IMG_FILE_PATH} + + if [ ! -f ${EFI_BOOT}/efisys_noprompt.bin ] || [ ! -f ${EFI_BOOT}/cdboot_noprompt.efi ]; then + echo "${EFI_BOOT}/efisys_noprompt.bin or ${EFI_BOOT}/cdboot_noprompt.efi not found in the iso file! Task expects that ISO file contains bootloader without prompt. If the no prompt bootloader is not present, the installation might behave unexpectedly. Exiting" + exit 1 + fi + + chmod u+w "${ISO_FILES_PATH}/efi" "${ISO_FILES_PATH}/efi/microsoft" "${ISO_FILES_PATH}/efi/microsoft/boot" + chmod u+w "${EFI_BOOT}/efisys.bin" "${EFI_BOOT}/cdboot.efi" "${EFI_BOOT}/efisys_noprompt.bin" "${EFI_BOOT}/cdboot_noprompt.efi" + + rm "${EFI_BOOT}/efisys.bin" "${EFI_BOOT}/cdboot.efi" + + mv "${EFI_BOOT}/efisys_noprompt.bin" "${EFI_BOOT}/efisys.bin" + mv "${EFI_BOOT}/cdboot_noprompt.efi" "${EFI_BOOT}/cdboot.efi" + env: + - name: "LIBGUESTFS_BACKEND" + value: "direct" + - name: "HOME" + value: "/usr/local/lib/guestfs/appliance" + computeResources: + limits: + devices.kubevirt.io/kvm: '1' + requests: + devices.kubevirt.io/kvm: '1' + volumeMounts: + - mountPath: /tmp/target-pvc/ + name: target-pvc + - mountPath: /tmp/extracted-iso-files/ + name: extracted-iso-files + - name: create-iso-file + securityContext: + allowPrivilegeEscalation: false + capabilities: + drop: + - "ALL" + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-create-datavolume-rhel9:v4.16.4" + script: | + #!/bin/bash + set -ex + export ISO_FILES_PATH="/tmp/extracted-iso-files" + export ISO_FILE_PATH="/tmp/iso-file/disk.iso" + + xorriso -as mkisofs -no-emul-boot \ + -e "efi/microsoft/boot/efisys.bin" \ + -boot-load-size 1 \ + -iso-level 4 \ + -J -l -D -N \ + -joliet-long \ + -relaxed-filenames \ + -V "WINDOWS" \ + -o ${ISO_FILE_PATH} ${ISO_FILES_PATH} + volumeMounts: + - mountPath: /tmp/extracted-iso-files/ + name: extracted-iso-files + - mountPath: /tmp/iso-file/ + name: iso-file + - name: convert-iso-file + securityContext: + allowPrivilegeEscalation: false + capabilities: + drop: + - "ALL" + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-disk-virt-customize-rhel9:v4.16.4" + script: | + #!/bin/bash + set -x + export ISO_FILE_PATH="/tmp/iso-file/disk.iso" + export TARGET_IMG_FILE_PATH="/tmp/target-pvc/disk.img" + + rm ${TARGET_IMG_FILE_PATH} + qemu-img convert -t writeback -p -O raw ${ISO_FILE_PATH} ${TARGET_IMG_FILE_PATH} + volumeMounts: + - mountPath: /tmp/target-pvc/ + name: target-pvc + - mountPath: /tmp/iso-file/ + name: iso-file + volumes: + - name: target-pvc + persistentVolumeClaim: + claimName: "$(params.pvcName)" + - name: extracted-iso-files + emptyDir: + sizeLimit: 12Gi + - name: iso-file + emptyDir: + sizeLimit: 12Gi diff --git a/tasks/wait-for-vmi-status/4.16.4/README.md b/tasks/wait-for-vmi-status/4.16.4/README.md new file mode 100644 index 00000000..3359f512 --- /dev/null +++ b/tasks/wait-for-vmi-status/4.16.4/README.md @@ -0,0 +1,83 @@ +# Wait For a VirtualMachineInstance Status Task + +This task waits for a specific status of a VirtualMachineInstance (VMI) and fails/succeeds accordingly. + +### Parameters + +- **vmiName**: Name of a VirtualMachineInstance to wait for. +- **vmiNamespace**: Namespace of a VirtualMachineInstance to wait for. (defaults to manifest namespace or active namespace) +- **successCondition**: A label selector expression to decide if the VirtualMachineInstance (VMI) is in a success state. Eg. `status.phase == Succeeded`. It is evaluated on each VMI update and will result in this task succeeding if true. It uses kubernetes label selection syntax and can be applied against any field of the resource (not just labels). Multiple AND conditions can be represented by comma delimited expressions. For more details, see: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/. +- **failureCondition**: A label selector expression to decide if the VirtualMachineInstance (VMI) is in a failed state. Eg. `status.phase in (Failed, Unknown)`. It is evaluated on each VMI update and will result in this task failing if true. It uses kubernetes label selection syntax and can be applied against any field of the resource (not just labels). Multiple AND conditions can be represented by comma delimited expressions. For more details, see: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/. + +### Usage + +Task run using resolver: +``` +apiVersion: tekton.dev/v1 +kind: TaskRun +metadata: + generateName: wait-for-vmi-status-taskrun-resolver- +spec: + params: + - name: vmiName + value: example-vm + - name: successCondition + value: status.phase == Succeeded + - name: failureCondition + value: status.phase in (Failed, Unknown) + taskRef: + params: + - name: catalog + value: kubevirt-tekton-tasks + - name: type + value: artifact + - name: kind + value: task + - name: name + value: wait-for-vmi-status + - name: version + value: v4.16.4 + resolver: hub +``` + +### Usage in different namespaces + +You can use task to do actions in different namespace. To do that, tasks requires special permissions. Apply these RBAC objects and permissions and update accordingly task run object with correct serviceAccount: + +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: wait-for-vmi-status-task +rules: +- apiGroups: + - kubevirt.io + resources: + - virtualmachineinstances + verbs: + - get + - list + - watch +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: wait-for-vmi-status-task +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: wait-for-vmi-status-task +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: wait-for-vmi-status-task +subjects: +- kind: ServiceAccount + name: wait-for-vmi-status-task +--- +``` + +### Platforms + +The Task can be run on linux/amd64 platform. diff --git a/tasks/wait-for-vmi-status/4.16.4/wait-for-vmi-status.yaml b/tasks/wait-for-vmi-status/4.16.4/wait-for-vmi-status.yaml new file mode 100644 index 00000000..20251c60 --- /dev/null +++ b/tasks/wait-for-vmi-status/4.16.4/wait-for-vmi-status.yaml @@ -0,0 +1,56 @@ +--- +apiVersion: tekton.dev/v1 +kind: Task +metadata: + annotations: + tekton.dev/source: "https://github.com/openshift-virtualization/openshift-virtualization-pipelines-tasks" + tekton.dev/pipelines.minVersion: "0.43.0" + tekton.dev/categories: Automation + tekton.dev/tags: kubevirt + tekton.dev/displayName: "OpenShift Virtualization wait for VMI status" + tekton.dev/platforms: "linux/amd64" + artifacthub.io/maintainers: | + - name: KubeVirt Tekton tasks maintainers + email: kubevirt-tekton-tasks@redhat.com + artifacthub.io/provider: Red Hat + artifacthub.io/recommendations: | + - url: https://kubevirt.io/ + artifacthub.io/category: integration-delivery + labels: + app.kubernetes.io/version: v4.16.4 + name: wait-for-vmi-status +spec: + description: >- + This tasks waits until KubeVirt virtual machine is in some + state. It can be used in pipeline where user needs to wait until e.g. + VM finish some installation. + params: + - name: vmiName + description: Name of a VirtualMachineInstance to wait for. + type: string + - name: vmiNamespace + description: Namespace of a VirtualMachineInstance to wait for. (defaults to manifest namespace or active namespace) + default: "" + type: string + - name: successCondition + default: "" + description: A label selector expression to decide if the VirtualMachineInstance (VMI) is in a success state. Eg. "status.phase == Succeeded". It is evaluated on each VMI update and will result in this task succeeding if true. + - name: failureCondition + default: "" + description: A label selector expression to decide if the VirtualMachineInstance (VMI) is in a failed state. Eg. "status.phase in (Failed, Unknown)". It is evaluated on each VMI update and will result in this task failing if true. + steps: + - name: wait-for-vmi-status + image: "registry.redhat.io/container-native-virtualization/kubevirt-tekton-tasks-create-datavolume-rhel9:v4.16.4" + command: + - entrypoint + env: + - name: COMMAND + value: wait-for-vmi-status + - name: VMI_NAME + value: $(params.vmiName) + - name: VMI_NAMESPACE + value: $(params.vmiNamespace) + - name: SUCCESS_CONDITION + value: $(params.successCondition) + - name: FAILURE_CONDITION + value: $(params.failureCondition)