Merge pull request #5 from acend/philipona/first-iteration

Add Feedback Lab4

content/en/docs/04/41_types-introduction.md

@@ -9,13 +9,13 @@ description: >
 
 Even if KubeVirt provides advanced options and a lot of configuration options for different VMs we usually have a common
 set of VM specifications which we will use for most of our VMs. Therefore, it may make sense of defining such
-specifications as Instancetypes and or Preferences.
+specifications as Instancetypes and / or Preferences.
 
 To achieve this, KubeVirt provides multiple Custom Resource
 Definitions like `VirtualMachineInstancetype`, `VirtualMachineClusterInstancetype` or `VirtualMachinePreference`.
 
 
-## VM Instancetype
+## VM VirtualMachineInstancetype
 
 For an Instancetype we have the option of using the cluster wide `VirtualMachineClusterInstancetype` or the namespaced
 `VirtualMachineInstancetype`.
@@ -30,7 +30,7 @@ With Instancetypes we can define the following resource related characteristics:
 * **LaunchSecurity** - Optional LaunchSecurity to be used
 
 {{% alert title="Important" color="warning" %}}
-Any provided Instancetype characteristic cannot be overridden from within the VirtualMachine. Be aware that `CPU` and
+Any provided Instancetype characteristic can not be overridden from within the VirtualMachine. Be aware that `CPU` and
 `Memory` both are required for an Instancetype. Therefore, any different request of `CPU` or `Memory` on a VirtualMachine
 will conflict and the request will be rejected.
 {{% /alert %}}
@@ -39,7 +39,7 @@ will conflict and the request will be rejected.
 ## VM Preference
 
 KubeVirt also provides a CRD `VirtualMachineClusterPreference` for cluster wide preferences as well as a namespaced
-version `VirtualMachinePreference`. A preference specification encapsulates every value of the remaining attribues of a VirtualMachine.
+version `VirtualMachinePreference`. A preference specification encapsulates every value of the remaining attributes of a VirtualMachine.
 
 {{% alert title="Note" color="info" %}}
 Not like the characteristics from an Instancetype the preferences only defined the preferred values. They can be overridden

content/en/docs/04/42_common-instancetypes.md

@@ -4,20 +4,23 @@ weight: 420
 labfoldernumber: "04"
 sectionnumber: 4.2
 description: >
-  Discover and user Common Instancetypes and Preferences provided by KubeVirt.
+  Discover and use common Instancetypes and Preferences provided by KubeVirt.
 ---
 
-The KubeVirt project [Common Instancetypes and Preferences](https://github.com/kubevirt/common-instancetypes) provides a set of instancetypes and preferences.
+The KubeVirt project [Common Instancetypes and Preferences](https://github.com/kubevirt/common-instancetypes) provides a set of Instancetypes and Preferences.
 
 
 ## Deployment of Common Instancetypes and Preferences
 
-The common instancetypes and preferences are not available by default. They have to be deployed manually or using a
-feature gate of the KubeVirt operator.
+The common Instancetypes and Preferences are not available by default. They have to be deployed manually or using a feature gate of the KubeVirt operator.
 
 You can check the configuration on the KubeVirt CustomResource:
 ```shell
-kubectl get kubevirt kubevirt -n kubevirt -o jsonpath={.spec.configuration.developerConfiguration.featureGates}
+kubectl get kubevirt kubevirt --namespace=kubevirt -o jsonpath={.spec.configuration.developerConfiguration.featureGates}
+```
+or
+```shell
+kubectl get kubevirt kubevirt --namespace=kubevirt -o yaml
 ```
 
 The relevant section on the CustomResource is the following:
@@ -34,16 +37,13 @@ spec:
 [...]
 ```
 
-With the feature gate enabled, the operator itself takes care of deploying the cluster wide common instance types and preferences.
+With the feature gate enabled, the operator itself takes care of deploying the cluster wide common Instancetypes and Preferences.
 
 
 ### Manually deploy the Common Instancetypes and Preferences
 
-If you want to deploy the instance types and preferences manually, simply apply them using the kustomize flag `-k`:
-
-```shell
-kubectl apply -k https://github.com/kubevirt/common-instancetypes.git
-```
+This step has been done for your on the Lab cluster.
+How to deploy the Common Instancetypes and Preferences on your own cluster can be found in the [documentation](https://kubevirt.io/user-guide/user_workloads/deploy_common_instancetypes/).
 
 
 ## List and inspect Instancetypes
@@ -160,7 +160,7 @@ centos.7                 10m
 
 You may see the details of a preference by describing the resource:
 ```shell
-kubectl describe virtualmachineclusterpreference windows.10
+kubectl describe virtualmachineclusterpreference cirros
 ```
 
 As an example you'll see that the instancetype `cirros` has the requirements of 1 CPU, 256Mi memory. The following output is shortened:
@@ -333,8 +333,8 @@ Deploy two VMs with different instance types:
 * Deploy a cirros VM using an `o` class instancetype and the same preference.
   * rite the VM specification in `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros.yaml`
 
-{{% details title="Task Hint" %}}
-`vm_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros.yaml` specification:
+{{% details title="Task Hint: Solution" %}}
+`{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vm_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros.yaml` specification:
 ```yaml
 apiVersion: kubevirt.io/v1
 kind: VirtualMachine
@@ -374,7 +374,7 @@ spec:
             userDataBase64: SGkuXG4=
 ```
 
-`vm_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros.yaml` specification:
+`{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vm_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros.yaml` specification:
 ```yaml
 apiVersion: kubevirt.io/v1
 kind: VirtualMachine
@@ -416,8 +416,8 @@ spec:
 
 Apply and start both VMs with
 ```shell
-kubectl apply -f vm_lab04-u1-cirros.yaml
-kubectl apply -f vm_lab04-o1-cirros.yaml
+kubectl apply -f {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vm_lab04-u1-cirros.yaml --namespace=$USER
+kubectl apply -f {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vm_lab04-o1-cirros.yaml --namespace=$USER
 virtctl start lab04-u1-cirros
 virtctl start lab04-o1-cirros
 ```
@@ -445,8 +445,8 @@ and `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros
 {{% details title="Task Hint" %}}
 Describe both VirtualMachine instances using:
 ```shell
-kubectl describe vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros -o yaml
-kubectl describe vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros -o yaml
+kubectl get vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros -o yaml --namespace=$USER
+kubectl get vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros -o yaml --namespace=$USER
 ```
 
 The `lab04-u1-cirros` instance:

content/en/docs/04/43_create-instancetype.md

@@ -15,7 +15,7 @@ In this section we will create and use our own instance type.
 In the previous section we have seen that the Cirros preference requests 256Mi of memory. However, the smallest Instancetype
 available requested 512Mi of memory. Let's create our own Instancetype and assign it to our VirtualMachines.
 
-Create a file `vmf_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico.yaml` and start with the
+Create a file `vmf_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico.yaml` under `{{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}` and start with the
 definition of the `o1.nano` instancetype.
 
 Define the Instancetype:
@@ -56,20 +56,26 @@ spec:
 
 Create your resource with:
 ```shell
-kubectl create -f vmf_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico.yaml
+kubectl create -f {{% param "labsfoldername" %}}/{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}/vmf_{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico.yaml --namespace=$USER
+```
+
+And verify whether the creation was successful:
+
+```shell
+kubectl get vmf {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-pico --namespace=$USER
 ```
 
 
 ## {{% task %}} Create your own Instancetype with virtctl
 
 The `virtctl` tool is also capable of creating Instancetypes. You can define and create a similar Instancetype `u1.pico` with:
 ```shell
-virtctl create instancetype --namespaced --cpu 1 --memory 256Mi --name {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-pico | kubectl create -f -
+virtctl create instancetype --namespaced --cpu 1 --memory 256Mi --name {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-pico --namespace=$USER | kubectl create --namespace=$USER -f -
 ```
 
 Show the created Instancetype with
 ```shell
-kubectl get vmf {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-pico -o yaml
+kubectl get vmf {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-pico -o yaml --namespace=$USER
 ```
 
 The output will be similar to this one:

content/en/docs/04/44_reassign-instancetype.md

@@ -29,7 +29,7 @@ spec:
 
 Use the following command to list all available `controllerrevision`:
 ```shell
-kubectl get controllerrevision
+kubectl get controllerrevision --namespace=$USER
 ```
 
 ```
@@ -43,12 +43,12 @@ If we want to explicitly change the Instancetype or preference we have to remove
 
 The easies way is to edit the resource directly is:
 ```shell
-kubectl edit vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros
+kubectl edit vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros --namespace=$USER
 ```
 
 An alternative would be patching the resource directly with:
 ```shell
-kubectl patch vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros --type merge --patch '{"spec":{"instancetype":{"kind":"<KIND>","name":"<NAME>","revisionName":null}}}'
+kubectl patch vm {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros --type merge --patch '{"spec":{"instancetype":{"kind":"<KIND>","name":"<NAME>","revisionName":null}}}' --namespace=$USER
 ```
 
 
@@ -77,14 +77,14 @@ spec:
 
 Make sure you restart both VMs to reflect the change of their instancetype:
 ```shell
-virtctl restart {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros
-virtctl restart {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros
+virtctl restart {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros --namespace=$USER
+virtctl restart {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros --namespace=$USER
 ```
 
 Describe both VirtualMachine instances and observe the effect:
 ```shell
-kubectl describe vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros -o yaml
-kubectl describe vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros -o yaml
+kubectl get vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros -o yaml --namespace=$USER
+kubectl get vmi {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros -o yaml --namespace=$USER
 ```
 
 The `{{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros` instance:
@@ -126,7 +126,7 @@ spec:
 
 Stop your running VM with
 ```shell
-virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros
-virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros
+virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-u1-cirros --namespace=$USER
+virtctl stop {{% param "labsubfolderprefix" %}}{{% param "labfoldernumber" %}}-o1-cirros --namespace=$USER
 ```
 {{% /alert %}}

content/en/docs/04/_index.md

@@ -14,7 +14,7 @@ runtime characteristics like resources or performance settings which can then be
 ## Lab Goals
 
 * Know the benefit of `VirtualMachineInstancetype` and `VirtualMachinePreference`
-* Examine Common Instance type and Preferences
-* Deploy VMs with a common instancetype
-* Define your own instance type and preference settings.
-* Use your custom instance types with your VMs
+* Examine Common Instance types and Preferences.
+* Deploy VMs with a common Instance type.
+* Define your own Instance type and Preference settings.
+* Use your custom Instance types with your VMs.