From 704e662879b1a0b2892b3bfdb436dfdb1eea9108 Mon Sep 17 00:00:00 2001 From: colton Date: Wed, 4 Sep 2024 09:31:13 -0400 Subject: [PATCH] [docathon] vale clean-up pass #1 (#24180) ## Summary & Motivation - Fixes linting errors thrown by Vale (36 errors remain, but many are TODOs or false-positives) ## How I Tested These Changes - Running `vale` locally ## Changelog [New | Bug | Docs] NOCHANGELOG --- docs/.vale.ini | 32 +++++- docs/docs-beta/docs/about/community.md | 12 +-- .../access/authentication/azure-ad-sso.md | 10 +- .../access/authentication/pingone-sso.md | 2 +- .../docs/dagster-plus/access/rbac/users.md | 6 +- .../setting-up-branch-deployments.md | 10 +- .../dagster-plus/deployment/code-locations.md | 8 +- .../code-locations/code-location-history.md | 2 +- .../environment-variables/dagster-ui.md | 4 +- .../deployment/hybrid/agents/kubernetes.md | 6 +- .../deployment/hybrid/architecture.md | 4 +- .../serverless/runtime-environment.md | 5 +- .../getting-started/code-requirements.md | 2 +- docs/docs-beta/docs/guides/automation.md | 8 +- .../data-modeling/asset-dependencies.md | 2 +- .../asset-factories-with-deps.md | 2 +- .../docs/guides/data-modeling/data-assets.md | 4 +- .../docs/guides/data-modeling/metadata.md | 10 +- .../docs/guides/data-modeling/partitioning.md | 14 +-- .../docs/guides/deployment/docker.md | 14 +-- .../docs/guides/deployment/kubernetes.md | 2 +- .../guides/external-systems/non-python.md | 6 +- .../docs/guides/external-systems/pipes.md | 4 +- .../ingesting-data.md | 8 +- .../ingestion-transformation/transform-dbt.md | 2 +- .../docs/guides/project-structure.md | 4 +- .../docs/guides/tbd/selection-syntax.md | 4 +- docs/vale/styles/Dagster/acronyms.yml | 26 ++++- docs/vale/styles/Dagster/headings-casing.yml | 29 ++++-- docs/vale/styles/Terms/engineering.yml | 2 +- .../config/vocabularies/Dagster/accept.txt | 99 ++++++++++--------- 31 files changed, 205 insertions(+), 138 deletions(-) diff --git a/docs/.vale.ini b/docs/.vale.ini index 896897ec2950b..107a1d88d499b 100644 --- a/docs/.vale.ini +++ b/docs/.vale.ini @@ -26,11 +26,33 @@ mdx = md # FORMAT-SPECIFIC # ######################## -[*.{md,mdx,rst}] -# Rules in this section are enforced in all md, mdx, and rst files - [*.{md,mdx,rst}] BasedOnStyles = Dagster, Terms, Vale -; Ignore all :py directives -IgnorePatterns = (:py:[^`]+`[^`]+`) \ No newline at end of file +; References: +; - https://vale.sh/docs/topics/scoping/#non-standard-markup +; - https://github.com/errata-ai/vale/blob/871dafd1e24500cee9d8ad82b25d42a136bb2103/testdata/fixtures/patterns/_vale#L14 + +; Pattern : (\\\{[^\n]+\}) +; Regex101 : https://regex101.com/r/GOx8Z6/2 +; Description : Ignore heading anchor renames + +; Description : Ignore code snippets +; Pattern : (`[^\n^`]+`) +; Regex101 : https://regex101.com/r/c5EE6S/1 + +; Pattern : \[.*\](\(.*\)) +; Regex101 : https://regex101.com/r/GOx8Z6/3 +; Description : Ignore link HREFs + +; Additionally, we include TokenIgnores of `` and `` to strip these HTML elements, +; because when these wrap markdown it causes the markdown linting to fail. For example, code blocks +; within a tab item. + +TokenIgnores = (`[^`]*`), \ + (\[.*\]\([^)]+\)), \ + (\\\{[^}]+\}), \ + (<\/?TabItem.*>), \ + (<\/?Tabs.*>), \ + (), \ + (.*<\/summary>) diff --git a/docs/docs-beta/docs/about/community.md b/docs/docs-beta/docs/about/community.md index dbea9925b23dc..830fd0f01dc44 100644 --- a/docs/docs-beta/docs/about/community.md +++ b/docs/docs-beta/docs/about/community.md @@ -21,7 +21,7 @@ Dagster itself, defined as the code and intellectual property in the [Dagster pu ### Our pledge -As members, contributors, and core team members, we pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation. +As members, contributors, and core team members, we pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible, or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation. We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. @@ -45,9 +45,9 @@ Examples of unacceptable behavior include: ### Slack content guidelines -The Dagster core team will do its best to respond to every message but can't guarantee a response to everyone. Please don't treat the community as your own personal customer support service. +The Dagster core team will do its best to respond to every message but can't guarantee a response to everyone. Don't treat the community as your own personal customer support service. -Community members are expected to follow the guidelines for discussion in the Dagster community. Please make an effort to contribute quality content so that our community can spend more time hanging out and talking about issues rather than cleaning and filtering our communication channels. +Community members are expected to follow the guidelines for discussion in the Dagster community. Make an effort to contribute quality content so that our community can spend more time hanging out and talking about issues rather than cleaning and filtering our communication channels. - Start discussions in the [right channels](https://app.slack.com/client/TCDGQDUKF/browse-channels) - Craft questions with sufficient detail to reproduce issues or address any concerns @@ -79,12 +79,12 @@ The Dagster core team will follow these Community Impact Guidelines in determini | Level | Community impact | Consequence | |---|----|----| | Reminder | Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community. | A private, written reminder from the Dagster core team, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. | -| Warning | A violation through a single incident or series of actions. | A warning with consequencyarn lints for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces and external channels like social media. Violating these terms will lead to a permanent ban. | +| Warning | A violation through a single incident or series of actions. | A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces and external channels like social media. Violating these terms will lead to a permanent ban. | | Permanent ban | Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. | A permanent ban from any sort of public interaction within the community. | ### Attribution -- This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org/), version 2.0, available [here](https://www.contributor-covenant.org/version/2/0/code_of_conduct.html). +- This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org/), version 2.0, available at: [Contributor Covenant Code of Conduct](https://www.contributor-covenant.org/version/2/0/code_of_conduct.html). - Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity). - Content Guidelines were inspired by [Discourse's FAQ for public discussion](https://meta.discourse.org/faq) and [dbt's Rules of the Road](https://docs.getdbt.com/docs/contributing/slack-rules-of-the-road). -- For answers to common questions about this code of conduct, see the [Contributor Covenant FAQ](https://www.contributor-covenant.org/faq). Translations are available [here](https://www.contributor-covenant.org/translations). \ No newline at end of file +- For answers to common questions about this code of conduct, see the [Contributor Covenant FAQ](https://www.contributor-covenant.org/faq), or the [Contributor Covenant Translations](https://www.contributor-covenant.org/translations). diff --git a/docs/docs-beta/docs/dagster-plus/access/authentication/azure-ad-sso.md b/docs/docs-beta/docs/dagster-plus/access/authentication/azure-ad-sso.md index 436a1ef3a48b1..316f793c67ca0 100644 --- a/docs/docs-beta/docs/dagster-plus/access/authentication/azure-ad-sso.md +++ b/docs/docs-beta/docs/dagster-plus/access/authentication/azure-ad-sso.md @@ -21,7 +21,7 @@ To complete the steps in this guide, you'll need: -## Step 1: Add the Dagster+ app in Azure AD \{#dagster-app} +## Step 1: add the Dagster+ app in Azure AD \{#dagster-app} In this step, you'll add the Dagster+ app to your list of managed SaaS apps in Azure AD. @@ -32,7 +32,7 @@ In this step, you'll add the Dagster+ app to your list of managed SaaS apps in A 5. In the **Add from the gallery** section, type **Dagster+** in the search box. 6. Select **Dagster+** from the results panel and then add the app. Wait a few seconds while the app is added to your tenant. -## Step 2: Configure SSO in Azure AD \{#configure-sso} +## Step 2: configure SSO in Azure AD \{#configure-sso} In this step, you'll configure and enable SSO for Azure AD in your Azure portal. @@ -65,7 +65,7 @@ In this step, you'll configure and enable SSO for Azure AD in your Azure portal. When prompted, save the SAML metadata file to your computer. -## Step 3: Upload the SAML metadata to Dagster+ \{#upload-saml} +## Step 3: upload the SAML metadata to Dagster+ \{#upload-saml} After you've downloaded the SAML metadata file, upload it to Dagster+ using the `dagster-cloud` CLI: @@ -75,7 +75,7 @@ dagster-cloud organization settings saml upload-identity-provider-metadata .dagster.cloud ``` -## Step 4: Create a test user \{#test-user} +## Step 4: create a test user \{#test-user} In this section, you'll create a test user in the Azure portal. @@ -92,4 +92,4 @@ import TestSSO from '../../../partials/\_TestSSO.md'; -Click **Test this application** in the Azure portal. If successful, you'll be automatically signed into your Dagster+ organization. \ No newline at end of file +Click **Test this application** in the Azure portal. If successful, you'll be automatically signed into your Dagster+ organization. diff --git a/docs/docs-beta/docs/dagster-plus/access/authentication/pingone-sso.md b/docs/docs-beta/docs/dagster-plus/access/authentication/pingone-sso.md index 3070a9a9df48f..f1de2b97008e2 100644 --- a/docs/docs-beta/docs/dagster-plus/access/authentication/pingone-sso.md +++ b/docs/docs-beta/docs/dagster-plus/access/authentication/pingone-sso.md @@ -49,7 +49,7 @@ To complete the steps in this guide, you'll need: 2. When finished, click **Save and Continue.** 2. In the **Configure SAML** page: 1. Fill in the following: - - **ACS URLS** and **Entity ID**: Copy and paste the following URL, replacing `` with your Dagster+ organization name: + - **ACS URLs** and **Entity ID**: Copy and paste the following URL, replacing `` with your Dagster+ organization name: ``` https://.dagster.cloud/auth/saml/consume diff --git a/docs/docs-beta/docs/dagster-plus/access/rbac/users.md b/docs/docs-beta/docs/dagster-plus/access/rbac/users.md index e3842f7dc4237..ea1d531250459 100644 --- a/docs/docs-beta/docs/dagster-plus/access/rbac/users.md +++ b/docs/docs-beta/docs/dagster-plus/access/rbac/users.md @@ -42,13 +42,13 @@ After the user is created, you can [add the user to teams and assign user roles After a user is created, the **Manage user permissions** window will automatically display. You can also access this window by clicking **Edit** next to a user in the users table. -TODO: Add picture previously at "/images/dagster-cloud/user-token-management/manage-new-user-permissions.png" +{/* TODO: Add picture previously at "/images/dagster-cloud/user-token-management/manage-new-user-permissions.png" */} ### Adding users to teams Using the **Teams** field, you can add users to one or more teams. This is useful for centralizing permission sets for different types of users. Refer to the [Managing teams](/dagster-plus/access/rbac/teams) guide for more info about creating and managing teams. -TODO: Add picture previously at "/images/dagster-cloud/user-token-management/add-user-to-teams.png +{/* TODO: Add picture previously at "/images/dagster-cloud/user-token-management/add-user-to-teams.png */} **Note**: When determining a user's level of access, Dagster+ will use the **most permissive** role assigned to the user between all of their team memberships and any individual role grants. Refer to the [Managing user roles and permissions](/dagster-plus/access/rbac/user-roles-permissions) guide for more info. @@ -89,4 +89,4 @@ Removing a user removes them from the organization. **Note**: If using a SAML-ba - Learn more about role-based access control (RBAC) in [Understanding User Roles & Permissions](/dagster-plus/access/rbac/user-roles-permissions) - Learn more about how to manage teams in Dagster+ in [Understanding Team Management in Dagster+](/dagster-plus/access/rbac/teams) - Learn more about SCIM provisioning in [Understanding SCIM Provisioning](/dagster-plus/access/authentication/scim-provisioning) -- Learn more about authentication in [Understanding Authentication](/dagster-plus/access/authentication) \ No newline at end of file +- Learn more about authentication in [Understanding Authentication](/dagster-plus/access/authentication) diff --git a/docs/docs-beta/docs/dagster-plus/deployment/branch-deployments/setting-up-branch-deployments.md b/docs/docs-beta/docs/dagster-plus/deployment/branch-deployments/setting-up-branch-deployments.md index 4eebd1a2bdcdb..d634e8b6dbea0 100644 --- a/docs/docs-beta/docs/dagster-plus/deployment/branch-deployments/setting-up-branch-deployments.md +++ b/docs/docs-beta/docs/dagster-plus/deployment/branch-deployments/setting-up-branch-deployments.md @@ -249,7 +249,7 @@ The last step is to verify that the GitHub Action runs successfully. -### Step 4.1: Add GitLab CI/CD script to your project +### Step 4.1: add GitLab CI/CD script to your project :::note If you used the GitLab app to configure you're repository, this step isn't required. [Skip ahead to Step 4.5](#step-45-verify-gitlab-pipeline-runs) @@ -263,7 +263,7 @@ Copy the following files to your project, and **replace** all references to `qui In the next step, you'll modify these files to work with your Dagster+ setup. -### Step 4.2: Add the agent registry to dagster_cloud.yaml +### Step 4.2: add the agent registry to dagster_cloud.yaml :::note If you used the GitLab app to configure you're repository, this step isn't required. [Skip ahead to Step 4.5](#step-45-verify-gitlab-pipeline-runs) @@ -276,7 +276,7 @@ For example: -### Step 4.3: Configure GitLab CI/CD variables +### Step 4.3: configure GitLab CI/CD variables :::note If you used the GitLab app to configure you're repository, this step isn't required. [Skip ahead to Step 4.5](#step-45-verify-gitlab-pipeline-runs) @@ -330,7 +330,7 @@ Repeat steps 3-6 for each of the secrets required for your registry type: -### Step 4.4: Configure GitLab CI/CD script +### Step 4.4: configure GitLab CI/CD script :::note If you used the GitLab app to configure you're repository, this step isn't required. [Skip ahead to Step 4.5](#step-45-verify-gitlab-pipeline-runs) @@ -350,7 +350,7 @@ build-image: Save and commit the files to the project. -### Step 4.5: Verify GitLab pipeline runs +### Step 4.5: verify GitLab pipeline runs The last step is to verify that the GitLab pipeline runs successfully. diff --git a/docs/docs-beta/docs/dagster-plus/deployment/code-locations.md b/docs/docs-beta/docs/dagster-plus/deployment/code-locations.md index 1e6c0ba8952fa..5a9a7af6b7fda 100644 --- a/docs/docs-beta/docs/dagster-plus/deployment/code-locations.md +++ b/docs/docs-beta/docs/dagster-plus/deployment/code-locations.md @@ -98,8 +98,8 @@ To get started, review the appropriate example repository and then create your G - [GitHub repository with Dagster+ Serverless](https://github.com/dagster-io/dagster-cloud-serverless-quickstart/) - [GitHub repository with Dagster+ Hybrid](https://github.com/dagster-io/dagster-cloud-hybrid-quickstart/) -- [Gitlab CI/CD for Dagster+ Serverless](https://github.com/dagster-io/dagster-cloud-action/blob/main/gitlab/serverless-ci.yml) -- [Gitlab CI/CD for Dagster+ Hybrid](https://github.com/dagster-io/dagster-cloud-action/blob/main/gitlab/hybrid-ci.yml) +- [GitLab CI/CD for Dagster+ Serverless](https://github.com/dagster-io/dagster-cloud-action/blob/main/gitlab/serverless-ci.yml) +- [GitLab CI/CD for Dagster+ Hybrid](https://github.com/dagster-io/dagster-cloud-action/blob/main/gitlab/hybrid-ci.yml) Overall, the Git repository should contain: @@ -133,7 +133,7 @@ Overall, the Git repository should contain: package_name: quickstart ``` -3. A CI/CD workflow file that contains the steps for adding your code location. These are the same steps outlined in the preceding section. Here is a minimal example workflow file for a Dagster+ Hybrid organization based on [this Gitlab template](https://github.com/dagster-io/dagster-cloud-action/blob/main/gitlab/hybrid-ci.yml). +3. A CI/CD workflow file that contains the steps for adding your code location. These are the same steps outlined in the preceding section. Here is a minimal example workflow file for a Dagster+ Hybrid organization based on [this GitLab template](https://github.com/dagster-io/dagster-cloud-action/blob/main/gitlab/hybrid-ci.yml). ```yaml variables: @@ -236,4 +236,4 @@ The monorepo should have CI/CD configured to deploy your changes and add or upda ## Next steps - After adding a code location, you may want to setup access controls -- You may want to add additional configuration to your code location. This configuration will vary by agent type, but see examples for [setting default resource limits for Kubernetes](/dagster-plus/deployment/hybrid/agents/kubernetes) or [changing the IAM role for ECS](/todo). \ No newline at end of file +- You may want to add additional configuration to your code location. This configuration will vary by agent type, but see examples for [setting default resource limits for Kubernetes](/dagster-plus/deployment/hybrid/agents/kubernetes) or [changing the IAM role for ECS](/todo). diff --git a/docs/docs-beta/docs/dagster-plus/deployment/code-locations/code-location-history.md b/docs/docs-beta/docs/dagster-plus/deployment/code-locations/code-location-history.md index b2f346fc1eae3..859276d42368c 100644 --- a/docs/docs-beta/docs/dagster-plus/deployment/code-locations/code-location-history.md +++ b/docs/docs-beta/docs/dagster-plus/deployment/code-locations/code-location-history.md @@ -31,7 +31,7 @@ Before continuing, you should be familiar with: ![Screenshot highlighting the "Updated" column for a code location](/img/placeholder.svg) -This will bring up a modal showing a history of every time that code location has been loaded, and metadata associated with that load. If you have connected Dagster+ to a GitHub or Gitlab repository, each row will have a link to the commit that was deployed at that point in time. +This will bring up a modal showing a history of every time that code location has been loaded, and metadata associated with that load. If you have connected Dagster+ to a GitHub or GitLab repository, each row will have a link to the commit that was deployed at that point in time. If a code location has been deployed multiple times with identical metadata, these rows will be collapsed together. You can expand them by deselecting **Collapse similar entries** in the top left corner of the modal. diff --git a/docs/docs-beta/docs/dagster-plus/deployment/environment-variables/dagster-ui.md b/docs/docs-beta/docs/dagster-plus/deployment/environment-variables/dagster-ui.md index 84620442fc8f9..af1ca03d14376 100644 --- a/docs/docs-beta/docs/dagster-plus/deployment/environment-variables/dagster-ui.md +++ b/docs/docs-beta/docs/dagster-plus/deployment/environment-variables/dagster-ui.md @@ -41,7 +41,9 @@ Before you begin, use the deployment switcher to select the right deployment. - **Code Location Scope** - select the code location(s) where the variable should be accessible. At least one code location is required. - ![TODO](/img/placeholder.svg) +{/* TODO replace placeholder image */} + +![Screenshot of adding environment variables](/img/placeholder.svg) 3. Click **Save** diff --git a/docs/docs-beta/docs/dagster-plus/deployment/hybrid/agents/kubernetes.md b/docs/docs-beta/docs/dagster-plus/deployment/hybrid/agents/kubernetes.md index c58794e964061..d88b09739578b 100644 --- a/docs/docs-beta/docs/dagster-plus/deployment/hybrid/agents/kubernetes.md +++ b/docs/docs-beta/docs/dagster-plus/deployment/hybrid/agents/kubernetes.md @@ -20,7 +20,7 @@ You'll also need access to a container registry to which you can push images and We recommend installing the Dagster+ agent using [Helm](https://helm.sh). -## Step 1: Create a Kubernetes namespace +## Step 1: create a Kubernetes namespace ```shell kubectl create namespace dagster-cloud @@ -113,11 +113,11 @@ helm --namespace dagster-cloud upgrade agent \ --values ./values.yaml ``` -## Troubleshooting Tips +## Troubleshooting tips You can see basic health information about your agent in the Dagster+ UI: -TODO: Screenshot +{/* TODO: Screenshot */} ### View logs diff --git a/docs/docs-beta/docs/dagster-plus/deployment/hybrid/architecture.md b/docs/docs-beta/docs/dagster-plus/deployment/hybrid/architecture.md index a209d1e82a17f..4f5199a9d1dd4 100644 --- a/docs/docs-beta/docs/dagster-plus/deployment/hybrid/architecture.md +++ b/docs/docs-beta/docs/dagster-plus/deployment/hybrid/architecture.md @@ -49,9 +49,9 @@ All user code runs within your environment, in isolation from Dagster system cod ## The agent -Because the agent communicates with the Dagster+ control plane over the agent API, it’s possible to support agents that operate in arbitrary compute environments. +Because the agent communicates with the Dagster+ control plane over the agent API, it's possible to support agents that operate in arbitrary compute environments. -This means that over time, Dagster+’s support for different user deployment environments will expand and custom agents can take advantage of bespoke compute environments such as HPC. +This means that over time, Dagster+'s support for different user deployment environments will expand and custom agents can take advantage of bespoke compute environments such as HPC. Refer to the [Agents documentation](/todo) for more info, including the agents that are currently supported. diff --git a/docs/docs-beta/docs/dagster-plus/deployment/serverless/runtime-environment.md b/docs/docs-beta/docs/dagster-plus/deployment/serverless/runtime-environment.md index 99e582883953d..810dac8ec7f4c 100644 --- a/docs/docs-beta/docs/dagster-plus/deployment/serverless/runtime-environment.md +++ b/docs/docs-beta/docs/dagster-plus/deployment/serverless/runtime-environment.md @@ -49,7 +49,7 @@ When possible, you should add dependencies by including the corresponding Python When adding dependencies with the `setup.py` file isn't possible, you can build a custom base image: :::note -Setting a custom base image is not supported for GitLab CI/CD workflows out of the box, but you can write a custom GitLab CI/CD yaml file that implements the manual steps noted. +Setting a custom base image isn't supported for GitLab CI/CD workflows out of the box, but you can write a custom GitLab CI/CD yaml file that implements the manual steps noted. ::: 1. Include `dagster-cloud[serverless]` as a dependency in your Docker image by adding the following line to your `Dockerfile`: @@ -99,6 +99,7 @@ If you want to include the data folder, modify your `setup.py` to add the `packa ## Disable PEX deploys \{#disable-pex} + Prior to using PEX files, Dagster+ deployed code using Docker images. This feature is still available. You can disable PEX in your GitHub or GitLab workflow, or by using the `dagster-cloud` CLI. @@ -163,4 +164,4 @@ Setting a custom base image isn't supported for GitLab CI/CD workflows out of th - \ No newline at end of file + diff --git a/docs/docs-beta/docs/dagster-plus/getting-started/code-requirements.md b/docs/docs-beta/docs/dagster-plus/getting-started/code-requirements.md index ce02088b425dc..4de13201cdd03 100644 --- a/docs/docs-beta/docs/dagster-plus/getting-started/code-requirements.md +++ b/docs/docs-beta/docs/dagster-plus/getting-started/code-requirements.md @@ -26,7 +26,7 @@ To work with Dagster+, your Dagster code: - **Must run in an environment where the `dagster` and `dagster-cloud` 0.13.2 or later Python packages are installed.** -Additionally, note that: +**Note**: - Different code locations can use different versions of Dagster - Dagster+ doesn't require a [`workspace.yaml` file](/todo). You can still create a `workspace.yaml` file to load your code in an open source Dagster webserver instance, but doing so won't affect how your code is loaded in Dagster+. diff --git a/docs/docs-beta/docs/guides/automation.md b/docs/docs-beta/docs/guides/automation.md index 33be9a06c6734..a54014b37e9b5 100644 --- a/docs/docs-beta/docs/guides/automation.md +++ b/docs/docs-beta/docs/guides/automation.md @@ -79,7 +79,7 @@ For more examples of how to create asset sensors, see the [How-To Use Asset Sens ## Declarative Automation -TODO: add content +{/* TODO: add content */} ## How to choose the right automation method @@ -101,8 +101,8 @@ Use this table to help guide your decision: ## Next steps -- Learn more about [advanced scheduling patterns] - TODO ADD LINK -- Explore [complex sensor examples] - TODO ADD LINK -- Dive into [Declarative Automation best practices] - TODO ADD LINK +- Learn more about [advanced scheduling patterns] - {/* TODO ADD LINK */} +- Explore [complex sensor examples] - {/* TODO ADD LINK */} +- Dive into [Declarative Automation best practices] - {/* TODO ADD LINK */} By understanding and effectively using these automation methods, you can build more efficient data pipelines that respond to your specific needs and constraints. diff --git a/docs/docs-beta/docs/guides/data-modeling/asset-dependencies.md b/docs/docs-beta/docs/guides/data-modeling/asset-dependencies.md index eb00da86270b3..7e0f0c97c77c2 100644 --- a/docs/docs-beta/docs/guides/data-modeling/asset-dependencies.md +++ b/docs/docs-beta/docs/guides/data-modeling/asset-dependencies.md @@ -119,4 +119,4 @@ The downsides of this approach are: ## Related resources -TODO: add links to relevant API documentation here. +{/* TODO: add links to relevant API documentation here. */} diff --git a/docs/docs-beta/docs/guides/data-modeling/asset-factories-with-deps.md b/docs/docs-beta/docs/guides/data-modeling/asset-factories-with-deps.md index 5b671f79b1317..8e45694b6c63c 100644 --- a/docs/docs-beta/docs/guides/data-modeling/asset-factories-with-deps.md +++ b/docs/docs-beta/docs/guides/data-modeling/asset-factories-with-deps.md @@ -27,7 +27,7 @@ This guide builds upon the concepts in the [asset factories](/guides/data-modeli ## Building an asset factory in Python -Imagine a data analytics team that maintains a large number of tables. In order to support analytics needs, the team runs queries and constructs new tables from the results. +Imagine a data analytics team that maintains a large number of tables. To support analytics needs, the team runs queries and constructs new tables from the results. Each table can be represented in YAML by a name, upstream asset dependencies, and a query: diff --git a/docs/docs-beta/docs/guides/data-modeling/data-assets.md b/docs/docs-beta/docs/guides/data-modeling/data-assets.md index 6744b7f48d093..f7bb63fb45f70 100644 --- a/docs/docs-beta/docs/guides/data-modeling/data-assets.md +++ b/docs/docs-beta/docs/guides/data-modeling/data-assets.md @@ -36,7 +36,7 @@ Dagster has four types of asset decorators: ## Defining operations that create a single asset \{#single-asset} -The simplest way to define a data asset in Dagster is by using the `@asset` decorator. This decorator marks a Python function as an asset. +The simplest way to define a data asset in Dagster is by using the `@asset` decorator. This decorator marks a Python function as an asset. @@ -81,4 +81,4 @@ flowchart LR - Learn to create [dependencies between assets](/guides/data-modeling/asset-dependencies) - Enrich Dagster's built-in data catalog with [asset metadata](/guides/data-modeling/metadata) -- Learn to use a [factory pattern](/guides/data-modeling/asset-factories) to create multiple, similar assets \ No newline at end of file +- Learn to use a [factory pattern](/guides/data-modeling/asset-factories) to create multiple, similar assets diff --git a/docs/docs-beta/docs/guides/data-modeling/metadata.md b/docs/docs-beta/docs/guides/data-modeling/metadata.md index 8a9265df831d5..6f7bf76a5399c 100644 --- a/docs/docs-beta/docs/guides/data-modeling/metadata.md +++ b/docs/docs-beta/docs/guides/data-modeling/metadata.md @@ -54,7 +54,7 @@ Here's an example of some tags you might apply to an asset: {"domain": "marketing", "pii": "true"} ``` -**Metadata** allows you to attach rich information to the asset, like a Markdown description, a table schema, or a time series. Metadata is more flexible than tags, as it can store more complex information. Metadata can be attached to an asset at definition time (that is, when the code is first imported) or at runtime (every time an asset is materialized). +**Metadata** allows you to attach rich information to the asset, like a Markdown description, a table schema, or a time series. Metadata is more flexible than tags, as it can store more complex information. Metadata can be attached to an asset at definition time (that's, when the code is first imported) or at runtime (every time an asset is materialized). Here's an example of some metadata you might apply to an asset: @@ -98,7 +98,7 @@ Some metadata keys will be given special treatment in the Dagster UI. | Key | Description | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `dagster/uri` | **Type:** `str`

The URI for the asset, e.g. "s3://my_bucket/my_object" | +| `dagster/uri` | **Type:** `str`

The URI for the asset, for example: "s3://my_bucket/my_object" | | `dagster/column_schema` | **Type:** [`TableSchema`](/todo)

For an asset that's a table, the schema of the columns in the table. Refer to the [Table and column metadata](#table-and-column-metadata) section for details. | | `dagster/column_lineage` | **Type:** [`TableColumnLineage`](/todo)

For an asset that's a table, the lineage of column inputs to column outputs for the table. Refer to the [Table and column metadata](#table-and-column-metadata) section for details. | | `dagster/row_count` | **Type:** `int`

For an asset that's a table, the number of rows in the table. Refer to the Table metadata documentation for details. | @@ -108,7 +108,7 @@ Some metadata keys will be given special treatment in the Dagster UI. ## Table and column metadata -Two of the most powerful metadata types are [`TableSchema`](/todo) and [`TableColumnLineage`](/todo). These metadata types allow stakeholders to view the schema of a table right within Dagster, and, in Dagster+, navigate the [Asset catalog](/todo) via the column lineage. +Two of the most powerful metadata types are [`TableSchema`](/todo) and [`TableColumnLineage`](/todo). These metadata types allow stakeholders to view the schema of a table right within Dagster, and, in Dagster+, navigate the [Asset catalog](/todo) with the column lineage. ### Table schema metadata @@ -165,7 +165,7 @@ If you want to customize how code references are attached - such as when you are -Dagster+ can automatically annotate your assets with code references to source control such as GitHub or Gitlab. +Dagster+ can automatically annotate your assets with code references to source control such as GitHub or GitLab. @@ -176,7 +176,7 @@ If you aren't using Dagster+, you can annotate your assets with code references -[`link_code_references_to_git`](/todo) currently supports GitHub and Gitlab repositories. It also supports customization of how file paths are mapped; see the [`AnchorBasedFilePathMapping`](/todo) API docs for more information. +[`link_code_references_to_git`](/todo) currently supports GitHub and GitLab repositories. It also supports customization of how file paths are mapped; see the [`AnchorBasedFilePathMapping`](/todo) API docs for more information. diff --git a/docs/docs-beta/docs/guides/data-modeling/partitioning.md b/docs/docs-beta/docs/guides/data-modeling/partitioning.md index b05021d067cea..a85edf8b63870 100644 --- a/docs/docs-beta/docs/guides/data-modeling/partitioning.md +++ b/docs/docs-beta/docs/guides/data-modeling/partitioning.md @@ -57,7 +57,7 @@ In this example: - We defined `region_partitions` using `StaticPartitionsDefinition` with a list of regions. - The `regional_sales_data` and `daily_sales_summary` are defined with the same partitioning scheme. -TODO: Link to Backfill page to explain how to backfill reginonal sales data +{/* TODO: Link to Backfill page to explain how to backfill regional sales data */} ### Define two-dimensional partitions @@ -94,25 +94,25 @@ Partitioned assets in Dagster can have dependencies on other partitioned assets. - A downstream asset can depend on one or more partitions of an upstream asset - The partitioning schemes don't need to be identical, but they should be compatible -TODO +{/* TODO */} ### Dependencies between time-based and static partitions Combining time-based and static partitions allows you to analyze data across both temporal and categorical dimensions. This is particularly useful for scenarios like regional time series analysis. -TODO +{/* TODO */} ### Dependencies between time-based and dynamic partitions -TODO +{/* TODO */} ### Dependencies between time-based partitions and un-partitioned assets -TODO +{/* TODO */} -## Integrating Dagster Partitions with External Systems: Incremental Models and dbt +## Integrating Dagster partitions with external systems: incremental models and dbt -TODO +{/* TODO */} ## Next steps diff --git a/docs/docs-beta/docs/guides/deployment/docker.md b/docs/docs-beta/docs/guides/deployment/docker.md index ecbd63af5c8b8..b4c6534039614 100644 --- a/docs/docs-beta/docs/guides/deployment/docker.md +++ b/docs/docs-beta/docs/guides/deployment/docker.md @@ -3,13 +3,13 @@ title: "Deploying with Docker Compose" description: A guide to deploying Dagster with Docker Compose. --- -This guide provides instructions for deploying Dagster using Docker Compose. This is useful when you want to, for example, deploy Dagster on an AWS EC2 host. A typical Dagster Docker deployment includes a several long-running containers: one for the web server, one for the daemon, and one for each code location. It also typically executes each run in its own container. +This guide provides instructions for deploying Dagster using Docker Compose. This is useful when you want to, for example, deploy Dagster on an AWS EC2 host. A typical Dagster Docker deployment includes a several long-running containers: one for the webserver, one for the daemon, and one for each code location. It also typically executes each run in its own container. ## What you'll learn - The different Docker containers that run as part of a Dagster Docker deployment - How to define Docker images for each of these containers -- How to write a docker-compose file that stands up these containers +- How to write a Docker Compose file that stands up these containers
Prerequisites @@ -19,9 +19,9 @@ This guide provides instructions for deploying Dagster using Docker Compose. Thi
-## Define a Docker image for the Dagster web server and daemon +## Define a Docker image for the Dagster webserver and daemon -The Dagster web server and daemon are the two _host processes_ in a Dagster deployment. They typically each run in their own container, using the same Docker image. This image contains Dagster packages and configuration, but no user code. +The Dagster webserver and daemon are the two _host processes_ in a Dagster deployment. They typically each run in their own container, using the same Docker image. This image contains Dagster packages and configuration, but no user code. To build this Docker image, use a Dockerfile like the following, with a name like `Dockerfile_dagster`: @@ -46,7 +46,7 @@ WORKDIR $DAGSTER_HOME ``` Additionally, the following files should be in the same directory as the Docker file: -- A `workspace.yaml` to tell the web server and daemon the location of the code servers +- A `workspace.yaml` to tell the webserver and daemon the location of the code servers - A `dagster.yaml` to configure the Dagster instance ## Define a Docker image for each code location @@ -74,9 +74,9 @@ EXPOSE 4000 CMD ["dagster", "code-server", "start", "-h", "0.0.0.0", "-p", "4000", "-f", "definitions.py"] ``` -## Write a docker-compose file +## Write a Docker Compose file -The following `docker-compose.yaml` defines how to run the web server container, daemon container, code location containers, and database container: +The following `docker-compose.yaml` defines how to run the webserver container, daemon container, code location containers, and database container: ```yaml title="docker-compose.yaml" version: "3.7" diff --git a/docs/docs-beta/docs/guides/deployment/kubernetes.md b/docs/docs-beta/docs/guides/deployment/kubernetes.md index a0fc3bc708424..e169333d6ea9a 100644 --- a/docs/docs-beta/docs/guides/deployment/kubernetes.md +++ b/docs/docs-beta/docs/guides/deployment/kubernetes.md @@ -191,7 +191,7 @@ This command gets the full name of the `webserver` pod from the output of `kubec ### Step 6.2: Visit your Dagster deployment The webserver has been port-forwarded to `8080`, so you can visit the Dagster deployment by going to [http://127.0.0.1:8080](http://127.0.0.1:8080). You should see the Dagster landing page -TODO SCREENSHOT +{/* TODO screenshot */} ### Step 6.3: Materialize an asset diff --git a/docs/docs-beta/docs/guides/external-systems/non-python.md b/docs/docs-beta/docs/guides/external-systems/non-python.md index 0264b6eca25e8..01c90612362a4 100644 --- a/docs/docs-beta/docs/guides/external-systems/non-python.md +++ b/docs/docs-beta/docs/guides/external-systems/non-python.md @@ -3,7 +3,7 @@ title: "Running non-Python languages" sidebar_position: 60 --- -Dagster is written in Python, but that doesn't mean it's limited to running Python to materialize assets. With Pipes, you can run code in other languages and send information back forth with Dagster. This guide covers how to run JavaScript with Dagster using Pipes, however, the same principle will apply to other languages. +Dagster is written in Python, but that doesn't mean it's that Python is the only language that can be used when materializing assets. With Pipes, you can run code in other languages and send information back forth with Dagster. This guide covers how to run JavaScript with Dagster using Pipes, however, the same principle will apply to other languages.
Prerequisites @@ -14,7 +14,7 @@ Dagster is written in Python, but that doesn't mean it's limited to running Pyth ## Create a script using Tensorflow in JavaScript -TODO: consider changing guide to step-based-guide template +{/* TODO: consider changing guide to step-based-guide template */} In this example, we will orchestrate a JavaScript script that reads in a CSV file, and uses the Tensorflow to train a sequential model using Dagster Pipes. @@ -30,7 +30,7 @@ Create an asset that takes the `PipesSubprocessClient` resource, and set the `co You will need `node` in the environment you are running Dagster, along with Tensorflow installed. ::: -TODO: consider adding instructions for installing dependencies +{/* TODO: consider adding instructions for installing dependencies */} diff --git a/docs/docs-beta/docs/guides/external-systems/pipes.md b/docs/docs-beta/docs/guides/external-systems/pipes.md index 3889221ace571..2ded7841f8de5 100644 --- a/docs/docs-beta/docs/guides/external-systems/pipes.md +++ b/docs/docs-beta/docs/guides/external-systems/pipes.md @@ -20,7 +20,7 @@ In this guide, we'll walk you through how to invoke non-Dagster code through Pip To set up invoking code outside of Dagster, you first need to set up an asset. We can invoke the external code within the asset function by using a Dagster Pipes client resource. -It is not a requirement that this external code know anything about Dagster. It can even be a process running a different language on a remote machine - the only requirement is that it can be triggered from Python. +It's not a requirement that this external code know anything about Dagster. It can even be a process running a different language on a remote machine - the only requirement is that it can be triggered from Python. In the following example, our external code is in a Python script that we invoke within a Dagster asset. @@ -35,4 +35,4 @@ Dagster Pipes also establishes a protocol for external code to optionally send b -The logs sent back using the `PipesContext` will be visible in the structured logs of that asset materialization's run, and the materialization metadata will be reflected in the asset history. \ No newline at end of file +The logs sent back using the `PipesContext` will be visible in the structured logs of that asset materialization's run, and the materialization metadata will be reflected in the asset history. diff --git a/docs/docs-beta/docs/guides/ingestion-transformation/ingesting-data.md b/docs/docs-beta/docs/guides/ingestion-transformation/ingesting-data.md index 077feec82f585..3a7ce6cf56693 100644 --- a/docs/docs-beta/docs/guides/ingestion-transformation/ingesting-data.md +++ b/docs/docs-beta/docs/guides/ingestion-transformation/ingesting-data.md @@ -52,15 +52,17 @@ Writing code in a language like Python to ingest data into a platform is also a For example, imagine there's a CSV file of counties on the internet and you want to load it into your Snowflake data warehouse as a table. To do this, you might directly define an asset that represents that table in your warehouse. The asset's materialization function fetches data from the internet and loads it into that table: +{/* TODO update example */} + ```python @asset def counties(snowflake: SnowflakeResource) -> None: - # TODO data = fetch_some_data() snowflake.conn.execute("INSERT INTO ...") ``` ## Next steps -- [TODO](/todo) -- Learn how to [transform data using Dagster's dbt integration](/guides/ingestion-transformation/transform-dbt) \ No newline at end of file +{/* TODO add next steps */} + +- Learn how to [transform data using Dagster's dbt integration](/guides/ingestion-transformation/transform-dbt) diff --git a/docs/docs-beta/docs/guides/ingestion-transformation/transform-dbt.md b/docs/docs-beta/docs/guides/ingestion-transformation/transform-dbt.md index 6a3674db9f049..fe0dcf88217e9 100644 --- a/docs/docs-beta/docs/guides/ingestion-transformation/transform-dbt.md +++ b/docs/docs-beta/docs/guides/ingestion-transformation/transform-dbt.md @@ -83,4 +83,4 @@ You can schedule your dbt models by using the `dagster-dbt`'s `build_schedule_fr ## Next steps -[comment]: <> (TODO: Add link to dbt partitioning guide) \ No newline at end of file +{/* TODO: Add link to dbt partitioning guide */} diff --git a/docs/docs-beta/docs/guides/project-structure.md b/docs/docs-beta/docs/guides/project-structure.md index 1941c337cc462..eb78b12c408a6 100644 --- a/docs/docs-beta/docs/guides/project-structure.md +++ b/docs/docs-beta/docs/guides/project-structure.md @@ -8,7 +8,7 @@ title: "How to structure your Dagster project" Refer to the project scaffolding tutorial to learn how to create a new Dagster project. ::: -There are many ways to structure your Dagster project, it can be difficult to know where to start. In this guide, we will walk through our recommendations for how to start with organizing your code. While these are just our recommendations, feel free to deviate from them as your needs evolve. +There are many ways to structure your Dagster project, and it can be difficult to know where to start. In this guide, we will walk you through our recommendations for how to organize your Dagster project. As your project grows, you are welcome to deviate from these recommendations. ## What you'll learn @@ -51,7 +51,7 @@ There are several paradigms in which you can structure your project. Choosing on ### Option 1: Structured by technology -Data engineer often have a strong understanding of the underlying technologies that are used in their data pipelines. For that reason, it's often beneficial to structure projects by the technology that are being used. This enables engineers to easily navigate the code base and locate files pertaining to the specific technology. +Data engineers often have a strong understanding of the underlying technologies that are used in their data pipelines. Because of that, it's often beneficial to organize your project by technology. This enables engineers to easily navigate the code base and locate files pertaining to the specific technology. Within the technology modules, sub-modules can be created to further organize your code. diff --git a/docs/docs-beta/docs/guides/tbd/selection-syntax.md b/docs/docs-beta/docs/guides/tbd/selection-syntax.md index a3a33b4d0be6a..b17b3c90001a2 100644 --- a/docs/docs-beta/docs/guides/tbd/selection-syntax.md +++ b/docs/docs-beta/docs/guides/tbd/selection-syntax.md @@ -12,7 +12,7 @@ Asset selection may be used to: - Define a job that targets a selection of assets - Select a set of assets to view in the Dagster UI -- Select a set of assets for an ad-hoc run +- Select a set of assets for an adhoc run ## Syntax usage @@ -349,4 +349,4 @@ Which would result in the following asset graph: ![Screenshot of Daggy U project graph](/img/placeholder.svg) - \ No newline at end of file + diff --git a/docs/vale/styles/Dagster/acronyms.yml b/docs/vale/styles/Dagster/acronyms.yml index de49de80c7148..7a3af0214a5a9 100644 --- a/docs/vale/styles/Dagster/acronyms.yml +++ b/docs/vale/styles/Dagster/acronyms.yml @@ -8,29 +8,43 @@ first: '\b([A-Z]{3,5})\b' second: '(?:\b[A-Z][a-z]+ )+\(([A-Z]{3,5})\)' # ... with the exception of these: exceptions: - - API + - ACR + - ACS + - AD - ADD + - AKS + - API - ASP + - AWS - CLI - CPU - CSS - CSV + - DAG - DEBUG - DOM - - dlt - DPI + - DSL + - ECR - ECS + - EKS + - ELT - ETL - FAQ - GCC + - GCP + - GCR - GDB - GET + - GKE - GPU - GTK - GUI + - HPC - HTML - HTTP - HTTPS + - IAM - IDE - JAR - JSON @@ -44,18 +58,24 @@ exceptions: - OSS - PATH - PDF + - PEX - PHP - POST - RAM + - RBAC + - RDS - REPL - REST - RSA + - S3 + - SAML - SCIM - SCM - SCSS - SDA - SDK - SFTP + - SHA - SQL - SSH - SSL @@ -68,8 +88,10 @@ exceptions: - URI - URL - USB + - UTC - UTF - XML - XSS - YAML - ZIP + - dlt diff --git a/docs/vale/styles/Dagster/headings-casing.yml b/docs/vale/styles/Dagster/headings-casing.yml index 412717f8112df..0d3a706f3d6e2 100644 --- a/docs/vale/styles/Dagster/headings-casing.yml +++ b/docs/vale/styles/Dagster/headings-casing.yml @@ -1,5 +1,7 @@ ## This rule finds section headings that don't use sentence casing. ## Ex: This is correct, but This Is Not Correct +## +## Setting indicators ":" allows capitalization after colon (e.g. Step 1: Testing) extends: capitalization message: "'%s' should be in sentence case" @@ -7,32 +9,35 @@ level: error scope: heading match: $sentence exceptions: - - Airbyte - - AirFlow - "Amazon (ECS|Redshift)" + - "Google (BigQuery|Cloud Platform|Workspace)" + - APIs + - Airbyte - AirFlow - Azure Active Directory - BigQuery - Branch Deployments - - Change Tracking - CI + - CI/CD - CLI + - Change Tracking + - Dagster+ - Databricks - Datadog - - dbt - DuckDB - ETL - GitHub + - GitLab - Gitlab - - "Google (BigQuery|Cloud Platform|Workspace)" - Hybrid - - Insights - IP - - Microsoft Teams + - Insights + - Kubernetes - MLflow + - Microsoft Teams - MongoDB - MySQL - - OneLogin - Okta + - OneLogin - OpenAI - PagerDuty - Pandera @@ -40,9 +45,13 @@ exceptions: - Postgres - Role-based Access Control - S3 + - SAML - SCIM + - SSO - Slack - Snowflake - - SSO - Twilio - - UI \ No newline at end of file + - UI + - dbt +indicators: + - ":" diff --git a/docs/vale/styles/Terms/engineering.yml b/docs/vale/styles/Terms/engineering.yml index a94475159b4e2..642a7bc9b3fc2 100644 --- a/docs/vale/styles/Terms/engineering.yml +++ b/docs/vale/styles/Terms/engineering.yml @@ -21,4 +21,4 @@ swap: python: "Python" pythonic: "Pythonic" sql: "SQL" - "[Tt]ypescript": "TypeScript" \ No newline at end of file + "[Tt]ypescript": "TypeScript" diff --git a/docs/vale/styles/config/vocabularies/Dagster/accept.txt b/docs/vale/styles/config/vocabularies/Dagster/accept.txt index 9546195827672..2a86f34aa3bcc 100644 --- a/docs/vale/styles/config/vocabularies/Dagster/accept.txt +++ b/docs/vale/styles/config/vocabularies/Dagster/accept.txt @@ -1,72 +1,81 @@ -[Cc]onfig -\bDagster\b +ACR +ACS +AD +AKS +AWS DAG -DataFrame -Declarative Automation -dagster-.* -gRPC -[Mm]aterializations -[Mm]aterializable -[Mm]emoization -REST API -[Ss]ubprocess -Serverless -CLI[s] -uncomment +DSL +ECR +ECS +EKS +ELT +GCR +GKE +HPC +IAM +PEX +RBAC +RDS +SCIM +SHA -Airbyte AirFlow -AWS +Airbyte BigQuery +CI/CD +CLI[s] Crontab +DataFrame Databricks Datadog +Declarative Automation +Docker Dockerfile -dbt -dlt DuckDB -ECR -ECS Fivetran -GCR GitHub -GitLab -IAM -Microsoft Teams +Helm +JavaScript MLflow +Microsoft Teams MongoDB MySQL -OneLogin Okta +OneLogin OpenAI PagerDuty Pandera PingOne Postgres -S3 -SCIM +Pydantic +REST API Snowflake +Tensorflow Twilio -PEX -Helm -Dockerfile -Docker - We have -we have -lookback -Pydantic -DSL +[Cc]onfig +[Mm]aterializable +[Mm]aterializations +[Mm]emoization [Rr]epo +[Ss]3 +[Ss]erverless +[Ss]ubprocess +\bDagster\b +auditable +dagster-.* +dbt +dlt +enqueue[ds] +gRPC +lookback +namespace plaintext +pluggable +stderr +stdout +toolchain +uncomment vCPU vCPUs -SAML - -Tensorflow -JavaScript -stdout -stderr - -enqueue[ds] -auditable \ No newline at end of file +we have