Merge pull request #214 from gianlucam76/fix

Fix links and index

docs/addons/clusterprofile.md

@@ -93,10 +93,10 @@ Now, if you're looking for real-time deployment and updates, the *Continuous* sy
 
 *ContinuousWithDriftDetection* instructs Sveltos to monitor the state of managed clusters and detect a configuration drift for any of the resources deployed because of that ClusterProfile.
 When Sveltos detects a configuration drift, it automatically re-syncs the cluster state back to the state described in the management cluster.
-To know more about configuration drift detection, refer to this [section](../configuration_drift.md).
+To know more about configuration drift detection, refer to this [section](../features/configuration_drift.md).
 
 Imagine you're about to make some important changes to your ClusterProfile, but you're not entirely sure what the results will be. You don't want to risk causing any unwanted side effects, right? Well, that's where the *DryRun* syncMode configuration comes in. By deploying your ClusterProfile with this configuration, you can launch a simulation of all the operations that would normally be executed in a live run. The best part? No actual changes will be made to the matching clusters during this dry run workflow, so you can rest easy knowing that there won't be any surprises. 
-To know more about dry run, refer to this [section](../dryrun.md).
+To know more about dry run, refer to this [section](../features/dryrun.md).
 
 ### Spec.StopMatchingBehavior
 
@@ -129,15 +129,15 @@ When a cluster matches the ClusterProfile, Kyverno Helm chart will be deployed i
 The *reloader* property determines whether rolling upgrades should be triggered for Deployment, StatefulSet, or DaemonSet instances managed by Sveltos and associated with this ClusterProfile when changes are made to mounted ConfigMaps or Secrets.
 When set to true, Sveltos automatically initiates rolling upgrades for affected Deployment, StatefulSet, or DaemonSet instances whenever any mounted ConfigMap or Secret is modified. This ensures that the latest configuration updates are applied to the respective workloads.
 
-Please refer to this [section](../rolling_upgrade.md) for more information.
+Please refer to this [section](../rolling_updates/rolling_upgrade.md) for more information.
 
 ### Spec.MaxUpdate
 
 A ClusterProfile might match more than one cluster. When a change is maded to a ClusterProfile, by default all matching clusters are update concurrently.
 The *maxUpdate* field specifies the maximum number of Clusters that can be updated concurrently during an update operation triggered by changes to the ClusterProfile's add-ons or applications.
 The specified value can be an absolute number (e.g., 5) or a percentage of the desired cluster count (e.g., 10%). The default value is 100%, allowing all matching Clusters to be updated simultaneously.
 For instance, if set to 30%, when modifications are made to the ClusterProfile's add-ons or applications, only 30% of matching Clusters will be updated concurrently. Updates to the remaining matching Clusters will only commence upon successful completion of updates in the initially targeted Clusters. This approach ensures a controlled and manageable update process, minimizing potential disruptions to the overall cluster environment.
-Please refer to this [section](../rolling_update_strategy.md) for more information.
+Please refer to this [section](../rolling_updates/rolling_update_strategy.md) for more information.
 
 ### Spec.ValidateHealths
 
@@ -147,7 +147,7 @@ The ValidateHealths property accepts a slice of Lua functions, where each functi
 
 Lua's scripting capabilities offer flexibility in defining complex validation logic tailored to specific add-ons or applications.
  
-Please refer to this [section](../rolling_update_strategy.md) for more information.
+Please refer to this [section](../rolling_updates/rolling_update_strategy.md) for more information.
 
 Consider a scenario where a new cluster with the label env:prod is created. The following instructions guide Sveltos to:
 

docs/addons/profile.md

@@ -96,10 +96,10 @@ Now, if you're looking for real-time deployment and updates, the *Continuous* sy
 
 *ContinuousWithDriftDetection* instructs Sveltos to monitor the state of managed clusters and detect a configuration drift for any of the resources deployed because of that Profile.
 When Sveltos detects a configuration drift, it automatically re-syncs the cluster state back to the state described in the management cluster.
-To know more about configuration drift detection, refer to this [section](../configuration_drift.md).
+To know more about configuration drift detection, refer to this [section](../features/configuration_drift.md).
 
 Imagine you're about to make some important changes to your Profile, but you're not entirely sure what the results will be. You don't want to risk causing any unwanted side effects, right? Well, that's where the *DryRun* syncMode configuration comes in. By deploying your Profile with this configuration, you can launch a simulation of all the operations that would normally be executed in a live run. The best part? No actual changes will be made to the matching clusters during this dry run workflow, so you can rest easy knowing that there won't be any surprises. 
-To know more about dry run, refer to this [section](../dryrun.md).
+To know more about dry run, refer to this [section](../features/dryrun.md).
 
 ### Spec.StopMatchingBehavior
 
@@ -133,15 +133,15 @@ When a cluster matches the Profile, Kyverno Helm chart will be deployed in such
 The *reloader* property determines whether rolling upgrades should be triggered for Deployment, StatefulSet, or DaemonSet instances managed by Sveltos and associated with this Profile when changes are made to mounted ConfigMaps or Secrets.
 When set to true, Sveltos automatically initiates rolling upgrades for affected Deployment, StatefulSet, or DaemonSet instances whenever any mounted ConfigMap or Secret is modified. This ensures that the latest configuration updates are applied to the respective workloads.
 
-Please refer to this [section](../rolling_upgrade.md) for more information.
+Please refer to this [section](../rolling_updates/rolling_upgrade.md) for more information.
 
 ### Spec.MaxUpdate
 
 A Profile might match more than one cluster. When a change is maded to a Profile, by default all matching clusters are update concurrently.
 The *maxUpdate* field specifies the maximum number of Clusters that can be updated concurrently during an update operation triggered by changes to the Profile's add-ons or applications.
 The specified value can be an absolute number (e.g., 5) or a percentage of the desired cluster count (e.g., 10%). The default value is 100%, allowing all matching Clusters to be updated simultaneously.
 For instance, if set to 30%, when modifications are made to the Profile's add-ons or applications, only 30% of matching Clusters will be updated concurrently. Updates to the remaining matching Clusters will only commence upon successful completion of updates in the initially targeted Clusters. This approach ensures a controlled and manageable update process, minimizing potential disruptions to the overall cluster environment.
-Please refer to this [section](../rolling_update_strategy.md) for more information.
+Please refer to this [section](../rolling_updates/rolling_update_strategy.md) for more information.
 
 ### Spec.ValidateHealths
 
@@ -151,7 +151,7 @@ The ValidateHealths property accepts a slice of Lua functions, where each functi
 
 Lua's scripting capabilities offer flexibility in defining complex validation logic tailored to specific add-ons or applications.
  
-Please refer to this [section](../rolling_update_strategy.md) for more information.
+Please refer to this [section](../rolling_updates/rolling_update_strategy.md) for more information.
 
 Consider a scenario where a new cluster with the label env:prod is created. The following instructions guide Sveltos to:
 

docs/events/addon_event_deployment.md

@@ -174,7 +174,7 @@ If following label is set on EventSource instance created by tenant admin
 projectsveltos.io/admin-name: <admin>
 ```
 
-Sveltos will make sure tenant admin can define events only looking at resources it has been [authorized to by platform admin](../multi-tenancy.md).
+Sveltos will make sure tenant admin can define events only looking at resources it has been [authorized to by platform admin](../features/multi-tenancy.md).
 
 Sveltos suggests using following Kyverno ClusterPolicy, which will take care of adding proper label to each EventSource at creation time.
 

docs/features/configuration_drift.md

@@ -36,4 +36,4 @@ The service then starts a watcher for each GroupVersionKind with at least one re
 
 This way, Sveltos ensures that your systems are always consistent and predictable, preventing any unexpected issues caused by configuration drift.
 
-![Configuration drift recovery](assets/reconcile_configuration_drift.gif)
+![Configuration drift recovery](../assets/reconcile_configuration_drift.gif)

docs/features/labels_management.md

@@ -22,7 +22,7 @@ Once Classifier is deployed in the management cluster, it is distributed to each
 
 By combining Classifier with ClusterProfiles, Sveltos can monitor the runtime status for each cluster, update cluster labels when the cluster runtime state changes, and deploy and upgrade Kubernetes add-ons accordingly. With Sveltos, managing cluster labels and add-ons has never been easier.
 
-![Classifier in action](assets/classifier.gif)
+![Classifier in action](../assets/classifier.gif)
 
 ## A simple use case: upgrade helm charts automatically when Kubernetes cluster is upgraded
 Suppose you are managing several Kubernetes clusters with different versions.

docs/features/multi-tenancy.md

@@ -72,7 +72,7 @@ data:
  verbs: ["*"]
 ```
 
-![Multi-tenancy in action](assets/multi_tenancy.gif)
+![Multi-tenancy in action](../assets/multi_tenancy.gif)
 
 More example can be found [here](https://github.com/projectsveltos/access-manager/tree/main/examples "Kubernetes multi-tenancy examples").
 

docs/observability/notifications.md

@@ -168,7 +168,7 @@ If following label is set on HealthCheck instance created by tenant admin
 projectsveltos.io/admin-name: <admin>
 ```
 
-Sveltos will make sure tenant admin can define notifications only looking at resources it has been [authorized to by platform admin](../multi-tenancy.md).
+Sveltos will make sure tenant admin can define notifications only looking at resources it has been [authorized to by platform admin](../features/multi-tenancy.md).
 
 Sveltos suggests using following Kyverno ClusterPolicy, which will take care of adding proper label to each HealthCheck at creation time.
 

docs/rolling_updates/rolling_upgrade.md

@@ -51,7 +51,7 @@ sveltosctl show addons
 
 Whenever the ConfigMap that is mounted by a Deployment undergoes modifications, Sveltos will automatically initiate a rolling upgrade process for the Deployment.
 
-![Sveltos: triggering rolling upgrades](assets/rolling_upgrades.gif)
+![Sveltos: triggering rolling upgrades](../assets/rolling_upgrades.gif)
 
 By setting the __reloader__ field to true in the ClusterProfile, you enable automated rolling upgrades that ensure the latest configurations are consistently applied to your applications. This significantly simplifies the maintenance and enhancement of your Kubernetes cluster, promoting stability and efficient resource utilization.
 

docs/sveltosctl/techsupport.md

@@ -21,7 +21,7 @@ To do that, add the below label to the Techsupport instance created by the tenan
 projectsveltos.io/admin-name: <admin>
 ```
 
-Sveltos will make sure the tenant admin collects what it has been [authorized to by platform admin](../multi-tenancy.md).
+Sveltos will make sure the tenant admin collects what it has been [authorized to by platform admin](../features/multi-tenancy.md).
 
 
 ## Techsupport CRD

docs/template/template.md

@@ -134,7 +134,7 @@ The same principle as above is applied to Helm charts. The `values` section of a
 
 Providing the necessary RBACs to Sveltos is a straightforward process. The Sveltos' ServiceAccount is tied to the **addon-controller-role-extra** ClusterRole. To grant Sveltos the necessary permissions, simply edit the role.
 
-If the ClusterProfile is created by a tenant administrator as part of a [multi-tenant setup](../multi-tenancy.md), Sveltos will act on behalf of (impersonate) the ServiceAccount that represents the tenant. This ensures that Kubernetes RBACs are enforced, which restricts the tenant's access to only authorized resources.
+If the ClusterProfile is created by a tenant administrator as part of a [multi-tenant setup](../features/multi-tenancy.md), Sveltos will act on behalf of (impersonate) the ServiceAccount that represents the tenant. This ensures that Kubernetes RBACs are enforced, which restricts the tenant's access to only authorized resources.
 
 ### Namespace
 

mkdocs.yml

@@ -49,14 +49,16 @@ nav:
  - ClusterProfile dependsOn field: 'deployment_order/depends_on.md'
  - ClusterProfile dependsOn and validateHealths: 'deployment_order/depends_on_with_health_checks.md'
  - Resource Deployment Order with events: 'deployment_order/order_with_events.md'
-- ConfigurationDrift detection: 'configuration_drift.md'
-- DryRun: 'dryrun.md'
-- Using Rolling Updates to Minimize Downtime and Risk: 'rolling_update_strategy.md'
-- Deployment, StatefulSet, DaemonSet Rolling upgrades: 'rolling_upgrade.md'
+- Features:
+ - ConfigurationDrift detection: 'features/configuration_drift.md'
+ - DryRun: 'features/dryrun.md'
+ - Cluster Classification: 'features/labels_management.md'
+ - Multi-tenancy: 'features/multi-tenancy.md'
+- Using Rolling Updates to Minimize Downtime and Risk: 'rolling_updates/rolling_update_strategy.md'
+- Deployment, StatefulSet, DaemonSet Rolling upgrades: 'rolling_updates/rolling_upgrade.md'
 - Event framework:
  - Event based add-on deployment: 'events/addon_event_deployment.md'
  - Cross cluster configuration: 'events/cross_cluster_configuration.md'
-- Cluster Classification: 'labels_management.md'
 - Cluster Observability:
  - Notifications: 'observability/notifications.md'
  - Send Slack, Webex and Discord notifications: 'observability/addons.md'
@@ -67,7 +69,6 @@ nav:
 - Scalability:
  - Vertical Scaling: 'scalability/configuration.md'
  - Horizontal Scaling: 'scalability/sharding.md'
-- Multi-tenancy: 'multi-tenancy.md'
 - Blogs and videos: 'blogs.md'
 theme:
  features: