-
Notifications
You must be signed in to change notification settings - Fork 144
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
feat(resource-status): Return PAUSED status for vetoed resources #572
Conversation
@luispollo we could add the same sort of logic into the Re: I think we chose to have a semi-parseable string given the vague feeling of "it's easy to look at, serialize, we've done things for redis like this before, and right now there aren't many resource types". I agree that it makes working with the IDs a little more challenging though. |
Why don't we just trigger a new |
keel-veto/src/main/kotlin/com/netflix/spinnaker/keel/veto/application/ApplicationVeto.kt
Outdated
Show resolved
Hide resolved
@robfletcher that's a great idea! That way, the status of the resource will be reflected easily. |
Oh hey I love that idea — then you could actually follow the chain of events in the history view too. Event names could be something like |
fdb5949
to
a969c14
Compare
@gal-yardeni FYI |
keel-core/src/main/kotlin/com/netflix/spinnaker/keel/api/ResourceId.kt
Outdated
Show resolved
Hide resolved
keel-actuator/src/main/kotlin/com/netflix/spinnaker/keel/actuation/ResourceActuator.kt
Show resolved
Hide resolved
keel-actuator/src/main/kotlin/com/netflix/spinnaker/keel/actuation/ResourceActuator.kt
Outdated
Show resolved
Hide resolved
* | ||
* @param id the resource id. | ||
*/ | ||
fun lastEvent(id: ResourceId): ResourceEvent? = eventHistory(id, 1).firstOrNull() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super useful 👍
Closes #561
After discussing with @emjburns, I implemented an override of the resource status inApplicationController
, which is what the UI calls to get resource summaries, so that it was possible to use the auto-wiredVetoEnforcer
bean without introducing new cross-module dependencies (theResourceRepository
interface, which is where status is currently calculated for resources, is inkeel-core
, andVetoEnforcer
is inkeel-veto
). This works, but has the undesired side-effect that thePAUSED
status as defined by a presence of any veto on a resource is only visible from the/application
API. For example, if you call/resources
you'll still get whatever the "real" status of the resource is.@asher @robfletcher If you have any ideas on how to do this in a different/better way, I'd be happy to change things around.
@erikmunson FYI.
Update: based on feedback below, I revisited the implementation to follow the existing pattern of emitting
ResourceEvent
s fromResourceActuator
, and introduced new events for when actuation is paused/resumed. I kept the tests forApplicationController
(which are now unrelated) because we didn't have any before. I extracted the logic to parse the app name from aResourceId
into a getter so it can be used consistently. Hope this will make more sense now.P.S. I think I may have uncovered an issue with different assumptions we make about theResourceId
format in different places (seeFIXME
comment inApplicationVeto
).