- Set as uninstallable app
- Update docs
- Adjust specs

Only prometheus can be uninstalled atm, the rest will be dealt with
later.

Presumption is that new application types will have uninstallation
implmemented at the same time.

Rescue and put into :uninstall_errored if something goes wrong while
destroying, which can happen. I think it is safe to expose the full
error message from the destroy error.

Remove the :uninstalled state as no longer used.

Added :uninstalled state as wasn't sure if we should be destroying the
cluster apps

This is the backend part which just allows uninstalling Prometheus for
now.

João Cunha authored 6 years ago and Jacques Erasmus committed 6 years ago

- Creates new route
- Creates new controller action
- Creates call stack:
  Clusterss::ApplciationsController calls -->
  Clusters::Applications::UpdateService calls -->
  Clusters::Applications::ScheduleUpdateService calls -->
  ClusterUpdateAppWorker calls -->
  Clusters::Applications::PatchService -->
  ClusterWaitForAppInstallationWorker

DRY req params

Adds gcp_cluster:cluster_update_app queue

Schedule_update_service is uneeded

Extract common logic to a parent class (UpdateService will need it)

Introduce new UpdateService

Fix rescue class namespace

Fix RuboCop offenses

Adds BaseService for create and update services

Remove request_handler code duplication

Fixes update command

Move update_command to ApplicationCore so all apps can use it

Adds tests for Knative update_command

Adds specs for PatchService

Raise error if update receives an unistalled app

Adds update_service spec

Fix RuboCop offense

Use subject in favor of go

Adds update endpoint specs for project namespace

Adds update endpoint specs for group namespace

- Adds to specs the case where apps are also updated
- Rename scope calls on Gitlab::UsageData and Clusters::Cluster
- Removes a duplicated spec

Given https://github.com/helm/helm/issues/3338, I think that we should
exclude applications that are :update_errored, :updating as well.

This could be potentially useful to all cluster applications.

Address followup issue https://gitlab.com/gitlab-org/gitlab-ce/issues/56524

We can have multiple and conditional transistions in a event, so make
use of that.

This makes this consistent with :updated. And also avoids a potential
issue where an install errors which means that that the recorded version
won't necessarily reflect the version that is actually installed.

Note: updating version column after :updating is not ideal in the
updating -> update_erroed case. This will mean that the application now
records the version as the version that failed to upgrade, not the
version that it is currently on.

- #update_errored? method def is redundant, already defined from state
machine
- #update_in_progress? moved to ApplicationStatus
- #ready_status becomes a constant. Previously it was extended in ee/ so
maybe that was why it's a instance method

Before this commit updating Prometheus (e.g. adding alerts) made it
"updated" therefore not installed.

Cluster applications in CE will need access to the same status values
for updating

Partially addresses #47424.

Fix up VERSION for each of the applications
* There is no 0.0.1 helm version for jupyterhub. Use the latest version instead
* `:nginx` is not a valid chart version. Lock the ingress application GitLab installs to the latest chart version.
* Use the latest gitlab-runner chart to prevent GitLab installing older versions when users have been installing the lastest version

Always install from the VERSION and not the database `version` column.
This should fix cases like https://gitlab.com/gitlab-org/gitlab-ee/issues/6795 in
the instances where an install command failed previously, which locked the version
in the database to an older version.

Also, ensure that the version column is updated to the version we are
installing.

Add specs to show how previously failed appplications will be handled when the helm installation is run again

Add changelog entry

This reverts merge request !20801

This is refactoring in the lead up to passing mutual TLS certs for helm applications. As such we expect all applications to need config files so we can remove the logic about which applications need and do not need this (ie `#config_map?`).