Follow the steps below to change the snapshot interval by patching the ForkliftController custom resource (CR).
Procedure
$ kubectl patch forkliftcontroller/<forklift-controller> -n konveyor-forklift -p '{"spec": {"controller_precopy_interval": <60>}}' --type=merge (1)
Note: The Creating custom rules for the Validation service section below refers to the callout in the sample code above.
Note: The forklift-controller pod does not need to be restarted.
The Validation service uses Open Policy Agent (OPA) rules to check the suitability of each virtual machine (VM) for migration. The Validation service generates a list of concerns for each VM, which are stored in the Provider Inventory service as VM attributes. The web console displays the concerns for each VM in the provider inventory.
Custom rules to extend the default ruleset of the Validation service can be created. For example, creating a rule that checks whether a VM has multiple disks.
Validation rules are written in Rego, the Open Policy Agent (OPA) native query language. The rules are stored as .rego files in the /usr/share/opa/policies/io/konveyor/forklift/ directory of the Validation pod.
Each validation rule is defined in a separate .rego file and tests for a specific condition. If the condition is true, the rule adds a {“category”, “label”, “assessment”} hash to the concerns. The concerns content is added to the concerns key in the inventory record of the VM. The web console displays the content of the concerns key for each VM in the provider inventory.
The following .rego file example checks if distributed resource scheduling is enabled in the cluster of a VMware VM. Below is a drs_enabled.rego example:
package io.konveyor.forklift.vmware (1)
has_drs_enabled {
input.host.cluster.drsEnabled (2)
}
concerns[flag] {
has_drs_enabled
flag := {
"category": "Information",
"label": "VM running in a DRS-enabled cluster",
"assessment": "Distributed resource scheduling is not currently supported by OpenShift Virtualization. The VM can be migrated but it will not have this feature in the target environment."
}
}
The explanations below refer to the callouts in the sample code above.
Before creating a custom rule, follow the steps below to check the default rules of the Validation service to prevent creating a rule that redefines an existing default value.
Example: If a default rule contains the line default valid_input = false and a custom rule that contains the line default valid_input = true is created, the Validation service will not start.
Procedure
$ kubectl rsh <validation_pod>
$ cd /usr/share/opa/policies/io/konveyor/forklift/<provider> (1)
The explanation below refers to the callouts in the sample code above.
$ grep -R "default" *
Follow the steps below to retrieve the Inventory service JSON by sending an Inventory service query to a virtual machine (VM). The output contains an “input” key, which contains the inventory attributes that are queried by the Validation service rules.
Create a validation rule based on any attribute in the “input” key, for example, input.snapshot.kind.
Procedure
$ kubectl get route <inventory_service> -n konveyor-forklift
$ GET https://<inventory_service_route>/providers/<provider> (1)
The explanation below refers to the callouts in the sample code above.
$ GET https://<inventory_service_route>/providers/<provider>/<UUID>/vms
$ GET https://<inventory_service_route>/providers/<provider>/<UUID>/workloads/<vm>
Example output:
{
"input": {
"selfLink": "providers/vsphere/c872d364-d62b-46f0-bd42-16799f40324e/workloads/vm-431",
"id": "vm-431",
"parent": {
"kind": "Folder",
"id": "group-v22"
},
"revision": 1,
"name": "iscsi-target",
"revisionValidated": 1,
"isTemplate": false,
"networks": [
{
"kind": "Network",
"id": "network-31"
},
{
"kind": "Network",
"id": "network-33"
}
Follow the instructions below to create a validation rule by applying a config map custom resource (CR) containing the rule to the Validation service.
If the rule has the same name as an existing rule, the Validation service performs an OR operation with the rules.
If the rule contradicts a default rule, the Validation service will not start.
Validation rules are based on virtual machine (VM) attributes collected by the Provider Inventory service.
For example, the VMware API uses this path to check whether a VMware VM has NUMA node affinity configured: MOR:VirtualMachine.config.extraConfig [“numa.nodeAffinity”].
The Provider Inventory service simplifies this configuration and returns a testable attribute with a list value:
"numaNodeAffinity": [
"0",
"1"
],
Create a Rego query, based on this attribute, and add it to the forklift-validation-config config map:
`count(input.numaNodeAffinity) != 0`
Procedure
$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
name: <forklift-validation-config>
namespace: konveyor-forklift
data:
vmware_multiple_disks.rego: |-
package <provider_package> (1)
has_multiple_disks { (2)
count(input.disks) > 1
}
concerns[flag] {
has_multiple_disks (3)
flag := {
"category": "<Information>", (4)
"label": "Multiple disks detected",
"assessment": "Multiple disks detected on this VM."
}
}
EOF
The explanations below refer to the callouts in the sample code above.
$ kubectl scale -n konveyor-forklift --replicas=0 deployment/forklift-controller
$ kubectl scale -n konveyor-forklift --replicas=1 deployment/forklift-controller
$ kubectl logs -f <validation_pod>
Note: If the custom rule conflicts with a default rule, the Validation pod will not start.
$ kubectl delete provider <provider> -n konveyor-forklift
$ cat << EOF | kubectl apply -f -
apiVersion: forklift.konveyor.io/v1beta1
kind: Provider
metadata:
name: <provider>
namespace: konveyor-forklift
spec:
type: <provider_type> (1)
url: <api_end_point> (2)
secret:
name: <secret> (3)
namespace: konveyor-forklift
EOF
The explanations below refer to the callouts in the sample code above.
Important: Update the rules version after creating a custom rule so that the Inventory service detects the changes and validates the VMs.
Follow the steps below to update the inventory rules version each time the rules are updated so that the Provider Inventory service detects the changes and triggers the Validation service.
The rules version is recorded in a rules_version.rego file for each provider.
Procedure
$ GET https://forklift-validation/v1/data/io/konveyor/forklift/<provider>/rules_version (1)
Example output:
{
"result": {
"rules_version": 5
}
}
$ kubectl rsh <validation_pod>
Update the rules version in the /usr/share/opa/policies/io/konveyor/forklift//rules_version.rego file.
Log out of the Validation pod terminal.
Verify the updated rules version:
$ GET https://forklift-validation/v1/data/io/konveyor/forklift/<provider>/rules_version (1)
Example output
{
"result": {
"rules_version": 6
}
}