Hi everyone,
The vote on SEP-1 passes with 7 +1 votes (3 binding) and no -1.
Votes are as follows:
+1 (binding) - Navina Ramesh, Yi Pan, Yan Fang
+1 (non-binding) - Boris Shkolnik, Xinyu Liu, Renato Marroquin Mogrovejo,
Ignacio Solis
The following are the discuss and vote mail threads:
DISCUSS m
+1 (binding) from me :)
Navina
On Sun, Apr 2, 2017 at 9:31 PM, Ignacio Solis wrote:
> +1 (non binding)
>
> May this be the first of many SEPs... I mean just as many as needed. :-)
>
> Nacho
>
> On Sat, Apr 1, 2017 at 1:03 PM, Kartik Paramasivam
> wrote:
> > +1 (non binding)
> >
> > Great to s
+1 (non binding)
May this be the first of many SEPs... I mean just as many as needed. :-)
Nacho
On Sat, Apr 1, 2017 at 1:03 PM, Kartik Paramasivam
wrote:
> +1 (non binding)
>
> Great to see the SEP process being followed.
>
> cheers
> Kartik
>
> On Thu, Mar 30, 2017 at 1:48 PM, Renato Marroquí
+1 (non binding)
Great to see the SEP process being followed.
cheers
Kartik
On Thu, Mar 30, 2017 at 1:48 PM, Renato Marroquín Mogrovejo <
renatoj.marroq...@gmail.com> wrote:
> Thanks for the answers Navina!
>
> +1 (non-binding)
>
> 2017-03-30 22:32 GMT+02:00 Navina Ramesh :
>
> > Hi Renato,
> >
Yi, why add 'local' to the method name? Isn't the method called only by the
StreamProcessor to get its own ID? Seems like both 1 & 2 belong in the
method documentation.
- Prateek
On Thu, Mar 30, 2017 at 1:43 PM, Yi Pan wrote:
> Talked w/ Navina offline and agreed upon:
> 1) JobCoordinator.getLo
Thanks for the answers Navina!
+1 (non-binding)
2017-03-30 22:32 GMT+02:00 Navina Ramesh :
> Hi Renato,
>
> > Having the big proposals documented on SEPs is really great to have a
> good understanding on the system!
> I agree. Our previous design process was not being strictly enforced. We
> hop
Talked w/ Navina offline and agreed upon:
1) JobCoordinator.getLocalProcessorId() to be clear that we are getting the
local processorId
2) Document the use case that there might be multiple StreamProcessors in
the same JVM and ProcessorIdGenerator should implement a counter in this
case.
So, +1 (b
Hi Renato,
> Having the big proposals documented on SEPs is really great to have a
good understanding on the system!
I agree. Our previous design process was not being strictly enforced. We
hope to enforce it going forward as there are major changes coming into the
next release.
> So this means t
Hi Navina,
Thanks for the great proposal! Having the big proposals documented on SEPs
is really great to have a good understanding on the system!
I have only a clarification question, the proposal states that every
containerId is the same as the processorId. So this means that inside a
container t
Hi Yi,
Good question. Three reasons:
1. In SAMZA-881, we came up with a set of responsibilities for the
JobCoordinator. One of them was to generate/assign processorId. So, it
makes sense to keep getProcessorId() within JobCoordinator interface.
2. StreamProcessor was initially introduced as a user
@Navina,
Sorry to chime in late. One question:
1. Why is it in JobCoordinator, and why not in StreamProcessor class?
Because JobCoordinator provides coordination service across many
processors, an interface getProcessorId() in JobCoordinator is confusing
regarding to which processorId we are getti
Good to hear from you, Yan. Thanks! :)
On Wed, Mar 29, 2017 at 7:48 PM, Yan Fang wrote:
> +1 . Thanks for the proposal, Navina. :)
>
> Fang, Yan
> yanfang...@gmail.com
>
> On Thu, Mar 30, 2017 at 4:24 AM, Prateek Maheshwari <
> pmaheshw...@linkedin.com.invalid> wrote:
>
> > +1 (non binding) from
+1 . Thanks for the proposal, Navina. :)
Fang, Yan
yanfang...@gmail.com
On Thu, Mar 30, 2017 at 4:24 AM, Prateek Maheshwari <
pmaheshw...@linkedin.com.invalid> wrote:
> +1 (non binding) from me.
>
> - Prateek
>
> On Tue, Mar 28, 2017 at 2:17 PM, Boris S wrote:
>
> > +1 Looks good to me.
> >
> >
+1 (non binding) from me.
- Prateek
On Tue, Mar 28, 2017 at 2:17 PM, Boris S wrote:
> +1 Looks good to me.
>
> On Tue, Mar 28, 2017 at 2:00 PM, xinyu liu wrote:
>
> > +1 on my side. Very happy to see this proposal. This is a blocker for
> > integrating fluent API with StreamProcessor, and hope
Thanks, Xinyu. I have already implemented a draft. Waiting for the voting
to close soon.
Navina
On Tue, Mar 28, 2017 at 2:17 PM, Boris S wrote:
> +1 Looks good to me.
>
> On Tue, Mar 28, 2017 at 2:00 PM, xinyu liu wrote:
>
> > +1 on my side. Very happy to see this proposal. This is a blocker f
+1 Looks good to me.
On Tue, Mar 28, 2017 at 2:00 PM, xinyu liu wrote:
> +1 on my side. Very happy to see this proposal. This is a blocker for
> integrating fluent API with StreamProcessor, and hopefully we can get it
> resolved soon :).
>
> Thanks,
> Xinyu
>
> On Tue, Mar 28, 2017 at 11:28 AM,
+1 on my side. Very happy to see this proposal. This is a blocker for
integrating fluent API with StreamProcessor, and hopefully we can get it
resolved soon :).
Thanks,
Xinyu
On Tue, Mar 28, 2017 at 11:28 AM, Navina Ramesh (Apache)
wrote:
> Hi everyone,
>
> This is a voting thread for SEP-1: Se
Hi everyone,
This is a voting thread for SEP-1: Semantics of ProcessorId in Samza.
For reference, here is the wiki link:
https://cwiki.apache.org/confluence/display/SAMZA/SEP-1%3A+Semantics+of+ProcessorId+in+Samza
Link to discussion mail thread:
http://mail-archives.apache.org/mod_mbox/samza-dev/
18 matches
Mail list logo
