feat: add Artifact object #1703
Conversation
Signed-off-by: Guilhem Lettron <[email protected]>
| // ArtifactSpec defines the desired state of Artifact | ||
| type ArtifactSpec struct { | ||
|
|
||
| // +kubebuilder:validation:Required | ||
| // +kubebuilder:validation:MinLength=1 | ||
| CurrentVersion string `json:"currentVersion,omitempty"` | ||
|
|
||
| // +kubebuilder:validation:Required | ||
| Versions map[string]*v1.Artifact `json:"versions,omitempty"` | ||
| } |
There was a problem hiding this comment.
| // ArtifactSpec defines the desired state of Artifact | |
| type ArtifactSpec struct { | |
| // +kubebuilder:validation:Required | |
| // +kubebuilder:validation:MinLength=1 | |
| CurrentVersion string `json:"currentVersion,omitempty"` | |
| // +kubebuilder:validation:Required | |
| Versions map[string]*v1.Artifact `json:"versions,omitempty"` | |
| } | |
| // ArtifactSpec defines the desired state of Artifact | |
| type ArtifactSpec v1.Artifact |
There was a problem hiding this comment.
That's really part of the discussion.
Having only the latest artifact in spec makes it simpler, but also points some problems:
- status is not made to be backup / stateful. So customers can't rely on it.
- having status quite implies a controller to manage changes from spec to status.
With everything in spec, it makes things trusty and "backupable":
- Any producer is responsible for content with any dedicated controller involved.
- Any consumer can decide to stay on an older version (if user asks “on hold”, for example)
I don't see that many usages of "Status" for an object like an Artifact (but I may be wrong).
But events produced by “consumers” can be a great thing.
There was a problem hiding this comment.
status is not made to be backup / stateful. So customers can't rely on it.
For sure, no user should relay on anything from this custom resource, status or not is irelevant. This custom resource is a side-efect of some 3rd-party source-controller that should fully manage the artifact. This type of object is not "desired state" it shouldn't be included in the backup. You should backup what ever custom resource your controller uses for "desired state".
source-controller-x would reconcile GitRepositoryX objects and would create/update/delete ArtifactX objects. If you want to pin your source to a Git commit, the user will do this in the GitRepositoryX. Users will never interact with ArtifactX as the artifact is a result of the reconciliation, it's not the "desired state", the artifact is the "actual state".
There was a problem hiding this comment.
It's ok for me, just wanted to know if the desired state should be managed by source controller and just an information storage :)
And yes, I'm developing a source-controller for Omaha / Nebraska, so I will need a way to interact with consumers controllers :)
There was a problem hiding this comment.
Flux source-controller plays no role here, this ArtifactX type is to enable other source controllers to feed data to Flux kustomize-controller. We discussed this in the dev meetings, the artifact for the native Flux sources will remain unchanged, it's part of the .status. For 3rd-party source controllers, they will have to generate the artifact in a standalone object that can be referenced in Flux Kustomizations.
| type ArtifactStatus struct { | ||
| } |
There was a problem hiding this comment.
| type ArtifactStatus struct { | |
| } | |
| type ArtifactStatus struct { | |
| // +kubebuilder:validation:Required | |
| History []v1.Artifact `json:"history"` | |
| } |
This is how we track versions in Flux APIs, the first entry is the current version, all this logic is already in helm-controller.
|
Hi @stefanprodan |
This pull request introduces a new
Artifactresource to the project, including its schema definition, deep copy functions, and necessary imports and registrations. The most important changes are summarized below:Introduction of
ArtifactResource:Artifactresource schema, includingArtifactSpec,ArtifactStatus, andArtifactListinapi/v1alpha1/artifact_types.go.Artifactresource inapi/v1alpha1/zz_generated.deepcopy.go.Project Configuration Updates:
PROJECTfile to include the newArtifactresource.Artifactresource to theconfig/crd/kustomization.yaml.Codebase Adjustments:
main.goto import the newv1alpha1package and register it with the scheme [1] [2].These changes ensure that the new
Artifactresource is properly integrated into the existing project structure and configuration.