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

Implement observedGeneration in order to compare with standard generation property #1062

Open
tolko opened this issue Feb 10, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@tolko
Copy link

tolko commented Feb 10, 2021

Is your feature request related to a problem? Please describe.
When observing k8s resource (ArgoCD application) during the update of the values we get two events fired.

Event source is:

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: resource
spec:
  template:
    serviceAccountName: argo-events-sa 
  resource:
    example:
      namespace: argocd
      group: argoproj.io
      version: v1alpha1
      resource: applications
      eventTypes:
        - UPDATE
      filter:
        fields:
          - key: metadata.name
            operation: ==
            value: ing

sensor is:

apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: resource
spec:
  template:
    serviceAccountName: argo-events-sa
  dependencies:
    - name: test-test
      eventSourceName: resource
      eventName: example
      filters:
        data:
          - path: body.status.health.status
            type: string
            value:
              - Healthy
          - path: body.status.sync.status
            type: string
            value:
              - Synced
          - path: body.status.operationState.phase
            type: string
            value:
              - Succeeded
          
  triggers:
    - template:
        name: webhook-pod-trigger
        k8s:
          group: ""
          version: v1
          resource: pods
          operation: create
          source:
            resource:
              apiVersion: v1
              kind: Pod
              metadata:
                generateName: hello-world-
              spec:
                containers:
                  - name: hello-container
                    args:
                      - "hello-world"
                    command:
                      - cowsay
                    image: "docker/whalesay:latest"
          parameters:
            - src:
                dependencyName: test-test
                dataKey: body
              dest: spec.containers.0.args.0

In the first event, we are getting an outdated status section with a "healthy" status for the application. However, the application is still not reconciled.
There is no way to distinguish the outdated status section from the new (valid) status section due to missing observedGeneration property.

Describe the solution you'd like
implement observedGeneration in order to compare this property with standard generation property

Describe alternatives you've considered
we tried to find another mechanism to distinguish outdated status section by comparing operationState finishAt and status reconciledAt without success


Message from the maintainers:

If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

@tolko tolko added the enhancement New feature or request label Feb 10, 2021
@whynowy
Copy link
Member

whynowy commented Feb 11, 2021

Is this the reason of #1025?

@VaibhavPage
Copy link
Contributor

@whynowy I think both are related

@whynowy
Copy link
Member

whynowy commented Mar 30, 2021

@tolko - I want to confirm the order with you, did you mean after the EventSource and Sensor were started, there was an Argo-cd Application update, and 2 events were triggered? Or after an Argo-cd Application object update, starting a EventSource trigged 2 actions?

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

No branches or pull requests

3 participants