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

Add sampling extension. #243

Merged
merged 4 commits into from
Aug 16, 2018

Conversation

inlined
Copy link
Contributor

@inlined inlined commented Jun 20, 2018

This pull request supercedes #76 and builds upon #242.

Per agreement at the f2f meeting 2018-06-15, this will be ratified
as an extension but not currently as part of the core spec. The
early inclusion of the spec and the ability for side-cars to impose
sampling early in the pipeline make it reasonable to start with
this as an extension.

I know the original author hoped to make this a core feature, though
there are two upsides:

  1. Due to other decisions on 2018-06-15, this will have zero impact
    on JSON encoding (but will in Proto and may in SDKs)
  2. Extensions now get a whole document. This lets us pitch sampling
    in more detail.

Necessary additional changes:

  • Added Integer to our type system
  • Added convention for how scalar extensions should be documented.
    I'm not really excited about this proposal so others are welcome.

Special thanks to @maplebed for kicking this effort off.

Closes #76

@duglin
Copy link
Collaborator

duglin commented Jun 29, 2018

@inlined I'm confused as to why github doesn't see a conflict when this touches (and overrides) some of the same files from #242 - and in the process I think we'd lose some edits (like the rename of the section to Documented Extensions). Maybe a rebase will help - not sure.


## Attributes

### (self)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if using (self) is less clear than just putting the actual text here? I'd kind of prefer to just be explicit about it instead of having a level of indirection.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed extensions.md to say that structured extensions' documentation will conventionally have an attributes section and scalar extensionsdocumentation will conventionally have avalue` section.

## Encoding

### In-memory formats
The Sampling extension uses the key `sampledRate` for in-memory formats
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing period?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we mention this for this attribute but not others?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean? The distributed tracing extension doc also says

The Distributed Tracing extension uses the key distributedTracing for in-memory formats

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't realize it did, but I was thinking about the core properties. no biggie either way.

the number of similar events that happened but were not sent plus this event.
For example, if a system sees 30 occurrences and emits a single event, `rate`
would be 30 (29 not sent and 1 sent).
Consumers SHOULD assume a value of `1` when the extension is omitted.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/SHOULD/MUST/ - although, its kind of weird to have any constraints when the extension isn't used.

Would it be better to say:
A value of 1 is the equivalent of this extension not being used at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ambivalent. Taking the change.

would be 30 (29 not sent and 1 sent).
Consumers SHOULD assume a value of `1` when the extension is omitted.
* Constraints
* The rate MUST be positive.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps "... MUST be greater than zero." ? Didn't want to get into the possible confusion around whether zero is positive or negative :-) so let's just be explicit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll change the prose rather than lecture everyone that zero is neither positive nor negative =p

@duglin
Copy link
Collaborator

duglin commented Jul 11, 2018

@inlined some comments need attention

This pull request supercedes cloudevents#76 and builds upon cloudevents#242.

Per agreement at the f2f meeting 2018-06-15, this will be ratified
as an extension but not currently as part of the core spec. The
early inclusion of the spec and the ability for side-cars to impose
sampling early in the pipeline make it reasonable to start with
this as an extension.

I know the original author hoped to make this a core feature, though
there are two upsides:
1. Due to other decisions on 2018-06-15, this will have zero impact
   on JSON encoding (but will in Proto and may in SDKs)
2. Extensions now get a whole document. This lets us pitch sampling
   in more detail.

Necessary additional changes:
* Added `Integer` to our type system
* Added convention for how scalar extensions should be documented.
  I'm not really excited about this proposal so others are welcome.

Special thanks to @maplebed for kicking this effort off.

Signed-off-by: Thomas Bouldin <[email protected]>
@inlined inlined force-pushed the extensions-breakout.sampling branch from 93b212e to d0d3e0b Compare July 25, 2018 17:40
Copy link
Contributor Author

@inlined inlined left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a bit more prose to the extensions.md to also warn about the danger of using custom transport-bindings. E.g. an MQTT -> HTTPS relay may drop custom transport bindings for extensions it is unaware.


## Attributes

### (self)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed extensions.md to say that structured extensions' documentation will conventionally have an attributes section and scalar extensionsdocumentation will conventionally have avalue` section.

the number of similar events that happened but were not sent plus this event.
For example, if a system sees 30 occurrences and emits a single event, `rate`
would be 30 (29 not sent and 1 sent).
Consumers SHOULD assume a value of `1` when the extension is omitted.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ambivalent. Taking the change.

would be 30 (29 not sent and 1 sent).
Consumers SHOULD assume a value of `1` when the extension is omitted.
* Constraints
* The rate MUST be positive.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll change the prose rather than lecture everyone that zero is neither positive nor negative =p

## Encoding

### In-memory formats
The Sampling extension uses the key `sampledRate` for in-memory formats
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean? The distributed tracing extension doc also says

The Distributed Tracing extension uses the key distributedTracing for in-memory formats

@inlined inlined force-pushed the extensions-breakout.sampling branch from d0d3e0b to 60ad09d Compare July 25, 2018 17:42
# Sampling extension

There are many cases in an Event's life when a system (either the system
creating the event or a system transporting the event) may wish to only emit a
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/may/might/

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since this isn't a normative statement, its just exemplary

There are many cases in an Event's life when a system (either the system
creating the event or a system transporting the event) may wish to only emit a
portion of the events that actually happened. In a high throughput system where
creating the event is costly, a system may wish to only create an event for
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/may/might/ since this isn't a normative statement

creating the event is costly, a system may wish to only create an event for
1/100 of the times that something happened. Additionally, during the
transmission of an event from the source to the eventual recipient, any step
along the way may choose to only pass along a fraction of the events it
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/may/can/


In order for the system receiving the event to understand what is actually
happening in the system that generated the event, information about how many
similar events may have happened must be included in the event itself. This
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/may have happened must be/happened would need to be/

@duglin
Copy link
Collaborator

duglin commented Jul 25, 2018

overall LGTM just a fit syntax things

@duglin
Copy link
Collaborator

duglin commented Aug 9, 2018

still LGTM

All - please review (and LGTM, or not) for next week's call

@Vlaaaaaaad
Copy link

LGTM

extensions.md Outdated

## Documented Extensions
As a convention, extensions of scalar types (`String`, `Binary`, `URI`,
Copy link
Contributor

@markpeek markpeek Aug 10, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR added an Integer type. Should either list it here or add "e.g." to not list all of the scaler types.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to adding e.g.

@duglin
Copy link
Collaborator

duglin commented Aug 15, 2018

All, please review this one. I'm putting into the category of "easy/quick approval" for this week's call, so please speak up prior to the call if you see any issues.

@duglin
Copy link
Collaborator

duglin commented Aug 16, 2018

Approved on 8/16 call

@duglin duglin merged commit 3248e31 into cloudevents:master Aug 16, 2018
zpencer pushed a commit to zpencer/spec that referenced this pull request Aug 22, 2018
* Add sampling extension.

This pull request supercedes cloudevents#76 and builds upon cloudevents#242.

Per agreement at the f2f meeting 2018-06-15, this will be ratified
as an extension but not currently as part of the core spec. The
early inclusion of the spec and the ability for side-cars to impose
sampling early in the pipeline make it reasonable to start with
this as an extension.

I know the original author hoped to make this a core feature, though
there are two upsides:
1. Due to other decisions on 2018-06-15, this will have zero impact
   on JSON encoding (but will in Proto and may in SDKs)
2. Extensions now get a whole document. This lets us pitch sampling
   in more detail.

Necessary additional changes:
* Added `Integer` to our type system
* Added convention for how scalar extensions should be documented.
  I'm not really excited about this proposal so others are welcome.

Special thanks to @maplebed for kicking this effort off.

Signed-off-by: Thomas Bouldin <[email protected]>

* PR feedback; also add conttent to extensions.md

Signed-off-by: Thomas Bouldin <[email protected]>

* @douglin doesn't like the world 'may' 😉

Signed-off-by: Thomas Bouldin <[email protected]>

* Add 'e.g.' to list of scalar types in conventions

Signed-off-by: Thomas Bouldin <[email protected]>
@duglin duglin mentioned this pull request Nov 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants