docs: updated descriptions

docs/docs-content/integrations/generic-vm-libvirt.md

@@ -20,10 +20,8 @@ tags: ["packs", "generic-vm-libvirt", "system app"]
 To configure the Generic-VM-Libvirt add-on pack for the application cluster, begin by editing the manifest namespace
 value.
 
-**Example**
-
 ```yaml
-namespace: jet-system
+namespace: cluster-{{ .spectro.system.cluster.uid }}
 ```
 
 If multiple instances of this pack have to be deployed on the cluster for different virtual machine applications, then

docs/docs-content/integrations/generic-vm-vsphere.md

@@ -14,10 +14,7 @@ tags: ["packs", "generic-vm-vsphere", "system app"]
 <Tabs queryString="parent">
 <TabItem label="1.0.x" value="1.0.x">
 
-</TabItem>
-</Tabs>
-
-## Configuring Generic-VM-vSphere
+### Configure Generic-VM-vSphere
 
 To configure the Generic-VM-vSphere Add-on pack for the application cluster, the namespace value should be as follows:
 
@@ -28,15 +25,15 @@ namespace: cluster-{{ .spectro.system.cluster.uid }}
 ```
 
 If multiple instances of this pack has to be deployed on the cluster for different virtual machine applications, then
-modify '`spectrocloud.com/display-name`' and '`releaseNameOverride`' with different names to make it unique across all
-the packs in the cluster.
+modify `spectrocloud.com/display-name` and `releaseNameOverride` with different names to make it unique across all the
+packs in the cluster.
 
 ```yaml
 spectrocloud.com/display-name: vm-app-1
 releaseNameOverride:
 ```
 
-## Generic-VM-vSphere Pack Manifest
+### Generic-VM-vSphere Pack Manifest
 
 ```yaml
 pack:
@@ -177,24 +174,24 @@ charts:
     #     echo "I am post exec"
 ```
 
-## Virtual Machine Hooks
+### Virtual Machine Hooks
 
 The Generic-VM-vSphere pack supports various hooks while deploying VM applications and supports multiple use-cases of
 customizing workflow, as customers require.
 
-## Using extraVMHclConfig
+#### extraVMHclConfig
 
 The extraVMHclConfig command can be used to provide an extra configuration in the virtual machine and the configuration
 file should be provided in HashiCorp Configuration Language (HCL) format.
 
-```terraform
-# extraVMHclConfig: |
-#   cdrom {
-#     client_device = true
-#   }
+```hcl
+extraVMHclConfig: |
+  cdrom {
+    client_device = true
+   }
 ```
 
-## Using preExecCmd and postExecCmd
+#### preExecCmd and postExecCmd
 
 The **preExecCmd** and **postExecCmd** commands will be executed in every pod reconciliation. The loop runs at
 approximately a 2-minute interval.
@@ -210,12 +207,16 @@ preExecCmd: "bash /var/files/pre-exec.sh"
 postExecCmd: "bash /var/files/pre-exec.sh"
 ```
 
-## Using preVMInitCmd and postVMInitCmd
+#### preVMInitCmd and postVMInitCmd
 
 The **preVMInitCmd** command is executed, only when the virtual machine is being created or recreated. Likewise, the
 **postVMInitCmd** command is executed only after the virtual machine is created or recreated.
 
-**Note**: These commands will not be executed in each reconciliation.
+:::info
+
+These commands will not be executed in each reconciliation.
+
+:::
 
 ```yaml
 preVMInitCmd: "echo 'Hey! Hang on tight. I am gonna create a VM.'"
@@ -225,7 +226,7 @@ preVMInitCmd: "echo 'Hey! Hang on tight. I am gonna create a VM.'"
 postVMInitCmd: "echo 'Ooho! VM is created.'"
 ```
 
-## Using preVMDestroyCmd
+#### preVMDestroyCmd
 
 Any command or script provided in this virtual machine hook will execute before the virtual machine is destroyed. It
 will be executed only when the VM is getting deleted. A virtual machine deletion can happen for any reason, like
@@ -237,15 +238,15 @@ preVMDestroyCmd: ""
 
 :::info
 
-During a first-time deployment, <b> preVMDestroyCmd</b> won't be invoked. However, if there is any change in cloud-init,
-then the VM resource will be recreated, preVMDestroyCmd will be invoked before deleting the VM, and once preVMDestroyCmd
-is executed successfully, only then the VM resource will be deleted.
+During a first-time deployment, `preVMDestroyCmd` won't be invoked. However, if there is any change in cloud-init, then
+the VM resource will be recreated, preVMDestroyCmd will be invoked before deleting the VM, and once preVMDestroyCmd is
+executed successfully, only then the VM resource will be deleted.
 
-Once the VM is deleted and before another virtual machine is created, <b>preVMInitCmd</b> will be invoked.
+Once the VM is deleted and before another virtual machine is created, `preVMInitCmd` will be invoked.
 
 :::
 
-## Mounts
+### Mounts
 
 Mount the data inside the existing configuration map or secret into the pod as files, where pre-and-post hooks are
 executed. This allows the data present in the configuration map or the secrets file to be accessible while running
@@ -265,7 +266,7 @@ mounts:
   #       path: /data/system-config-2
 ```
 
-## Environment Variables
+### Environment Variables
 
 The ENVS section can inject data inside the existing config maps or secrets into the pod as environment variables, where
 pre-and post-hooks are executed so that data present in the config map or the secret file can be accessed while running
@@ -283,10 +284,10 @@ envs:
     #       dataKey: "db.password"
 ```
 
-## Files
+### Files
 
 Files present in this section will be added to the pod and will be accessible while executing pre-and-post execution
-hooks and absolute file path would be '/var/files/\<file_name>'.
+hooks and absolute file path would be `/var/files/file_name`.
 
 ```yaml
 files:
@@ -300,6 +301,9 @@ files:
 #     echo "I am post exec"
 ```
 
+</TabItem>
+</Tabs>
+
 ## Terraform
 
 You can retrieve details about the Generic-VM-Libvirt pack by using the following Terraform code.

static/packs-data/packs_information.json

@@ -427,6 +427,14 @@
     "name": "generic-vm-vsphere",
     "description": "Generic-VM-vSphere is a Palette Add-on pack used to simplify deploying the virtual machine resource from a cluster profile or a system profile. Generic-VM-vSphere extracts all Terraform constructs inside the pack and exposes nothing but the values. Users will then have the ability to modify the add-on pack for the different applications."
   },
+  {
+    "name": "gloo",
+    "descrption": "Gloo Gateway is a feature-rich, fast, and flexible Kubernetes-native ingress controller and next-generation API gateway that is built on top of Envoy proxy and the Kubernetes Gateway API. It excels in function-level routing, supports legacy apps, microservices and serverless, offers robust discovery capabilities, integrates seamlessly with open-source projects, and is designed to support hybrid applications with various technologies, architectures, protocols, and clouds."
+  },
+  {
+    "name": "gvisor",
+    "description": "gVisor is an open-source Linux-compatible sandbox that can be deployed anywhere existing container tooling does. It enables cloud-native container security and portability. gVisor leverages years of experience isolating production workloads at Google."
+  },
   {
     "name": "kubernetes-microk8s",
     "description": "MicroK8s is a lightweight CNCF-certified Kubernetes distribution developed by Canonical. It deploys all Kubernetes services in a single, fully contained package and offers out-of-the-box add-ons."