Hide CLI commands and docs / examples for gen1 clusters (#393)

* Hide CLI commands and docs / examples for gen1 clusters

* Remove gen1 tutorial link from home (overview) page

* Updated concepts and cluster template page

cmd/cluster/cluster.go

@@ -22,9 +22,11 @@ func NewCommand() *cobra.Command {
 			c.Usage()
 		},
 	}
-	command.AddCommand(deployClusterCommand())
+	// `cluster deploy` is only for gen1 clusters
+	//command.AddCommand(deployClusterCommand())
 	command.AddCommand(listClustersCommand())
-	command.AddCommand(updateClusterCommand())
+	// `cluster update` is only for gen1 clusters
+	//command.AddCommand(updateClusterCommand())
 	command.AddCommand(manageClusterCommand())
 	command.AddCommand(unmanageClusterCommand())
 	command.AddCommand(createClusterCommand())

cmd/cluster/deploy.go

@@ -3,9 +3,10 @@ package cluster
 import (
 	_ "embed"
 	"fmt"
-	"github.com/arlonproj/arlon/pkg/gitrepo"
 	"os"
 
+	"github.com/arlonproj/arlon/pkg/gitrepo"
+
 	"github.com/argoproj/argo-cd/v2/pkg/apis/application/v1alpha1"
 	"github.com/argoproj/argo-cd/v2/util/cli"
 	argocdio "github.com/argoproj/argo-cd/v2/util/io"
@@ -19,6 +20,7 @@ import (
 	"k8s.io/client-go/tools/clientcmd"
 )
 
+// `cluster deploy` is gen1 only and is now deprecated.
 func deployClusterCommand() *cobra.Command {
 	var clientConfig clientcmd.ClientConfig
 	var argocdNs string

cmd/cluster/ngupdate.go

@@ -39,18 +39,18 @@ func ngupdateClusterCommand() *cobra.Command {
 				return fmt.Errorf("failed to list apps related to cluster: %s", err)
 			}
 			if len(apps.Items) == 0 {
-				return fmt.Errorf("Failed to get the given cluster")
+				return fmt.Errorf("failed to get the given cluster")
 			}
 			if !deleteProfileName {
 				_, err = cluster.NgUpdate(appIf, config, argocdNs, arlonNs, name, profileName, true)
 				if err != nil {
 
-					return fmt.Errorf("Error: %s", err)
+					return fmt.Errorf("error: %s", err)
 				}
 			} else {
 				err = cluster.DestroyProfileApps(appIf, name)
 				if err != nil {
-					return fmt.Errorf("Failed to delete the profile app")
+					return fmt.Errorf("failed to delete the profile app")
 				}
 			}
 			return nil

cmd/cluster/update.go

@@ -16,6 +16,7 @@ import (
 	"k8s.io/client-go/tools/clientcmd"
 )
 
+// `cluster update` is gen1 only and is now deprecated.
 func updateClusterCommand() *cobra.Command {
 	var clientConfig clientcmd.ClientConfig
 	var argocdNs string

docs/README.md

@@ -6,11 +6,11 @@
 ## What Is Arlon?
 
 Arlon is a declarative, gitops based fleet management tool for Kubernetes clusters.
-It allows administrators to: 
+It allows administrators to:
 
-- Deploy and upgrade a large number of *workload clusters* 
+- Deploy and upgrade a large number of *workload clusters*
 - Secure clusters by installing and configuring policies
-- Install a set of applications / add-ons on the clusters 
+- Install a set of applications / add-ons on the clusters
 
 all in a structured, predictable manner. Arlon makes Kubernetes cluster fleet management secure, version controlled, auditable and easy to perform at scale. 
 
@@ -25,18 +25,17 @@ e.g. Kubernetes version, cloud provider, cluster type, node instance type.
 - *Profile*: a grouping of configuration bundles which will be installed into the cluster
 - *Configuration bundle*: a unit of configuration which contains (or references) one or
 more Kubernetes manifests. A bundle can encapsulate anything that can be deployed onto a cluster:
-an RBAC ruleset, an add-on, an application, etc... 
+an RBAC ruleset, an add-on, an application, etc...
 
 ## Arlon Benefits
 
 - Improves time to market by enabling better velocity for developers through infrastructure management that is more fluid and agile. Define, store, change and enforce your cluster infrastructure & application add-ons at scale.  
-- Reduces the risk of unexpected infrastructure downtime and outages, or unexpected security misconfiguration, with consistent management of infrastructure and security policies.   
-- Allows IT and Platform Ops admins to operate large scale of clusters, infrastructure & add-ons with significantly reduced team size & operational overhead, using GitOps. 
+- Reduces the risk of unexpected infrastructure downtime and outages, or unexpected security misconfiguration, with consistent management of infrastructure and security policies.
+- Allows IT and Platform Ops admins to operate large scale of clusters, infrastructure & add-ons with significantly reduced team size & operational overhead, using GitOps.
 
 ## Contents
 
-- [Concepts](./concepts.md) 
+- [Concepts](./concepts.md)
 - [Installation](./installation.md)
-- [Tutorial (gen-1)](./tutorial.md)
-- [Tutorial (gen-2)](./gen2_Tutorial.md)
+- [Tutorial](./gen2_Tutorial.md)
 - [Architecture](./architecture.md)

docs/appprofiles.md

@@ -4,10 +4,11 @@ The Application Profiles feature, also known as Gen2 Profiles, is an
 addition to Arlon v0.10.0 that provides a new way to describe, group,
 and deploy manifests to workload clusters. The new feature introduces
 these concepts:
+
 * Arlon Application (or just "App")
 * Application Profile (a.k.a. AppProfile)
 * Targeting application profiles to workload clusters via annotation
- 
+
 The feature provides an alternative to the Bundle and Profile concepts
 ("the old way") of earlier versions of Arlon. Specifically,
 the Arlon Application can be viewed as a replacement for Bundles,
@@ -40,6 +41,7 @@ the management cluster to actually create the app.
 (Without the ``--output-yaml` flag, the command will apply the resource for you).
 
 Here's an example of an initial Arlon Application manifest:
+
 ```yaml
 apiVersion: argoproj.io/v1alpha1
 kind: ApplicationSet
@@ -70,33 +72,38 @@ spec:
 ```
 
 The List generator that the AppProfile controller maintains supplies two variables for template substitution:
-- `cluster_name`: the name of the target workload cluster
-- `cluster_server`: the URL+FQDN of the workload cluster's Kubernetes API endpoint
+
+* `cluster_name`: the name of the target workload cluster
+* `cluster_server`: the URL+FQDN of the workload cluster's Kubernetes API endpoint
 
 Notice how the initial manifest takes advantage of those variables to set
-- `spec.template.metadata.name` to `{{cluster-name}}-app-myconfigmap`
-to ensure that any actual ArgoCD Application resources deployed from the ApplicationSet
-are uniquely named, by prefixing the cluster name.
-- `spec.template.spec.destination.server` to `{{cluster_server}}` to target the correct workload cluster
+
+* `spec.template.metadata.name` to `{{cluster-name}}-app-myconfigmap`
+to ensure that any actual ArgoCD Application resources deployed from the ApplicationSet are uniquely named, by prefixing the cluster name.
+* `spec.template.spec.destination.server` to `{{cluster_server}}` to target the correct workload cluster
 
 Arlon apps can be listed in two ways. The first is to use the `arlon app list` command. One advantage
 is that it's simple to use and also displays additional information about the app, such as which AppProfiles
 are currently associated with the app.
 
 Example:
+
 ```shell
 $ arlon app list
 NAME         REPO                                     PATH              REVISION  APP_PROFILES
 myconfigmap  https://github.com/bcle/fleet-infra.git  apps/my-cfgmap-1  HEAD      [marketing]
 ```
+
 The second way is to use pure kubectl to list ApplicationSets with a particular label:
-```
+
+```shell
 $ kubectl -n argocd get applicationset
 NAME          AGE
 myconfigmap   21d
 ```
 
 Similarly, an Arlon app can be deleted in two ways:
+
 - `arlon app delete <appName>`
 - `kubectl -n argocd delete applicationset <appName>`
 
@@ -110,13 +117,15 @@ An AppProfile specifies the apps it is associated with via the `appNames` list.
 It is legal for `appNames` to contain names of Arlon Apps that don't exist yet.
 To indicate whether some app names are currently invalid, the AppProfile controller
 will update the resource's `status` section as follows:
+
 - If all specified app names refer to valid Arlon apps, `status.health`
   is set to `healthy`.
 - If one or more specified app names refer to non-existent Arlon apps,
   then `status.health` is set to `degraded`, and `status.invalidAppNames`
   lists the invalid names.
 
 Here is an example of an AppProfile manifest that includes 3 apps, one of which does not exist:
+
 ```yaml
 apiVersion: core.arlon.io/v1
 kind: AppProfile
@@ -140,7 +149,8 @@ status:
 Since AppProfiles are defined by their own custom resource and are fairly straightforward, their lifecycle
 can be managed entirely using `kubectl`. That said, Arlon provides the `arlon appprofile list` to display
 useful information about current AppProfiles. Example:
-```
+
+```shell
 $ arlon appprofile list
 NAME         APPS                     HEALTH   INVALID_APPS
 engineering  [wordpress]              healthy  []
@@ -155,7 +165,8 @@ When those AppProfiles are targeted to a workload cluster, the cluster receives
 Apps are actually deployed to workload clusters by annotating the desired cluster(s) with `arlon.io/profiles=<comma separated list of AppProfiles>`. This is supported only on Arlon Gen2 clusters, which themselves are represented as ArgoCD Application resources.
 
 Example: suppose we have a Gen2 workload cluster named **clust1**.  Since the cluster is represented as an ArgoCD Application resource, targeting the `engineering` and `marketing` app profiles to it is achieved with:
-```
+
+```shell
 kubectl -n argocd annotate --overwrite application clust1 arlon.io/profiles=engineering,marketing
 ```
 
@@ -165,10 +176,12 @@ of all the valid appNames from every app profile listed in the annotation.
 
 By default, every ArgoCD Application Resource generated by the app's ApplicationSet is named with the pattern `<clustername>-app-<appname>`.
 In the running example, these two ArgoCD application resources will be generated:
-- clust1-app-wordpress
-- clust1-app-myconfigmap
+
+* clust1-app-wordpress
+* clust1-app-myconfigmap
 
 To detach all profiles from a cluster, simply remove the annotation:
+
 ```shell
 kubectl -n argocd annotate application clust1 arlon.io/profiles-
 ```