Comments (7)
The way that Argo CD does conditions actually seems counter to current best practices around conditions: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties
The API conventions page suggests the following condition fields:
conditions:
- type: # Example: ErrorOccurred / ParametersGenerated / TemplateRendered
status: # True/False/Unknown
reason: # Single word camelcase representing the reason for the status eg MissingParameter or ErrorOccurred
message: # Human readable message or error
lastTransitionTime: # When this value last changed.
EDIT: I previously proposed a .status.applications
field, containing conditions for each generated Application. There is concern (myself included) that this might be too long (too large a resource payload), so I've moved it to a separate issue (#347). This current comment has been updated to remove the applications
field.
We should first begin by adding general conditions that communicate success or failure for the specific ApplicationSet reconciliation tasks that the ApplicationSet controller performs:
Here is an ApplicationSet with a single Application that failed on rendering the template:
status:
conditions:
- type: ErrorOccurred
status: True
reason: MissingParameter
message: "error occurred: Template referenced a parameter that doesn't exist"
lastTransitionTime: (...)
- type: ResourcesUpToDate
status: False
reason: ErrorOccurred
message: "A previous error occurred"
lastTransitionTime: (...)
This simulates an ApplicationSet with a single Application has no errors, it sucessfully generated, templated, and applied:
status:
conditions:
- type: ErrorOccurred
status: False
lastTransitionTime: (...)
- type: ResourcesUpToDate
status: True
lastTransitionTime: (...)
And these were the condition types I used above:
condition types for the ApplicationSet as a whole (these are for status.conditions):
- ErrorOccurred: true if an error occurred at any point in the reconciliation, false otherwise.
- ResourcesUpToDate: true if we were successfully able to reconcile, and thus the Applications are fully up-to-date with the ApplicationSet, false otherwise
from applicationset.
may be we can add the list of generated application in the status field
from applicationset.
@jgwest I would like to work on this.
from applicationset.
Hey @jnpacker, yah, on the issue of the .status.applications
field being way too long if you have lots of clusters, agreed. We can probably mitigate that to some degree. But in any case, lets move implementation of that part of this issue to a separate issue, so that it doesn't block adding conditions. I'll handle that.
For your condition examples, would it be possible to instead include those in the reasons
field?
For example, if CustomDecisionResource shows a cluster NOT found in Argo CD:
status:
conditions:
- type: ErrorOccurred
status: True
reason: ClusterNotFound # This field is an enum, eg a fixed set of strings that may be used here to communicate various known error states
# Q: Is there other machine-readable information it would be useful to provide, in addition to the `reason`?
message: Unable to locate cluster 'cluster-mcclusterface' # This field is a human readable field, that can be passed back to the user as-is
lastTransitionTime: (...)
This way, we don't necessarily need to have conditions for individual generators. Not that I'm against conditions that are only for individual generators, but it would good to first attempt to make it work generically.
Finally, as per the Q comment in the yaml above, also I'm curious what other additional information it would be beneficial to include for your use cases 🤔.
from applicationset.
A single condition would work for tracking errors. I was thinking the reverse of a list of clusters that matched though, but a list of clusters that didn't match between the decision resource and what is in Argo. For now I would represent that as a count. But I also feel this might be more of a warning condition vs an error.. if for example two clusters didn't match between the decision resource and Argos cluster list... But I could see that being an error as well.
from applicationset.
Hi, what do you think about this structure (based on argocd ApplicationStatus)?
status:
applications:
- name:
lastSync:
condition:
- type:
message:
LastTransitionTime
from applicationset.
I agree with @mksha a condition that the generator was successful, not sure if there is a concern of a long list of clusters.
Some possible conditions:
- Generator complete: True/False
- Labels match NO clusters
- List has a cluster name NOT found in Argo CD
- CustomDecisionResource shows a cluster NOT found in Argo CD
from applicationset.
Related Issues (20)
- Webhooks: add support for Bitbucket HOT 3
- Github rate limit hit, even using `scmProvider.filters` HOT 1
- scmProvider Github filter combination (repositoryMatch + labelMatch) not generating apps HOT 1
- Merge generator where a generator can reference items of another one HOT 1
- FATA[0000] rpc error: code = Unimplemented desc = unknown service applicationset.ApplicationSetService HOT 2
- using helm and git repos inside ApplicationSet HOT 2
- git-generator-directory - doesn't apply value file
- docs: merge generator typo in example
- Feature Request: ApplicationSet Generators Should Support Jinja Conditionals HOT 1
- ApplicationSet not able to render helm chart when value is not defined in generator list
- Include SHA of test merge commit in PR generator for GitHub
- clusterDecisionResource example outdate ?
- Ability to provide multiple values files for Helm chart, using multiple sources HOT 3
- ApplicationSet fails silently
- Replace deprecated `set-output` command with environment file HOT 1
- How to set scmProvider filter based on repository group or path? HOT 1
- scmProvider for gitlab should export a Normalized version of the organization value HOT 2
- Plugin Generator throws `ApplicationSet: strict decoding error: unknown field "spec.generators[0].plugin"` HOT 4
- Application Set with Existing Project Issue HOT 1
- Matrix generator - Combine SCM and Git Generators, consume parameters from parent HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from applicationset.