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

Removed and upgraded predicates for service, removal consideration? #193

Open
xibz opened this issue Mar 25, 2024 · 6 comments
Open

Removed and upgraded predicates for service, removal consideration? #193

xibz opened this issue Mar 25, 2024 · 6 comments
Assignees
Labels
breaking change Indicates when a PR or issue will have breaking changes
Milestone

Comments

@xibz
Copy link
Contributor

xibz commented Mar 25, 2024

When creating predicates I think there are two avenues to look at:

  1. How consumer will use such event
  2. How tools can produce these events

Specifically, upgraded and removal seem questionable for 2.

For tools like Spinnaker, Argo, and Temporal, there is no concept of removed and/or upgraded. Artifacts are only ever deployed. This would only be possible if the user provided such metadata. Most deployments are automated, so it isn't too clear how these events could be generated. These are the only CD platforms I considered, so if there is a tool that does support these concepts, then these events have a purpose. I just did not find any.

I would like to start discussion on removal and/or adding for what makes sense in the CD type events.

@xibz
Copy link
Contributor Author

xibz commented Mar 25, 2024

One thing we could consider if it makes sense to have something like Kubernetes that would send these events. However, would that make sense to be under CD? Or a new grouping of infrastructure?

@afrittoli
Copy link
Contributor

The events were indeed defined as thinking about generic deployment workflows. A service can be deployed for instance to Kubernetes using Helm, and through Helm, it is possible to upgrade the service and remove it.
Tools that do not support such events can safely ignore them.

@xibz
Copy link
Contributor Author

xibz commented Apr 15, 2024

I wonder if it makes sense to highlight that in the docs for these events, cause they aren't necessarily apart of CD services. So users may find it confusing.

What may be odd too, is that if helm decided to implement this along with kubernetes, wont that be duplicate events?

@e-backmark-ericsson e-backmark-ericsson added this to the v0.5 milestone Apr 22, 2024
@xibz xibz added the breaking change Indicates when a PR or issue will have breaking changes label Apr 30, 2024
@afrittoli
Copy link
Contributor

@afrittoli to provide more context on the semantic

@xibz
Copy link
Contributor Author

xibz commented Nov 8, 2024

@afrittoli - Based on your comment of "services can just ignore it", I still don't see how that would work simply. So if things get removed, would producers send two events? Removed and updated? Otherwise services who don't have a remove concept, would send updated, and any consumer would need to listen for both then? That seem complicated and seems to indicate some problem

@xbcsmith
Copy link

If the tools don't understand the data then the information is just for humans.

My suggestion is use a single predicate of "deployed" and push "upgraded" and "removed" down into the event.

@xibz xibz moved this from Todo to Review in CDEvents Releases Nov 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Indicates when a PR or issue will have breaking changes
Projects
Status: Review
Development

No branches or pull requests

4 participants