You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Jordan Zimmerman <jz...@netflix.com> on 2011/12/13 17:46:11 UTC
Curator, a ZooKeeper Recipe Proposal
While we're not interested in submitting Curator to the Incubator, I've
prepared a proposal for including Curator as a ZooKeeper sub-project or
inclusion in the main project. Here's the proposal (for commenting, etc.):
Curator, a ZooKeeper Recipe Proposal
====================================
== Abstract ==
Users of Apache ZooKeeper would greatly benefit from having a high quality
implementation of common recipes included with the ZooKeeper distribution.
Curator is that implementation.
== Proposal ==
Apache ZooKeeper should produce a new artifact for recipes/applications.
This artifact should either be a ZooKeeper sub-project or top-level part
of ZooKeeper itself. For Java (and possibly other JVM based languages),
the Netflix Curator project should be the artifact.
The recipe implementations currently included with the ZooKeeper
distribution should be deprecated in favor of Curator.
== Background ==
ZooKeeper consists of server software and client software. The client
implementations that are part of the ZooKeeper distribution are very low
level and difficult to use correctly. Further, implementing the recipes
listed in the ZooKeeper documentation is non-trivial and involves deep
knowledge of ZooKeeper best practices and edge cases.
== Rationale ==
The existing clients for ZooKeeper are difficult to use and are limited.
Further, correct usage of ZooKeeper is non-trivial and non-obvious. Users
of ZooKeeper are mostly interested in the recipes/applications and are not
likely interested in becoming experts in the minutiae of correct ZooKeeper
client usage. What they want is a simple way to use the recipes. Curator
is directed at this goal.
== Current Status ==
Curator is an active open source project hosted at Github
(https://github.com/netflix/curator). It has no dependencies other than
industry standard libraries. It provides implementations for all recipes
listed on the ZooKeeper recipes doc as well as a high level framework for
using ZooKeeper that simplifies most of the low level housekeeping
normally required.
Curator has been open since October, 2011 and has been reviewed by several
active members of the ZooKeeper community.
Netflix is a strong proponent of open source and is supportive of
providing the community with this project.
== Core Developers ==
The initial set of committers are all employees of Netflix, Inc. The lead
developer is Jordan Zimmerman (jzimmerman@netflix.com), Senior Platform
Engineer at Netflix, Inc.
== Alignment ==
The current ZooKeeper distribution has an obvious hole in regard to
recipes/applications. Curator's minimal dependencies and use of standard
ZooKeeper components and recipe algorithms make it a natural compliment to
the ZooKeeper distribution.
== Known Risks ==
Orphan-ing of Curator:
ZooKeeper has become a major component at Netflix. Curator is the
abstraction being used.
Open Source Experience:
Netflix has major experience with open source. All the committers of
Curator have long experience with open source.
Homogenous/Salaried Developers:
The current committers are all salaried employees of Netflix. This
proposal would help by having a more diverse set of committers.
Ties to Apache products:
The initial codebase relies heavily on existing Apache technologies and
will continue to do so.
== Documentation ==
Comprehensive documentation is at https://github.com/Netflix/curator/wiki
== Initial Source ==
The source code currently is hosted at Github at:
https://github.com/Netflix/curator
== External Dependencies ==
Runtime:
* Apache ZooKeeper
* Google Guava
Testing:
* Test NG
* Apache Commons Math
* Mockito
* Javaassist
Building:
* Apache Maven
== Initial Committers ==
Jordan Zimmerman (Netflix, Inc.)
Jay Zarfoss (Netflix, Inc.)
Jerome Boulon (Netflix, Inc.)
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Jordan Zimmerman <jz...@netflix.com>.
Of course. I'll update the proposal (my copy - I'll resend when there are
more comments).
-JZ
On 12/15/11 1:24 PM, "Ted Dunning" <te...@gmail.com> wrote:
>That will be our responsibility once (if) this is accepted.
>
>On Thu, Dec 15, 2011 at 1:35 PM, Jordan Zimmerman
><jz...@netflix.com>wrote:
>
>> As long as the doc for the legacy recipes point ppl to the new
>> implementations that would be fine. What should be avoided is someone
>> casually looking at the docs and using the legacy version because he
>> wasn't aware that there was a newer one.
>>
>> -JZ
>>
>> On 12/15/11 12:17 PM, "Ted Dunning" <te...@gmail.com> wrote:
>>
>> >>I thought that that would be confusing. My thinking is that most
>>people
>> >> are going to get ZooKeeper because they need to do X (locking,
>>leader,
>> >> etc.). They won't spend a lot of time learning the internals and will
>> >>just
>> >> search for the recipe they need. If they see two they'd be uncertain.
>> >>
>> >
>> >This is what Javadoc is for. If one of the legacy recipes is
>>distinctly
>> >less good than a new one, we should document the distinction and give a
>> >pointer in the javadoc.
>>
>>
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Ted Dunning <te...@gmail.com>.
That will be our responsibility once (if) this is accepted.
On Thu, Dec 15, 2011 at 1:35 PM, Jordan Zimmerman <jz...@netflix.com>wrote:
> As long as the doc for the legacy recipes point ppl to the new
> implementations that would be fine. What should be avoided is someone
> casually looking at the docs and using the legacy version because he
> wasn't aware that there was a newer one.
>
> -JZ
>
> On 12/15/11 12:17 PM, "Ted Dunning" <te...@gmail.com> wrote:
>
> >>I thought that that would be confusing. My thinking is that most people
> >> are going to get ZooKeeper because they need to do X (locking, leader,
> >> etc.). They won't spend a lot of time learning the internals and will
> >>just
> >> search for the recipe they need. If they see two they'd be uncertain.
> >>
> >
> >This is what Javadoc is for. If one of the legacy recipes is distinctly
> >less good than a new one, we should document the distinction and give a
> >pointer in the javadoc.
>
>
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Jordan Zimmerman <jz...@netflix.com>.
As long as the doc for the legacy recipes point ppl to the new
implementations that would be fine. What should be avoided is someone
casually looking at the docs and using the legacy version because he
wasn't aware that there was a newer one.
-JZ
On 12/15/11 12:17 PM, "Ted Dunning" <te...@gmail.com> wrote:
>>I thought that that would be confusing. My thinking is that most people
>> are going to get ZooKeeper because they need to do X (locking, leader,
>> etc.). They won't spend a lot of time learning the internals and will
>>just
>> search for the recipe they need. If they see two they'd be uncertain.
>>
>
>This is what Javadoc is for. If one of the legacy recipes is distinctly
>less good than a new one, we should document the distinction and give a
>pointer in the javadoc.
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Ted Dunning <te...@gmail.com>.
On Thu, Dec 15, 2011 at 12:58 PM, Jordan Zimmerman
<jz...@netflix.com>wrote:
> >I wonder if it really makes sense to deprecate the current ones in
> >favor of Curator's, or if it is a better idea to keep multiple
> >versions in the case of duplicates.
>
> I thought that that would be confusing. My thinking is that most people
> are going to get ZooKeeper because they need to do X (locking, leader,
> etc.). They won't spend a lot of time learning the internals and will just
> search for the recipe they need. If they see two they'd be uncertain.
>
This is what Javadoc is for. If one of the legacy recipes is distinctly
less good than a new one, we should document the distinction and give a
pointer in the javadoc.
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Ted Dunning <te...@gmail.com>.
To amplify on this, it would be much easier to add committers to the
incubator project than to ZK itself.
On Wed, Dec 28, 2011 at 2:52 PM, Patrick Hunt <ph...@apache.org> wrote:
> > WRT committer status, I don't see how it can work without us being
> > committers to Curator. If we're not committers, we'll need to fork it
> > internally and I've already gotten a lot of negative feedback on that
> > (there are a lot of former Yahoo-ers here).
>
> What Doug is suggesting is that while you wouldn't be able to commit
> yourselves (to start with) one of the existing zk committers would
> have to review/commit for you. Granted it's not an optimal situation.
> That's why incubator/subproj are better imo.
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Patrick Hunt <ph...@apache.org>.
On Wed, Dec 28, 2011 at 2:39 PM, Jordan Zimmerman
<jz...@netflix.com> wrote:
> I appreciate the desire to go through Incubator. Maybe our concerns are
> out-dated. I'll circulate this around Netflix and get some responses.
whirr recently graduated to tlp status, see flume, sqoop, bigtop,
mrunit, s4 for examples of projects that I'm currently mentoring and
are doing quite well (granted I'm not the only mentor. ;-) ). All
short of s4 and flume have had successful releases in the incubator
with minimal muss/fuss. (s4 is quite new and flume is about to put out
a release).
> WRT committer status, I don't see how it can work without us being
> committers to Curator. If we're not committers, we'll need to fork it
> internally and I've already gotten a lot of negative feedback on that
> (there are a lot of former Yahoo-ers here).
What Doug is suggesting is that while you wouldn't be able to commit
yourselves (to start with) one of the existing zk committers would
have to review/commit for you. Granted it's not an optimal situation.
That's why incubator/subproj are better imo.
Patrick
>
> On 12/28/11 10:02 AM, "Patrick Hunt" <ph...@apache.org> wrote:
>
>>I wanted to share this section of my recent report to the board (I've
>>also gotten permission to share the board's response)
>>
>>> A discussion is currently under way regarding the possibility of>
>>>merging the recently open sourced "Curator" source base from> Netflix.
>>>These are client implementations of ZooKeeper "recipes"> (e.g.
>>>leadership election, group membership, etc...) which simplify> the act
>>>of using ZooKeeper in client side applications.>> The authors of Curator
>>>are unwilling to join the incubator, this is> based on their past
>>>experience as well as some of the ongoing issues> they are seeing wrt
>>>projects entering the incubator. They have> expressed a preference to
>>>come in either as a subproject or as a> separate release artifact of the
>>>TLP.
>>
>>to which the board responded:
>>
>>Doug Cutting (chairman):
>>+ Long-term, do you think that Curator will have an
>>+ indepdendent community from Zookeeper? If so, then it
>>+ ought to enter through the Incubator. If not then the
>>+ code might still enter through the incubator for
>>+ resolution of IP issues, but then transfer relatively
>>+ quickly to live under the Zookeeper PMC. Or the
>>+ Zookeeper PMC could directly adopt the code, although
>>+ you might not immediately add its committers to the
>>+ project but rather have them first contribute patches
>>+ through the normal process until their community merit
>>+ is established.
>>
>>Sam Ruby:
>>+ suggested that the "short form" of the incubator's IP clearance
>>process would be appropriate if Zookeeper directly adopts this code.
>>
>>The short form can be found here:
>>http://incubator.apache.org/ip-clearance/index.html
>>
>>I personally still feel that incubator is the best place for starting
>>this. I have a good track record as a podling mentor and I feel
>>strongly that we could quickly/successfully incubate this project and
>>graduate (given there's strong leadership by the Curator committers
>>themselves).
>>
>>Patrick
>>
>>On Tue, Dec 27, 2011 at 11:10 AM, Jordan Zimmerman
>><jz...@netflix.com> wrote:
>>> Any other comments on this? If not, what should the next steps be?
>>>
>>> -JZ
>>>
>>> On 12/15/11 10:07 AM, "Jordan Zimmerman" <jz...@netflix.com> wrote:
>>>
>>>>I'd be happy to have Ted as both committer and mentor. I'd be happy to
>>>>have Patrick and/or as mentor as well.
>>>>
>>>>-JZ
>>>>
>>>>On 12/14/11 7:03 PM, "Ted Dunning" <te...@gmail.com> wrote:
>>>>
>>>>>On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <fp...@yahoo-inc.com>
>>>>>wrote:
>>>>>
>>>>>> Hi Jordan, Here is some feedback. I like the proposal and it makes
>>>>>>sense
>>>>>> to have such a project as either sub-project or incubator. I have a
>>>>>>few
>>>>>> concerns, though:
>>>>>>
>>>>>> 1- I haven't been following closely the development of the recipes,
>>>>>>but
>>>>>>I
>>>>>> wonder if it really makes sense to deprecate the current ones in
>>>>>>favor
>>>>>>of
>>>>>> Curator's, or if it is a better idea to keep multiple versions in the
>>>>>>case
>>>>>> of duplicates. People in the community have spent time on the current
>>>>>> recipes, so I don't like very much the idea of dropping the current
>>>>>>recipes
>>>>>> without some evidence that the community accepts it. Note that I'm
>>>>>>not
>>>>>> saying that deprecating is not the right thing to do, I'm simply
>>>>>>saying
>>>>>> that we need to make sure that the community agrees.
>>>>>>
>>>>>
>>>>>I agree that not deprecating is a good thing. We could mark them with
>>>>>annotations that indicate that we haven't heard yet from a community of
>>>>>users. If we don't hear about significant usage, then deprecation
>>>>>might
>>>>>be
>>>>>warranted.
>>>>>
>>>>>2- The set of committers needs to be more diverse. Perhaps it would be
>>>>>> easier to find more committers if you follow the incubation process,
>>>>>>given
>>>>>> that typically people sign up for committership once you post a
>>>>>>proposal
>>>>>> there. I wonder how many other people on this list would like to
>>>>>>volunteer
>>>>>> to become a committer of Curator, though. I like the project, but
>>>>>> unfortunately I don't have the cycles to do it.
>>>>>>
>>>>>
>>>>>I would volunteer.
>>>>>
>>>>>
>>>>>> 3- If Curator becomes a sub-project of ZooKeeper, then you need at
>>>>>>least
>>>>>> one mentor. Is there anyone who would like to sign up to mentor
>>>>>>Curator?
>>>>>>
>>>>>
>>>>>Likewise.
>>>>
>>>>
>>>
>>
>
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Jordan Zimmerman <jz...@netflix.com>.
I appreciate the desire to go through Incubator. Maybe our concerns are
out-dated. I'll circulate this around Netflix and get some responses.
WRT committer status, I don't see how it can work without us being
committers to Curator. If we're not committers, we'll need to fork it
internally and I've already gotten a lot of negative feedback on that
(there are a lot of former Yahoo-ers here).
-JZ
On 12/28/11 10:02 AM, "Patrick Hunt" <ph...@apache.org> wrote:
>I wanted to share this section of my recent report to the board (I've
>also gotten permission to share the board's response)
>
>> A discussion is currently under way regarding the possibility of>
>>merging the recently open sourced "Curator" source base from> Netflix.
>>These are client implementations of ZooKeeper "recipes"> (e.g.
>>leadership election, group membership, etc...) which simplify> the act
>>of using ZooKeeper in client side applications.>> The authors of Curator
>>are unwilling to join the incubator, this is> based on their past
>>experience as well as some of the ongoing issues> they are seeing wrt
>>projects entering the incubator. They have> expressed a preference to
>>come in either as a subproject or as a> separate release artifact of the
>>TLP.
>
>to which the board responded:
>
>Doug Cutting (chairman):
>+ Long-term, do you think that Curator will have an
>+ indepdendent community from Zookeeper? If so, then it
>+ ought to enter through the Incubator. If not then the
>+ code might still enter through the incubator for
>+ resolution of IP issues, but then transfer relatively
>+ quickly to live under the Zookeeper PMC. Or the
>+ Zookeeper PMC could directly adopt the code, although
>+ you might not immediately add its committers to the
>+ project but rather have them first contribute patches
>+ through the normal process until their community merit
>+ is established.
>
>Sam Ruby:
>+ suggested that the "short form" of the incubator's IP clearance
>process would be appropriate if Zookeeper directly adopts this code.
>
>The short form can be found here:
>http://incubator.apache.org/ip-clearance/index.html
>
>I personally still feel that incubator is the best place for starting
>this. I have a good track record as a podling mentor and I feel
>strongly that we could quickly/successfully incubate this project and
>graduate (given there's strong leadership by the Curator committers
>themselves).
>
>Patrick
>
>On Tue, Dec 27, 2011 at 11:10 AM, Jordan Zimmerman
><jz...@netflix.com> wrote:
>> Any other comments on this? If not, what should the next steps be?
>>
>> -JZ
>>
>> On 12/15/11 10:07 AM, "Jordan Zimmerman" <jz...@netflix.com> wrote:
>>
>>>I'd be happy to have Ted as both committer and mentor. I'd be happy to
>>>have Patrick and/or as mentor as well.
>>>
>>>-JZ
>>>
>>>On 12/14/11 7:03 PM, "Ted Dunning" <te...@gmail.com> wrote:
>>>
>>>>On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <fp...@yahoo-inc.com>
>>>>wrote:
>>>>
>>>>> Hi Jordan, Here is some feedback. I like the proposal and it makes
>>>>>sense
>>>>> to have such a project as either sub-project or incubator. I have a
>>>>>few
>>>>> concerns, though:
>>>>>
>>>>> 1- I haven't been following closely the development of the recipes,
>>>>>but
>>>>>I
>>>>> wonder if it really makes sense to deprecate the current ones in
>>>>>favor
>>>>>of
>>>>> Curator's, or if it is a better idea to keep multiple versions in the
>>>>>case
>>>>> of duplicates. People in the community have spent time on the current
>>>>> recipes, so I don't like very much the idea of dropping the current
>>>>>recipes
>>>>> without some evidence that the community accepts it. Note that I'm
>>>>>not
>>>>> saying that deprecating is not the right thing to do, I'm simply
>>>>>saying
>>>>> that we need to make sure that the community agrees.
>>>>>
>>>>
>>>>I agree that not deprecating is a good thing. We could mark them with
>>>>annotations that indicate that we haven't heard yet from a community of
>>>>users. If we don't hear about significant usage, then deprecation
>>>>might
>>>>be
>>>>warranted.
>>>>
>>>>2- The set of committers needs to be more diverse. Perhaps it would be
>>>>> easier to find more committers if you follow the incubation process,
>>>>>given
>>>>> that typically people sign up for committership once you post a
>>>>>proposal
>>>>> there. I wonder how many other people on this list would like to
>>>>>volunteer
>>>>> to become a committer of Curator, though. I like the project, but
>>>>> unfortunately I don't have the cycles to do it.
>>>>>
>>>>
>>>>I would volunteer.
>>>>
>>>>
>>>>> 3- If Curator becomes a sub-project of ZooKeeper, then you need at
>>>>>least
>>>>> one mentor. Is there anyone who would like to sign up to mentor
>>>>>Curator?
>>>>>
>>>>
>>>>Likewise.
>>>
>>>
>>
>
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Patrick Hunt <ph...@apache.org>.
I wanted to share this section of my recent report to the board (I've
also gotten permission to share the board's response)
> A discussion is currently under way regarding the possibility of> merging the recently open sourced "Curator" source base from> Netflix. These are client implementations of ZooKeeper "recipes"> (e.g. leadership election, group membership, etc...) which simplify> the act of using ZooKeeper in client side applications.>> The authors of Curator are unwilling to join the incubator, this is> based on their past experience as well as some of the ongoing issues> they are seeing wrt projects entering the incubator. They have> expressed a preference to come in either as a subproject or as a> separate release artifact of the TLP.
to which the board responded:
Doug Cutting (chairman):
+ Long-term, do you think that Curator will have an
+ indepdendent community from Zookeeper? If so, then it
+ ought to enter through the Incubator. If not then the
+ code might still enter through the incubator for
+ resolution of IP issues, but then transfer relatively
+ quickly to live under the Zookeeper PMC. Or the
+ Zookeeper PMC could directly adopt the code, although
+ you might not immediately add its committers to the
+ project but rather have them first contribute patches
+ through the normal process until their community merit
+ is established.
Sam Ruby:
+ suggested that the "short form" of the incubator's IP clearance
process would be appropriate if Zookeeper directly adopts this code.
The short form can be found here:
http://incubator.apache.org/ip-clearance/index.html
I personally still feel that incubator is the best place for starting
this. I have a good track record as a podling mentor and I feel
strongly that we could quickly/successfully incubate this project and
graduate (given there's strong leadership by the Curator committers
themselves).
Patrick
On Tue, Dec 27, 2011 at 11:10 AM, Jordan Zimmerman
<jz...@netflix.com> wrote:
> Any other comments on this? If not, what should the next steps be?
>
> -JZ
>
> On 12/15/11 10:07 AM, "Jordan Zimmerman" <jz...@netflix.com> wrote:
>
>>I'd be happy to have Ted as both committer and mentor. I'd be happy to
>>have Patrick and/or as mentor as well.
>>
>>-JZ
>>
>>On 12/14/11 7:03 PM, "Ted Dunning" <te...@gmail.com> wrote:
>>
>>>On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <fp...@yahoo-inc.com>
>>>wrote:
>>>
>>>> Hi Jordan, Here is some feedback. I like the proposal and it makes
>>>>sense
>>>> to have such a project as either sub-project or incubator. I have a few
>>>> concerns, though:
>>>>
>>>> 1- I haven't been following closely the development of the recipes, but
>>>>I
>>>> wonder if it really makes sense to deprecate the current ones in favor
>>>>of
>>>> Curator's, or if it is a better idea to keep multiple versions in the
>>>>case
>>>> of duplicates. People in the community have spent time on the current
>>>> recipes, so I don't like very much the idea of dropping the current
>>>>recipes
>>>> without some evidence that the community accepts it. Note that I'm not
>>>> saying that deprecating is not the right thing to do, I'm simply saying
>>>> that we need to make sure that the community agrees.
>>>>
>>>
>>>I agree that not deprecating is a good thing. We could mark them with
>>>annotations that indicate that we haven't heard yet from a community of
>>>users. If we don't hear about significant usage, then deprecation might
>>>be
>>>warranted.
>>>
>>>2- The set of committers needs to be more diverse. Perhaps it would be
>>>> easier to find more committers if you follow the incubation process,
>>>>given
>>>> that typically people sign up for committership once you post a
>>>>proposal
>>>> there. I wonder how many other people on this list would like to
>>>>volunteer
>>>> to become a committer of Curator, though. I like the project, but
>>>> unfortunately I don't have the cycles to do it.
>>>>
>>>
>>>I would volunteer.
>>>
>>>
>>>> 3- If Curator becomes a sub-project of ZooKeeper, then you need at
>>>>least
>>>> one mentor. Is there anyone who would like to sign up to mentor
>>>>Curator?
>>>>
>>>
>>>Likewise.
>>
>>
>
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Jordan Zimmerman <jz...@netflix.com>.
Any other comments on this? If not, what should the next steps be?
-JZ
On 12/15/11 10:07 AM, "Jordan Zimmerman" <jz...@netflix.com> wrote:
>I'd be happy to have Ted as both committer and mentor. I'd be happy to
>have Patrick and/or as mentor as well.
>
>-JZ
>
>On 12/14/11 7:03 PM, "Ted Dunning" <te...@gmail.com> wrote:
>
>>On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <fp...@yahoo-inc.com>
>>wrote:
>>
>>> Hi Jordan, Here is some feedback. I like the proposal and it makes
>>>sense
>>> to have such a project as either sub-project or incubator. I have a few
>>> concerns, though:
>>>
>>> 1- I haven't been following closely the development of the recipes, but
>>>I
>>> wonder if it really makes sense to deprecate the current ones in favor
>>>of
>>> Curator's, or if it is a better idea to keep multiple versions in the
>>>case
>>> of duplicates. People in the community have spent time on the current
>>> recipes, so I don't like very much the idea of dropping the current
>>>recipes
>>> without some evidence that the community accepts it. Note that I'm not
>>> saying that deprecating is not the right thing to do, I'm simply saying
>>> that we need to make sure that the community agrees.
>>>
>>
>>I agree that not deprecating is a good thing. We could mark them with
>>annotations that indicate that we haven't heard yet from a community of
>>users. If we don't hear about significant usage, then deprecation might
>>be
>>warranted.
>>
>>2- The set of committers needs to be more diverse. Perhaps it would be
>>> easier to find more committers if you follow the incubation process,
>>>given
>>> that typically people sign up for committership once you post a
>>>proposal
>>> there. I wonder how many other people on this list would like to
>>>volunteer
>>> to become a committer of Curator, though. I like the project, but
>>> unfortunately I don't have the cycles to do it.
>>>
>>
>>I would volunteer.
>>
>>
>>> 3- If Curator becomes a sub-project of ZooKeeper, then you need at
>>>least
>>> one mentor. Is there anyone who would like to sign up to mentor
>>>Curator?
>>>
>>
>>Likewise.
>
>
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Jordan Zimmerman <jz...@netflix.com>.
I'd be happy to have Ted as both committer and mentor. I'd be happy to
have Patrick and/or as mentor as well.
-JZ
On 12/14/11 7:03 PM, "Ted Dunning" <te...@gmail.com> wrote:
>On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <fp...@yahoo-inc.com>
>wrote:
>
>> Hi Jordan, Here is some feedback. I like the proposal and it makes sense
>> to have such a project as either sub-project or incubator. I have a few
>> concerns, though:
>>
>> 1- I haven't been following closely the development of the recipes, but
>>I
>> wonder if it really makes sense to deprecate the current ones in favor
>>of
>> Curator's, or if it is a better idea to keep multiple versions in the
>>case
>> of duplicates. People in the community have spent time on the current
>> recipes, so I don't like very much the idea of dropping the current
>>recipes
>> without some evidence that the community accepts it. Note that I'm not
>> saying that deprecating is not the right thing to do, I'm simply saying
>> that we need to make sure that the community agrees.
>>
>
>I agree that not deprecating is a good thing. We could mark them with
>annotations that indicate that we haven't heard yet from a community of
>users. If we don't hear about significant usage, then deprecation might
>be
>warranted.
>
>2- The set of committers needs to be more diverse. Perhaps it would be
>> easier to find more committers if you follow the incubation process,
>>given
>> that typically people sign up for committership once you post a proposal
>> there. I wonder how many other people on this list would like to
>>volunteer
>> to become a committer of Curator, though. I like the project, but
>> unfortunately I don't have the cycles to do it.
>>
>
>I would volunteer.
>
>
>> 3- If Curator becomes a sub-project of ZooKeeper, then you need at least
>> one mentor. Is there anyone who would like to sign up to mentor Curator?
>>
>
>Likewise.
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Ted Dunning <te...@gmail.com>.
On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <fp...@yahoo-inc.com> wrote:
> Hi Jordan, Here is some feedback. I like the proposal and it makes sense
> to have such a project as either sub-project or incubator. I have a few
> concerns, though:
>
> 1- I haven't been following closely the development of the recipes, but I
> wonder if it really makes sense to deprecate the current ones in favor of
> Curator's, or if it is a better idea to keep multiple versions in the case
> of duplicates. People in the community have spent time on the current
> recipes, so I don't like very much the idea of dropping the current recipes
> without some evidence that the community accepts it. Note that I'm not
> saying that deprecating is not the right thing to do, I'm simply saying
> that we need to make sure that the community agrees.
>
I agree that not deprecating is a good thing. We could mark them with
annotations that indicate that we haven't heard yet from a community of
users. If we don't hear about significant usage, then deprecation might be
warranted.
2- The set of committers needs to be more diverse. Perhaps it would be
> easier to find more committers if you follow the incubation process, given
> that typically people sign up for committership once you post a proposal
> there. I wonder how many other people on this list would like to volunteer
> to become a committer of Curator, though. I like the project, but
> unfortunately I don't have the cycles to do it.
>
I would volunteer.
> 3- If Curator becomes a sub-project of ZooKeeper, then you need at least
> one mentor. Is there anyone who would like to sign up to mentor Curator?
>
Likewise.
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Jordan Zimmerman <jz...@netflix.com>.
>I wonder if it really makes sense to deprecate the current ones in
>favor of Curator's, or if it is a better idea to keep multiple
>versions in the case of duplicates.
I thought that that would be confusing. My thinking is that most people
are going to get ZooKeeper because they need to do X (locking, leader,
etc.). They won't spend a lot of time learning the internals and will just
search for the recipe they need. If they see two they'd be uncertain.
On 12/14/11 4:35 PM, "Flavio Junqueira" <fp...@yahoo-inc.com> wrote:
>Hi Jordan, Here is some feedback. I like the proposal and it makes
>sense to have such a project as either sub-project or incubator. I
>have a few concerns, though:
>
>1- I haven't been following closely the development of the recipes,
>but I wonder if it really makes sense to deprecate the current ones in
>favor of Curator's, or if it is a better idea to keep multiple
>versions in the case of duplicates. People in the community have spent
>time on the current recipes, so I don't like very much the idea of
>dropping the current recipes without some evidence that the community
>accepts it. Note that I'm not saying that deprecating is not the right
>thing to do, I'm simply saying that we need to make sure that the
>community agrees.
>
>2- The set of committers needs to be more diverse. Perhaps it would be
>easier to find more committers if you follow the incubation process,
>given that typically people sign up for committership once you post a
>proposal there. I wonder how many other people on this list would like
>to volunteer to become a committer of Curator, though. I like the
>project, but unfortunately I don't have the cycles to do it.
>
>3- If Curator becomes a sub-project of ZooKeeper, then you need at
>least one mentor. Is there anyone who would like to sign up to mentor
>Curator?
>
>-Flavio
>
>On Dec 13, 2011, at 5:46 PM, Jordan Zimmerman wrote:
>
>> While we're not interested in submitting Curator to the Incubator,
>> I've
>> prepared a proposal for including Curator as a ZooKeeper sub-project
>> or
>> inclusion in the main project. Here's the proposal (for commenting,
>> etc.):
>>
>>
>> Curator, a ZooKeeper Recipe Proposal
>> ====================================
>>
>> == Abstract ==
>> Users of Apache ZooKeeper would greatly benefit from having a high
>> quality
>> implementation of common recipes included with the ZooKeeper
>> distribution.
>> Curator is that implementation.
>>
>> == Proposal ==
>> Apache ZooKeeper should produce a new artifact for recipes/
>> applications.
>> This artifact should either be a ZooKeeper sub-project or top-level
>> part
>> of ZooKeeper itself. For Java (and possibly other JVM based
>> languages),
>> the Netflix Curator project should be the artifact.
>>
>> The recipe implementations currently included with the ZooKeeper
>> distribution should be deprecated in favor of Curator.
>>
>> == Background ==
>> ZooKeeper consists of server software and client software. The client
>> implementations that are part of the ZooKeeper distribution are very
>> low
>> level and difficult to use correctly. Further, implementing the
>> recipes
>> listed in the ZooKeeper documentation is non-trivial and involves deep
>> knowledge of ZooKeeper best practices and edge cases.
>>
>> == Rationale ==
>> The existing clients for ZooKeeper are difficult to use and are
>> limited.
>> Further, correct usage of ZooKeeper is non-trivial and non-obvious.
>> Users
>> of ZooKeeper are mostly interested in the recipes/applications and
>> are not
>> likely interested in becoming experts in the minutiae of correct
>> ZooKeeper
>> client usage. What they want is a simple way to use the recipes.
>> Curator
>> is directed at this goal.
>>
>> == Current Status ==
>> Curator is an active open source project hosted at Github
>> (https://github.com/netflix/curator). It has no dependencies other
>> than
>> industry standard libraries. It provides implementations for all
>> recipes
>> listed on the ZooKeeper recipes doc as well as a high level
>> framework for
>> using ZooKeeper that simplifies most of the low level housekeeping
>> normally required.
>>
>> Curator has been open since October, 2011 and has been reviewed by
>> several
>> active members of the ZooKeeper community.
>>
>> Netflix is a strong proponent of open source and is supportive of
>> providing the community with this project.
>>
>> == Core Developers ==
>> The initial set of committers are all employees of Netflix, Inc. The
>> lead
>> developer is Jordan Zimmerman (jzimmerman@netflix.com), Senior
>> Platform
>> Engineer at Netflix, Inc.
>>
>> == Alignment ==
>> The current ZooKeeper distribution has an obvious hole in regard to
>> recipes/applications. Curator's minimal dependencies and use of
>> standard
>> ZooKeeper components and recipe algorithms make it a natural
>> compliment to
>> the ZooKeeper distribution.
>>
>> == Known Risks ==
>> Orphan-ing of Curator:
>> ZooKeeper has become a major component at Netflix. Curator is the
>> abstraction being used.
>>
>> Open Source Experience:
>> Netflix has major experience with open source. All the committers of
>> Curator have long experience with open source.
>>
>> Homogenous/Salaried Developers:
>> The current committers are all salaried employees of Netflix. This
>> proposal would help by having a more diverse set of committers.
>>
>> Ties to Apache products:
>> The initial codebase relies heavily on existing Apache technologies
>> and
>> will continue to do so.
>>
>> == Documentation ==
>> Comprehensive documentation is at
>>https://github.com/Netflix/curator/wiki
>>
>> == Initial Source ==
>> The source code currently is hosted at Github at:
>> https://github.com/Netflix/curator
>>
>> == External Dependencies ==
>> Runtime:
>> * Apache ZooKeeper
>> * Google Guava
>>
>> Testing:
>> * Test NG
>> * Apache Commons Math
>> * Mockito
>> * Javaassist
>>
>> Building:
>> * Apache Maven
>>
>> == Initial Committers ==
>> Jordan Zimmerman (Netflix, Inc.)
>> Jay Zarfoss (Netflix, Inc.)
>> Jerome Boulon (Netflix, Inc.)
>>
>
>It would be good to have more diversity here. I would love to
>contribute, but I don't feel I have cycles for now.
>
>-Flavio
>
>flavio
>junqueira
>
>research scientist
>
>fpj@yahoo-inc.com
>direct +34 93-183-8828
>
>avinguda diagonal 177, 8th floor, barcelona, 08018, es
>phone (408) 349 3300 fax (408) 349 3301
>
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Flavio Junqueira <fp...@yahoo-inc.com>.
Hi Jordan, Here is some feedback. I like the proposal and it makes
sense to have such a project as either sub-project or incubator. I
have a few concerns, though:
1- I haven't been following closely the development of the recipes,
but I wonder if it really makes sense to deprecate the current ones in
favor of Curator's, or if it is a better idea to keep multiple
versions in the case of duplicates. People in the community have spent
time on the current recipes, so I don't like very much the idea of
dropping the current recipes without some evidence that the community
accepts it. Note that I'm not saying that deprecating is not the right
thing to do, I'm simply saying that we need to make sure that the
community agrees.
2- The set of committers needs to be more diverse. Perhaps it would be
easier to find more committers if you follow the incubation process,
given that typically people sign up for committership once you post a
proposal there. I wonder how many other people on this list would like
to volunteer to become a committer of Curator, though. I like the
project, but unfortunately I don't have the cycles to do it.
3- If Curator becomes a sub-project of ZooKeeper, then you need at
least one mentor. Is there anyone who would like to sign up to mentor
Curator?
-Flavio
On Dec 13, 2011, at 5:46 PM, Jordan Zimmerman wrote:
> While we're not interested in submitting Curator to the Incubator,
> I've
> prepared a proposal for including Curator as a ZooKeeper sub-project
> or
> inclusion in the main project. Here's the proposal (for commenting,
> etc.):
>
>
> Curator, a ZooKeeper Recipe Proposal
> ====================================
>
> == Abstract ==
> Users of Apache ZooKeeper would greatly benefit from having a high
> quality
> implementation of common recipes included with the ZooKeeper
> distribution.
> Curator is that implementation.
>
> == Proposal ==
> Apache ZooKeeper should produce a new artifact for recipes/
> applications.
> This artifact should either be a ZooKeeper sub-project or top-level
> part
> of ZooKeeper itself. For Java (and possibly other JVM based
> languages),
> the Netflix Curator project should be the artifact.
>
> The recipe implementations currently included with the ZooKeeper
> distribution should be deprecated in favor of Curator.
>
> == Background ==
> ZooKeeper consists of server software and client software. The client
> implementations that are part of the ZooKeeper distribution are very
> low
> level and difficult to use correctly. Further, implementing the
> recipes
> listed in the ZooKeeper documentation is non-trivial and involves deep
> knowledge of ZooKeeper best practices and edge cases.
>
> == Rationale ==
> The existing clients for ZooKeeper are difficult to use and are
> limited.
> Further, correct usage of ZooKeeper is non-trivial and non-obvious.
> Users
> of ZooKeeper are mostly interested in the recipes/applications and
> are not
> likely interested in becoming experts in the minutiae of correct
> ZooKeeper
> client usage. What they want is a simple way to use the recipes.
> Curator
> is directed at this goal.
>
> == Current Status ==
> Curator is an active open source project hosted at Github
> (https://github.com/netflix/curator). It has no dependencies other
> than
> industry standard libraries. It provides implementations for all
> recipes
> listed on the ZooKeeper recipes doc as well as a high level
> framework for
> using ZooKeeper that simplifies most of the low level housekeeping
> normally required.
>
> Curator has been open since October, 2011 and has been reviewed by
> several
> active members of the ZooKeeper community.
>
> Netflix is a strong proponent of open source and is supportive of
> providing the community with this project.
>
> == Core Developers ==
> The initial set of committers are all employees of Netflix, Inc. The
> lead
> developer is Jordan Zimmerman (jzimmerman@netflix.com), Senior
> Platform
> Engineer at Netflix, Inc.
>
> == Alignment ==
> The current ZooKeeper distribution has an obvious hole in regard to
> recipes/applications. Curator's minimal dependencies and use of
> standard
> ZooKeeper components and recipe algorithms make it a natural
> compliment to
> the ZooKeeper distribution.
>
> == Known Risks ==
> Orphan-ing of Curator:
> ZooKeeper has become a major component at Netflix. Curator is the
> abstraction being used.
>
> Open Source Experience:
> Netflix has major experience with open source. All the committers of
> Curator have long experience with open source.
>
> Homogenous/Salaried Developers:
> The current committers are all salaried employees of Netflix. This
> proposal would help by having a more diverse set of committers.
>
> Ties to Apache products:
> The initial codebase relies heavily on existing Apache technologies
> and
> will continue to do so.
>
> == Documentation ==
> Comprehensive documentation is at https://github.com/Netflix/curator/wiki
>
> == Initial Source ==
> The source code currently is hosted at Github at:
> https://github.com/Netflix/curator
>
> == External Dependencies ==
> Runtime:
> * Apache ZooKeeper
> * Google Guava
>
> Testing:
> * Test NG
> * Apache Commons Math
> * Mockito
> * Javaassist
>
> Building:
> * Apache Maven
>
> == Initial Committers ==
> Jordan Zimmerman (Netflix, Inc.)
> Jay Zarfoss (Netflix, Inc.)
> Jerome Boulon (Netflix, Inc.)
>
It would be good to have more diversity here. I would love to
contribute, but I don't feel I have cycles for now.
-Flavio
flavio
junqueira
research scientist
fpj@yahoo-inc.com
direct +34 93-183-8828
avinguda diagonal 177, 8th floor, barcelona, 08018, es
phone (408) 349 3300 fax (408) 349 3301
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Jordan Zimmerman <jz...@netflix.com>.
>what does it mean to deprecate the old recipes? Carry them fwd as
>deprecated in Curator but not drop them?
I haven't thought too much about project organization. But, that is a
possibility.
>lang bindings - would Curator accept all comers (c, python, perl,
>etc...). If not it doesn't seem like a great replacement for current
>recipes.
Absolutely. I'd love to see it.
On 12/14/11 4:54 PM, "Patrick Hunt" <ph...@apache.org> wrote:
>This proposal looks good to me in general. I'm in favor of having
>improved recipes available for users, Curator seems to fit the bill.
>However as I stated previously while I'd be +1 for this to go to the
>incubator (with ZK PMC as sponsor), I'm -0 for this as a sub/artifact.
>(this is the same as my vote for BK btw)
>
>I have similar comments to Flavio:
>
>* what does it mean to deprecate the old recipes? Carry them fwd as
>deprecated in Curator but not drop them?
>
>* lang bindings - would Curator accept all comers (c, python, perl,
>etc...). If not it doesn't seem like a great replacement for current
>recipes.
>
>* re diversity I think it's fine, that's what incubation is for - to
>build diversity.
>
>Patrick
>
>On Tue, Dec 13, 2011 at 8:46 AM, Jordan Zimmerman
><jz...@netflix.com> wrote:
>> While we're not interested in submitting Curator to the Incubator, I've
>> prepared a proposal for including Curator as a ZooKeeper sub-project or
>> inclusion in the main project. Here's the proposal (for commenting,
>>etc.):
>>
>>
>> Curator, a ZooKeeper Recipe Proposal
>> ====================================
>>
>> == Abstract ==
>> Users of Apache ZooKeeper would greatly benefit from having a high
>>quality
>> implementation of common recipes included with the ZooKeeper
>>distribution.
>> Curator is that implementation.
>>
>> == Proposal ==
>> Apache ZooKeeper should produce a new artifact for recipes/applications.
>> This artifact should either be a ZooKeeper sub-project or top-level part
>> of ZooKeeper itself. For Java (and possibly other JVM based languages),
>> the Netflix Curator project should be the artifact.
>>
>> The recipe implementations currently included with the ZooKeeper
>> distribution should be deprecated in favor of Curator.
>>
>> == Background ==
>> ZooKeeper consists of server software and client software. The client
>> implementations that are part of the ZooKeeper distribution are very low
>> level and difficult to use correctly. Further, implementing the recipes
>> listed in the ZooKeeper documentation is non-trivial and involves deep
>> knowledge of ZooKeeper best practices and edge cases.
>>
>> == Rationale ==
>> The existing clients for ZooKeeper are difficult to use and are limited.
>> Further, correct usage of ZooKeeper is non-trivial and non-obvious.
>>Users
>> of ZooKeeper are mostly interested in the recipes/applications and are
>>not
>> likely interested in becoming experts in the minutiae of correct
>>ZooKeeper
>> client usage. What they want is a simple way to use the recipes. Curator
>> is directed at this goal.
>>
>> == Current Status ==
>> Curator is an active open source project hosted at Github
>> (https://github.com/netflix/curator). It has no dependencies other than
>> industry standard libraries. It provides implementations for all recipes
>> listed on the ZooKeeper recipes doc as well as a high level framework
>>for
>> using ZooKeeper that simplifies most of the low level housekeeping
>> normally required.
>>
>> Curator has been open since October, 2011 and has been reviewed by
>>several
>> active members of the ZooKeeper community.
>>
>> Netflix is a strong proponent of open source and is supportive of
>> providing the community with this project.
>>
>> == Core Developers ==
>> The initial set of committers are all employees of Netflix, Inc. The
>>lead
>> developer is Jordan Zimmerman (jzimmerman@netflix.com), Senior Platform
>> Engineer at Netflix, Inc.
>>
>> == Alignment ==
>> The current ZooKeeper distribution has an obvious hole in regard to
>> recipes/applications. Curator's minimal dependencies and use of standard
>> ZooKeeper components and recipe algorithms make it a natural compliment
>>to
>> the ZooKeeper distribution.
>>
>> == Known Risks ==
>> Orphan-ing of Curator:
>> ZooKeeper has become a major component at Netflix. Curator is the
>> abstraction being used.
>>
>> Open Source Experience:
>> Netflix has major experience with open source. All the committers of
>> Curator have long experience with open source.
>>
>> Homogenous/Salaried Developers:
>> The current committers are all salaried employees of Netflix. This
>> proposal would help by having a more diverse set of committers.
>>
>> Ties to Apache products:
>> The initial codebase relies heavily on existing Apache technologies and
>> will continue to do so.
>>
>> == Documentation ==
>> Comprehensive documentation is at
>>https://github.com/Netflix/curator/wiki
>>
>> == Initial Source ==
>> The source code currently is hosted at Github at:
>> https://github.com/Netflix/curator
>>
>> == External Dependencies ==
>> Runtime:
>> * Apache ZooKeeper
>> * Google Guava
>>
>> Testing:
>> * Test NG
>> * Apache Commons Math
>> * Mockito
>> * Javaassist
>>
>> Building:
>> * Apache Maven
>>
>> == Initial Committers ==
>> Jordan Zimmerman (Netflix, Inc.)
>> Jay Zarfoss (Netflix, Inc.)
>> Jerome Boulon (Netflix, Inc.)
>>
>>
>
Re: Curator, a ZooKeeper Recipe Proposal
Posted by Patrick Hunt <ph...@apache.org>.
This proposal looks good to me in general. I'm in favor of having
improved recipes available for users, Curator seems to fit the bill.
However as I stated previously while I'd be +1 for this to go to the
incubator (with ZK PMC as sponsor), I'm -0 for this as a sub/artifact.
(this is the same as my vote for BK btw)
I have similar comments to Flavio:
* what does it mean to deprecate the old recipes? Carry them fwd as
deprecated in Curator but not drop them?
* lang bindings - would Curator accept all comers (c, python, perl,
etc...). If not it doesn't seem like a great replacement for current
recipes.
* re diversity I think it's fine, that's what incubation is for - to
build diversity.
Patrick
On Tue, Dec 13, 2011 at 8:46 AM, Jordan Zimmerman
<jz...@netflix.com> wrote:
> While we're not interested in submitting Curator to the Incubator, I've
> prepared a proposal for including Curator as a ZooKeeper sub-project or
> inclusion in the main project. Here's the proposal (for commenting, etc.):
>
>
> Curator, a ZooKeeper Recipe Proposal
> ====================================
>
> == Abstract ==
> Users of Apache ZooKeeper would greatly benefit from having a high quality
> implementation of common recipes included with the ZooKeeper distribution.
> Curator is that implementation.
>
> == Proposal ==
> Apache ZooKeeper should produce a new artifact for recipes/applications.
> This artifact should either be a ZooKeeper sub-project or top-level part
> of ZooKeeper itself. For Java (and possibly other JVM based languages),
> the Netflix Curator project should be the artifact.
>
> The recipe implementations currently included with the ZooKeeper
> distribution should be deprecated in favor of Curator.
>
> == Background ==
> ZooKeeper consists of server software and client software. The client
> implementations that are part of the ZooKeeper distribution are very low
> level and difficult to use correctly. Further, implementing the recipes
> listed in the ZooKeeper documentation is non-trivial and involves deep
> knowledge of ZooKeeper best practices and edge cases.
>
> == Rationale ==
> The existing clients for ZooKeeper are difficult to use and are limited.
> Further, correct usage of ZooKeeper is non-trivial and non-obvious. Users
> of ZooKeeper are mostly interested in the recipes/applications and are not
> likely interested in becoming experts in the minutiae of correct ZooKeeper
> client usage. What they want is a simple way to use the recipes. Curator
> is directed at this goal.
>
> == Current Status ==
> Curator is an active open source project hosted at Github
> (https://github.com/netflix/curator). It has no dependencies other than
> industry standard libraries. It provides implementations for all recipes
> listed on the ZooKeeper recipes doc as well as a high level framework for
> using ZooKeeper that simplifies most of the low level housekeeping
> normally required.
>
> Curator has been open since October, 2011 and has been reviewed by several
> active members of the ZooKeeper community.
>
> Netflix is a strong proponent of open source and is supportive of
> providing the community with this project.
>
> == Core Developers ==
> The initial set of committers are all employees of Netflix, Inc. The lead
> developer is Jordan Zimmerman (jzimmerman@netflix.com), Senior Platform
> Engineer at Netflix, Inc.
>
> == Alignment ==
> The current ZooKeeper distribution has an obvious hole in regard to
> recipes/applications. Curator's minimal dependencies and use of standard
> ZooKeeper components and recipe algorithms make it a natural compliment to
> the ZooKeeper distribution.
>
> == Known Risks ==
> Orphan-ing of Curator:
> ZooKeeper has become a major component at Netflix. Curator is the
> abstraction being used.
>
> Open Source Experience:
> Netflix has major experience with open source. All the committers of
> Curator have long experience with open source.
>
> Homogenous/Salaried Developers:
> The current committers are all salaried employees of Netflix. This
> proposal would help by having a more diverse set of committers.
>
> Ties to Apache products:
> The initial codebase relies heavily on existing Apache technologies and
> will continue to do so.
>
> == Documentation ==
> Comprehensive documentation is at https://github.com/Netflix/curator/wiki
>
> == Initial Source ==
> The source code currently is hosted at Github at:
> https://github.com/Netflix/curator
>
> == External Dependencies ==
> Runtime:
> * Apache ZooKeeper
> * Google Guava
>
> Testing:
> * Test NG
> * Apache Commons Math
> * Mockito
> * Javaassist
>
> Building:
> * Apache Maven
>
> == Initial Committers ==
> Jordan Zimmerman (Netflix, Inc.)
> Jay Zarfoss (Netflix, Inc.)
> Jerome Boulon (Netflix, Inc.)
>
>