Changing the application slug

Hi Replicated team, if we were to change the application slug at some point in the future, would it be possible to update an existing embedded install without rebuilding the cluster?

2 Likes

Application slugs cannot be changed. Can you explain what problem you are trying to solve?

If you want to have a specific application slug that is currently not available, it may be possible to take ownership of it, provided it is not currently in use by another vendor, but you will have to work with a Replicated CSM.

Having said all that, you will not be able to link existing installs to a new application.

2 Likes

Here’s a brief outline of the problem that we’re trying to solve. We’re not quite sure when this will happen so we’re trying to work things out as early as possible.

We started off developing our application as a standalone product and have been trialling it with several partners. Since we have started developing, it has been decided that our application should be bundled as one part of a bigger company-wide offering. This would mean releasing with a new application slug.

While this would be ok for new installs, it would mean our existing partners would potentially have to rebuild their embedded clusters. This is painful and we’d like to avoid this if at all possible. If we could adjust their cluster somehow so that it pointed at the new app slug and treated it as an upgrade, that would be preferable.

There are a couple of options:

  1. If your release pipeline is automated, you could release the same manifests for two apps. There is nothing in KOTS that would prevent you from adding more components to an existing app.
  2. You could continue using the same app but with more components, for existing an all future installs.

The only thing that could technically prevent you from going down either path is potential issues with upgrading existing installs (for example a kubernetes spec change that is not allowed by kubernetes). But you would face these issues even if you could move existing installs to the new application slug. The upgrade process would be identical either way.

You can also work with your CSM to request this new feature, but that would have to go through evaluation and prioritization process before it even gets to development.