In Keptn 0.7.x and spec 0.1.7 as well as Keptn 0.8.0-alpha and spec 0.2.0-alpha we are still using the old Problem / Problem.Open CloudEvents.
Those are most certainly not compatible with our new .triggered/.started/.finished structure. In addition, in our spec we only list problem.open, but no longer “just” problem (which is sent by Dynatrace to our API).
Suggested fix (to be discussed):
Right now the workflow is a little bit weird. Dynatrace sends a Problem Notification to Keptn API, which is processed as if it was a CloudEvent, and then Service parses this and sends a Problem.Open CloudEvent.
For one, Dynatrace could try to communicate directly via Dynatrace-Service (and not via Keptn API) to send the Problem Event (though this would require Dynatrace-Service to be reachable from the outside, which it currently is not).
Second, Problem.Open CloudEvents could be streamlined to use .triggered/.started/.finished - or maybe it should even just be .problem.triggered (without the .open)?
As a tradeoff, we could do the following:
Dynatrace keeps sending a sh.keptn.events.problem to stay backwards compatible (we can think of introducing sh.keptn.events.problem.triggered). We need to define this event in our CloudEvents spec.
Dynatrace-Service reacts on this event, and sends a problem.open.triggered (we need to introduce problem.open.triggered).
Remediation-Service listens on problem.open.triggered and reacts on it with sending appropriate .started and .finished events
To be discussed: How do we handle problem close/resolve events from Dynatrace?
In Keptn 0.7.x and spec 0.1.7 as well as Keptn 0.8.0-alpha and spec 0.2.0-alpha we are still using the old Problem / Problem.Open CloudEvents.
Those are most certainly not compatible with our new .triggered/.started/.finished structure. In addition, in our spec we only list problem.open, but no longer “just” problem (which is sent by Dynatrace to our API).
Suggested fix (to be discussed):
Right now the workflow is a little bit weird. Dynatrace sends a Problem Notification to Keptn API, which is processed as if it was a CloudEvent, and then Service parses this and sends a Problem.Open CloudEvent.
For one, Dynatrace could try to communicate directly via Dynatrace-Service (and not via Keptn API) to send the Problem Event (though this would require Dynatrace-Service to be reachable from the outside, which it currently is not).
Second, Problem.Open CloudEvents could be streamlined to use .triggered/.started/.finished - or maybe it should even just be .problem.triggered (without the .open)?
As a tradeoff, we could do the following:
Dynatrace keeps sending a sh.keptn.events.problem to stay backwards compatible (we can think of introducing sh.keptn.events.problem.triggered). We need to define this event in our CloudEvents spec.
Dynatrace-Service reacts on this event, and sends a problem.open.triggered (we need to introduce problem.open.triggered).
Remediation-Service listens on problem.open.triggered and reacts on it with sending appropriate .started and .finished events
To be discussed: How do we handle problem close/resolve events from Dynatrace?