Roadmap updated with feedback#55
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ultrasaurus The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| # 0.4 | ||
| * A. An event can trigger an Elafros function [issue#52](https://github.com/elafros/eventing/issues/52) | ||
| * B. A local event can trigger a Google Cloud Function | ||
| * C. A Google source can trigger a local action. Likely this will use some |
There was a problem hiding this comment.
Does local mean within the Elafros cluster?
There was a problem hiding this comment.
Yep. Updated the wording to convey that
| * A. Ability to register an event sources and specify which events may be | ||
| generated from that source | ||
| [Proposal](https://github.com/elafros/eventing/issues/39) | ||
| * B. kubctl command to set up a trigger where a specific event will cause a |
| # 0.1 CloudEvents Demo | ||
|
|
||
| # 0.2 | ||
| * A. Ability to register an event sources and specify which events may be |
There was a problem hiding this comment.
FWIW, if you prefix these with 1. the items will be numbered. Or * to make bullet points. e.g.,
1. foo
1. bar
1. baz
- foo
- bar
- baz
Not sure how to make them A, B, C though.
There was a problem hiding this comment.
GitHub markdown doesn't support A, B, C. I miss it terribly, but it's not going to happen.
imjasonh
left a comment
There was a problem hiding this comment.
I don't have any feedback on the roadmap itself, just formatting nits and typos
| @@ -1,22 +1,48 @@ | |||
| Eventing Roadmap | |||
|
|
||
| # 0.1 | ||
| At the end of each milestone, there should be a new or updated demo in | ||
| the samples directory. |
There was a problem hiding this comment.
Link to samples directory?
There was a problem hiding this comment.
simplified to link in README
| 1. There is a well-defined interface that allows the use of popular event | ||
| brokers for persistence, such as Kafka and Rabbit Mq | ||
|
|
||
| # 0.5 Piplelines |
| generated from that source | ||
| [Proposal](https://github.com/elafros/eventing/issues/39) | ||
| 1. kubectl command to set up a trigger where a specific event will cause a | ||
| specific action powered by a specific processor |
There was a problem hiding this comment.
why is the processor abstraction needed? If the "target" is simply a URL, we could rely on all of the features of envoy (traffic policies, security, metrics, etc), and that would provide consistency with "normal" HTTP traffic via routes to apps
There was a problem hiding this comment.
Sorry if the term processor is confusing... it makes sense to me to have the target be a specific URL, but also having some additional data besides the URL may help instrumentation and debugging. For now, I'll drop "powered by a specific processor" from the roadmap and we can work out the details in PRs or issues
|
|
||
| # 0.6 Streams | ||
|
|
||
| 1. an action may accept a stream interface to process many events at once |
There was a problem hiding this comment.
interesting.... will review. Prolly too granular for the roadmap tho
|
|
||
| # 0.5 Piplelines | ||
|
|
||
| 1. Pipeline the output of one action into the input of another |
There was a problem hiding this comment.
this should include (perhaps as a separate bullet point) the ability to have multiple actions downstream
should this include buffering? would it require one of the brokers mentioned in the 0.4 section?
There was a problem hiding this comment.
- buffering was intended to be part of 0.4 -- made that more clear
- added second bullet on pipelining
ultrasaurus
left a comment
There was a problem hiding this comment.
addressed feedback
| generated from that source | ||
| [Proposal](https://github.com/elafros/eventing/issues/39) | ||
| 1. kubectl command to set up a trigger where a specific event will cause a | ||
| specific action powered by a specific processor |
There was a problem hiding this comment.
Sorry if the term processor is confusing... it makes sense to me to have the target be a specific URL, but also having some additional data besides the URL may help instrumentation and debugging. For now, I'll drop "powered by a specific processor" from the roadmap and we can work out the details in PRs or issues
|
|
||
| # 0.1 | ||
| At the end of each milestone, there should be a new or updated demo in | ||
| the samples directory. |
There was a problem hiding this comment.
simplified to link in README
| 1. There is a well-defined interface that allows the use of popular event | ||
| brokers for persistence, such as Kafka and Rabbit Mq | ||
|
|
||
| # 0.5 Piplelines |
|
|
||
| # 0.5 Piplelines | ||
|
|
||
| 1. Pipeline the output of one action into the input of another |
There was a problem hiding this comment.
- buffering was intended to be part of 0.4 -- made that more clear
- added second bullet on pipelining
|
|
||
| # 0.6 Streams | ||
|
|
||
| 1. an action may accept a stream interface to process many events at once |
There was a problem hiding this comment.
interesting.... will review. Prolly too granular for the roadmap tho
|
/assign @mogar1980 -- all feedback addressed, pls review |
|
/lgtm |
partially addresses #45
this addresses feedback from #46 (and fixes formatting)
I accidentally requested review when I hadn't pushed the changes!