Merge pull request #1550 from replicatedhq/91052

HOLD FOR KOTS v1.104.0: Update docs for installing with sdk-enabled charts

docs/vendor/custom-metrics.md

@@ -16,7 +16,11 @@ Custom metrics can be used to generate insights on customer usage and adoption o
 * Low feature usage and adoption overall can indicate the need to invest in usability, discoverability, documentation, education, or in-product onboarding
 * High usage volume for a customer can indicate that the customer might need help in scaling their instance infrastructure to keep up with projected usage
 
-The vendor portal collects custom metrics through Replicated KOTS or through the Replicated SDK, depending on which is installed in the cluster alongside the application instance. KOTS and the SDK both expose an in-cluster API where you can configure your application to POST metric payloads. When an application instance sends data to the API, KOTS or the SDK sends the data (including any custom and built-in metrics) to the Replicated app service. The app service is located at `replicated.app` or at your custom domain.
+## How the Vendor Portal Collects Custom Metrics
+
+The vendor portal collects custom metrics through Replicated KOTS or through the Replicated SDK, depending on which is installed in the cluster alongside the application.
+
+KOTS and the SDK both expose an in-cluster API where you can configure your application to POST metric payloads. When an application instance sends data to the API, KOTS or the SDK sends the data (including any custom and built-in metrics) to the Replicated app service. The app service is located at `replicated.app` or at your custom domain.
 
 If any values in the metric payload are different from the current values for the instance, then a new event is generated and displayed in the vendor portal. For more information about how the vendor portal generates events, see [How the Vendor Portal Generates Events and Insights](/vendor/instance-insights-event-data#how-the-vendor-portal-generates-events-and-insights) in _About Instance and Event Data_.
 
@@ -70,10 +74,15 @@ Custom metrics have the following limitations:
 
 ## Configure Custom Metrics
 
-You can configure your application to send a set of metrics as key value pairs to the API that is running in the cluster alongside the application instance.
+You can configure your application to POST a set of metrics as key value pairs to the API that is running in the cluster alongside the application instance.
+
+Both KOTS and the SDK expose an in-cluster API:
+
+:::note
+If both KOTS and the SDK are installed in the cluster, then you can POST custom metrics to either in-cluster API.
+:::
 
-The location of the API endpoint is different depending on if KOTS or the SDK is installed in the cluster:
-* For applications installed with KOTS, the in-cluster API custom metrics endpoint is located at `http://kotsadm:3000/api/v1/app/custom-metrics`. 
+* KOTS provides an in-cluster API custom metrics endpoint at `http://kotsadm:3000/api/v1/app/custom-metrics`. 
 
   **Example:**
 
@@ -90,7 +99,7 @@ The location of the API endpoint is different depending on if KOTS or the SDK is
   }
   ```
 
-* For Helm chart-based applications that include the Replicated SDK, the in-cluster API custom metrics endpoint is located at `http://replicated:3000/api/v1/app/custom-metrics`.
+* The Replicated SDK provides an in-cluster API custom metrics endpoint at `http://replicated:3000/api/v1/app/custom-metrics`.
 
   **Example:**
 

docs/vendor/distributing-workflow.md

@@ -32,10 +32,7 @@ For more information about creating releases, see [Managing Releases with the Ve
     <td>HelmChart</td>
     <td><p>Provides instructions for KOTS about how to deploy your Helm chart.</p><p><strong>Note:</strong> Required for supporting KOTS installations of Helm charts.</p></td>
     <td>
-      <ul>
-        <li><a href="helm-native-v2-using">Configuring the HelmChart Custom Resource</a></li>
-        <li><a href="helm-kots-using-sdk">Using an SDK-Enabled Helm Chart for KOTS Installations</a></li>
-      </ul>  
+      <a href="helm-native-v2-using">Configuring the HelmChart Custom Resource</a>
     </td>
   </tr>
   <tr>

docs/vendor/insights-app-status.md

@@ -52,6 +52,8 @@ After you include the SDK as a dependency, the requirements for enabling status
 
 For applications installed with Replicated KOTS, configure one or more status informers in the Replicated Application custom resource. For more information, see [Add Status Informers](admin-console-display-app-status#add-status-informers) in _Adding Resource Status Informers_.
 
+When Helm chart-based applications that include the Replicated SDK are deployed by KOTS, the SDK inherits the KOTS status informers configured in the Application custom resource. In this case, the SDK does _not_ automatically report the status of the resources that are part of the Helm release. This prevents discrepancies in the instance data in the vendor platform.
+
 ## Understanding Application Status
 
 This section provides information about how Replicated interprets and aggregates the status of Kubernetes resources for your application to report an application status.

docs/vendor/instance-insights-event-data.md

@@ -4,31 +4,35 @@ This topic provides an overview of the customer and instance insights that you c
 
 ## How the Vendor Portal Collects Instance Data {#about-reporting}
 
-The vendor portal collects data from instances installed in online environments. Depending on the application's installation method, either the Replicated SDK or Replicated KOTS periodically sends a small amount of data to the vendor portal, including properties such as the current version and status of the instance. For a full overview of what data might be included, see the [Replicated Data Transmission Policy](https://docs.replicated.com/vendor/policies-data-transmission).
+The vendor portal collects data from instances installed in online environments. Either Replicated KOTS or the Replicated SDK periodically sends a small amount of data to the vendor portal, depending on which is installed in the cluster alongside the application. If both KOTS and the SDK are installed in the cluster (such as when a Helm chart-based application that includes the SDK is installed with KOTS), then both KOTS and the SDK send instance data.
 
-The vendor portal receives instance data from either the Replicated SDK or from KOTS when any of the following _check-ins_ occur:
+The data sent to the vendor portal includes properties such as the current version and status of the instance. For a full overview of what data might be included, see the [Replicated Data Transmission Policy](https://docs.replicated.com/vendor/policies-data-transmission).
 
-* For Helm installations that include the Replicated SDK, the SDK sends instance data to the vendor portal when any of the following occur:
+### From the Replicated SDK
 
-  * The instance checks for updates. An update check occurs when the instance makes a request to the `/api/v1/app/updates` SDK API endpoint. See [app](/reference/replicated-sdk-apis#app) in _Replicated SDK API (Alpha)_.
+When installed alongside the application, the SDK automatically sends instance data to the vendor portal when any of the following occur:
 
-  * The instance completes a Helm update to a new application version. After the update completes, the SDK sends data when it restarts.
+* The SDK sends data every four hours.
 
-  * The status of an instance changes. For example, an instance can change from a Ready to Degraded status. For more information, see [Enabling and Understanding Application Status](insights-app-status).
+* The instance checks for updates. An update check occurs when the instance makes a request to the `/api/v1/app/updates` SDK API endpoint. See [app](/reference/replicated-sdk-apis#app) in _Replicated SDK API (Alpha)_.
 
-  * Every four hours, the SDK automatically sends data.
+* The instance completes a Helm update to a new application version. After the update completes, the SDK sends data when it restarts.
 
-* For KOTS installations, KOTS sends instance data to the vendor portal when any of the following occur:
+* The status of an instance changes. For example, an instance can change from a Ready to Degraded status. For more information, see [Enabling and Understanding Application Status](insights-app-status).
 
-  * The instance checks for updates. By default, KOTS checks for updates every four hours. Additionally, an update check can occur when a user clicks the **Check for updates** button in the Replicated admin console. 
+### From KOTS
 
-    :::note
-    KOTS users can modify or disable automatic update checks from the admin console. For more information, see [Updating an Application](/enterprise/updating-apps) in the _Enterprise_ section.
-    :::
+When installed alongisde the application, KOTS automatically sends instance data to the vendor portal when any of the following occur:
 
-  * The status of an instance changes. For example, an instance can change from a Ready to Degraded status. For more information, see [Enabling and Understanding Application Status](insights-app-status).
+* The instance checks for updates. By default, KOTS checks for updates every four hours. Additionally, an update check can occur when a user clicks the **Check for updates** button in the Replicated admin console. 
 
-  * (KOTS v1.92 and later only) The instance completes an update to a new application version.
+  :::note
+  KOTS users can modify or disable automatic update checks from the admin console. For more information, see [Updating an Application](/enterprise/updating-apps) in the _Enterprise_ section.
+  :::
+
+* The status of an instance changes. For example, an instance can change from a Ready to Degraded status. For more information, see [Enabling and Understanding Application Status](insights-app-status).
+
+* (KOTS v1.92 and later only) The instance deploys a new application version.
 
 ## How the Vendor Portal Generates Events and Insights
 
@@ -40,11 +44,11 @@ The vendor portal uses events to display insights for each active instance in a
 
 ## Requirements
 
-Viewing instance data in the vendor portal has the following requirements:
+Collecting instance data has the following requirements:
 
-* For applications installed with Helm, the Replicated SDK must also be installed in the cluster to send data to the vendor portal. To install the SDK with your application, include the SDK as a dependency in your `Chart.yaml` file. For more information, [About the Replicated SDK (Alpha)](replicated-sdk-overview).
+* Replicated KOTS or the Replicated SDK must be installed in the cluster where the application instance is running. 
 
-* Collecting application status data for an instance requires additional configuration. You must indicate Kubernetes resources that Replicated will monitor for changes in state. For more information, see [Enabling and Understanding Application Status](insights-app-status).
+* For KOTS installations and for Helm CLI installations that use `helm template` then `kubectl apply`, additional configuration is required to get application status data. For more information, see [Enabling and Understanding Application Status](/vendor/insights-app-status).
 
 ## Limitations
 

docs/vendor/replicated-sdk-overview.md

@@ -17,9 +17,7 @@ For more information about the Replicated SDK API, see [Replicated SDK API (Beta
 
 The Replicated SDK has the following limitations:
 
-* **SDK-Enabled Helm Charts with KOTS**: When a Helm chart that includes the SDK as a dependency is installed with KOTS, instance data might be duplicated because both KOTS and the SDK are reporting data. To install an SDK-enabled Helm chart with KOTS, you must update both the chart and the HelmChart custom resource so that the SDK is excluded from KOTS installations. For more information, see [Using an SDK-Enabled Chart for KOTS Installations](helm-kots-using-sdk).
-
-* **Installing with `helm template` and `kubectl apply`**: Some popular enterprise continuous delivery tools, such as ArgoCD and Pulumi, deploy Helm charts by running `helm template` then `kubectl apply` on the generated manifests, rather than running `helm install` or `helm upgrade`.  The following limitations apply to applications installed by running `helm template` then `kubectl apply`:
+* Some popular enterprise continuous delivery tools, such as ArgoCD and Pulumi, deploy Helm charts by running `helm template` then `kubectl apply` on the generated manifests, rather than running `helm install` or `helm upgrade`.  The following limitations apply to applications installed by running `helm template` then `kubectl apply`:
 
   * The `/api/v1/app/history` SDK API endpoint always returns an empty array because there is no Helm history in the cluster. See [GET /app/history](/reference/replicated-sdk-apis#get-apphistory) in _Replicated SDK API (Beta)_.
 

netlify.toml

@@ -142,7 +142,11 @@
 
 [[redirects]]
   from="https://docs.replicated.com/vendor/replicated-sdk-rbac"
-  to="https://docs.replicated.com/vendor/replicated-sdk-customizing"           
+  to="https://docs.replicated.com/vendor/replicated-sdk-customizing" 
+
+[[redirects]]
+  from="https://docs.replicated.com/vendor/helm-kots-using-sdk"
+  to="https://docs.replicated.com/vendor/helm-native-about"               
 
 ###################################################
 # Redirects To the Enterprise Section

sidebars.js

@@ -35,7 +35,6 @@ const sidebars = {
       items: [
         'vendor/helm-native-about',
         'vendor/helm-native-v2-using',
-        'vendor/helm-kots-using-sdk',
         'vendor/helm-native-helm-install-order',
         'vendor/helm-optional-charts',
         'vendor/helm-optional-value-keys',