Define conventional labels we intend the agent to interact with

Background

Currently various GMA integrations rely on these annotations:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: "APPLICATION_NAME"
  annotations:
    app.gitlab.com/app: ${CI_PROJECT_PATH_SLUG}
    app.gitlab.com/env: ${CI_ENVIRONMENT_SLUG}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: "APPLICATION_NAME"
  template:
    metadata:
      labels:
        app: "APPLICATION_NAME"
      annotations:
        app.gitlab.com/app: ${CI_PROJECT_PATH_SLUG}
        app.gitlab.com/env: ${CI_ENVIRONMENT_SLUG}

I suppose we need to add all kinds of labels:

  • app.gitlab.com/agent_id containing agent ID, which created/is responsible for the object.
  • app.gitlab.com/agent_config_project_id agent's configuration project ID.
  • app.gitlab.com/project_id manifest project ID that contains the CiliumNetworkPolicy object.

via @ash2k in !252 (comment 504623868)

Proposal

Need to define a list of labels that we plan for the agent to interact with in some way whether that be:

  • setting them automatically / documenting what users should set manually
  • filtering for various integrations/dashboards
  • preventing disparate deployments from stepping on each others toes accidentally

The important thing is that we standardize and document them here so that various parties working on different agent integrations know what is available and/or should be set on their resources.

  • As @ash2k mentioned in !252 (comment 501014764) it would be preferable to use labels instead of annotations
  • Use a different prefix (agent.gitlab.com) to avoid confusion or any implicit relationship with the existing cluster integration.
    • This will make it obvious which type of cluster integration is being targeted by a given gitops project or chart
    • auto-deploy-app chart used by Auto DevOps could just support both for a time
  • Implement a mutating admission webhook to add labels. Implement validating admission webhook for label validation.
  • Labels we've identified a need for thus far include:
    • agent.gitlab.com/id containing agent ID, which created/is responsible for the object.
    • agent.gitlab.com/config_project_id agent's configuration project ID.
    • agent.gitlab.com/manifest_project_id manifest project ID (for gitops based deployments).
    • agent.gitlab.com/ci_project_id CI project ID (for CI based deployments).
    • agent.gitlab.com/env project environment scope (generally for CI based deployments, but could be set manually elsewhere).

TODOs

  • Start with documenting what we want to have in
    • in the GitLab user docs
  • Start implementing the webhooks
    1. It should work for both GitOps and CI builds
    2. Impersonate a user/group to inject the info the webhook needs
    3. Given the webhook, we don't need a separate implementation for GitOps and CI

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by 🤖 GitLab Bot 🤖