Spring and summer gave autumn a miss, but the Replicated Product & Engineering teams are charging ahead on our product roadmap! It’s time for another fresh batch of exciting capabilities newly available in our application manager (a/k/a “KOTS” (Kubernetes Off-The-Shelf), our Kubernetes installer (a/k/a “kURL”), and the vendor portal (previously “Vendor Web”). Check out the recently shipped features and release highlights for September 2022 below.
What’s New for the vendor portal:
Vendor portal: Team auto-join is now GA
Vendor portal: Implement best practices with linting warnings and errors
What’s New for the application manager
Application manager: Automatic update checks in Helm-managed mode (Alpha) (Released v1.85.0)
Application manager: Enforce required config items for new Helm chart versions in Helm-managed mode (Alpha) (Released v1.85.0)
Application manager: Icon colors can now be custom branded (Alpha) (Released v1.86.0)
Application manager: Include custom fonts when branding the admin console (Alpha) (Released v1.84.0)
Application manager: Redesigned display of license fields (Released v1.85.0)
What’s New for the Kubernetes installer
Kubernetes installer: Added support for Kubernetes v1.25 (Released v2022.09.16-0)
Kubernetes installer: Default kURL spec changed to OpenEBS
Kubernetes installer: Add-ons on kurl.sh now listed in numerical order
What’s New for Troubleshoot
Troubleshoot: Search for secrets in Kubernetes matching a label, which contain support-bundle specs (Released v0.43.0)
Troubleshoot: Multiple support-bundle specs from the command line
What’s New for the Replicated Documentation
Replicated documentation: Docs templates in a new vendor-docs-starter repo
Replicated documentation: Host collector documentation added
Replicated documentation: New workflow to set up Velero snapshots
Replicated documentation: “Getting started” moved to top level and re-titled
Collaboration is the key to success, and it starts with having your staff working in the right teams. First introduced in our August release highlights blog, this new capability prevents vendors from accidentally creating new teams. Now new users can accept an invite, join an “auto-join” enabled team with their email address domain or Google Authentication, or continue to create a new team if they really want. After validating their account in vendor portal, if the user has a pending invite to an existing team they will be presented the option to join that team. If the user does not have an invite to any teams, they will simply continue to create a new team. Additionally, if a team is available with the auto-join feature enabled and configured, the user also has the option to auto-join that team. An example of this page with these three options is shown below. You can read more about this in our docs about managing team members with auto-join.
To encourage vendors to avoid common mistakes with Replicated, linting details have now been added to help make warnings and errors easier for vendors to identify. We’ve expanded our linting rules to include warnings about best practices, such as using StatusInformers and customizing app preflights. And we’re raising awareness of these linter errors by showing them in more places, such as the channels page and the release promotion page.
Even better, when a Vendor receives an error from the Vendor Portal linter, it will link them directly to the relevant helper docs. Find the right recommendations with just a click!
Automatic update checks are now available through the admin console in Helm-managed mode. Just as regular users of the admin console can configure automatic update checks so that new versions of their vendor’s app are pulled on a regular basis, end-users using our new alpha Helm install method can turn on similar automatic update checks. The version history page will reflect any new chart versions that are available, so that the end-user can choose to install them.
In Helm-managed mode, we used to show the `helm upgrade` command for all new chart versions. However, if a required config item was introduced in a new version, the value would not yet be set, which should prevent the new version from being deployed.
Now, new Helm chart versions that introduce a required config value must be configured before the `helm upgrade` command is available. We will direct end-users to the config page first so that they must configure this new version, thus setting the required config value, before deploying it.
As we continued to iterate on allowing vendors to brand the admin console, our icons were still a static color. If someone revamped the admin console to use their colors—say, green and red—but the icons were still the blue from our default theme, this would not look good. So we reworked the icons to make them into an icon font. This allows vendors to change the color of icons using the `color` CSS property, as they would with any text, making it all more cohesive and aesthetically pleasing. Check out these great pink icons! Reach out if you would like early access to this feature.
Similar to the previous item, we are continuing to help you beautify your application manager and make it a seamless part of your application experience. Although our recently released custom CSS support allows you to change fonts using the `font-family` property, only fonts available on the user’s system can be used. If a vendor wants to use a less common font, they need to be able to include that font in a release so that the admin console has access to it. Now font files can be included in a release and referenced in the Application custom resource so that those font families can be used in the vendor’s custom CSS. Reach out if you would like early access to this feature.
Data helped us determine that some people have many more license fields than we realized, and the values for those fields can be quite long too. The way we displayed license fields wasn’t optimized for these scenarios, yielding an ugly UX. No one wants an ugly UX. Now in the vendor portal, the download portal, and the admin console, license field details are automatically hidden behind a dropdown if you have five or more, keeping the view clean but letting you expand it when needed. Longer values are also truncated, but clicking “more” lets you view the entire value.
Making the latest Kubernetes version available to customers leveraging kURL helps them keep their customers up to date. In keeping with our goals to improve add-on delivery time, we released support for v1.25 a full week before our 30-day from upstream release goal, woohoo! Please note that K8s v1.25 fully removed PodSecurityPolicy support which contributes to incompatibility issues with some existing add-ons. Current add-on incompatibilities with K8s 1.25 include: Rook v1.8x or earlier, and Longhorn "latest" (1.3.x) - Longhorn does not intend to support K8s 1.25 until later this year in version 1.4. If you are using one of these add-ons, please contact us for advice.
The default kURL installer spec has been updated, which impacts vendors creating new applications in Vendor Portal, as well as those using the kurl.sh spec or replicated-starter-kots template. This spec changes the default CSI from Longhorn to OpenEBS, and provides guidance on when this storage provider is appropriate, guiding the vendor to documentation on choosing a PV provisioner if a particular use case is more complex.
For add-ons where the “latest” version pin lags behind the true latest version available for a given add-on, the dropdown order previously had “latest” at the top, followed by earlier versions in descending order to the earliest, and then the versions greater than “latest” would be listed at the bottom. This not only resulted in a lot of scrolling to find the actual most recent add-on version, but it was a common point of escalations and confusion. Now when this edge case is present, where the version marked “latest” isn’t actually the latest version available, the kurl.sh add-on version options are listed in numerical order, making it easier to find and choose the newest add-on versions.
Use Troubleshoot to search for secrets in Kubernetes matching a label, which contain support-bundle specs. This means we no longer need to provide the spec(s) on the CLI. It is also now possible for KOTS and kURL to store secrets with specific Troubleshoot specs for various components, and have Troubleshoot go find them and execute accordingly. Those components are able to update their own secret without affecting other components.
This enables the user to store spec snippets alongside parts of their system or applications instead of having to deal with merging all of their specs into a single one.
For our vendors, writing their end user documentation can be a challenging and time-consuming part of releasing a beta or GA application. We talked about Creating install docs for your customers at RepliCon Q3 2022, check out the video! To help make this process easier, we also published a set of documentation starter templates in a new vendor-docs-starter repository. Vendors can copy these markdown templates to their own documentation repository and fill them in with their application-specific content. The readme for the vendor-docs-starter repo contains detailed instructions and context for vendors using the templates. This repo is also linked from the Help creating Replicated documentation for end user Kubernetes installs community post. We are hoping to gather feedback from vendors to continue to improve these templates and add new resources to this repo. If you are getting ready to start your documentation, please see the vendor-docs-starter!
To help vendors troubleshoot a cluster that is down without having to go to the Troubleshoot.sh docs site, the host collector support bundle information has been added to the product docs. This new content explains why and how to configure host support bundle manifest files, and adds an enterprise Generate a Host Support Bundle procedure that can be shared with customers. This content is part of our ongoing initiatives to enable vendors to better self-serve and reduce the support burden, as well as improve the preflight and support bundle content.
Enterprise users can now follow a clear workflow in the docs that walks them through all the steps required to configure their snapshots storage destination and start taking backups. We also added new steps for installing and configuring Velero in an online environment. Installation has historically been a particularly challenging step in getting started with snapshots. Previously, enterprise users had to use the Velero documentation heavily in order to configure snapshots storage destinations, resulting in errors, misconfiguration, and frustration. With these latest docs improvements, the commands that users need are available right on the Replicated docs site. This reduces the amount of times our documentation must be supplemented by third-party vendor docs, creating fewer opportunities for errors in the snapshots configuration process.
When vendors are getting started with Replicated, we recommend that they complete a few introductory tutorials to get hands-on experience with packaging and deploying a sample application. To help make it easier for vendors to find this content, we moved the tutorials to a section at the top of the docs named “Getting Started Tutorials”. We also updated the Welcome topic to provide better direction on where to start.
That’s it for the September release highlights! Want to learn more about these new features and what Replicated does to help vendors and customers install and manage modern apps on-prem? We would love to show you -- click here to schedule a demo.