July was another big month for the Replicated Product & Engineering teams! We have some exciting new capabilities to share based on input from vendors like you.
Let’s take a look at what’s now available in our application manager (building on the open source “KOTS” project AKA Kubernetes Off-The-Shelf) and our Kubernetes installer (expanding on “kURL.”) Read on for all the juicy details!
Replicated Recent Release Highlights: July 2022
What’s new for the Vendor Portal:
- Vendor Portal: Make requests and get help directly on the Vendor Portal support page
- Vendor Portal: Streamlined ‘open support request’ encourages support bundle upload
- Vendor Portal: No new releases saved until you are ready
- Vendor Portal: Including an installer in a release (beta)
What’s new for the Application Installer
- Application Installer: Use Helm upgrade flags to customize your installations
- Application Installer: Improved Helm install version history (alpha)
- Application Installer: Check K8s installers before deploying apps (beta)
- Application Installer: Upgrading from Postgres 10 to Postgres 14
What’s new for the product documentation
- Product documentation: More automated feedback on docs pages
- Product documentation: What you need in your support requests
- Product documentation: Improved documentation for host preflights
- Product documentation: Clearer instructions for snapshots
What’s new for the Vendor Portal
Vendor Portal: Make requests and get help directly on the Vendor Portal support page
We love your ideas for new features! So we’ve made it easier than ever to open new feature requests directly from the Vendor Portal support page, with a new button right alongside requests for support. This streamlines the process for you to get in touch with us in a trackable and referenceable way and automates the routing of your requests to the right team. You can also now find self-service help in context too! These enhancements will make it more efficient to get you the product enhancements, fixes, and help you need to be successful. See the demo below.
Vendor Portal: Streamlined ‘open support request’ encourages support bundle upload
Similarly, the vendor support page experience has several enhancements for the ‘open support request.’ This is now a two-step process to help reduce complexity, ease readability, and, most importantly, reinforce the importance of providing a support bundle when creating a ticket. You are not required to provide bundles, but this makes providing valuable information easier and speeds up the support process. Additionally, we now call out the need for ‘Product Area’ and ‘Type of Installation’ when submitting a ticket to expedite the routing of the request and provide a faster response.
Vendor Portal: No new releases saved until you are ready
We’ve made an enhancement so that clicking “Create release” in the vendor portal now opens a draft release, but this release isn’t persisted until you click “Save release.” Previously, when you clicked to create a release in the vendor portal, a release was immediately created and saved, rather than opening a draft that could be edited. So if you clicked “Create release” and navigated away from the editor without making changes, you still ended up with a new release that was identical to your previous release. This could cause confusion on the Releases page, and it was different behavior than the Replicated CLI (where you make all your changes first and then create a release.) Immediately creating a release also felt unexpected—if you haven’t made changes yet, why save the release? Now, in addition to opening a draft release, navigating away from the editor after making changes causes a prompt to appear to remind you to save your new release if you want it.
Vendor Portal: Including an installer in a release (beta)
Including an installer in a release yields reproducible installations that ensure the appropriate Kubernetes installer and release version are used together. Moving forward, this will likely be our recommended approach for the Kubernetes installer, so they are promoted to a channel together, coupling the components for reproducibility and reduced risk. We described this in more detail last month when it was alpha; you can read more here. We are keen to have you use this new feature and provide feedback. Please try it out and let us know what you think -- we're looking for input from anyone interested in more tightly coupling their installer and release. This capability is relevant for the “Check K8s installers before deploying apps” feature described below. Documentation is available here.
What’s new for the Application Installer
Application Installer: Use Helm upgrade flags to customize your installations
Replicated now enables you to use your choice of `helm upgrade` flags during application deployments. These flags will be passed to customize the installation of Helm charts when using native Helm. Recently we’ve received several requests to be able to customize Helm installations: extend the timeout, shorten the timeout, ignore custom resources, etc. Instead of incrementally exposing these individual Helm options, we added `helmUpgradeFlags` to the HelmChart custom resource. This way, you can override our defaults (for the timeout, for example) and customize the installation with options we haven’t yet considered. Note that the `helm upgrade` command is used for initial installations and upgrades by passing the `--install` option. So these flags apply to all deployments of charts. You can read more about helmUpgradeFlags in our docs.
Application Installer: Improved Helm install version history (alpha)
The version history page works when the admin console runs in Helm-managed mode after installing using `helm install` (alpha). As we continue to work on the new alpha feature to install an application using Helm (new public documentation available here), we continue converting functionality in the admin console to make it work in a situation where Helm, rather than the app manager, manages the lifecycle of the application. In this case, the app manager's version history page is updated in v1.77.0 to use Helm concepts like revisions to work with Helm installations. Specifically, the version history page will show all previous revisions and any new versions of the chart that the vendor has promoted.
Application Installer: Check K8s installers before deploying apps (beta)
You can now use a preflight check to encourage or require Kubernetes installer updates before deploying a new version of your application (in app manager 1.74.0+). Previously Replicated didn’t offer a way to encourage (or require!) end users to rerun their Kubernetes installer and update their cluster, despite this being a crucial workflow. Now, if an installer is included in a release (see documentation), a preflight check can be used to compare the installer in the release with the installer that is currently in use in the environment (docs). This allows you to check whether the installer associated with a given release has been run before deployment.
As a preflight check, you can choose whether a mismatch should warn or fail; you can use a strict preflight check to disallow deployment until the updated installer is run, and you can customize the messaging to point your end users to documentation on how to update their Kubernetes installation. “Including an installer in a release” (described above) was the first step to more tightly coupling our installation process. This preflight check takes that a step further by bringing Kubernetes installer updates into the standard end user workflow.
Application Installer: Upgrading from Postgres 10 to Postgres 14
The App Manager installs Postgres to store information about versions that have been fetched in the customer environment (version label, whether it has been deployed, etc.) Postgres 10 has been in use for some time, but support for version 10 ends later this year. As of App Manager v1.78.0, Postgres 14 is installed. When upgrading the app manager from an earlier version to any version 1.78.0+, a migration from Postgres 10 to 14 will occur.
What’s new for the product documentation
Product documentation: More automated feedback on docs pages
We added a new button to docs pages so you can more easily open an issue on the Replicated Docs repo. There is now a new “Provide Feedback” button on the bottom of each page on docs.replicated.com. You can click this button to open a new issue for us to address. Previously, there was one button at the bottom of the page for submitting a request against the given topic. With this new feedback button, you can quickly let us know where the docs can be improved to help make you more successful.
Providing feedback on a docs page will now also automatically populate the details around your created issues. This feature makes things easier for our Product Docs team to know which article you are referencing by automatically noting the title of the page and the page URL.
Product documentation: What you need in your support requests
We have added additional documentation that clarifies what information must be attached to a support request. For users who cannot generate a support bundle, Submitting a Support Request describes what information they must attach to a support request. Now, with more details on what information must be included, you are empowered to create support issues that can be triaged and addressed more quickly.
Product documentation: Improved documentation for host preflights
We took your feedback that finding the kURL vendor documentation could be confusing, with no clear path to implementing the host preflights procedure. So we improved the host preflights conceptual information and added a procedure for host preflight customization to the vendor documentation.
Product documentation: Clearer instructions for snapshots
We’ve improved the snapshots documentation to ensure critical requirements are clear and discoverable. We updated the topics on using a NFS and using a host path as storage destinations for snapshots to clarify the requirements for each (for example, how to set the required user:group permissions). Also, to improve the findability of the snapshots docs and reduce confusion, we updated the titles of many topics to replace the term “snapshots” with “backup and restore.” These changes will help users self-serve when troubleshooting the backup and restore process, reducing the number of support issues opened by users running into the same issues.
We invite you to let us know if you’re interested in trying any of our alpha or beta features by emailing us at beta+managers@replicated.com. Thanks!