Merge pull request #2687 from replicatedhq/112484

Remove Helm-only release content

Author: paigecalvert

docs/partials/customers/_kots-entitlement-overview.mdx

@@ -67,7 +67,7 @@ The following fields are supported on all optional collectors for preflights and
   </tr>
   <tr>
     <td><code>exclude</code></td>
-    <td>(Optional) Based on the runtime available configuration, a conditional can be specified in the <code>exclude</code> field. This is useful for deployment techniques that allow templating for Replicated KOTS and the optional KOTS Helm component. When this value is <code>true</code>, the collector is not included.</td>
+    <td>(Optional) (KOTS Only) Based on the runtime available configuration, a conditional can be specified in the <code>exclude</code> field. This is useful for deployment techniques that allow templating for Replicated KOTS and the optional KOTS Helm component. When this value is <code>true</code>, the collector is not included.</td>
   </tr>
 </table>
 
@@ -110,11 +110,11 @@ The following fields are supported on all optional analyzers for preflights and
   </tr>
   <tr>
     <td><code>exclude</code></td>
-    <td>(Optional) For KOTS only, a condition based on the runtime available configuration can be specified in the <code>exclude</code> field. This is useful for deployment techniques that allow templating for KOTS and the optional KOTS Helm component. When this value is <code>true</code>, the analyzer is not included.</td>
+    <td>(Optional) (KOTS Only) A condition based on the runtime available configuration can be specified in the <code>exclude</code> field. This is useful for deployment techniques that allow templating for KOTS and the optional KOTS Helm component. When this value is <code>true</code>, the analyzer is not included.</td>
   </tr>
   <tr>
     <td><code>strict</code></td>
-    <td>(Optional) For KOTS only, an analyzer can be set to <code>strict: true</code> so that <code>fail</code> outcomes for that analyzer prevent the release from deploying until the vendor-specified requirements are met. When <code>exclude: true</code> is also specified, <code>exclude</code> overrides <code>strict</code> and the analyzer is not executed.</td>
+    <td>(Optional) (KOTS Only) An analyzer can be set to <code>strict: true</code> so that <code>fail</code> outcomes for that analyzer prevent the release from being deployed by KOTS until the vendor-specified requirements are met. When <code>exclude: true</code> is also specified, <code>exclude</code> overrides <code>strict</code> and the analyzer is not executed.</td>
   </tr>
 </table>
 

docs/reference/custom-resource-preflight.md

@@ -1,12 +1,16 @@
-# Redactor (KOTS-Only)
+# Redactor (KOTS Only)
 
-This topic describes the Redactor custom resource. The information in this topic applies to Replicated KOTS installations only.
+This topic describes how to define redactors with the Redactor custom resource.
+
+:::note
+Custom redactors defined with the Redactor resource apply only to installations with Replicated KOTS.
+:::
 
 ## Overview
 
 Preflight checks and support bundles include built-in redactors. These built-in redactors use regular expressions to identify and hide potentially sensitive data before it is analyzed. For example, the built-in redactors hide values that match common patterns for data sources, passwords, and user IDs that can be found in standard database connection strings. They also hide environment variables with names that begin with words like token, password, or user. To view the complete list of regex patterns for the built-in redactors, see [`redact.go`](https://github.com/replicatedhq/troubleshoot/blob/main/pkg/redact/redact.go#L204) in the open-source Troubleshoot GitHub repo.
 
-For KOTS installations, you can also add custom redactors to support bundles using the Redactor custom resource manifest file. For example, you can redact API keys or account numbers, depending on your customer needs. For more information about redactors, see [Redacting Data](https://troubleshoot.sh/docs/redact/) in the Troubleshoot documentation.
+For Replicated KOTS installations, you can also add custom redactors to support bundles using the Redactor custom resource manifest file. For example, you can redact API keys or account numbers, depending on your customer needs. For more information about redactors, see [Redacting Data](https://troubleshoot.sh/docs/redact/) in the Troubleshoot documentation.
 
 ## Defining Custom Redactors
 

docs/reference/custom-resource-redactor.md

@@ -11,10 +11,6 @@ Create a new release using a collection of application manifest files and/or one
 replicated release create --yaml-dir YAML_DIR [flags]
 ```
 
-```bash
-replicated release create --chart HELM_CHART [flags]
-```
-
 :::note
 Additional flags returned by `--help` that are not supported by Replicated are omitted from the table below.
 :::
@@ -30,11 +26,6 @@ Additional flags returned by `--help` that are not supported by Replicated are o
   <td>path</td>
   <td><p>The local directory containing multiple YAML manifest files for a release. <strong>(Required)</strong></p><p><ChartYamlDirReqs/></p></td>
 </tr>
-  <tr>
-    <td><code>--chart</code></td>
-    <td>string</td>
-    <td><p>The path to the Helm chart for a release.<strong>(Required)</strong></p><p><ChartYamlDirReqs/></p></td>
-  </tr>
   <tr>
     <td><code>--promote</code></td>
     <td>string</td>
@@ -75,16 +66,6 @@ replicated release create --yaml-dir ./manifests
     • SEQUENCE: 58
 ```
 
-### `--chart`
-
-```bash
-replicated release create --chart=my-chart-1.0.0.tgz
-
-  • Reading chart from my-chart-1.0.0.tgz ✓
-  • Creating Release ✓
-    • SEQUENCE: 58
-```
-
 ### `--promote`
 
 ```bash

docs/reference/replicated-cli-release-create.md

@@ -81,7 +81,7 @@ The **Instances** section displays the following details about each active insta
    * Whether the instance is installed in a Replicated kURL cluster.
    * (kURL Clusters Only) The number of nodes ready in the cluster.
    * (KOTS Only) The KOTS version running in the cluster.
-   * (Replicated SDK Only) The Replicated SDK version running in the cluster.
+   * The Replicated SDK version running in the cluster.
    * The cloud provider and region, if applicable.
 * Instance uptime data, including:
    * The timestamp of the last recorded check-in for the instance. For more information about what triggers an instance check-in, see [How the Vendor Portal Collects Instance Data](instance-insights-event-data#about-reporting) in _About Instance and Event Data_.

docs/vendor/customer-reporting.md

@@ -10,14 +10,7 @@ If you are new to Replicated, complete the following prerequisites before you ge
 
 * Create an account in the Vendor Portal. You can either create a new team or join an existing team. For more information, see [Creating a Vendor Account](vendor-portal-creating-account).
 
-* Complete a basic Replicated onboarding workflow to create an application and then promote and install initial releases in a development environment: 
-  * (Recommended) For Helm chart-based applications, Replicated recommends that you complete the [Replicated Quick Start](/vendor/replicated-onboarding) workflow before getting started with KOTS. The workflow in _Replicated Quick Start_ demonstrates how to add a Helm chart to a release in the vendor platform and then install with the Helm CLI.
-  
-     :::note
-     Packaging your application with Helm is recommended because it allows you to support both installations with the Helm CLI and with KOTS from the same release, without having to maintain separate sets of Helm charts or application manifests.
-     :::
-
-  * Alternatively, if you do _not_ intend to distribute a Helm application with Replicated, see [Install with KOTS in an Existing Cluster](tutorial-cli-setup) for a workflow that uses a sample application with Kubernetes manifests.
+* Review [Replicated Onboarding](/vendor/replicated-onboarding) for more information about onboarding an application to the Replicated Platform before you get started with KOTS.
 
 ## Add Custom Resources
 
@@ -131,6 +124,6 @@ You can choose to use either Replicated Embedded Cluster or Replicated kURL to e
 
 ## Configure Additional Replicated Features
 
-Review the [Features Checklist](/vendor/replicated-onboarding#features-checklist) in _Replicated Quick Start_ for a list of features to integrate with your application to fully onboard onto the Replicated platform.
+See [Replicated Onboarding](/vendor/replicated-onboarding) for a list of features to integrate with your application to fully onboard onto the Replicated platform.
 
 For example, you can add custom domains for the Replicated registry and app service, configure checks in your application for custom license entitlements, collect custom metrics using the Replicated SDK API, and more.

docs/vendor/distributing-workflow.md

@@ -22,7 +22,7 @@ For vendors that do not want to use Helm, applications distributed with Replicat
 
 Replicated recommends that new users start by completing one or more labs or tutorials to get familiar with the processes of creating, installing, and iterating on releases for an application with the Replicated Platform.
 
-Then, when you are ready to begin onboarding your own application to the Replicated Platform, see [Replicated Quick Start](replicated-onboarding) for a list of Replicated features to begin integrating.
+Then, when you are ready to begin onboarding your own application to the Replicated Platform, see [Replicated Onboarding](replicated-onboarding) for a list of Replicated features to begin integrating.
 
 #### Labs
 
@@ -59,7 +59,7 @@ The phases are:
 * Report
 * Support
 
-For more information about the Replicated features that enhance each phase of the lifecycle, see [About the Commerical Software Distribution Lifecycle](../intro-replicated#life-cycle) in _Introduction to Replicated_.
+For more information about the Replicated features that enhance each phase of the lifecycle, see [Introduction to Replicated](../intro-replicated).
 
 ## Compatibility Matrix FAQs
 

docs/vendor/kots-faq.mdx

@@ -1,5 +1,4 @@
 import ChangeChannel from "../partials/customers/_change-channel.mdx"
-import KotsEntitlement from "../partials/customers/_kots-entitlement-overview.mdx"
 
 # About Customers
 
@@ -96,7 +95,7 @@ Replicated enforces the following logic when a license expires:
    To change the behavior of your application when a license expires, you can can add custom logic in your application that queries the `expires_at` field using the Replicated SDK in-cluster API. For more information, see [Querying Entitlements with the Replicated SDK API](/vendor/licenses-reference-sdk).
 * Expired licenses cannot log in to the Replicated registry to pull a Helm chart for installation or upgrade.
 * Expired licenses cannot pull application images through the Replicated proxy registry or from the Replicated registry.
-* (KOTS Only) KOTS prevents instances with expired licenses from receiving updates.
+* In Replicated KOTS installations, KOTS prevents instances with expired licenses from receiving updates.
 
 ## About Customer Channel Assignment {#channel-assignment}
 
@@ -110,23 +109,6 @@ For example, if the latest release promoted to the Beta channel is version 1.25.
 
 For more information about how to mark a release as required, see [Properties](releases-about#properties) in _About Channels and Releases_. For more information about how to synchronize licenses in the Admin Console, see [Updating Licenses](/enterprise/updating-licenses).
 
-### Assigning KOTS and Helm-Only Customers
-
-<KotsEntitlement/>
-
-To prevent KOTS or Helm CLI-only customers from accessing a release that they cannot install, Replicated enforces the following channel assignment rules:
-* A KOTS customer can be assigned to a channel only when the head release contains the required KOTS manifests.
-
-  <img width="400px" alt="KOTS customer blocked from channel assignment" src="/images/channel-assignment-helm-only.png"/>
-
-  [View a larger version of this image](/images/channel-assignment-helm-only.png) 
-
-* A Helm CLI-only customer can be assigned to a channel only when the head release contains at least one Helm chart.
-
-  <img width="400px" alt="Helm customer blocked from channel assignment" src="/images/channel-assignment-kots-only.png"/>
-  
-  [View a larger version of this image](/images/channel-assignment-kots-only.png)
-
 ## About the Customers Page
 
 The following shows an example of the **Customers** page:
@@ -145,7 +127,7 @@ From the **Customers** page, you can do the following:
 
 * Click the **Manage customer** button to edit details such as the customer name and email, the custom license fields assigned to the customer, and the license expiration policy. For more information, see [Creating and Managing Customers](releases-creating-customer).
 
-* (KOTS Only) Download the license file for each customer.
+* Download the license file for each customer.
 
 * Click the **Customer reporting** button to view data about the active application instances associated with each customer. For more information, see [Customer Reporting](customer-reporting).
 

docs/vendor/licenses-about.mdx

@@ -4,13 +4,17 @@ import GitOpsNotRecommended from "../partials/gitops/_gitops-not-recommended.mdx
 
 Built-in fields are reserved field names. The following table describes each built-in license field that you can define for a customer.
 
+:::note
+License fields labeled "KOTS Only" in the table below apply only to Replicated KOTS installations.
+:::
+
 | License field         | Description           |
 |------------------------|------------------------|
 | `appSlug` | Application slug value. This value never changes. |
 | `channelID` | Current channel ID from which releases will be downloaded. When channel changes, the latest release of that will be downloaded on the next update check. |
 | `channelName` | Current channel name from which releases will be downloaded. When channel changes, the latest release of that will be downloaded on the next update check. |
 | `customerName` | The name of the customer. |
-| `endpoint` | (KOTS Only) The endpoint that the Replicated Admin Console uses to synchronize license and download updates. This is typically `https://replicated.app`. |
+| `endpoint` | (KOTS Only) The endpoint that the KOTS Admin Console uses to synchronize license and download updates. This is typically `https://replicated.app`. |
 | `entitlements` | The `entitlements` property includes the `expires_at` field and any custom entitlements for the license. For more information about adding custom license fields, see [Managing Custom License Fields](licenses-adding-custom-fields).|
 | `expires_at` | <p>Defines the expiration date for the license. The date is encoded in ISO 8601 format (`2026-01-23T00:00:00Z`) and is set to midnight UTC on the date selected. If a license does not expire, this field is missing.</p><p>By default, instances with an expired license continue to run. Additionally, instances installed with KOTS that have an expired license do not receive updates. For more information about the default behavior when a license expires, see [License Expiration Handling](licenses-about#expiration) in _About Customers_.</p>|
 | `isAirgapSupported` | (KOTS Only) If a license supports air gapped installations, then this field is set to `true`. If air gapped is not supported, this field is missing. When you enable this feature, the `.rli` file will have license meta data embedded in it, and must be re-downloaded. |