Hi, Cameron, Sorry to chime in late. Overall, looks great! I do have a few suggestions/questions before I can cast my vote here: a) for the configuration variable names, why are we limiting ourselves to yarn.resource.*? We have changed some of the configuration variables from yarn specific to non-yarn specific. I would love to keep that consistent (i.e. gradually moving all our yarn-specific configuration variables to non-yarn-specifc names) b) for the avro case as referred to in the delegation case in the Infrastructure classloader, if we delegate the object deserialization class to the application classloader, would it be possible that the application provides an non-compatible version of avro class than the ones used within the "infrastructure plugins" and hence causing runtime exception in the infrastructure plugin? Or is the solution being: do not directly use serde classes in the infrastructure code? c) following the description of infrastructure classloader flow, where should we expect the serde classes? In the application classpath, I guess? So, does that mean that we should exclude serde classes (including SerializableSerde and JsonSerdeV2) in the Samza infrastructure package, and tell the users to package them in application package? d) I am a bit confused about the description on "multiple" application classloaders on the job coordinator: one is for the describe flow and the other is in the "Application" classloader, instead of "API" classloader, right?
Best, -Yi On Wed, Mar 4, 2020 at 11:32 AM Ke Wu <ke.wu...@gmail.com> wrote: > +1. > > Thanks for driving this effort. > > Best, > Ke > > > On Mar 3, 2020, at 6:28 PM, Jagadish Venkatraman <jagadish1...@gmail.com> > wrote: > > > > +1 binding. > > > > Thanks Cameron. I look forward to this feature taking our "Stream > > Processing as a service" offering to the next level. > > > > Cheers > > > > On Tuesday, March 3, 2020, Prateek Maheshwari <prate...@utexas.edu> > wrote: > > > >> +1 (binding) from me. Thanks for contributing this feature. Looking > forward > >> to having dependency isolation and to the ability to upgrade the > framework > >> independently from an application. > >> > >> Thanks, > >> Prateek > >> > >> On Fri, Feb 28, 2020 at 10:48 AM Cameron Lee <cameronlee...@gmail.com> > >> wrote: > >> > >>> Hi all, > >>> > >>> This is a call for a vote on SEP-24: Cluster-based Job Coordinator > >>> Dependency Isolation. Thanks to everyone who reviewed the proposal and > >>> provided feedback. > >>> > >>> I have addressed comments on the SEP, and I am not aware of any further > >>> major questions or objections, so I am starting this vote. > >>> > >>> SEP link: > >>> > >>> https://cwiki.apache.org/confluence/display/SAMZA/SEP- > >> 24%3A+Cluster-based+Job+Coordinator+Dependency+Isolation > >>> > >>> Discuss thread: > >>> > >>> https://mail-archives.apache.org/mod_mbox/samza-dev/202001.mbox/% > >> 3cCAMja7KeGcRZ3H95Rxk5XE=60zxm6jxjkjuwwxmgmadpfbyk...@mail.gmail.com%3e > >>> There was also some discussion through comments on the SEP page (see > >>> Resolved Comments). > >>> > >>> Please vote: > >>> [ ] +1 approve > >>> [ ] +0 no opinion > >>> [ ] -1 disapprove (and reason why) > >>> > >>> Thank you, > >>> Cameron > >>> > >> > > > > > > -- > > Jagadish > >
