- Show Knative install button on group/instance cluster pages
- Allow Knative to be installed on group/instance clusters
- Add feature specs for installing applications on group/instance
  clusters
- Add changelog entry
- Update docs to reflect that Knative can now be installed on
  group-level and instance-level clusters

Removes limitations on cluster types that can install JupyterHub

Tiger Watson authored 5 years ago and Thong Kuah committed 5 years ago

Kubernetes deployments on new clusters will now have
a separate namespace per project environment, instead
of sharing a single namespace for the project.

Behaviour of existing clusters is unchanged.

All new functionality is controlled by the
:kubernetes_namespace_per_environment feature flag,
which is safe to enable/disable at any time.

All cluster resources are now created on demand when
a deployment job starts.

Whenever we are selecting a namespace to use for a
deployment or to query a cluster we want to exclude
Kubernetes namespace records that don't have a token
set as they will not have the required permissions.
However when configuring clusters, we want to
use the original namespace record even if it has no
token, as a namespace has to be unique on a cluster.

Aligns with the other reactive cache options by
providing a default that can be overridden if necessary.

Since they are not GitLab managed we wont make assumptions about the
namespaces used

Remove Kn services cache from Clusters::Application::Knative

Knative function can exist even if user did not installed Knative via
GitLab managed apps.

-> Move responsibility of finding services into the Cluster
-> Responsability is inside Clusters::Cluster::KnativeServiceFinder
-> Projects::Serverless::FunctionsFinder now calls depends solely on a
cluster to find the Kn services.
-> Detect Knative by resource presence instead of service presence
-> Mock knative_installed response temporarily for frontend to develop

Display loader while `installed === 'checking'`

Added frontend work to determine if Knative is installed

Memoize with_reactive_cache(*args, &block) to avoid race conditions

When calling with_reactive_cache more than once, it's possible that the
second call will already have the value populated. Therefore, in cases
where we need the sequential calls to have consistent results, we'd fall
under a race condition.

Check knative installation via Knative resource presence

Only load pods if Knative is discovered

Always return a response in FunctionsController#index

- Always indicate if Knative is installed, not installed or checking
- Always indicate the partial response for functions. Final response is
guaranteed when knative_installed is either true | false.

Adds specs for Clusters::Cluster#knative_services_finder

Fix method name when calling on specs

Add an explicit check for functions

Added an explicit check to see if there are any functions available

Fix Serverless feature spec

- we don't find knative installation via database anymore,
rather via Knative resource

Display error message for request timeouts

Display an error message if the request times out

Adds feature specs for when functions exist

Remove a test purposed hardcoded flag

Add ability to partially load functions

Added the ability to partially load functions on the frontend

Add frontend unit tests

Added tests for the new frontend additions

Generate new translations

Generated new frontend translations

Address review comments

Cleaned up the frontend unit test.
Added computed prop for `isInstalled`.

Move string to constant

Simplify nil to array conversion

Put knative_installed states in a frozen hash for better read

Pluralize list of Knative states

Quey services and pods filtering name

This way we don't need to filter the namespace in memory.
Also, the data we get from the network is much smaller.

Simplify cache_key and fix bug

- Simplifies the cache_key by removing namespace duplicate
- Fixes a bug with reactive_cache memoization

Added a changelog entry for the feature

Update documentation to reflect removal

When Kubernetes clusters were originally built they could only
exist at the project level, and so there was logic included
that assumed there would only ever be a single Kubernetes
namespace per cluster. We now support clusters at the group
and instance level, which allows multiple namespaces.

This change consolidates various project-specific fallbacks to
generate namespaces, and hands all responsibility to the
Clusters::KubernetesNamespace model. There is now no concept of
a single namespace for a Clusters::Platforms::Kubernetes; to
retrieve a namespace a project must now be supplied in all cases.

This simplifies upcoming work to use a separate Kubernetes
namespace per project environment (instead of a namespace
per project).

There are two cluster hierarchies one for the deployment platform and
one for controllers. The main difference is that deployment platforms do
not check user permissions and only return the first match.

Instance level clusters were already mostly supported, this change adds
admin area controllers for cluster CRUD

Peter Leitzen authored 5 years ago and Bob Van Landuyt :neckbeard: committed 5 years ago

Tweak cluster helper and refactor its specs.

When this option is enabled, GitLab will create namespaces and service
accounts as usual. When disabled, GitLab wont create any project
specific kubernetes resources

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/56557

João Cunha authored 5 years ago and Grzegorz Bizon committed 5 years ago

- Dry create_service.rb and update_service.rb duplicated code
- Remove known list of applications responsibility from services
- Refactor the complex builders->builder call from base_service.rb

This will allow to user the term managed? on
https://gitlab.com/gitlab-org/gitlab-ce/issues/56557. Managed? will be
used to distinct clusters that are automatically managed by GitLab

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

- Avoid using direct code on spec migration
- Removes milestone and point to issue, to avoid making fake promises

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57397

- Changes help text on clusters form to make it more explicit.
- Removes unnecessary warnings on auto devops form
- Simplifies cluster methods logic

- Fixes multiple typos on AutoDevops script
- Add an alias to Clusters::Cluster#domain as base_domain, so it's more
descriptive
- Removes unnecessary memoization on qa specs
- Changes migration to a post migration to deal better with traffic on
big instances (like gitlab.com)

Changes domain field to be on the Cluster page show, removing it from
Auto DevOps setting. Also injects the new environment variable
KUBE_INGRESS_BASE_DOMAIN into kubernetes#predefined_variables.

Migration to move the information from ProjectAutoDevops#domain
to Clusters::Cluster#domain. As well as necessary modifications to qa
selectors

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/52363

This is the 1st step for moving Auto DevOps domain into cluster
settings, whether is project or group.

Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/52363

This also means we need to apply the `current_scope` otherwise this
method will return all clusters associated with the groups regardless of
any scopes applied to this method