Replies: 0 comments 8 replies
-
Hi Thomas. In a recent discussion we had I thought we came to the conclusion that the "configuration rep" (upstream or not) - is a great architectural benefit as all keptn-services only need access to that configuration repo via the Keptn API vs needing access to the source code repo where devs put their config files |
Beta Was this translation helpful? Give feedback.
-
Hi Thomas and thanks for opening the discussion. I was one of the persons that brought up this topic after seeing this in KEP-67 Here we suggest that there will be three potentially different Git Repos involved. In my opinion, the Config Repo, Code Repo and Keptn Upstream Repo should really be a single repo, e.g.: For the end-user, the only thing to do is to create a project, and tell Keptn where the config files are, e.g.: keptn create project best-project-ever --git-repo=https://github.com/christian-kreuzberger-dtx/my-jenkins-test.git --git-auth-credentials=... \
--branch=main --keptn-config=.keptn [--slo-file=slo.yaml --remediation-file=remediation.yaml] However, we never create a service, a stage, or add any files. This is something that the Git Repo holds as a truth (e.g., there could be a edit: |
Beta Was this translation helpful? Give feedback.
-
Hi Andreas, I`d like to add my feedback regarding what @thschue already mentioned, based on my current experience with keptn deployments.
|
Beta Was this translation helpful? Give feedback.
-
It would 100% fit my needs, application standalone testing, different deployment scenarios, ... Some changes e.g. Personally I would be totally fine, if changes can only be done with files. I really like that idea, maybe because I'm used to that because it is what gitlab, github,... also do. I actually like the approach with Custom Resources too like tekton does. Both approaches are an real improvement in my point of view as either with custom resources or a .keptn folder it is much easier to work as a team on configs. (e.g. Pull Request for changing configs) I personally see no problem in giving keptn-core, locust-service, or any execution-plane-service read access to the repo. |
Beta Was this translation helpful? Give feedback.
-
Motivation
When discussing the Keptn Architecture, one of the most frequent discussion points is the purpose of the upstream repository. Although it is the source of truth for deployment, it introduces some major drawbacks, especially when dealing with more deployment focussed use cases.
Example 1:
When using keptn for deployment, keptn is acting as an artifact store. Therefore, you have to publish artifacts and configurations to keptn before you can use them. In the case of a Helm chart, the chart is published in an uncommon way (keptn send artifact instead of helm push).
Example 2:
When designing the GitOps approaches, a lot of effort has been put into dealing with the keptn configuration repo, manipulating git and getting the correct configuration versions for a service deployed. Many of the problems were related to git, also some performance problems were caused by git.
Assumption
If the configuration, deployment artifact (e.g. helm chart), and the container images are stored in an artifact registry, we could get rid of the upstream repository.
Approach
In all of the current approaches, the configuration of keptn (sli.yaml, helm-charts, test configuration) is stored in a code/configuration repository maintained by developers. Therefore, it would be possible to generate an artifact out of them in the ci-process (e.g. https://oras.land/) and push them to an OCI-compliant registry. Since Helm 3.8.0, such registries are also supported for Helm Charts (https://github.com/helm/helm/releases/tag/v3.8.0) and Container images in any way. Therefore, all of the information can be stored in an OCI registry in the CI process and consumed by Keptn during the workflow. Using an OCI registry, would allow us to use common signing mechanisms for all artifacts (https://github.com/sigstore/cosign#oci-artifacts) and validate them during deployment.
Keptn specific configuration (Shipyard, Stages, Sequences, ...) could be stored in Custom Resource Definitions.
Prerequisites
Using the artifacts
When a workflow runs, the artifacts for a specific version (tagged) are fetched, extracted, and stored for deployment (git, s3, filesystem, whatever).
Benefits
These are just my first ideas regarding this topic. What do you think about this?
Beta Was this translation helpful? Give feedback.
All reactions