Skip to content

Resolve "Use GitLab serverless with existing Knative installation"

What does this MR do?

Following the suggestion on https://gitlab.com/gitlab-org/gitlab-ce/issues/58941#note_155863604

Our goal is to find deployed functions regardless of the associated cluster instance having a Knative application installed via GitLab managed apps.

Although, we're currently using ReactiveCaching to fetch the services which is associated with a Clusters::Applications::Knative model. Since we might not have a Clusters::Applications::Knative instance associated to the cluster, then we need to extract this ReactiveCaching logic out of this model.

Proposal:

  1. Stop detecting Knative from the database presence, since it might not have been installed by us. Instead, search by the apis/serving.knative.dev resource on the cluster. (already implemented by our KubeClient gem).

  2. Since Clusters::Applications::Knative instance might not exist for the cluster, move the responsibility of finding services to a Clusters::Cluster::KnativeServicesFinder class.

  3. Since Clusters::Cluster::KnativeServicesFinder wont be ActiveRecord class, use the ReactiveCaching key as the the cluster id.

Does this MR meet the acceptance criteria?

Conformity

Performance and testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team

Closes #58941 (closed)

Edited by Grzegorz Bizon

Merge request reports