crossplane/gitlab-controller

GitLab application controller to provision GitLab application instance on Crossplane and using Crossplane constructs (resources and workloads)

GitLab Controller

Overview

GitLab-Controller is Crossplane native application which enables provisioning production-grade GitLab services across multiple supported cloud providers. GitLab-Controller leverages Crossplane core constructs such as CloudProvider(s), ResourceClass(es), and ResourceClaim(s) to satisfy GitLab Services dependencies on public cloud managed services. GitLab-Controller utilizes Crossplane Workloads to provision GitLab services and all its dependencies on target Kubernetes clusters managed and provisioned by the Crossplane.

Architecture and Vision

The design draft of the Crossplane GitLab-Controller initial design.

Getting Started and Documentation

TBD: For getting started guides, installation, deployment, and administration, see our Documentation.

Contributing

Crossplane GitLab-Controller is a community-driven project, and we welcome contributions. See Contributing to get started.

Report a Bug

For filing bugs, suggesting improvements, or requesting new features, please open an issue.

Contact

Please use the following to reach members of the community:

• Slack: Join our slack channel
• Forums: crossplane-dev
• Twitter: @crossplane_io
• Email: [email protected]

Community Meeting

A regular Crossplane community meeting takes place every other Tuesday. For up-to-date meeting information and details see Crossplane Community Meeting

Project Status

The project is an early preview. We realize that it's going to take a village to arrive at the vision of a multicloud control plane, and we wanted to open this up early to get your help and feedback. Please see the Roadmap for details on what we are planning for future releases.

Official Releases

Official releases of GitLab-Controller can be found on the releases page. Please note that it is strongly recommended that you use official releases of GitLab-Controller, as unreleased versions from the master branch are subject to changes and incompatibilities that will not be supported in the official releases. Builds from the master branch can have functionality changed and even removed at any time without compatibility support and prior notice.

Licensing

Gitlab-Controller is under the Apache 2.0 license.

gitlab-controller's Issues

Certmanager Rolebinding is invalid

demo-clusterrolebinding-gitlab-certmanager

cannot sync resource: could not create object: ClusterRoleBinding.rbac.authorization.k8s.io "gitlab-certmanager" is invalid: subjects[0].namespace: Required value

    subjects:
    - kind: ServiceAccount
      name: gitlab-certmanager
      namespace: ""

Looks like we're passing through an empty namespace for the Certmanager service account at the moment; this will likely prevent Gitlab from working as expected.

Gitlab CR flashes a Failed state during create

And then goes back to Ready. Must be a retry?

Status:
  Conditions:
    Last Transition Time:  2019-05-15T22:14:59Z
    Message:               postgresql
    Reason:                has pending resourceClaims
    Status:                False
    Type:                  Pending
    Last Transition Time:  2019-05-15T22:15:00Z
    Message:               failed to update connection secret: upbound/sj0bw-bucket-backups-tmp: Operation cannot b
e fulfilled on secrets "sj0bw-bucket-backups-tmp": the object has been modified; please apply your changes to the l
atest version and try again
    Reason:                fail to process resource
    Status:                False
    Type:                  Failed
    Last Transition Time:  2019-05-15T22:15:04Z
    Message:
    Reason:
    Status:                True
    Type:                  Ready

gitlab-controller.io link in README.md 404s

The README.md includes a broken link to the latest documentation.

https://github.com/crossplaneio/gitlab-controller/edit/master/README.md

gitlab-runner is stuck looking for nonexistent minio-secrets

Events:
  Type     Reason       Age                    From                                                          Message
  ----     ------       ----                   ----                                                          -------
  Normal   Scheduled    9m20s                  default-scheduler                                             Successfully assigned default/gitlab-gitlab-runner-769f698b88-cg956 to gke-gke-19ce924c-7876-11-default-pool-f2836bd4-416g
  Warning  FailedMount  8m48s (x7 over 9m20s)  kubelet, gke-gke-19ce924c-7876-11-default-pool-f2836bd4-416g  MountVolume.SetUp failed for volume "init-runner-secrets" : [secrets "gitlab-minio-secret" not found, secrets "gitlab-gitlab-runner-secret" not found]
  Warning  FailedMount  65s (x5 over 8m16s)    kubelet, gke-gke-19ce924c-7876-11-default-pool-f2836bd4-416g  MountVolume.SetUp failed for volume "init-runner-secrets" : secrets "gitlab-minio-secret" not found
  Warning  FailedMount  27s (x4 over 7m17s)    kubelet, gke-gke-19ce924c-7876-11-default-pool-f2836bd4-416g  Unable to mount volumes for pod "gitlab-gitlab-runner-769f698b88-cg956_default(3ebe4fee-7878-11e9-908c-42010af00075)": timeout expired waiting for volumes to attach or mount for pod "default"/"gitlab-gitlab-runner-769f698b88-cg956". list of unmounted volumes=[init-runner-secrets]. list of unattached volumes=[runner-secrets etc-gitlab-runner init-runner-secrets scripts gitlab-gitlab-runner-token-l7h24]

The gitlab-runner pod is wedged because it can't find minio-secrets. We've disabled Minio, so it's not immediately why the runner chart is looking for it. The rendered deployment has

      volumes:
      - emptyDir:
          medium: Memory
        name: runner-secrets
      - emptyDir:
          medium: Memory
        name: etc-gitlab-runner
      - name: init-runner-secrets
        projected:
          defaultMode: 420
          sources:
          - secret:
              name: gitlab-minio-secret
          - secret:
              items:
              - key: runner-registration-token
                path: runner-registration-token
              - key: runner-token
                path: runner-token
              name: gitlab-gitlab-runner-secret

This corresponds to https://gitlab.com/charts/gitlab-runner/blob/v0.4.1/templates/deployment.yaml#L102. I don't speak Go template very well, but it seems to me like it should not try to use this secret when caching is disabled, which it is - https://github.com/crossplaneio/gitlab-controller/blob/0e45f18/pkg/controller/gitlab/reconciler.go#L310

Name Suffix Length limits in Gitlab

name suffix has an implied limit based on:
Per RFC 1035, each DNS label can contain up to 63 characters, as long as the whole domain name does not exceed a total length of 255 characters, but in practice most domain registries limit at 253 characters. Subdomains in this context are defined by editing the DNS zone file pertaining to the parent domain.

Since we have a domain that we pass, the subdomain should be validated in a fashion similar to the below sudo code:
len(domain) + len("gitlab-") + len(domainSuffix) < 253 && len("gitlab-") + len(domainSuffix) < 63

Also we're using this suffix in buckets, and we should be mindful of trimming this name appropriately for the limitations of bucket naming in GCS which are similar.
Related: crossplane/crossplane#458

Randomly named API resources never run to completion

The current proof of concept implementation of this controller uses the Gitlab Helm chart to build a KubernetesApplication and submit it to a Crossplane-managed KubernetesCluster. A KubernetesApplication consists of templates for many KubernetesApplicationResources, subresources that each represent a resource (such as a Job or Pod) to be created in the managed KubernetesCluster. The KubernetesApplication controller garbage collects KubernetesApplicationResources that it controls but that no longer match one of its templates.

Currently the controller downloads and renders the Helm chart each time it reconciles a GitLab object. This is a problem because some Gitlab resources are given randomly generated names by the Helm chart, meaning their names in the KubernetesApplication change frequently. This causes them to be garbage collected and replaced before they get a chance to be submitted to their target cluster.

Unfortunately one of the resources affected by this bug is the shared-secrets Job that almost everything else depends on.