Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Be able to compute the status from an object list #4

Open
jlore-decathlon opened this issue Oct 5, 2023 Discussed in #3 · 1 comment · May be fixed by #6
Open

Be able to compute the status from an object list #4

jlore-decathlon opened this issue Oct 5, 2023 Discussed in #3 · 1 comment · May be fixed by #6
Assignees

Comments

@jlore-decathlon
Copy link

Discussed in #3

Originally posted by GregoireW October 5, 2023
In case we push multiple object in kubernetes to deploy one application it may be interesting to compute a status from all the object.

Example: your repository is a mono repo with a front app, an api, a worker. You deploy all of them when you put your application in production, you want to check all them to be deployed to declare a deployment succesful.

The CRD could be modified to something like this:

apiVersion: github.decathlon.com/v1beta1
kind: GitHubDeployment
metadata:
  name: example
spec:
  sourceRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo-primary
    namespace: test

  additionnalRef:
    -  apiVersion: apps/v1
       kind: Deployment
       name: front-app
      namespace: test
    - apiVersion: apps/v1
      kind: Deployment
      name: worker
      namespace: test


  extract:  # Extract the ref on which to GitHub will create the deployment ( commit sha1, tag, etc... )
    containerName: podinfod  #  get the tag of the image of this container. If it is not set, a `jsonPath` option has to be given.
    # jsonPath: $.metadata.annotations.source-ref # a jsonPath to extract a value. Mandatory is `containerName` is not set  
    regexp: main-.*-(.*) # optional. If present, extract a substring from the tag. Capture a single group (can be named "ref")
    # template: "{}"  # optional. If present, use this template to build the GitHub ref from the extracted string. "{}" will be replaced by the extract string. 
                      # For instance if you capture "1.2.3", a template like 'tag-{}' will send to GitHub a ref "tag-123"  
  repository:
    name: my-repo  # your repo name (no need to set the org/user, you can just set the repo name)
    environment: staging # the environment name. It can be anything like  production, staging, ..

Extract / template to get the commit point in git would be extracted from the sourceRef object, but the overall status would be the minimum status from all the objects from additionalRef + sourceRef.

  • If one object is in error, the global status is in error
  • else if one object is in pending, the global status is pending
  • else if ALL object are current, the result is current.
@rossignolloic
Copy link

Extract / template to get the commit point in git would be extracted from the sourceRef object, but the overall status would be the minimum status from all the objects from additionalRef + sourceRef.

Extracting the git ref only from the sourceRef object can lead to the wrong status. If all objects do not have the same git ref, the status computed is not reliable.

If we have a sourceRef A and additionnalRef B and C with v1 git ref, compute status from all objects makes sense because they are with the same git ref.
But I see two other cases:

  • If only B git ref changes to v2, this will result to any update into github because sourceRef doesn't change.
  • If only A git ref changes to v2, this will result to an update into github with v2 ref, but status will be computed on A in v2, B and C are still in v1. This case doesn't mean that B and C will not be updated to v2 in near future. Flux can check the image registry when only one of the 3 images has its tag pushed. If B and C update to v2 after A is in its final state, their states in v2 will never be taken into account, and if one of them fail, the deployment will be success instead of failure in GitHub.

So I don't think this proposal can manage multi-object deployments properly at this stage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants