Re: [RESULT][VOTE] Accept Traffic Control into the Apache Incubator

2016-07-20 Thread Leif Hedstrom 

> On Jul 20, 2016, at 4:43 PM, John D. Ament  wrote:
> 
> On Jul 20, 2016 18:15, "Leif Hedstrom"  > wrote:
>> 
>> 
>>> On Jul 20, 2016, at 4:10 PM, John D. Ament 
> wrote:
>>> 
>>> On Wed, Jul 20, 2016 at 6:09 PM Leif Hedstrom  wrote:
>>> 
 
> On Jul 12, 2016, at 3:08 PM, Jan van Doorn  wrote:
> 
> The results are in and voting is now closed. The votes:
> 
> [7] +1 Accept Traffic Control into the Apache Incubator
 
 
 
 Great!
 
 Incubator PMC: As the sponsor of this Podling, we would like to request
 that you officially call this vote, and accept the Traffic Control
> project
 for Incubation with the ASF. The proposed list of mentors are:
 
>>> 
>>> Can you explain what you mean by this statement?  Maybe take a look at
>>> podling bootstrap from http://incubator.apache.org/guides/mentor.html
>> 
>> 
>> 
>> According to
> http://incubator.apache.org/incubation/Process_Description.html, the
> Sponsor (which in this case the IPMC) must accept the new podling first,
> before mentors do their work. If that’s not the case, then great, we’ll
> move along and start getting the resource requests etc. going :).
> 
> I believe that is represented as the IPMC vote.

Roger. I’ve asked the mentors to proceed with their tasks, and we’ll also make 
sure all the initial committers either have signed the ICLA, or are prepared to 
do so.

Thanks again!

— leif

Re: [RESULT][VOTE] Accept Traffic Control into the Apache Incubator

2016-07-20 Thread John D. Ament 
On Jul 20, 2016 18:15, "Leif Hedstrom"  wrote:
>
>
> > On Jul 20, 2016, at 4:10 PM, John D. Ament 
wrote:
> >
> > On Wed, Jul 20, 2016 at 6:09 PM Leif Hedstrom  wrote:
> >
> >>
> >>> On Jul 12, 2016, at 3:08 PM, Jan van Doorn  wrote:
> >>>
> >>> The results are in and voting is now closed. The votes:
> >>>
> >>> [7] +1 Accept Traffic Control into the Apache Incubator
> >>
> >>
> >>
> >> Great!
> >>
> >> Incubator PMC: As the sponsor of this Podling, we would like to request
> >> that you officially call this vote, and accept the Traffic Control
project
> >> for Incubation with the ASF. The proposed list of mentors are:
> >>
> >
> > Can you explain what you mean by this statement?  Maybe take a look at
> > podling bootstrap from http://incubator.apache.org/guides/mentor.html
>
>
>
> According to
http://incubator.apache.org/incubation/Process_Description.html, the
Sponsor (which in this case the IPMC) must accept the new podling first,
before mentors do their work. If that’s not the case, then great, we’ll
move along and start getting the resource requests etc. going :).

I believe that is represented as the IPMC vote.

>
> Cheers,
>
> — leif
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: [RESULT][VOTE] Accept Traffic Control into the Apache Incubator

2016-07-20 Thread Leif Hedstrom 

> On Jul 20, 2016, at 4:10 PM, John D. Ament  wrote:
> 
> On Wed, Jul 20, 2016 at 6:09 PM Leif Hedstrom  wrote:
> 
>> 
>>> On Jul 12, 2016, at 3:08 PM, Jan van Doorn  wrote:
>>> 
>>> The results are in and voting is now closed. The votes:
>>> 
>>> [7] +1 Accept Traffic Control into the Apache Incubator
>> 
>> 
>> 
>> Great!
>> 
>> Incubator PMC: As the sponsor of this Podling, we would like to request
>> that you officially call this vote, and accept the Traffic Control project
>> for Incubation with the ASF. The proposed list of mentors are:
>> 
> 
> Can you explain what you mean by this statement?  Maybe take a look at
> podling bootstrap from http://incubator.apache.org/guides/mentor.html



According to http://incubator.apache.org/incubation/Process_Description.html, 
the Sponsor (which in this case the IPMC) must accept the new podling first, 
before mentors do their work. If that’s not the case, then great, we’ll move 
along and start getting the resource requests etc. going :).

Cheers,

— leif


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [RESULT][VOTE] Accept Traffic Control into the Apache Incubator

2016-07-20 Thread John D. Ament 
On Wed, Jul 20, 2016 at 6:09 PM Leif Hedstrom  wrote:

>
> > On Jul 12, 2016, at 3:08 PM, Jan van Doorn  wrote:
> >
> > The results are in and voting is now closed. The votes:
> >
> > [7] +1 Accept Traffic Control into the Apache Incubator
>
>
>
> Great!
>
> Incubator PMC: As the sponsor of this Podling, we would like to request
> that you officially call this vote, and accept the Traffic Control project
> for Incubation with the ASF. The proposed list of mentors are:
>

Can you explain what you mean by this statement?  Maybe take a look at
podling bootstrap from http://incubator.apache.org/guides/mentor.html

John


>
>   * Phil Sorber (sorber at apache.org )
>   * Eric Covener (covener at apache.org )
>   * Daniel Gruno (humbedooh at apache.org )
>   * J. Aaron Farr (farra at apache.org )
>
>
> Sincerely,
>
> — leif
>
>

Re: [RESULT][VOTE] Accept Traffic Control into the Apache Incubator

2016-07-20 Thread Leif Hedstrom 

> On Jul 12, 2016, at 3:08 PM, Jan van Doorn  wrote:
> 
> The results are in and voting is now closed. The votes:
> 
> [7] +1 Accept Traffic Control into the Apache Incubator



Great!

Incubator PMC: As the sponsor of this Podling, we would like to request that 
you officially call this vote, and accept the Traffic Control project for 
Incubation with the ASF. The proposed list of mentors are:

  * Phil Sorber (sorber at apache.org )
  * Eric Covener (covener at apache.org )
  * Daniel Gruno (humbedooh at apache.org )
  * J. Aaron Farr (farra at apache.org )


Sincerely,

— leif

[RESULT][VOTE] Accept Traffic Control into the Apache Incubator

2016-07-12 Thread Jan van Doorn 
The results are in and voting is now closed. The votes:

[7] +1 Accept Traffic Control into the Apache Incubator

  Phil Sorber (binding)
  Leif Hedstrom (binding)
  Josh Elser (binding)
  Pierre Smits (non-binding)
  Jacky Li (non-binding)
  Nick Kew (binding)
  Daniel Gruno (binding)

[0] +/-0 Not overly bothered either way

[0] -1 DO NOT accept Traffic Control into the Apache Incubator

Thanks to everyone who voted and reviewed our proposal.

Traffic Control has been accepted into the Incubator!

The [VOTE] thread can be found here:
https://lists.apache.org/thread.html/b9c118f59a825024ca20f8b0b4500b4456c154b34295d94de058e834@%3Cgeneral.incubator.apache.org%3E
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Traffic Control into the Apache Incubator

2016-07-11 Thread Daniel Gruno 
+1 (binding) also.

With regards,
Daniel.

On 07/09/2016 10:08 AM, Nick Kew wrote:
> On Fri, 2016-07-08 at 18:16 -0600, Jan van Doorn wrote:
> 
>> I don't think the association with ATS would hold us back, but I do think it 
>> could give prospective users of Traffic Control the impression that it only 
>> works with ATS. This is true now, but won't be in the future.
> 
> I'm not sure a bit of internal organisation will make much difference
> once you start listing TC+TS and TC+Other as equally valid options.
> But I don't want to make an issue of it.
> 
>> Only one or two people actively work on both projects, the development 
>> communities are mostly separate.
> 
> OK, thanks.
> 
>> I'm not familiar with the HTTPD and APR history, is there a lesson we should 
>> learn from that?
> 
> The main issue we've found is that with a close relationship and with
> a large overlap between the dev teams, we've often found a development
> in HTTPD driving one in APR, even to the point of "we need a new APR
> release that'll support [new HTTPD feature]".  At the same time, the
> original reason for the separation - that APR has applications outside
> httpd (Apache SVN being one such) - works well.
> 
> On reflection, you probably have a cleaner separation than that anyway.
> 
> +1 (binding) to your vote.
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Traffic Control into the Apache Incubator

2016-07-09 Thread Nick Kew 
On Fri, 2016-07-08 at 18:16 -0600, Jan van Doorn wrote:

> I don't think the association with ATS would hold us back, but I do think it 
> could give prospective users of Traffic Control the impression that it only 
> works with ATS. This is true now, but won't be in the future.

I'm not sure a bit of internal organisation will make much difference
once you start listing TC+TS and TC+Other as equally valid options.
But I don't want to make an issue of it.

> Only one or two people actively work on both projects, the development 
> communities are mostly separate.

OK, thanks.

> I'm not familiar with the HTTPD and APR history, is there a lesson we should 
> learn from that?

The main issue we've found is that with a close relationship and with
a large overlap between the dev teams, we've often found a development
in HTTPD driving one in APR, even to the point of "we need a new APR
release that'll support [new HTTPD feature]".  At the same time, the
original reason for the separation - that APR has applications outside
httpd (Apache SVN being one such) - works well.

On reflection, you probably have a cleaner separation than that anyway.

+1 (binding) to your vote.

-- 
Nick Kew


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Traffic Control into the Apache Incubator

2016-07-08 Thread Jan van Doorn 

> On Jul 8, 2016, at 12:27, Nick Kew  wrote:
> 
> Just wondering if you could elaborate on one point:
> 
> "We don't want to become a sub-project of ATS though, because we
> believe we should add other caching proxies as they are deemed to be a
> valuable addition to the Traffic Control CDN. "
> 
> To me that raises a couple of questions:
> - Would association with ATS really hold you back?
> - How much overlap is there between the dev communities?
> I'm wondering if the experience of separating HTTPD and APR
> might just be relevant to this issue.
> 

I don't think the association with ATS would hold us back, but I do think it 
could give prospective users of Traffic Control the impression that it only 
works with ATS. This is true now, but won't be in the future.

Only one or two people actively work on both projects, the development 
communities are mostly separate.

I'm not familiar with the HTTPD and APR history, is there a lesson we should 
learn from that?

Thanks,
JvD

(apologies if you get this twice, I sent this out earlier, but never saw it 
make the list)


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Traffic Control into the Apache Incubator

2016-07-08 Thread Nick Kew 
On Fri, 8 Jul 2016 09:05:29 -0600
Leif Hedstrom  wrote:

> > The proposal follows, you can also access the wiki page:
> > https://wiki.apache.org/incubator/TrafficControlProposal
> 
> 
> 
> Any more thoughts on this [VOTE] and proposal? Any concerns? Seems
> like we could use a couple of more binding votes.

OK, I've taken a look: looks good to me.

Just wondering if you could elaborate on one point:

"We don't want to become a sub-project of ATS though, because we
believe we should add other caching proxies as they are deemed to be a
valuable addition to the Traffic Control CDN. "

To me that raises a couple of questions:
 - Would association with ATS really hold you back?
 - How much overlap is there between the dev communities?
I'm wondering if the experience of separating HTTPD and APR
might just be relevant to this issue.

-- 
Nick Kew

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Traffic Control into the Apache Incubator

2016-07-08 Thread Leif Hedstrom 

> On Jul 1, 2016, at 8:00 AM, Jan van Doorn  wrote:
> 
> Following the discussion thread, I would like to call a VOTE on accepting 
> Traffic Control into the Apache Incubator.
> 
> [] +1 Accept Traffic Control into the Apache Incubator
> [] +0 Abstain.
> [] -1 Do not accept Traffic Control into the Apache Incubator because ...
> 
> This vote will be open for at least 1 week (extra long to accommodate holiday 
> schedules).
> 
> The proposal follows, you can also access the wiki page: 
> https://wiki.apache.org/incubator/TrafficControlProposal



Any more thoughts on this [VOTE] and proposal? Any concerns? Seems like we 
could use a couple of more binding votes.

Cheers,

— leif


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Traffic Control into the Apache Incubator

2016-07-06 Thread Jacky Li 
+1 (non-binding)

Good luck!

Regards,
Jacky

> 在 2016年7月6日，下午4:11，Pierre Smits  写道：
> 
> +1 (non-binding)
> 
> Best regards,
> 
> Pierre Smits
> 
> ORRTIZ.COM 
> OFBiz based solutions & services
> 
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
> 
> On Tue, Jul 5, 2016 at 3:08 PM, Josh Elser  wrote:
> 
>> +1 (binding)
>> 
>> Good luck!
>> 
>> 
>> Jan van Doorn wrote:
>> 
>>> Following the discussion thread, I would like to call a VOTE on accepting
>>> Traffic Control into the Apache Incubator.
>>> 
>>> [] +1 Accept Traffic Control into the Apache Incubator
>>> [] +0 Abstain.
>>> [] -1 Do not accept Traffic Control into the Apache Incubator because ...
>>> 
>>> This vote will be open for at least 1 week (extra long to accommodate
>>> holiday schedules).
>>> 
>>> The proposal follows, you can also access the wiki page:
>>> https://wiki.apache.org/incubator/TrafficControlProposal
>>> 
>>> Thanks,
>>> JvD
>>> 
>>> 
>>> = Traffic Control Proposal =
>>> 
>>> == Abstract ==
>>> 
>>> Traffic Control allows you to build a large scale content delivery
>>> network using
>>> open source.
>>> 
>>> == Proposal ==
>>> 
>>> The goal of this proposal is to bring the Traffic Control project into the
>>> Apache Software Foundation.
>>> 
>>> == Background ==
>>> 
>>> Initially built around Apache Traffic Server as the caching software,
>>> Traffic
>>> Control implements all functions of a modern CDN except the caching
>>> software:
>>> 
>>>  * Traffic Router is a Java Tomcat application that routes clients to
>>> the closest
>>>  available cache on the CDN using both HTTP and DNS. By using consistent
>>> hashing
>>>  it sends requests for the same content to the same cache in a group of
>>> caches
>>>  working together in a location. It takes care of routing clients around
>>> hot
>>>  spots and problems in the CDN by using the information from Traffic
>>> Monitor with
>>>  regards to state of all the caches.
>>> 
>>>  * Traffic Monitor is a Java Tomcat application that implements the CDN
>>> health
>>>  protocol. Every cache in the CDN is checked using HTTP for vital stats,
>>> and
>>>  based on these stats, caches are declared healthy or unhealthy. This
>>> information
>>>  is then used by Traffic Router to make its routing decisions.
>>> 
>>>  * Traffic Ops is a Perl Mojolicious and jQuery UI application for
>>> management and
>>>  monitoring of all servers in the CDN. All server and content routing
>>> information
>>>  for the CDN is managed through Traffic Ops. It also exposes RESTful API
>>>  endpoints for consumption by tools and other applications.
>>> 
>>>  * Traffic Stats is a Go application that is used to acquire and store
>>> statistics
>>>  about CDNs controlled by Traffic Control. Traffic Stats mines metrics
>>> from
>>>  Traffic Monitor’s JSON APIs and stores the data in InfluxDB, and
>>> visualizes them
>>>  using Grafana.
>>> 
>>>  * Traffic Analytics is a new component we are starting to build for log
>>> file
>>>  analysis, based on Apache Kafka, Heka, and Elastic Search.
>>> 
>>> 
>>> Traffic Control was developed by Comcast Cable and released as open
>>> source under
>>> the Apache 2.0 license in April of 2015. Traffic Control is deployed at
>>> Comcast
>>> and other cable operators.
>>> 
>>> The Traffic Control project was presented at ApacheCon NA 2016, see
>>> http://bit.ly/1UwMzmR for additional background information.
>>> 
>>> == Rationale ==
>>> 
>>> Even though the traffic on today's CDNs is strictly defined by open
>>> standards,
>>> and there are many open source implementations of caches available, CDNs
>>> are
>>> still proprietary. The current providers of CDN-as-a-product or
>>> CDN-as-a-service all have their own proprietary implementation of the
>>> control
>>> plane.  The CDN control plane of one vendor can't interoperate with the
>>> CDN
>>> control plane of another, creating a classic vendor-lockin for
>>> CDN-as-a-product
>>> customers. Traffic Control changes that. Emerging standards from IETF
>>> (CDNi
>>> working group) and the Streaming Video Alliance Open Caching working
>>> group need
>>> an open source reference implementation; Traffic Control will strive to be
>>> that.
>>> 
>>> == Initial Goals ==
>>> 
>>> Initial goals of transitioning to ASF is to grow and diversify the
>>> community,
>>> and to move to a more open and inclusive development model.
>>> 
>>> == Current Status ==
>>> 
>>> Traffic Control is functional and deployed at Comcast and other cable
>>> operators.
>>> In the past 12 months 10 major releases have been made.
>>> 
>>> === Meritocracy ===
>>> 
>>> Initial development was done at Comcast Cable. Since April 2015  it has
>>> been
>>> open source, and a handful outside contributors have been added.
>>> 
>>> Our main goal during incubation is to try to create a more diverse group
>>> of
>>> contributors and users.
>>> 
>>> === Community ===
>>> 
>>> Traffic Control is being used

Re: [VOTE] Accept Traffic Control into the Apache Incubator

2016-07-06 Thread Pierre Smits 
+1 (non-binding)

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 5, 2016 at 3:08 PM, Josh Elser  wrote:

> +1 (binding)
>
> Good luck!
>
>
> Jan van Doorn wrote:
>
>> Following the discussion thread, I would like to call a VOTE on accepting
>> Traffic Control into the Apache Incubator.
>>
>> [] +1 Accept Traffic Control into the Apache Incubator
>> [] +0 Abstain.
>> [] -1 Do not accept Traffic Control into the Apache Incubator because ...
>>
>> This vote will be open for at least 1 week (extra long to accommodate
>> holiday schedules).
>>
>> The proposal follows, you can also access the wiki page:
>> https://wiki.apache.org/incubator/TrafficControlProposal
>>
>> Thanks,
>> JvD
>>
>>
>> = Traffic Control Proposal =
>>
>> == Abstract ==
>>
>> Traffic Control allows you to build a large scale content delivery
>> network using
>> open source.
>>
>> == Proposal ==
>>
>> The goal of this proposal is to bring the Traffic Control project into the
>> Apache Software Foundation.
>>
>> == Background ==
>>
>> Initially built around Apache Traffic Server as the caching software,
>> Traffic
>> Control implements all functions of a modern CDN except the caching
>> software:
>>
>>   * Traffic Router is a Java Tomcat application that routes clients to
>> the closest
>>   available cache on the CDN using both HTTP and DNS. By using consistent
>> hashing
>>   it sends requests for the same content to the same cache in a group of
>> caches
>>   working together in a location. It takes care of routing clients around
>> hot
>>   spots and problems in the CDN by using the information from Traffic
>> Monitor with
>>   regards to state of all the caches.
>>
>>   * Traffic Monitor is a Java Tomcat application that implements the CDN
>> health
>>   protocol. Every cache in the CDN is checked using HTTP for vital stats,
>> and
>>   based on these stats, caches are declared healthy or unhealthy. This
>> information
>>   is then used by Traffic Router to make its routing decisions.
>>
>>   * Traffic Ops is a Perl Mojolicious and jQuery UI application for
>> management and
>>   monitoring of all servers in the CDN. All server and content routing
>> information
>>   for the CDN is managed through Traffic Ops. It also exposes RESTful API
>>   endpoints for consumption by tools and other applications.
>>
>>   * Traffic Stats is a Go application that is used to acquire and store
>> statistics
>>   about CDNs controlled by Traffic Control. Traffic Stats mines metrics
>> from
>>   Traffic Monitor’s JSON APIs and stores the data in InfluxDB, and
>> visualizes them
>>   using Grafana.
>>
>>   * Traffic Analytics is a new component we are starting to build for log
>> file
>>   analysis, based on Apache Kafka, Heka, and Elastic Search.
>>
>>
>> Traffic Control was developed by Comcast Cable and released as open
>> source under
>> the Apache 2.0 license in April of 2015. Traffic Control is deployed at
>> Comcast
>> and other cable operators.
>>
>> The Traffic Control project was presented at ApacheCon NA 2016, see
>> http://bit.ly/1UwMzmR for additional background information.
>>
>> == Rationale ==
>>
>> Even though the traffic on today's CDNs is strictly defined by open
>> standards,
>> and there are many open source implementations of caches available, CDNs
>> are
>> still proprietary. The current providers of CDN-as-a-product or
>> CDN-as-a-service all have their own proprietary implementation of the
>> control
>> plane.  The CDN control plane of one vendor can't interoperate with the
>> CDN
>> control plane of another, creating a classic vendor-lockin for
>> CDN-as-a-product
>> customers. Traffic Control changes that. Emerging standards from IETF
>> (CDNi
>> working group) and the Streaming Video Alliance Open Caching working
>> group need
>> an open source reference implementation; Traffic Control will strive to be
>> that.
>>
>> == Initial Goals ==
>>
>> Initial goals of transitioning to ASF is to grow and diversify the
>> community,
>> and to move to a more open and inclusive development model.
>>
>> == Current Status ==
>>
>> Traffic Control is functional and deployed at Comcast and other cable
>> operators.
>> In the past 12 months 10 major releases have been made.
>>
>> === Meritocracy ===
>>
>> Initial development was done at Comcast Cable. Since April 2015  it has
>> been
>> open source, and a handful outside contributors have been added.
>>
>> Our main goal during incubation is to try to create a more diverse group
>> of
>> contributors and users.
>>
>> === Community ===
>>
>> Traffic Control is being used by a number of cable companies and is being
>> evaluated by a number of vendors and ISPs. Two vendors have created
>> products
>> based on Traffic Control and are active in the community.
>>
>> === Core Developers ===
>>
>> Most of the core developers of Traffic Control are currently at

Re: [VOTE] Accept Traffic Control into the Apache Incubator

2016-07-05 Thread Josh Elser 

+1 (binding)

Good luck!

Jan van Doorn wrote:

Following the discussion thread, I would like to call a VOTE on accepting 
Traffic Control into the Apache Incubator.

[] +1 Accept Traffic Control into the Apache Incubator
[] +0 Abstain.
[] -1 Do not accept Traffic Control into the Apache Incubator because ...

This vote will be open for at least 1 week (extra long to accommodate holiday 
schedules).

The proposal follows, you can also access the wiki page: 
https://wiki.apache.org/incubator/TrafficControlProposal

Thanks,
JvD


= Traffic Control Proposal =

== Abstract ==

Traffic Control allows you to build a large scale content delivery network using
open source.

== Proposal ==

The goal of this proposal is to bring the Traffic Control project into the
Apache Software Foundation.

== Background ==

Initially built around Apache Traffic Server as the caching software, Traffic
Control implements all functions of a modern CDN except the caching software:

  * Traffic Router is a Java Tomcat application that routes clients to the 
closest
  available cache on the CDN using both HTTP and DNS. By using consistent 
hashing
  it sends requests for the same content to the same cache in a group of caches
  working together in a location. It takes care of routing clients around hot
  spots and problems in the CDN by using the information from Traffic Monitor 
with
  regards to state of all the caches.

  * Traffic Monitor is a Java Tomcat application that implements the CDN health
  protocol. Every cache in the CDN is checked using HTTP for vital stats, and
  based on these stats, caches are declared healthy or unhealthy. This 
information
  is then used by Traffic Router to make its routing decisions.

  * Traffic Ops is a Perl Mojolicious and jQuery UI application for management 
and
  monitoring of all servers in the CDN. All server and content routing 
information
  for the CDN is managed through Traffic Ops. It also exposes RESTful API
  endpoints for consumption by tools and other applications.

  * Traffic Stats is a Go application that is used to acquire and store 
statistics
  about CDNs controlled by Traffic Control. Traffic Stats mines metrics from
  Traffic Monitor’s JSON APIs and stores the data in InfluxDB, and visualizes 
them
  using Grafana.

  * Traffic Analytics is a new component we are starting to build for log file
  analysis, based on Apache Kafka, Heka, and Elastic Search.


Traffic Control was developed by Comcast Cable and released as open source under
the Apache 2.0 license in April of 2015. Traffic Control is deployed at Comcast
and other cable operators.

The Traffic Control project was presented at ApacheCon NA 2016, see
http://bit.ly/1UwMzmR for additional background information.

== Rationale ==

Even though the traffic on today's CDNs is strictly defined by open standards,
and there are many open source implementations of caches available, CDNs are
still proprietary. The current providers of CDN-as-a-product or
CDN-as-a-service all have their own proprietary implementation of the control
plane.  The CDN control plane of one vendor can't interoperate with the CDN
control plane of another, creating a classic vendor-lockin for CDN-as-a-product
customers. Traffic Control changes that. Emerging standards from IETF (CDNi
working group) and the Streaming Video Alliance Open Caching working group need
an open source reference implementation; Traffic Control will strive to be
that.

== Initial Goals ==

Initial goals of transitioning to ASF is to grow and diversify the community,
and to move to a more open and inclusive development model.

== Current Status ==

Traffic Control is functional and deployed at Comcast and other cable operators.
In the past 12 months 10 major releases have been made.

=== Meritocracy ===

Initial development was done at Comcast Cable. Since April 2015  it has been
open source, and a handful outside contributors have been added.

Our main goal during incubation is to try to create a more diverse group of
contributors and users.

=== Community ===

Traffic Control is being used by a number of cable companies and is being
evaluated by a number of vendors and ISPs. Two vendors have created products
based on Traffic Control and are active in the community.

=== Core Developers ===

Most of the core developers of Traffic Control are currently at Comcast. The
main goal of the incubation is to grow the developer and user group into a
community beyond Comcast and US cable.

=== Alignment ===

Traffic Control is closely aligned with Apache Traffic Server (ATS). The only
supported cache in a Traffic Control CDN at this time is ATS.  One of our
proposed mentors is a committers to ATS, and our proposed champion the ATS PMC
chair.

We don't want to become a sub-project of ATS though, because we believe we
should add other caching proxies as they are deemed to be a valuable addition to
the Traffic Control CDN.

== Known Risks ==

=== Orphaned products ===

Traffic Control is

Re: [VOTE] Accept Traffic Control into the Apache Incubator

2016-07-02 Thread Leif Hedstrom 

> On Jul 1, 2016, at 8:00 AM, Jan van Doorn  wrote:
> 
> Following the discussion thread, I would like to call a VOTE on accepting 
> Traffic Control into the Apache Incubator.
> 
> [] +1 Accept Traffic Control into the Apache Incubator
> [] +0 Abstain.
> [] -1 Do not accept Traffic Control into the Apache Incubator because …
> 

+1 (binding).

Cheers,

— leif



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Traffic Control into the Apache Incubator

2016-07-01 Thread Phil Sorber 
+1

On Fri, Jul 1, 2016 at 8:00 AM Jan van Doorn  wrote:

> Following the discussion thread, I would like to call a VOTE on accepting
> Traffic Control into the Apache Incubator.
>
> [] +1 Accept Traffic Control into the Apache Incubator
> [] +0 Abstain.
> [] -1 Do not accept Traffic Control into the Apache Incubator because ...
>
> This vote will be open for at least 1 week (extra long to accommodate
> holiday schedules).
>
> The proposal follows, you can also access the wiki page:
> https://wiki.apache.org/incubator/TrafficControlProposal
>
> Thanks,
> JvD
>
>
> = Traffic Control Proposal =
>
> == Abstract ==
>
> Traffic Control allows you to build a large scale content delivery network
> using
> open source.
>
> == Proposal ==
>
> The goal of this proposal is to bring the Traffic Control project into the
> Apache Software Foundation.
>
> == Background ==
>
> Initially built around Apache Traffic Server as the caching software,
> Traffic
> Control implements all functions of a modern CDN except the caching
> software:
>
>  * Traffic Router is a Java Tomcat application that routes clients to the
> closest
>  available cache on the CDN using both HTTP and DNS. By using consistent
> hashing
>  it sends requests for the same content to the same cache in a group of
> caches
>  working together in a location. It takes care of routing clients around
> hot
>  spots and problems in the CDN by using the information from Traffic
> Monitor with
>  regards to state of all the caches.
>
>  * Traffic Monitor is a Java Tomcat application that implements the CDN
> health
>  protocol. Every cache in the CDN is checked using HTTP for vital stats,
> and
>  based on these stats, caches are declared healthy or unhealthy. This
> information
>  is then used by Traffic Router to make its routing decisions.
>
>  * Traffic Ops is a Perl Mojolicious and jQuery UI application for
> management and
>  monitoring of all servers in the CDN. All server and content routing
> information
>  for the CDN is managed through Traffic Ops. It also exposes RESTful API
>  endpoints for consumption by tools and other applications.
>
>  * Traffic Stats is a Go application that is used to acquire and store
> statistics
>  about CDNs controlled by Traffic Control. Traffic Stats mines metrics from
>  Traffic Monitor’s JSON APIs and stores the data in InfluxDB, and
> visualizes them
>  using Grafana.
>
>  * Traffic Analytics is a new component we are starting to build for log
> file
>  analysis, based on Apache Kafka, Heka, and Elastic Search.
>
>
> Traffic Control was developed by Comcast Cable and released as open source
> under
> the Apache 2.0 license in April of 2015. Traffic Control is deployed at
> Comcast
> and other cable operators.
>
> The Traffic Control project was presented at ApacheCon NA 2016, see
> http://bit.ly/1UwMzmR for additional background information.
>
> == Rationale ==
>
> Even though the traffic on today's CDNs is strictly defined by open
> standards,
> and there are many open source implementations of caches available, CDNs
> are
> still proprietary. The current providers of CDN-as-a-product or
> CDN-as-a-service all have their own proprietary implementation of the
> control
> plane.  The CDN control plane of one vendor can't interoperate with the CDN
> control plane of another, creating a classic vendor-lockin for
> CDN-as-a-product
> customers. Traffic Control changes that. Emerging standards from IETF (CDNi
> working group) and the Streaming Video Alliance Open Caching working group
> need
> an open source reference implementation; Traffic Control will strive to be
> that.
>
> == Initial Goals ==
>
> Initial goals of transitioning to ASF is to grow and diversify the
> community,
> and to move to a more open and inclusive development model.
>
> == Current Status ==
>
> Traffic Control is functional and deployed at Comcast and other cable
> operators.
> In the past 12 months 10 major releases have been made.
>
> === Meritocracy ===
>
> Initial development was done at Comcast Cable. Since April 2015  it has
> been
> open source, and a handful outside contributors have been added.
>
> Our main goal during incubation is to try to create a more diverse group of
> contributors and users.
>
> === Community ===
>
> Traffic Control is being used by a number of cable companies and is being
> evaluated by a number of vendors and ISPs. Two vendors have created
> products
> based on Traffic Control and are active in the community.
>
> === Core Developers ===
>
> Most of the core developers of Traffic Control are currently at Comcast.
> The
> main goal of the incubation is to grow the developer and user group into a
> community beyond Comcast and US cable.
>
> === Alignment ===
>
> Traffic Control is closely aligned with Apache Traffic Server (ATS). The
> only
> supported cache in a Traffic Control CDN at this time is ATS.  One of our
> proposed mentors is a committers to ATS, and our proposed champion the ATS
> PMC
>

[VOTE] Accept Traffic Control into the Apache Incubator

2016-07-01 Thread Jan van Doorn 
Following the discussion thread, I would like to call a VOTE on accepting 
Traffic Control into the Apache Incubator.

[] +1 Accept Traffic Control into the Apache Incubator
[] +0 Abstain.
[] -1 Do not accept Traffic Control into the Apache Incubator because ...

This vote will be open for at least 1 week (extra long to accommodate holiday 
schedules).

The proposal follows, you can also access the wiki page: 
https://wiki.apache.org/incubator/TrafficControlProposal

Thanks,
JvD


= Traffic Control Proposal =

== Abstract ==

Traffic Control allows you to build a large scale content delivery network using
open source. 

== Proposal ==

The goal of this proposal is to bring the Traffic Control project into the
Apache Software Foundation.

== Background ==

Initially built around Apache Traffic Server as the caching software, Traffic
Control implements all functions of a modern CDN except the caching software:

 * Traffic Router is a Java Tomcat application that routes clients to the 
closest
 available cache on the CDN using both HTTP and DNS. By using consistent hashing
 it sends requests for the same content to the same cache in a group of caches
 working together in a location. It takes care of routing clients around hot
 spots and problems in the CDN by using the information from Traffic Monitor 
with
 regards to state of all the caches.

 * Traffic Monitor is a Java Tomcat application that implements the CDN health
 protocol. Every cache in the CDN is checked using HTTP for vital stats, and
 based on these stats, caches are declared healthy or unhealthy. This 
information
 is then used by Traffic Router to make its routing decisions.

 * Traffic Ops is a Perl Mojolicious and jQuery UI application for management 
and
 monitoring of all servers in the CDN. All server and content routing 
information
 for the CDN is managed through Traffic Ops. It also exposes RESTful API
 endpoints for consumption by tools and other applications.

 * Traffic Stats is a Go application that is used to acquire and store 
statistics
 about CDNs controlled by Traffic Control. Traffic Stats mines metrics from 
 Traffic Monitor’s JSON APIs and stores the data in InfluxDB, and visualizes 
them 
 using Grafana.

 * Traffic Analytics is a new component we are starting to build for log file 
 analysis, based on Apache Kafka, Heka, and Elastic Search.


Traffic Control was developed by Comcast Cable and released as open source under
the Apache 2.0 license in April of 2015. Traffic Control is deployed at Comcast
and other cable operators.

The Traffic Control project was presented at ApacheCon NA 2016, see 
http://bit.ly/1UwMzmR for additional background information.

== Rationale ==

Even though the traffic on today's CDNs is strictly defined by open standards,
and there are many open source implementations of caches available, CDNs are
still proprietary. The current providers of CDN-as-a-product or
CDN-as-a-service all have their own proprietary implementation of the control
plane.  The CDN control plane of one vendor can't interoperate with the CDN
control plane of another, creating a classic vendor-lockin for CDN-as-a-product
customers. Traffic Control changes that. Emerging standards from IETF (CDNi
working group) and the Streaming Video Alliance Open Caching working group need
an open source reference implementation; Traffic Control will strive to be
that.

== Initial Goals ==

Initial goals of transitioning to ASF is to grow and diversify the community,
and to move to a more open and inclusive development model.

== Current Status ==

Traffic Control is functional and deployed at Comcast and other cable operators.
In the past 12 months 10 major releases have been made.

=== Meritocracy ===

Initial development was done at Comcast Cable. Since April 2015  it has been
open source, and a handful outside contributors have been added.

Our main goal during incubation is to try to create a more diverse group of
contributors and users.

=== Community ===

Traffic Control is being used by a number of cable companies and is being
evaluated by a number of vendors and ISPs. Two vendors have created products
based on Traffic Control and are active in the community.

=== Core Developers ===

Most of the core developers of Traffic Control are currently at Comcast. The
main goal of the incubation is to grow the developer and user group into a
community beyond Comcast and US cable.

=== Alignment ===

Traffic Control is closely aligned with Apache Traffic Server (ATS). The only
supported cache in a Traffic Control CDN at this time is ATS.  One of our
proposed mentors is a committers to ATS, and our proposed champion the ATS PMC
chair.

We don't want to become a sub-project of ATS though, because we believe we
should add other caching proxies as they are deemed to be a valuable addition to
the Traffic Control CDN.

== Known Risks ==

=== Orphaned products ===

Traffic Control is a new system that does not have wide adoption, but at least
two