Incident bucket

[afrittoli]

Changes

Introduce incident events.
Reference design: https://hackmd.io/h8DBfgwLQuKR7JyUPy0Xow?both

Partially-fixes: #59

Signed-off-by: Andrea Frittoli andrea.frittoli@gmail.com

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has the primer doc been updated if a design decision is involved
• Have the JSON schemas been updated if the specification changed
• Has spec version and event versions been updated according to the versioning policy
• Meets the CDEvents contributor standards

[afrittoli]

Reference hackmd: https://hackmd.io/h8DBfgwLQuKR7JyUPy0Xow

[e-backmark-ericsson]

About the naming of the new bucket. I believe it should be without an 's' in the end. So "Continuous Operation" instead of "Continuous Operations"

[m-linner-ericsson]

Same comments for all: Shouldn't this be uri instead of uri-reference? Main concern is with interoperability, the reader must then know intricate knowledge of the sender e.g. which cluster is it deployed in.

[afrittoli]

This is how it is defined in the spec https://github.com/cdevents/spec/blob/v0.1.1/spec.md#source-context so not anything defined in this PR.

The initial reason for that is that source is a URI-reference in CloudEvents. I don't think we can enforce a URI here really since not all event sources will have a URI associated, but we could do a better job at describe the format of URI-references - I'm tracking this in #29

[m-linner-ericsson]

The main reason for my objection about the uri-reference was that it allows relative urls. Basically you can have a system with two sources having the same source as they differ on the host which is not part of the source field.

Regarding this PR: These are the only events that have uri-reference in the schemas. I would suggest to remove it here an do a PR to add it in all the events. Main motivation for this is to keep the protocol consistent, why have do we have one event with this but not all.

[e-backmark-ericsson]

I'd say this PR should align with how the existing schemas look, and aligning the usage or uri/uri-reference should be done in #114

[afrittoli]

I updated this PR - alternatively we could merge #116 first, and bring back the URI-reference format here.

[afrittoli]

About the naming of the new bucket. I believe it should be without an 's' in the end. So "Continuous Operation" instead of "Continuous Operations"

Could you elaborate on why we should remove the "s"? As far as I can see from searching the internet, the practice is commonly referred to as "continuous operations" with the "s". One example https://www.gartner.com/en/information-technology/glossary/continuous-operations

[e-backmark-ericsson]

About the naming of the new bucket. I believe it should be without an 's' in the end. So "Continuous Operation" instead of "Continuous Operations"

Could you elaborate on why we should remove the "s"? As far as I can see from searching the internet, the practice is commonly referred to as "continuous operations" with the "s". One example https://www.gartner.com/en/information-technology/glossary/continuous-operations

Well, I actually mostly use the term "continuous operations" myself, but when I google on "continuous operations" and compare it to "continuous operation", the singular version is much more common it seems. And our other buckets are named in singular.

We still have the possibility to change things like this before we reach 1.0, but it will probably hurt a bit if we do so I'd like us to make conscious decisions on names like these.

Let's bring it to our workgroup meeting later today and set it there.

[e-backmark-ericsson]

Decided on workgroup meeting on March 7th to keep the 's'

[afrittoli]

Merging as discussed in the working group.