Feat/launchpad orientation map

docs/launchpad/advanced/advanced-kubernetes.md → docs/launchpad/advanced-tutorials/advanced-kubernetes.md

@@ -6,7 +6,7 @@ This guide provides a general walkthrough for installing Kubernetes using Fedora
 
 ## Prerequisites
 
-Before proceeding with this guide, ensure you have a solid understanding of how FCOS works and the steps required to install and enable FCOS as detailed in [Install FCOS Guide](../guides/install-fcos).
+Before proceeding with this guide, ensure you have a solid understanding of how FCOS works and the steps required to install and enable FCOS as detailed in [Install FCOS Guide](install-fcos.md).
 
 Additionally, a clear grasp of the fundamental [Kubernetes architecture](https://devopscube.com/kubernetes-architecture-explained/) will greatly aid in navigating the guidance outlined ahead.
 

docs/launchpad/guides/install-fcos.md → docs/launchpad/advanced-tutorials/install-fcos.md

@@ -148,4 +148,4 @@ If you've run the above command the folowing will happen on the host
 
 ## Next steps 
 
-The outlined steps mark the initial phase of grasping the workings of FCOS. For the different components that you'd need to include in your `butane` config to install Kuberneter follow [Advanced Kubernetes](../advanced/advanced-kubernetes).
+The outlined steps mark the initial phase of grasping the workings of FCOS. For the different components that you'd need to include in your `butane` config to install Kuberneter follow [Advanced Kubernetes](advanced-kubernetes.md).

docs/launchpad/docs-map.md

@@ -0,0 +1,31 @@
+---
+sidebar_position: 1
+---
+
+# Launchpad Documentation
+
+Everything you need to know about the Launchpad project.
+
+## First steps
+
+Are you new to Launchpad or to Kubernetes? Here's a high-level overview of how this documentation is organised, to help you know where to look for the information you need:
+
+* **From Scratch** - this includes overview of the project, details on the project modularity and how you can leverage features of Launchpad as best suits your needs: [Launchpad Introduction](intro) | [Opt in features](modularity) | [Installation](client-side-tooling) 
+* **Project Maintenance** - find out how often new versions of the project are released and how GraphOps decides what namespaces and chains to support: [Release Channels](release-channels) | [Supported Namespaces](supported-namespaces)
+* **Tutorials** - guides to get you started with Launchpad, everything you need to deploy different blockchain nodes and guides on what you need for highly available postgresql and monitoring: [Getting Started](quick-start) | [Arbitrum-One Guide](tutorials/arbitrum-archive-kubernetes-guide) | [Celo-Mainnet Guide](tutorials/celo-archive-kubernetes-guide) | [PostgreSQL HA](tutorials/postgresql_ha.md) | [Monitoring Stack HA](tutorials/monitoring-stack-with-HA.md)
+* **Advanced Tutorials** - want to start with Launchpad but you don't yet have a Kubernetes Cluster? Find out how to create one: [Creating a Kubernetes Cluster with kubeadm](advanced-tutorials/kubernetes-create-cluster-with-kubeadm) | [Creating a Kubernetes Cluster with FCOS](advanced-tutorials/advanced-kubernetes.md) 
+
+## Getting help
+
+Having trouble? We'd like to help!
+
+* The [FAQ](faq) page has answers to many common questions.
+* Not found something you need? See [FAQ: Need more help](faq#need-more-help) for information on getting support and asking questions.
+* Request new features, check out existing bugs or report new ones in [Launchpad Charts](https://github.com/graphops/launchpad-charts/issues) and [Launchpad Namespaces](https://github.com/graphops/launchpad-namespaces/issues)
+
+
+## Getting Involved
+
+Launchpad is a collaborative effort to create the best UX for Graph Protocol Indexers on Kubernetes. As such contributors are highly appreciated and welcome. Visit the github repos' guidance to contribute code to [Launchpad Charts](https://github.com/graphops/launchpad-charts/blob/main/CONTRIBUTING.md) or [Launchpad Namespaces](https://github.com/graphops/launchpad-namespaces/blob/main/CONTRIBUTING.md)
+
+You can also get involved by simply attending our biweekly [Launchpad Office Hours(LOH)](https://discord.com/events/438038660412342282/1229824398127534130) community call on discord. You can access previous LOH recordings [here](https://www.youtube.com/watch?v=qC5KbhD3urc&list=PLpbkfkwg_V6Ceidcn06VSP9BoU0g14voq).

docs/launchpad/faq.md

@@ -89,7 +89,7 @@ Normal  WaitForFirstConsumer  6m52s                   persistentvolume-controlle
 
 **Q: Do I need a specific CNI (Cilium, Calico etc) in order to use Launchpad?**
 
-**A:** The Launchpad stack will work regardless of CNI used and in more general terms should work will all Kubernetes clusters - so you can customize your cluster how you prefer. In our [Kubernetes guide](guides/kubernetes-create-cluster-with-kubeadm.md) we use Cilium due to its use of [eBPF](https://ebpf.io/what-is-ebpf/) technology. This advanced approach offers a significant boost in efficiency, especially noticeable when managing a large number of nodes. It scales well and ensures lower latency, which is crucial for high-performance requirements. While Calico does enjoy a broader base of community support and is a strong choice with its iptables routing, Cilium has the upper advantage due to its performance and its more expansive set of features.
+**A:** The Launchpad stack will work regardless of CNI used and in more general terms should work will all Kubernetes clusters - so you can customize your cluster how you prefer. In our [Kubernetes guide](advanced-tutorials/kubernetes-create-cluster-with-kubeadm.md) we use Cilium due to its use of [eBPF](https://ebpf.io/what-is-ebpf/) technology. This advanced approach offers a significant boost in efficiency, especially noticeable when managing a large number of nodes. It scales well and ensures lower latency, which is crucial for high-performance requirements. While Calico does enjoy a broader base of community support and is a strong choice with its iptables routing, Cilium has the upper advantage due to its performance and its more expansive set of features.
 
 It's important to acknowledge that while Cilium has better performance and features than Calico, it is a bit trickier to set up. Our decision isn't influenced by Launchpad; it's purely a preference based on the operational benefits that Cilium brings to our infrastructure.
 

docs/launchpad/intro.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 1
+sidebar_position: 2
 ---
 
 # Introduction
@@ -22,9 +22,10 @@ There are three major components to be aware of:
 - Preconfigured namespaces for core cluster functions (logging, monitoring, etc) and major blockchains
 - An automated dependency update pipeline for [`graphops/launchpad-charts`](https://github.com/graphops/launchpad-charts) and [`graphops/launchpad-namespaces`](https://github.com/graphops/launchpad-namespaces)
 
+Are you interested in exploring Launchpad but not ready to adopt the entire stack? Explore our [Modularity](modularity) page to discover how you can selectively integrate elements of Launchpad, like `launchpad-starter`, `launchpad-charts`, and `launchpad-namespaces`, to fit your specific needs without committing to a full end-to-end implementation.
+
 ## Next Steps
 
-- Read the [Prerequisites](prerequisites) section to understand what you need to bring
+- Read the [Prerequisites](prerequisites) section to understand what you need to started
 - Read the [Quick Start guide](quick-start) to get up and running
-- Look at the repositories above on GitHub to understand how they work
-- Review **Advanced Topics** to understand more advanced behavior
+- Look at the repositories above on GitHub to understand how they work

docs/launchpad/prerequisites.md

@@ -41,7 +41,9 @@ Currently, Launchpad comes with support for Linux and MacOS clients. Windows is
 
 The Launchpad project requires a certain level of familiarity with [Kubernetes](https://kubernetes.io/) and its intricacies. The extent of this Kubernetes expertise depends on your choice of cluster. Opting for a managed cluster from a leading Cloud Provider requires less intensive Kubernetes knowledge, as operating such a cluster is more straightforward, necessitating only a fundamental grasp of different Kubernetes resource types.
 
-However, it's essential to note that managed clusters can be very costly when running blockchains. In contrast, selecting a self-managed cluster demands a deeper understanding, encompassing all components necessary for cluster provisioning and management - for more details on this please checkout our [Kubernetes guide](guides/kubernetes-create-cluster-with-kubeadm.md). Regardless of your choice, you'll need to create a Kubernetes cluster. This can involve setting up a self-managed cluster, as outlined in our [Fedora CoreOS guide](guides/install-fcos.md), or opting for a managed cluster provided by a major Cloud Provider like AWS or GCP.
+However, it's essential to note that managed clusters can be very costly when running blockchains. In contrast, selecting a self-managed cluster demands a deeper understanding, encompassing all components necessary for cluster provisioning and management. Regardless of your choice, you'll need to create a Kubernetes cluster. 
+
+For a detailed exploration of setting up a Kubernetes cluster yourself, please refer to our [Kubernetes guide](advanced-tutorials/kubernetes-create-cluster-with-kubeadm.md). If you choose to set up a self-managed cluster, you might consider using Fedora CoreOS as one of the possible options, detailed in our [Fedora CoreOS guide](advanced-tutorials/install-fcos.md), among other methods.
 
 ## Operational knowledge of Helm
 

docs/launchpad/quick-start.md

@@ -183,7 +183,7 @@ helmfiles:
   - path: git::https://github.com/graphops/launchpad-namespaces.git@arbitrum/helmfile.yaml?ref=arbitrum-canary/latest
     selectorsInherited: true
     values:
-    - flavor: goerli
+    - flavor: sepolia
       helmDefaults:
         <<: *helmDefaults
       arbitrum-nitro:
@@ -239,7 +239,7 @@ helmfiles:
                     namespace: graph-arbitrum-sepolia
                   type: Opaque
                 encryptedData:
-                  mnemonic: <<your encrypted mnemonic>> # Generate a SealedSecret encryptedData key with the "utils:seal-secrets" task, e.g.: task utils:seal-secrets -- -n graph-goerli -s graph-operator-mnemonic -k mnemonic -v "your mnemonic words"
+                  mnemonic: <<your encrypted mnemonic>> # Generate a SealedSecret encryptedData key with the "utils:seal-secrets" task, e.g.: task utils:seal-secrets -- -n graph-arbitrum-sepolia -s graph-operator-mnemonic -k mnemonic -v "your mnemonic words"
       graph-database:
         values:
           resources:

docs/launchpad/release-channels.md

@@ -30,7 +30,7 @@ Below you can find a more comprehensive breakdown of the process, divided into a
 
 **operator**
   - Tests the new `canary` chart release to verify it is working properly, if it is adds commit to PR to set the `stable` chart release version. Following the merge of this PR, the new `stable` chart release is automatically issued in draft mode. This step provides the operator with an opportunity to review and manually publish the final release, ensuring precise control and quality assurance in the deployment process.
-  - Run `task releases:apply -- eth-goerli` which should pick changes from latest `ethereum` canary tag that would contain new `erigon` canary chart version (after renovate has run and has picked those up, which it does in 15m intervals).
+  - Run `task releases:apply -- eth-sepolia` which should pick changes from latest `ethereum` canary tag that would contain new `erigon` canary chart version (after renovate has run and has picked those up, which it does in 15m intervals).
   - If the previous task runs successfully and workloads appear healthy, the operator updates their helmfile reference to `ethereum-canary/latest` for `eth-mainnet` namespace and runs `task releases:apply -- eth-mainnet`.
   - If `task releases:apply -- eth-mainnet` succeeds and all workloads are healthy, operator  manually tags the `ethereum` namespace as `stable`
 
@@ -41,12 +41,12 @@ Manually tagging a namespace as `stable` is an intentional process. Our aim is t
 Alongside the ability to choose between `canary` or `stable` releases based on user risk preferences, we've also enabled the capability to manually override a specific chart version during namespace deployment.
 
 ```yaml
-  - path: git::https://github.com/graphops/launchpad-namespaces.git@ethereum/helmfile.yaml?ref=ethereum-stable/latest
+  - path: git::https://github.com/graphops/launchpad-namespaces.git@ethereum/helmfile.yaml?ref=ethereum-canary/latest
     selectorsInherited: true
     values:
       - helmDefaults:
           <<: *helmDefaults
-        flavor: "goerli"
+        flavor: "sepolia"
         erigon:
           chartVersion: "0.8.1" # to override the chart version the namespace is setup with
           values:

docusaurus.config.js

@@ -66,7 +66,7 @@ const config = {
         items: [
           {
             type: 'doc',
-            docId: 'launchpad/intro',
+            docId: 'launchpad/docs-map',
             position: 'left',
             label: 'Launchpad',
           },