Adds tags to doc pages (#3085)

* Adds tags to doc pages Signed-off-by: Samhita Alla <[email protected]> * remove tags Signed-off-by: Samhita Alla <[email protected]> * add all tags link Signed-off-by: Samhita Alla <[email protected]> * fixed troubleshoot page tag Signed-off-by: Samhita Alla <[email protected]> Signed-off-by: Samhita Alla <[email protected]>
flyteorg · Nov 18, 2022 · f534819 · f534819
1 parent fa4ca80
commit f534819
Show file tree

Hide file tree

Showing 55 changed files with 239 additions and 78 deletions.
diff --git a/.gitignore b/.gitignore
@@ -30,3 +30,4 @@ dist
 *.db
 vendor/
 /docker/sandbox-bundled/images/tar
+rsts/_tags/
diff --git a/doc-requirements.in b/doc-requirements.in
@@ -12,3 +12,8 @@ sphinxcontrib-mermaid
 sphinxcontrib-video
 sphinxcontrib-yt
 sphinx-tabs
+sphinx-tags
+grpcio<1.49.0
+grpcio-status<1.49.0
+sphinx-tabs<3.4.1
+
diff --git a/doc-requirements.txt b/doc-requirements.txt
@@ -1,63 +1,94 @@
 #
-# This file is autogenerated by pip-compile with python 3.8
+# This file is autogenerated by pip-compile with python 3.9
 # To update, run:
 #
 #    pip-compile doc-requirements.in
 #
 alabaster==0.7.12
     # via sphinx
-astroid==2.11.2
+astroid==2.12.12
     # via sphinx-autoapi
-babel==2.9.1
+babel==2.11.0
     # via sphinx
 beautifulsoup4==4.11.1
     # via
     #   furo
     #   sphinx-code-include
-certifi==2021.10.8
+certifi==2022.9.24
     # via requests
-charset-normalizer==2.0.12
+cfgv==3.3.1
+    # via pre-commit
+charset-normalizer==2.1.1
     # via requests
+distlib==0.3.6
+    # via virtualenv
 docutils==0.17.1
     # via
     #   sphinx
     #   sphinx-panels
     #   sphinx-tabs
+filelock==3.8.0
+    # via virtualenv
 furo @ git+https://github.com/flyteorg/furo@main
     # via -r doc-requirements.in
-idna==3.3
+googleapis-common-protos==1.57.0
+    # via grpcio-status
+grpcio==1.48.2
+    # via
+    #   -r doc-requirements.in
+    #   grpcio-status
+grpcio-status==1.48.2
+    # via -r doc-requirements.in
+identify==2.5.8
+    # via pre-commit
+idna==3.4
     # via requests
-imagesize==1.3.0
+imagesize==1.4.1
     # via sphinx
-importlib-metadata==4.11.3
+importlib-metadata==5.0.0
     # via sphinx
-jinja2==3.1.1
+jinja2==3.0.3
     # via
     #   sphinx
     #   sphinx-autoapi
-lazy-object-proxy==1.7.1
+    #   sphinx-tabs
+lazy-object-proxy==1.8.0
     # via astroid
 markupsafe==2.1.1
     # via jinja2
+nodeenv==1.7.0
+    # via pre-commit
 packaging==21.3
     # via sphinx
-pbr==5.8.1
+pbr==5.11.0
     # via sphinxcontrib-video
-pygments==2.11.2
+platformdirs==2.5.4
+    # via virtualenv
+pre-commit==2.20.0
+    # via sphinx-tags
+protobuf==4.21.9
+    # via
+    #   googleapis-common-protos
+    #   grpcio-status
+pygments==2.13.0
     # via
+    #   furo
     #   sphinx
     #   sphinx-prompt
     #   sphinx-tabs
-pyparsing==3.0.8
+pyparsing==3.0.9
     # via packaging
-pytz==2022.1
+pytz==2022.6
     # via babel
 pyyaml==6.0
-    # via sphinx-autoapi
-requests==2.27.1
+    # via
+    #   pre-commit
+    #   sphinx-autoapi
+requests==2.28.1
     # via sphinx
 six==1.16.0
     # via
+    #   grpcio
     #   sphinx-code-include
     #   sphinxext-remoteliteralinclude
 snowballstemmer==2.2.0
@@ -69,20 +100,23 @@ sphinx==4.5.0
     #   -r doc-requirements.in
     #   furo
     #   sphinx-autoapi
+    #   sphinx-basic-ng
     #   sphinx-code-include
     #   sphinx-copybutton
     #   sphinx-fontawesome
     #   sphinx-issues
     #   sphinx-panels
     #   sphinx-prompt
     #   sphinx-tabs
+    #   sphinx-tags
     #   sphinxcontrib-yt
-    #   sphinxext-remoteliteralinclude
-sphinx-autoapi==1.8.4
+sphinx-autoapi==2.0.0
     # via -r doc-requirements.in
+sphinx-basic-ng==1.0.0b1
+    # via furo
 sphinx-code-include==1.1.1
     # via -r doc-requirements.in
-sphinx-copybutton==0.5.0
+sphinx-copybutton==0.5.1
     # via -r doc-requirements.in
 sphinx-fontawesome==0.0.6
     # via -r doc-requirements.in
@@ -92,7 +126,9 @@ sphinx-panels==0.6.0
     # via -r doc-requirements.in
 sphinx-prompt==1.5.0
     # via -r doc-requirements.in
-sphinx-tabs==3.3.1
+sphinx-tabs==3.4.0
+    # via -r doc-requirements.in
+sphinx-tags==0.1.6
     # via -r doc-requirements.in
 sphinxcontrib-applehelp==1.0.2
     # via sphinx
@@ -112,17 +148,21 @@ sphinxcontrib-video==0.0.1.dev3
     # via -r doc-requirements.in
 sphinxcontrib-yt==0.2.2
     # via -r doc-requirements.in
-sphinxext-remoteliteralinclude==0.3.0
+sphinxext-remoteliteralinclude==0.4.0
     # via -r doc-requirements.in
-typing-extensions==4.1.1
+toml==0.10.2
+    # via pre-commit
+typing-extensions==4.4.0
     # via astroid
-unidecode==1.3.4
+unidecode==1.3.6
     # via sphinx-autoapi
-urllib3==1.26.9
+urllib3==1.26.12
     # via requests
-wrapt==1.14.0
+virtualenv==20.16.7
+    # via pre-commit
+wrapt==1.14.1
     # via astroid
-zipp==3.8.0
+zipp==3.10.0
     # via importlib-metadata
 
 # The following packages are considered to be unsafe in a requirements file:

diff --git a/rsts/community/contribute.rst b/rsts/community/contribute.rst
@@ -1,10 +1,12 @@
 .. _contribute_Flyte:
 
-######################
+#####################
 Contributing to Flyte
-######################
+#####################
 
-Thank you for taking the time to contribute to Flyte! 
+.. tags:: Contribute, Basic
+
+Thank you for taking the time to contribute to Flyte!
 Please read our `Code of Conduct <https://lfprojects.org/policies/code-of-conduct/>`__ before contributing to Flyte.
 
 Here are some guidelines for you to follow, which will make your first and follow-up contributions easier.

diff --git a/rsts/community/troubleshoot.rst b/rsts/community/troubleshoot.rst
@@ -3,6 +3,8 @@
 Troubleshooting Guide
 ---------------------
 
+.. tags:: Troubleshoot, Basic
+
 .. admonition:: Why did we craft this guide?
 
     To help streamline your onboarding experience as much as possible, and sort out common issues.

diff --git a/rsts/concepts/admin.rst b/rsts/concepts/admin.rst
@@ -1,8 +1,10 @@
 .. _divedeep-admin:
 
-###########
+##########
 FlyteAdmin
-###########
+##########
+
+.. tags:: Advanced, Design
 
 Admin Structure
 ===============
@@ -14,7 +16,6 @@ FlyteAdmin serves as the main Flyte API to process all client requests to the sy
 
 Below, we'll dive into each component defined in admin in more detail.
 
-
 RPC
 ---
 

diff --git a/rsts/concepts/architecture.rst b/rsts/concepts/architecture.rst
@@ -4,6 +4,8 @@
 Component Architecture
 ######################
 
+.. tags:: Advanced, Glossary, Design
+
 This document aims to demystify how Flyte's major components ``Flyteidl``, ``Flytekit``, ``Flytectl``, ``FlyteConsole``, ``FlyteAdmin``, ``FlytePropeller``, and ``FlytePlugins`` fit together at a high level.
 
 FlyteIDL

diff --git a/rsts/concepts/catalog.rst b/rsts/concepts/catalog.rst
@@ -3,6 +3,8 @@
 What is Data Catalog?
 =====================
 
+.. tags:: Advanced, Design
+
 `DataCatalog <https://github.com/flyteorg/datacatalog>`__ is a service to index parameterized, strongly-typed data artifacts across revisions. It allows clients to query artifacts based on meta information and tags.
 
 

diff --git a/rsts/concepts/component_architecture/flytepropeller_architecture.rst b/rsts/concepts/component_architecture/flytepropeller_architecture.rst
@@ -4,7 +4,9 @@
 FlytePropeller Architecture
 ###########################
 
-.. note:: 
+.. tags:: Advanced, Design
+
+.. note::
    In the frame of this document, we use the term “workflow” to describe the single execution of a workflow definition.
 
 Introduction
@@ -13,7 +15,7 @@ Introduction
 A Flyte :ref:`workflow <divedeep-workflows>` is represented as a Directed Acyclic Graph (DAG) of interconnected Nodes. Flyte supports a robust collection of Node types to ensure diverse functionality.
 - ``TaskNodes`` support a plugin system to externally add system integrations.
 - Control flow can be altered during runtime using ``BranchNodes``, which prune downstream evaluation paths based on input. 
-- ``DynamicNodes`` add nodes to the DAG. 
+- ``DynamicNodes`` add nodes to the DAG.
 - ``WorkflowNodes`` allow embedding workflows within each other.
 
 FlytePropeller is responsible for scheduling and tracking execution of Flyte workflows. It is implemented using a K8s controller and adheres to the established K8s design principles. In this scheme, resources are periodically evaluated and the goal is to transition from the observed state to a requested state. 

diff --git a/rsts/concepts/component_architecture/native_scheduler_architecture.rst b/rsts/concepts/component_architecture/native_scheduler_architecture.rst
@@ -4,6 +4,8 @@
 Flyte Native Scheduler Architecture
 ###################################
 
+.. tags:: Advanced, Design
+
 Introduction
 ============
 Any workflow engine needs functionality to support scheduled executions. Flyte fulfills this using an in-built native scheduler, which schedules fixed rate and cron-based schedules. The workflow author specifies the schedule during the `launchplan creation <https://docs.flyte.org/projects/cookbook/en/latest/auto/core/scheduled_workflows/lp_schedules.html#cron-schedules>`__ and `activates or deactivates <https://docs.flyte.org/projects/cookbook/en/latest/auto/core/scheduled_workflows/lp_schedules.html#activating-a-schedule>`__ the schedule using the `admin APIs <https://docs.flyte.org/projects/flyteidl/en/latest/protos/docs/admin/admin.html#launchplanupdaterequest>`__ exposed for the launch plan.

diff --git a/rsts/concepts/console.rst b/rsts/concepts/console.rst
@@ -1,8 +1,10 @@
 .. _divedeep-console:
 
-#############
+############
 FlyteConsole
-#############
+############
+
+.. tags:: Intermediate, Contribute
 
 FlyteConsole is the web UI for the Flyte platform. Here's a video that dives into the graph UX:
 

diff --git a/rsts/concepts/data_management.rst b/rsts/concepts/data_management.rst
@@ -4,6 +4,8 @@
 Understand How Flyte Handles Data
 #################################
 
+.. tags:: Basic, Glossary, Design
+
 Types of Data
 =============
 

diff --git a/rsts/concepts/domains.rst b/rsts/concepts/domains.rst
@@ -3,6 +3,8 @@
 Domains
 =======
 
+.. tags:: Basic, Glossary
+
 Domains provide an abstraction to isolate resources and feature configuration for different
 deployment environments. 
 

diff --git a/rsts/concepts/dynamic_spec.rst b/rsts/concepts/dynamic_spec.rst
@@ -3,6 +3,8 @@
 Dynamic Job Spec
 ================
 
+.. tags:: Basic, Design
+
 A dynamic job spec is a subset of the entire workflow spec that defines a set of tasks, workflows, nodes, and output bindings that control how the job should assemble its outputs.
 
 This spec is currently only supported as an intermediate step in running Dynamic Tasks.

diff --git a/rsts/concepts/execution_timeline.rst b/rsts/concepts/execution_timeline.rst
@@ -4,6 +4,8 @@
 Timeline of a workflow execution
 ########################################
 
+.. tags:: Intermediate, Glossary
+
 The illustration below shows the timeline view of a workflow execution. 
 
 .. image:: https://raw.githubusercontent.com/flyteorg/static-resources/main/flyte/deployment/monitoring/flyte_wf_timeline.svg?sanitize=true

diff --git a/rsts/concepts/executions.rst b/rsts/concepts/executions.rst
@@ -3,6 +3,9 @@
 ##########
 Executions
 ##########
+
+.. tags:: Basic, Glossary
+
 **Executions** are instances of workflows, nodes or tasks created in the system as a result of a user-requested execution or a scheduled execution.
 
 Typical Flow Using Flytectl

diff --git a/rsts/concepts/flyte_console.rst b/rsts/concepts/flyte_console.rst
@@ -3,11 +3,13 @@
 How to Use Flyte UI
 ===================
 
+.. tags:: Basic, UI
+
 Flyte UI is a web-based user interface for Flyte. It helps interact with Flyte objects and builds DAGs out of your workflows.
 
 With Flyte UI, you can:
 
-* Launch tasks 
+* Launch tasks
 * Launch workflows
 * View Versioned Tasks and Workflows
 * Trigger Versioned Tasks and Workflows

diff --git a/rsts/concepts/launchplans.rst b/rsts/concepts/launchplans.rst
@@ -1,7 +1,10 @@
 .. _divedeep-launchplans:
-  
+
 Launch plans
-=============
+============
+
+.. tags:: Basic, Glossary, Design
+
 Launch plans help execute workflows. A workflow can be associated with multiple launch plans and launch plan versions, but an individual launch plan is always associated with a single, specific workflow. After creating a launch plan, it is easy to share and execute them.
 
 Launch plans provide a way to templatize Flyte workflow invocations. Launch plans contain a set of bound workflow inputs that are passed as arguments to create an execution. Launch plans do not necessarily contain the entire set of required workflow inputs, but a launch plan is always necessary to trigger an execution. Additional input arguments can be provided at execution time to supplement launch plan static input values.
@@ -11,7 +14,8 @@ plan can optionally define a single schedule (which can be easily disabled by di
 optional notifications. Refer to the :ref:`deployment-cluster-config-notifications` for a deep dive into available notifications.
 
 The Association between Workflows and LaunchPlans
---------------------------------------------------
+-------------------------------------------------
+
 Every workflow comes with a `default` launch plan that has the same name as that of a workflow. The default launch plan is authored (in code) as part of creating a new workflow.
 A launch plan version can only ever be mapped to one workflow version; meaning a launch plan version cannot be used twice. This is because part of what makes a new launch plan version is the mapping to the specific workflow version.
 

diff --git a/rsts/concepts/nodes.rst b/rsts/concepts/nodes.rst
@@ -3,6 +3,8 @@
 Nodes
 =====
 
+.. tags:: Basic, Glossary
+
 A node represents a unit of execution or work within a workflow. Ordinarily, a node encapsulates an instance of 
 a :ref:`task <divedeep-tasks>`, but it can also contain an entire subworkflow or trigger an external workflow. 
 Nodes can have inputs and outputs, which are used to coordinate task inputs and outputs. 

diff --git a/rsts/concepts/projects.rst b/rsts/concepts/projects.rst
@@ -2,6 +2,9 @@
 
 Projects
 ========
+
+.. tags:: Basic, Glossary
+
 A project in Flyte is a group of :ref:`workflows <divedeep-workflows>` and :ref:`tasks <divedeep-tasks>` tied together to achieve a goal. 
 
 A Flyte project can map to an engineering project or everything that's owned by a team or an individual. There cannot be multiple projects with the same name in Flyte.
-Original file line number
+Diff line change
@@ Expand Up / @@ -30,3 +30,4 @@ dist @@
     *.db
     vendor/
     /docker/sandbox-bundled/images/tar
+    rsts/_tags/