Re: General TC Cleanup

[Dave Neuman]

I am +1 on moving it to our website. We can have GitHub link to it from
there.

On Mon, Apr 30, 2018 at 13:07 Hank Beatty  wrote:

> I was considering adding a News page that would have a link in the top
> menu (HOME INFO DOCS ISSUES NEWS ...) when I was
> release manager.
>
> Other projects put the news on the main page: https://httpd.apache.org/
>
> Regardless, I think we should move it to the our apache.org site instead
> of GitHub.
>
> - Hank
>
> On 03/21/2018 12:54 PM, Dewayne Richardson wrote:
> > As we get more visibility as we become an Apache project, I've been
> taking
> > a fresh eye at Github project so that we can tidy up a bit to present
> > ourselves well.  I highly recommend that each of you do as well so that
> we
> > can get more eyeballs on the matter.
> >
> > One nit that I've noticed is the
> >
> > Github README.md News
> > https://github.com/apache/incubator-trafficcontrol#news
> >
> > This section always seems to get overlooked with each TC release.  The
> > question I have is do we think the "News" section is still valuable (it's
> > was only used to point out releases), or is there a better location we
> > should be directing from our Github project that is more Apache facing so
> > that we're making changes in one place?
> >
> > I've created this PR as my suggestion to the change.  Please provide
> > feedback and suggestions on the appropriate location for our "Traffic
> > Control News".
> >
> > https://github.com/apache/incubator-trafficcontrol/pull/2011
> >
> > -Dew
> >
>

Re: ATC Spring Summit 2018 Registration and CFP

[Dave Neuman]

Hey All,
I am looking forward to seeing everyone tomorrow! Eric has updated the
spring summit wiki page with information on checking in at Cisco
tomorrow[1]. Please make sure to take a look before you head in. Here is
the gist of it:

Directions to the meeting room: Park in front building 500 and enter
through the front doors. Check in with the lobby ambassador to receive a
temporary badge and Wi-Fi credentials. The meeting will be in the
Marblehead room. Proceed past the lobby desk and turn right into the
Customer Briefing Center. Follow the hallway to the left, turning right at
the end of the hallway.

Remember, breakfast is from 0800 - 0900 and we will start at 0900.

Thanks,
Dave


[1]
https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA

​

On Thu, Apr 5, 2018 at 12:12 PM, Dave Neuman  wrote:

> Hi everyone,
> I have created a premliminary schedule for the spring summit!  Please take
> a look and let me know if you have any questions or concerns.
>
> https://cwiki.apache.org/confluence/display/TC/ATC+
> Spring+Summit+-+April+2018%2C+Boxborough%2C+MA
>
> Thanks!
> Dave
>
> On Mon, Apr 2, 2018 at 12:40 PM, Dave Neuman  wrote:
>
>> Hey All,
>> We have a few slots still available to speak at the summit. Let me know
>> if you are interested!
>>
>> Thanks,
>> Dave
>>
>> On Thu, Mar 29, 2018 at 2:24 PM, Dave Neuman  wrote:
>>
>>> Hey Everyone,
>>> Just a reminder that our spring summit is less than a month away and our
>>> CFP will be closing in just 3 more days!  If you haven't had the
>>> opportunity to register yet, I encourage you to do so!  There is no
>>> registration fee, you just need to get yourself to Boston.  If you are
>>> planning on submitting a talk please do so by April 1st so that I can get a
>>> schedule out.  Please be assured that we have plenty of speaking slots
>>> still available.
>>>
>>> Register here:  https://cwiki.apache.org/confluence/display/TC/ATC+Sp
>>> ring+Summit+-+April+2018%2C+Boxborough%2C+MA.
>>> <https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA>
>>> Submit a talk by sending an email here:   summits@trafficcontrol
>>> .incubator.apache.org 
>>>
>>> Thanks,
>>> Dave
>>>
>>> On Fri, Mar 2, 2018 at 2:51 PM, Dave Neuman  wrote:
>>>
>>>> I just wanted to let everyone know that I have updated updated the wiki
>>>> page with hotel and transportation information.
>>>>
>>>> Thanks to everyone that has signed up and I look forward to more people
>>>> signing up.
>>>>
>>>> Thanks,
>>>> Dave
>>>>
>>>> On Sat, Feb 24, 2018 at 9:26 AM, Dave Neuman  wrote:
>>>>
>>>>> Hey All,
>>>>> It's my pleasure to announce that Apache Traffic Control will be
>>>>> having our spring summit on April 24 and 25 in Boxborough (Boston),
>>>>> Massachusetts!
>>>>> If you want to learn more about ATC, get some questions answered by
>>>>> members of the community, or just hang out with us for a few days, please
>>>>> see the following wiki page to RSVP:  https://cwiki.apache.org/conf
>>>>> luence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborou
>>>>> gh%2C+MA.
>>>>> <https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA>
>>>>>
>>>>> This email also servers as a CFP (Call for papers/presentations), if
>>>>> you have a great idea for a presentation let us know at
>>>>> summ...@trafficcontrol.incubator.apache.org
>>>>>  by April 1, 2018.  We
>>>>> will work on publishing a schedule as soon as we start getting 
>>>>> submissions.
>>>>>
>>>>> Any questions just let me know.
>>>>>
>>>>> Thanks and I look forward to seeing everyone there!
>>>>>
>>>>> Dave
>>>>>
>>>>>
>>>>
>>>
>>
>

[RESULT] [VOTE] Resolution for Traffic Control graduation to TLP

[Dave Neuman]

Hi All,
This vote has passed with 9 binding +1 votes and 0 -1 votes.  Thanks to all
who voted, I will work on submitting our resolution to the IPMC!

--Dave

On Thu, Apr 12, 2018 at 2:30 PM, David Neuman 
wrote:

> Thanks to everyone for voting.  It has been plenty of time so I am calling
> this vote.  I will send a resolution shortly.
> Thanks!
> Dave
>
> On Wed, Apr 4, 2018 at 9:01 AM, Jeremy Mitchell 
> wrote:
>
>> +1
>>
>> Jeremy
>>
>> On Mon, Apr 2, 2018 at 10:28 PM, Jason Tucker 
>> wrote:
>>
>> > +1
>> >
>> > On Tue, Apr 3, 2018 at 2:58 AM, John Rushford 
>> > wrote:
>> >
>> > > +1
>> > >
>> > > > On Apr 2, 2018, at 7:07 PM, Eric Friedrich (efriedri) <
>> > > efrie...@cisco.com> wrote:
>> > > >
>> > > > +1
>> > > >> On Apr 2, 2018, at 4:11 PM, David Neuman > >
>> > > wrote:
>> > > >>
>> > > >> Dear Traffic Control community members:
>> > > >>
>> > > >> I would like to call a vote on the resolution for Traffic Control
>> to
>> > > >> graduate from to an Apache TLP.  We have already voted on whether
>> or
>> > > not we
>> > > >> should start the graduation process [1] and this is the next step.
>> > > Please
>> > > >> see the resolution below and vote as follows:
>> > > >>
>> > > >> [ ] +1 Graduate Traffic Control from the incubator
>> > > >> [ ] +0 No Opinion
>> > > >> [ ] -1 Do not graduate Traffic Control from the incubator (please
>> > > provide a
>> > > >> reason)
>> > > >>
>> > > >> The vote is open for a minimum of 72 hours and will need at least 3
>> > > more +1
>> > > >> votes than -1 votes from PMC members to succeed.
>> > > >>
>> > > >> If this VOTE succeeds, a similar VOTE will be started on the
>> > > >> gene...@incubator.apache.org mailing list. If that VOTE succeeds,
>> a
>> > > >> resolution will be included in the next Apache Board Meeting.
>> > > >>
>> > > >> Please feel free to reach out with any questions.
>> > > >>
>> > > >> Thanks,
>> > > >> Dave
>> > > >>
>> > > >> [1]
>> > > >> https://lists.apache.org/thread.html/fb1fae0785feb6568cef6de
>> b6fa207
>> > > 23eba54ed63a445462d44564d3@%3Cdev.trafficcontrol.apache.org%3E
>> > > >>
>> > > >> -
>> > > >>
>> > > >> Establish the Apache Traffic Control Project
>> > > >>
>> > > >> WHEREAS, the Board of Directors deems it to be in the best
>> interests
>> > of
>> > > >> the Foundation and consistent with the Foundation's purpose to
>> > establish
>> > > >> a Project Management Committee charged with the creation and
>> > maintenance
>> > > >> of open-source software, for distribution at no charge to the
>> public,
>> > > >> related to building, monitoring, configuring, and provisioning a
>> large
>> > > >> scale content delivery network (CDN)..
>> > > >>
>> > > >> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
>> > > >> (PMC), to be known as the "Apache Traffic Control Project", be and
>> > > >> hereby is established pursuant to Bylaws of the Foundation; and be
>> it
>> > > >> further
>> > > >>
>> > > >> RESOLVED, that the Apache Traffic Control Project be and hereby is
>> > > >> responsible for the creation and maintenance of software related to
>> > > >> building, monitoring, configuring, and provisioning a large scale
>> > > >> content delivery network (CDN).; and be it further
>> > > >>
>> > > >> RESOLVED, that the office of "Vice President, Apache Traffic
>> Control"
>> > be
>> > > >> and hereby is created, the person holding such office to serve at
>> the
>> > > >> direction of the Board of Directors as the chair of the Apache
>> Traffic
>> > > >> Control Project, and to have primary responsibility for management
>> of
>> > > >> the projects within the scope of responsibility of the Apache
>> Traffic
>> > > >> Control Project; and be it further
>> > > >>
>> > > >> RESOLVED, that the persons listed immediately below be and hereby
>> are
>> > > >> appointed to serve as the initial members of the Apache Traffic
>> > Control
>> > > >> Project:
>> > > >>
>> > > >> * Dan Kirkwood   
>> > > >> * David Neuman   
>> > > >> * Dewayne Richardson 
>> > > >> * Eric Covener   
>> > > >> * Eric Friedrich 
>> > > >> * Hank Beatty
>> > > >> * Jan van Doorn  
>> > > >> * Jeff Elsloo
>> > > >> * Jeremy Mitchell
>> > > >> * Leif Hedstrom  
>> > > >> * Mark Torluemke 
>> > > >> * Phil Sorber
>> > > >> * Steve Malenfant
>> > > >>
>> > > >> NOW, THEREFORE, BE IT FURTHER RESOLVED, that David Neuman be
>> appointed
>> > > >> to the office of Vice President, Apache Traffic Control, to serve
>> in
>> > > >> accordance with and subject to the direction of the Board of
>> Directors
>> > > >> and the Bylaws of the Foundation until death, resignation,
>> retirement,
>> > > >> removal or disqualification, or until a successor is appointed;
>> and be
>> > > >> it further
>> > > >>
>> > > >> RESOLVED, that the initial Apache Traffic Control PMC be and
>> hereby is
>> > > >> tasked with the creation of a set of bylaws intended to encourage
>> open
>> > > >> developme

Re: Updated TO API guidelines

[Dave Neuman]

I am fine if we move in this direction, but I think we should be very
careful not to break existing functionality.  We need to make sure that if
we do change from path params to query params that we update our API
versions, documentation, and tests accordingly.
Unless I am reading it wrong, it looks like the PR mentioned above by
Jeremy is not updating the version, the docs, or any associated tests.

Thanks,
Dave

On Fri, Apr 6, 2018 at 3:14 PM, Jeremy Mitchell 
wrote:

> Rawlin,
>
> I have submitted a PR to change some new ds request routes to utilize query
> params instead of path/route params (the legacy format):
>
> https://github.com/apache/incubator-trafficcontrol/pull/2094
>
> On Fri, Apr 6, 2018 at 11:59 AM, Rawlin Peters 
> wrote:
>
> > Do we currently have an example of an API endpoint written in the
> > traffic_ops_golang framework that uses only query parameters like
> > this? How would it compare to the legacy format?
> >
> > -Rawlin
> >
> > On Thu, Apr 5, 2018 at 9:45 AM, Dewayne Richardson 
> > wrote:
> > > Thank you John for giving us "API Use Cases" to think about with these
> > new
> > > TO API Guidelines.  The main goal for these changes are to build TO
> API's
> > > that are intuitive.  I'm of the opinion that if the API's are intuitive
> > > (with easy to understand patterns) that prevents me from wasting time
> > > looking up API docs.  A nice side effect of having simple standards and
> > > patterns is that simplicity ripples into our API Go code which allows
> us
> > to
> > > easily build frameworks that do all of the work instead of the API
> > > snowflakes that we have today.
> > >
> > > I encourage everyone to shoot as many holes into our thoughts around
> this
> > > new direction so that we can see the bigger picture.
> > >
> > > -Dew
> > >
> > > On Wed, Apr 4, 2018 at 10:29 PM, John Rushford 
> > wrote:
> > >
> > >> Why the change?  It’s my understanding that path parameters should be
> > used
> > >> to specify a particular resource
> > >> and query parameters should be used to sort/filter the query.  Why
> use a
> > >> query parameter to specify a particular
> > >> resource?  Is this REST API best practice?
> > >>
> > >> What about sub resource queries such as using the following:
> > >>
> > >> GET api/1.3/deliveryservices/{xmlID}/urisigning
> > >>
> > >> where you are requesting a particular urisigning keys sub resource for
> > the
> > >> particular deliveryservice resource. You can make it work
> > >> with an xmlid query parameter but what do you return if the query
> > >> parameter is left off, all uri signing keys?  Is that useful?
> > >>
> > >> John
> > >>
> > >> > On Apr 4, 2018, at 3:23 PM, Jeremy Mitchell 
> > >> wrote:
> > >> >
> > >> > tbh i'm not sure about versioning. I was just trying to suggest that
> > new
> > >> > routes be formulated this way per the new API guidelines:
> > >> >
> > >> > GET /foos[?id, name, etc=]
> > >> > POST /foos
> > >> > PUT /foos [?id, name, etc=]
> > >> > DELETE /foos [?id, name, etc=]
> > >> >
> > >> > instead of the old way:
> > >> >
> > >> > GET /foos
> > >> > GET /foos/:id
> > >> > POST /foos
> > >> > PUT /foos/:id
> > >> > DELETE /foos/:id
> > >> >
> > >> > The difference being the use of query params over route/path params.
> > >> >
> > >> > Technically, adding new routes does not break old stuff right so i
> > don't
> > >> > think that warrants a major version roll.
> > >> >
> > >> > While we're on the subject, what does everyone think if we took this
> > one
> > >> > step further and made routes handle a request payload with one or
> more
> > >> > items. For example:
> > >> >
> > >> > GET /foos[?id, name, etc=]
> > >> > POST /foos <-- takes in an array of foos to create
> > >> > PUT /foos <-- takes in an array of foos to update
> > >> > DELETE /foos <-- takes in an array of foos to delete
> > >> >
> > >> > in this scenario, query params only pertain to the GET. The POST,
> PUT
> > and
> > >> > DELETE rely on the contents of the request json...
> > >> >
> > >> > Jeremy
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Apr 4, 2018 at 1:55 PM, Robert Butts <
> > robert.o.bu...@gmail.com>
> > >> > wrote:
> > >> >
> > >> >> That document doesn't mention versions, 1.2 vs 1.3 vs 2.0.
> > >> >>
> > >> >> Just to clarify, changing to query parameters breaks compatibility
> > with
> > >> 1.2
> > >> >> and older, so new APIs in that format have to be a new major
> version,
> > >> i.e.
> > >> >> 2.0, per Semantic Versioning, right?
> > >> >>
> > >> >> On Tue, Apr 3, 2018 at 3:26 PM, Jeremy Mitchell <
> > mitchell...@apache.org
> > >> >
> > >> >> wrote:
> > >> >>
> > >> >>> FYI - I've updated the TO API guidelines to reflect our desire to
> > move
> > >> >> away
> > >> >>> from route/path params and embrace query params in the Golang API.
> > >> >>>
> > >> >>> https://cwiki.apache.org/confluence/display/TC/API+Guidelines
> > >> >>>
> > >> >>> Jeremy
> > >> >>>
> > >> >>
> > >>

Re: ATC Spring Summit 2018 Registration and CFP

[Dave Neuman]

Hi everyone,
I have created a premliminary schedule for the spring summit!  Please take
a look and let me know if you have any questions or concerns.

https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA


Thanks!
Dave

On Mon, Apr 2, 2018 at 12:40 PM, Dave Neuman  wrote:

> Hey All,
> We have a few slots still available to speak at the summit. Let me know if
> you are interested!
>
> Thanks,
> Dave
>
> On Thu, Mar 29, 2018 at 2:24 PM, Dave Neuman  wrote:
>
>> Hey Everyone,
>> Just a reminder that our spring summit is less than a month away and our
>> CFP will be closing in just 3 more days!  If you haven't had the
>> opportunity to register yet, I encourage you to do so!  There is no
>> registration fee, you just need to get yourself to Boston.  If you are
>> planning on submitting a talk please do so by April 1st so that I can get a
>> schedule out.  Please be assured that we have plenty of speaking slots
>> still available.
>>
>> Register here:  https://cwiki.apache.org/confluence/display/TC/ATC+Sp
>> ring+Summit+-+April+2018%2C+Boxborough%2C+MA.
>> <https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA>
>> Submit a talk by sending an email here:   summits@trafficcontrol
>> .incubator.apache.org 
>>
>> Thanks,
>> Dave
>>
>> On Fri, Mar 2, 2018 at 2:51 PM, Dave Neuman  wrote:
>>
>>> I just wanted to let everyone know that I have updated updated the wiki
>>> page with hotel and transportation information.
>>>
>>> Thanks to everyone that has signed up and I look forward to more people
>>> signing up.
>>>
>>> Thanks,
>>> Dave
>>>
>>> On Sat, Feb 24, 2018 at 9:26 AM, Dave Neuman  wrote:
>>>
>>>> Hey All,
>>>> It's my pleasure to announce that Apache Traffic Control will be having
>>>> our spring summit on April 24 and 25 in Boxborough (Boston), Massachusetts!
>>>> If you want to learn more about ATC, get some questions answered by
>>>> members of the community, or just hang out with us for a few days, please
>>>> see the following wiki page to RSVP:  https://cwiki.apache.org/conf
>>>> luence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA.
>>>> <https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA>
>>>>
>>>> This email also servers as a CFP (Call for papers/presentations), if
>>>> you have a great idea for a presentation let us know at
>>>> summ...@trafficcontrol.incubator.apache.org
>>>>  by April 1, 2018.  We
>>>> will work on publishing a schedule as soon as we start getting submissions.
>>>>
>>>> Any questions just let me know.
>>>>
>>>> Thanks and I look forward to seeing everyone there!
>>>>
>>>> Dave
>>>>
>>>>
>>>
>>
>

Re: Podling Report Reminder - April 2018

[Dave Neuman]

Hey All,
I have published a draft of our report here:
https://wiki.apache.org/incubator/April2018
I know that it is short notice, but please take a look and let me know if
you see anything that you would like updated or fixed.

Thanks,
Dave

On Fri, Mar 30, 2018 at 1:22 AM,  wrote:

> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
>
> The board meeting is scheduled for Wed, 18 April 2018, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, April 04).
>
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
>
> --
>
> Your report should contain the following:
>
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> *   A list of the three most important issues to address in the move
> towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
>
> This should be appended to the Incubator Wiki page at:
>
> https://wiki.apache.org/incubator/April2018
>
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
>
> Mentors
> ---
>
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
>
> Incubator PMC
>

Re: [VOTE] Resolution for Traffic Control graduation to TLP

[Dave Neuman]

+1

On Mon, Apr 2, 2018 at 2:11 PM, David Neuman 
wrote:

> Dear Traffic Control community members:
>
> I would like to call a vote on the resolution for Traffic Control to
> graduate from to an Apache TLP.  We have already voted on whether or not we
> should start the graduation process [1] and this is the next step.  Please
> see the resolution below and vote as follows:
>
> [ ] +1 Graduate Traffic Control from the incubator
> [ ] +0 No Opinion
> [ ] -1 Do not graduate Traffic Control from the incubator (please provide
> a reason)
>
> The vote is open for a minimum of 72 hours and will need at least 3 more
> +1 votes than -1 votes from PMC members to succeed.
>
> If this VOTE succeeds, a similar VOTE will be started on the
> gene...@incubator.apache.org mailing list. If that VOTE succeeds, a
> resolution will be included in the next Apache Board Meeting.
>
> Please feel free to reach out with any questions.
>
> Thanks,
> Dave
>
> [1] https://lists.apache.org/thread.html/fb1fae0785feb6568cef6deb6fa207
> 23eba54ed63a445462d44564d3@%3Cdev.trafficcontrol.apache.org%3E
>
> -
>
> Establish the Apache Traffic Control Project
>
> WHEREAS, the Board of Directors deems it to be in the best interests of
> the Foundation and consistent with the Foundation's purpose to establish
> a Project Management Committee charged with the creation and maintenance
> of open-source software, for distribution at no charge to the public,
> related to building, monitoring, configuring, and provisioning a large
> scale content delivery network (CDN)..
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Traffic Control Project", be and
> hereby is established pursuant to Bylaws of the Foundation; and be it
> further
>
> RESOLVED, that the Apache Traffic Control Project be and hereby is
> responsible for the creation and maintenance of software related to
> building, monitoring, configuring, and provisioning a large scale
> content delivery network (CDN).; and be it further
>
> RESOLVED, that the office of "Vice President, Apache Traffic Control" be
> and hereby is created, the person holding such office to serve at the
> direction of the Board of Directors as the chair of the Apache Traffic
> Control Project, and to have primary responsibility for management of
> the projects within the scope of responsibility of the Apache Traffic
> Control Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the Apache Traffic Control
> Project:
>
>  * Dan Kirkwood   
>  * David Neuman   
>  * Dewayne Richardson 
>  * Eric Covener   
>  * Eric Friedrich 
>  * Hank Beatty
>  * Jan van Doorn  
>  * Jeff Elsloo
>  * Jeremy Mitchell
>  * Leif Hedstrom  
>  * Mark Torluemke 
>  * Phil Sorber
>  * Steve Malenfant
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that David Neuman be appointed
> to the office of Vice President, Apache Traffic Control, to serve in
> accordance with and subject to the direction of the Board of Directors
> and the Bylaws of the Foundation until death, resignation, retirement,
> removal or disqualification, or until a successor is appointed; and be
> it further
>
> RESOLVED, that the initial Apache Traffic Control PMC be and hereby is
> tasked with the creation of a set of bylaws intended to encourage open
> development and increased participation in the Apache Traffic Control
> Project; and be it further
>
> RESOLVED, that the Apache Traffic Control Project be and hereby is
> tasked with the migration and rationalization of the Apache Incubator
> Traffic Control podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> Traffic Control podling encumbered upon the Apache Incubator PMC are
> hereafter discharged.
>
>
>

Re: ATC Spring Summit 2018 Registration and CFP

[Dave Neuman]

Hey All,
We have a few slots still available to speak at the summit. Let me know if
you are interested!

Thanks,
Dave

On Thu, Mar 29, 2018 at 2:24 PM, Dave Neuman  wrote:

> Hey Everyone,
> Just a reminder that our spring summit is less than a month away and our
> CFP will be closing in just 3 more days!  If you haven't had the
> opportunity to register yet, I encourage you to do so!  There is no
> registration fee, you just need to get yourself to Boston.  If you are
> planning on submitting a talk please do so by April 1st so that I can get a
> schedule out.  Please be assured that we have plenty of speaking slots
> still available.
>
> Register here:  https://cwiki.apache.org/confluence/display/TC/ATC+
> Spring+Summit+-+April+2018%2C+Boxborough%2C+MA.
> <https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA>
> Submit a talk by sending an email here:   summits@
> trafficcontrol.incubator.apache.org
> 
>
> Thanks,
> Dave
>
> On Fri, Mar 2, 2018 at 2:51 PM, Dave Neuman  wrote:
>
>> I just wanted to let everyone know that I have updated updated the wiki
>> page with hotel and transportation information.
>>
>> Thanks to everyone that has signed up and I look forward to more people
>> signing up.
>>
>> Thanks,
>> Dave
>>
>> On Sat, Feb 24, 2018 at 9:26 AM, Dave Neuman  wrote:
>>
>>> Hey All,
>>> It's my pleasure to announce that Apache Traffic Control will be having
>>> our spring summit on April 24 and 25 in Boxborough (Boston), Massachusetts!
>>> If you want to learn more about ATC, get some questions answered by
>>> members of the community, or just hang out with us for a few days, please
>>> see the following wiki page to RSVP:  https://cwiki.apache.org/conf
>>> luence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA.
>>> <https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA>
>>>
>>> This email also servers as a CFP (Call for papers/presentations), if you
>>> have a great idea for a presentation let us know at
>>> summ...@trafficcontrol.incubator.apache.org
>>>  by April 1, 2018.  We
>>> will work on publishing a schedule as soon as we start getting submissions.
>>>
>>> Any questions just let me know.
>>>
>>> Thanks and I look forward to seeing everyone there!
>>>
>>> Dave
>>>
>>>
>>
>

Re: ATC Spring Summit 2018 Registration and CFP

[Dave Neuman]

Hey Everyone,
Just a reminder that our spring summit is less than a month away and our
CFP will be closing in just 3 more days!  If you haven't had the
opportunity to register yet, I encourage you to do so!  There is no
registration fee, you just need to get yourself to Boston.  If you are
planning on submitting a talk please do so by April 1st so that I can get a
schedule out.  Please be assured that we have plenty of speaking slots
still available.

Register here:  https://cwiki.apache.org/confluence/display/TC/ATC+
Spring+Summit+-+April+2018%2C+Boxborough%2C+MA.
<https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA>
Submit a talk by sending an email here:   summits@trafficcontrol.
incubator.apache.org 

Thanks,
Dave

On Fri, Mar 2, 2018 at 2:51 PM, Dave Neuman  wrote:

> I just wanted to let everyone know that I have updated updated the wiki
> page with hotel and transportation information.
>
> Thanks to everyone that has signed up and I look forward to more people
> signing up.
>
> Thanks,
> Dave
>
> On Sat, Feb 24, 2018 at 9:26 AM, Dave Neuman  wrote:
>
>> Hey All,
>> It's my pleasure to announce that Apache Traffic Control will be having
>> our spring summit on April 24 and 25 in Boxborough (Boston), Massachusetts!
>> If you want to learn more about ATC, get some questions answered by
>> members of the community, or just hang out with us for a few days, please
>> see the following wiki page to RSVP:  https://cwiki.apache.org/conf
>> luence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA.
>> <https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA>
>>
>> This email also servers as a CFP (Call for papers/presentations), if you
>> have a great idea for a presentation let us know at
>> summ...@trafficcontrol.incubator.apache.org
>>  by April 1, 2018.  We
>> will work on publishing a schedule as soon as we start getting submissions.
>>
>> Any questions just let me know.
>>
>> Thanks and I look forward to seeing everyone there!
>>
>> Dave
>>
>>
>

Re: Podling Report Reminder - April 2018

[Dave Neuman]

I’ve got this.

On Wed, Mar 28, 2018 at 03:19  wrote:

> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
>
> The board meeting is scheduled for Wed, 18 April 2018, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, April 04).
>
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
>
> --
>
> Your report should contain the following:
>
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> *   A list of the three most important issues to address in the move
> towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
>
> This should be appended to the Incubator Wiki page at:
>
> https://wiki.apache.org/incubator/April2018
>
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
>
> Mentors
> ---
>
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
>
> Incubator PMC
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC2

[Dave Neuman]

Dangit, I already started this email so I am going to finish it:
+1
I tested the following:
- Signatures and hashes are good
- Created builds via PKG on a brand new Centos 7.x server
- Tested install of TM, TR, and TS.

On Thu, Mar 8, 2018 at 9:28 AM, Dan Kirkwood  wrote:

> Hank, fyi -- from the top level of trafficcontrol, `./pkg -v` will build
> all components.
>
> -dan
>
> On Thu, Mar 8, 2018 at 6:34 AM, Hank Beatty  wrote:
>
> > +1
> >
> > Lab Testing:
> >
> > - Docker build - Could not figure out how to get all components to build
> > at once
> > - build/build.sh on CentOS 6 - all components built successfully
> > - Upgraded Traffic Monitor (2.2.0.d7e588 -> 2.2.0.6ea850)
> >   - Could pull up UI and it connects to all cache servers
> > - Upgraded Traffic Router (2.2.0.d7e588 -> 2.2.0.6ea850)
> >   - Could connect to : and crs/stats looked correct
> > - Upgraded Traffic Stats (2.2.0.d7e588 -> 2.2.0.6ea850) CentOS 6
> > - Upgraded Traffic Ops ORT
> >   - mid cache "report" and "badass" mode seem to work correctly
> >   - edge cache "report" and "badass" mode seem to work correctly
> > - Tested DNS DS and works correctly
> >
> > On 03/05/2018 01:25 PM, Robert Butts wrote:
> >
> >> Hello All,
> >>
> >> I've prepared a release for v2.2.0-RC2
> >>
> >> The vote is open for at least 72 hours and passes if a majority of at
> >> least
> >> 3 +1 PPMC votes are cast.
> >>
> >> [ ] +1 Approve the release
> >>
> >> [ ] -1 Do not release this package because ...
> >>
> >> Changes since 2.1.0:
> >> https://github.com/apache/incubator-trafficcontrol/compare/
> >> RELEASE-2.1.0...RELEASE-2.2.0-RC2
> >>
> >> This corresponds to git:
> >>   Hash: 6ea85056a1a69973be4a74b82d602df29f21f42d
> >>   Tag: RELEASE-2.2.0-RC2
> >>
> >> Which can be verified with the following: git tag -v RELEASE-2.2.0-RC2
> >>
> >> My code signing key is available here:
> >> http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F&op=vindex
> >>
> >> Make sure you refresh from a key server to get all relevant signatures.
> >>
> >> The source .tar.gz file, pgp signature (.asc signed with my key from
> >> above), md5 and sha1 checksums are provided here:
> >>
> >> https://dist.apache.org/repos/dist/dev/incubator/
> trafficcontrol/2.2.0/RC2
> >>
> >>
> >> Thanks!
> >>
> >>
>

Re: Question about the "ALL" CDN in Traffic Ops

[Dave Neuman]

Derek is correct, in a multi-CDN environment, it is used for servers that
serve all CDNS.
To answer your last question, it should not cause any issues to remove the
"ALL" CDN as long as nothing is assigned to it.

Thanks,
Dave


On Mon, Mar 19, 2018 at 6:11 AM, Gelinas, Derek 
wrote:

> The "ALL" CDN is for the support server types that are not specific to one
> CDN.  Traffic portal, riak, traffic ops, traffic stats, influxdb, splunk,
> etc would all be "ALL" devices.  Traffic monitor and traffic router are
> server types that would instead be assigned to a specific CDN.  In a single
> CDN environment, this is less clear than in a multiple CDN environment.
> Hope that helps!
>
> Derek
>
> On 3/19/18, 7:07 AM, "Jifeng Yang (jifyang)"  wrote:
>
> Hi,
>
> I noticed that a CDN named “ALL” was added in Traffic Ops since
> Traffic Control 2.1.
>
> I wonder the reason for adding the “ALL” CDN (what’s the purpose of
> adding it). Would it cause any issue if I remove the “ALL” CDN in my
> deployment?
>
> Thanks,
> Jifeng
>
>
>

Re: Backup Cache Group Selection

[Dave Neuman]

Good point Rawlin, but I think it does answer your questions.  CZF for now,
whatever the new CZF thing is after that.

On Mon, Mar 12, 2018 at 1:44 PM, Rawlin Peters 
wrote:

> The original scope of this thread was determining where the Backup
> Cache Group config should live (API vs CZF), not necessarily about
> building the entire CZF in the database, although I'm +1 on that idea
> as well. I think any decisions made about doing that should probably
> be started in a separate thread.
>
> - Rawlin
>
> On Mon, Mar 12, 2018 at 1:11 PM, Dave Neuman  wrote:
> > +1 on building the CZF in the database.  Jan tried to go down that rabbit
> > hole but realized it was a pretty hard problem to solve.  I think this is
> > something we might want to re-visit.  Maybe this is something we should
> > discuss at our meetup and then update this thread with our decisions?
> >
> > On Mon, Mar 12, 2018 at 11:25 AM, Rawlin Peters  >
> > wrote:
> >
> >> @VijayAnand:
> >>
> >> Right, a Coverage Zone that doesn't map to a Cache Group in TO won't
> >> be chosen as a backup in case of failure, but you could have a
> >> Coverage-Zone-not-in-TO that configures Coverage-Zones-in-TO as
> >> backups. But, I think the general sentiment right now is that all
> >> Coverage Zones in the CZF should map back to Cache Groups in TO, so
> >> the backup config should also be done via the Cache Group API.
> >>
> >> So from the Traffic Router perspective, the process should become:
> >> 1. Rather than parsing from the CZF into the NetworkNode class, parse
> >> Cache Group backup config from the CRConfig into the existing
> >> CacheLocation class
> >> 2. in the DS request flow, the NetworkNode will map back to a
> >> registered CacheLocation which would contain the backup CG config
> >>
> >> The rest of the PR's behavior should stay the same, it's just a matter
> >> of the config being located in a different class. To give you an idea
> >> of how I would format it in the CRConfig (so you know how to parse it
> >> out), here is a snippet of "edgeLocations" from CRConfig.json:
> >>
> >> "edgeLocations": {
> >> "edge-cg-1": {
> >>   "latitude": 1.00,
> >>   "longitude": 2.00,
> >>   "backupLocations": {
> >>   "list": ["edge-cg-2"],
> >>   "fallbackToClosest": false
> >>   }
> >> },
> >> "edge-cg-2": {
> >>   "latitude": 3.00,
> >>   "longitude": 4.00
> >> },
> >> }
> >>
> >> The "backupLocations" section would still remain optional (if missing,
> >> follow existing behavior of falling back to next closest CG). Existing
> >> defaults in the current PR should remain the same.
> >>
> >> How would you feel about making those changes in your PR? Feel free to
> >> tackle the new TO API and Traffic Portal changes too if you want, but
> >> I don't want to burden you with this unexpected work if you don't want
> >> it. I (or another willing contributor) could work on the necessary TO
> >> API and Traffic Portal changes sometime in the near future and
> >> integrate them with your Traffic Router enhancement.
> >>
> >> - Rawlin
> >>
> >>
> >> On Mon, Mar 12, 2018 at 7:39 AM, vijayanand.jayaman...@gmail.com
> >>  wrote:
> >> >
> >> > Rawlin,
> >> >
> >> > I believe the following statement is not correct.
> >> >
> >> > 
> >> > However, after reading your initial proposal below, it sounds like you
> >> > might have Coverage Zones in your CZF that don't necessarily map back
> >> > to Cache Groups in TO. Might that be the case?
> >> > 
> >> >
> >> > We can have Coverage Zones in CZF which don’t necessarily map in to
> TO’s
> >> configured list of Cache Groups. But then , it won’t be chosen as a
> valid
> >> backup in case of failure.
> >> >
> >> > For example:
> >> > GROUP1 and GROUP2 are Cache Groups configured in TO (and hence
> >> cr-config) , where GROUP3 is not in TO. Even though GROUP3 is specified
> as
> >> a backup for GROUP1, it wont be  chosen in case of GROUP1 failure ,
> since
> >> it is not in TO.
> >> > {
> >> >   "coverageZon

Re: Backup Cache Group Selection

[Dave Neuman]

+1 on building the CZF in the database.  Jan tried to go down that rabbit
hole but realized it was a pretty hard problem to solve.  I think this is
something we might want to re-visit.  Maybe this is something we should
discuss at our meetup and then update this thread with our decisions?

On Mon, Mar 12, 2018 at 11:25 AM, Rawlin Peters 
wrote:

> @VijayAnand:
>
> Right, a Coverage Zone that doesn't map to a Cache Group in TO won't
> be chosen as a backup in case of failure, but you could have a
> Coverage-Zone-not-in-TO that configures Coverage-Zones-in-TO as
> backups. But, I think the general sentiment right now is that all
> Coverage Zones in the CZF should map back to Cache Groups in TO, so
> the backup config should also be done via the Cache Group API.
>
> So from the Traffic Router perspective, the process should become:
> 1. Rather than parsing from the CZF into the NetworkNode class, parse
> Cache Group backup config from the CRConfig into the existing
> CacheLocation class
> 2. in the DS request flow, the NetworkNode will map back to a
> registered CacheLocation which would contain the backup CG config
>
> The rest of the PR's behavior should stay the same, it's just a matter
> of the config being located in a different class. To give you an idea
> of how I would format it in the CRConfig (so you know how to parse it
> out), here is a snippet of "edgeLocations" from CRConfig.json:
>
> "edgeLocations": {
> "edge-cg-1": {
>   "latitude": 1.00,
>   "longitude": 2.00,
>   "backupLocations": {
>   "list": ["edge-cg-2"],
>   "fallbackToClosest": false
>   }
> },
> "edge-cg-2": {
>   "latitude": 3.00,
>   "longitude": 4.00
> },
> }
>
> The "backupLocations" section would still remain optional (if missing,
> follow existing behavior of falling back to next closest CG). Existing
> defaults in the current PR should remain the same.
>
> How would you feel about making those changes in your PR? Feel free to
> tackle the new TO API and Traffic Portal changes too if you want, but
> I don't want to burden you with this unexpected work if you don't want
> it. I (or another willing contributor) could work on the necessary TO
> API and Traffic Portal changes sometime in the near future and
> integrate them with your Traffic Router enhancement.
>
> - Rawlin
>
>
> On Mon, Mar 12, 2018 at 7:39 AM, vijayanand.jayaman...@gmail.com
>  wrote:
> >
> > Rawlin,
> >
> > I believe the following statement is not correct.
> >
> > 
> > However, after reading your initial proposal below, it sounds like you
> > might have Coverage Zones in your CZF that don't necessarily map back
> > to Cache Groups in TO. Might that be the case?
> > 
> >
> > We can have Coverage Zones in CZF which don’t necessarily map in to TO’s
> configured list of Cache Groups. But then , it won’t be chosen as a valid
> backup in case of failure.
> >
> > For example:
> > GROUP1 and GROUP2 are Cache Groups configured in TO (and hence
> cr-config) , where GROUP3 is not in TO. Even though GROUP3 is specified as
> a backup for GROUP1, it wont be  chosen in case of GROUP1 failure , since
> it is not in TO.
> > {
> >   "coverageZones": {
> >  "GROUP3": {
> >   "network6": [
> > "1234:567a::\/64",
> > "1234:567b::\/64"
> >   ],
> >   "network": [
> > "10.197.89.0\/24"
> >   ]
> > },
> >
> >  "GROUP2": {
> >   "network6": [
> > "1234:567a::\/64",
> > "1234:567b::\/64"
> >   ],
> >   "network": [
> > "10.197.69.0\/24"
> >   ]
> > },
> > "GROUP1": {
> >"backupZones":{
> >   "list": ["GROUP3"],? This wont be chosen as backup Cache Group in
> case of failure , since it is not in crconfig.
> >   "fallbackToClosestGroup":false
> >},
> >   "network6": [
> > "1234:5677::\/64",
> > "1234:5676::\/64"
> >   ],
> >   "network": [
> > "10.126.250.0\/24"
> >   ]
> > }
> >   }
> > }
> >
> > So, i feel, the existing implementation of specifying backupZones
> configuratioin in CZF should be fine.
> >
> > Thanks,
> > Vijayanand S
> >
> > On 2018/03/09 18:31:56, Rawlin Peters  wrote:
> >> Hey Eric (and others),
> >>
> >> I'm resurrecting this thread because the PR [1] implementing this
> >> proposed functionality is just about ready to be merged. The full
> >> mailing list discussion can be read here [2] if interested.
> >>
> >> I've discussed this PR a bit more with my colleagues here at Comcast,
> >> and while it provides the functionality we need, we think in the
> >> long-term this configuration should live in the Cache Group API in
> >> Traffic Ops rather than just the Coverage Zone File.
> >>
> >> However, after reading your initial proposal below, it sounds like you
> >> might have Coverage Zones in your CZF that don't necessarily map back
> >> to Cache Groups in TO. Might that be the case? That scenario seems to
> >> be allowed by Traffic Router but might not necess

Re: Traffic Ops Access Control v2

[Dave Neuman]

This sounds great Jeremy, looking forward to it getting implemented.  A few
things though:

1) The "proposed roles" are really just "default roles" right?  Meaning we
will provide a way to create new roles and assign capabilities to them?
2) We will provide a way to CRUD capabilities, correct?
3) Is it assumed that Admin gets everything?  What does Operations NOT get
that admin DOES get?  Trying to differentiate between the two.

Thanks,
Dave

On Thu, Mar 8, 2018 at 9:53 AM, Jeremy Mitchell 
wrote:

> There has been some discussion for quite some time regarding an overhaul of
> the TO access control model. I'd like to refresh eveyone's memory on that
> discussion.
>
>
> *Current system:*
>
> Since the beginning, resources (or routes (UI and API)) have been locked
> down by role, or more specifically, privilege level. For example, if a
> route requires a privilege level of 20, then only users with the operations
> role (priv level=20) or admin role (priv level=30) could access that route.
> Here are our current roles (and their priv levels):
>
> Admin (30)
> Operations (20)
> Portal (15)
> Federation (15)
> Steering (15)
> ORT (11)
> Read-Only (10)
> Disallowed (0)
>
> This method has served us well for quite a while but there are some
> drawbacks to this approach. Here are a few I can think of:
>
> - No clear understanding of which routes each role provides access to. For
> example, what is the difference between the Admin and Operations role? All
> I know is that the admin role has a priv level of 30 and operations has 20.
> I can't tell you which routes an admin has access to that operations does
> not without reading the code or going thru all the docs. Ain't nobody got
> time for that!
>
> - The "Additive" nature of the roles (via priv level) prevents the ability
> to create unrelated roles. You can't create 2 roles with unique access.
> Higher level roles always inherit from lower level roles. The Federation
> role is a good example. Federation users only need access to a couple
> routes yet since it has a priv-level=15, federation users look like they
> can do federation, steering, portal, ort and read-only things...
>
> - Not easy to alter the access level of a role. For example, if you wanted
> the Portal role to have access to a few more routes, what would you do?
> Raise priv level to 18? Not sure what that would do...if anything. You'd
> have to make code changes to ensure an 18 would actually do something.
>
> - Many API consumers have elevated permissions when they only need access
> to a few routes. I.e. traffic monitors, traffic routers, traffic stats all
> have to be given the admin role. so basically, they've been granted access
> to do EVERYTHING when they only access a few routes.
>
> - There is also inconsistency in how roles are enforced. Most routes use
> priv level to determine access but some routes simply check if the user has
> the role (i.e. steering).
>
>
> *New proposed system:*
>
> *Tenancy*
>
> Last summer tenancy was introduced (thanks Qwilt) giving us the ability to
> "scope" certain resources (delivery services, users and also tenants) to
> certain users. This was a big step towards self-service as we can now limit
> what certain users see. Access control is now role + tenancy (if tenancy is
> applicable and turned on via the use_tenancy parameter).
>
> *Roles/Capabilities*
>
> Actually, a lot of work has already been done (thanks again, Qwilt) in this
> area but of course, there is more to do. Let me explain a bit how it works
> conceptually.
>
> Proposed Roles:
>
> Admin
> Operations
> Content Provider (formerly known as Portal)
> Federation
> Cache (formerly known as ORT)
> Monitor (new)
> Router (new)
> Stats (new)
> Read-Only
> Disallowed
>
> Concept:
>
> - a user has one role
> - a role has N capabilities (i.e. ds-read, ds-write, etc)
> - a capability is mapped to N API endpoints (i.e. ds-read is mapped to GET
> /api/deliveryservices and GET /api/deliveryservices/:id)
>
> A user's capabilities (and not privilege level) determine whether a user
> has access to an API endpoint or not.
>
> Advantages:
>
> - By mapping roles to capabilities and capabilities to API endpoints, it's
> easy to see what level of API access each role provides. For example, easy
> to see the difference between the Admin and Operations role.
>
> - Roles are not "additive". Unrelated, unique roles can be created. For
> example, the Federation role and Content Provider role (formerly Portal
> role) can provide 2 completely different levels of access control.
> Currently, they provide the exact same level of access because of priv
> level.
>
> - Tightly defined roles with specific capabilities provides better
> security. I.e. you don't have to give a user an admin role so they can do
> only 2 things.
>
> - Can create custom roles on the fly to only include access to certain API
> endpoints. If you want to create a Bob role with just the ds-read
> capability, go for it. You can get very creative wit

[RESULT][VOTE] Traffic Control Graduation to TLP

[Dave Neuman]

The vote for Apache Traffic Control to graduate to a top level project [1]
has overwhelmingly passed with 16 +1 votes and 0 -1 votes!
Thank you to everyone who voted, I am excited to start on the resolution
and move forward toward graduation!

--Dave

[1]
https://lists.apache.org/thread.html/fb1fae0785feb6568cef6deb6fa20723eba54ed63a445462d44564d3@%3Cdev.trafficcontrol.apache.org%3E






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

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC2

[Dave Neuman]

The 2.1 profiles should work for 2.2

On Tue, Mar 6, 2018 at 9:19 AM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Can you please post default profiles for 2.2 on the website?
>
> For now, I’m using 2.1 default profiles to test the release
>
> —Eric
>
> > On Mar 5, 2018, at 1:25 PM, Robert Butts  wrote:
> >
> > Hello All,
> >
> > I've prepared a release for v2.2.0-RC2
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> least
> > 3 +1 PPMC votes are cast.
> >
> > [ ] +1 Approve the release
> >
> > [ ] -1 Do not release this package because ...
> >
> > Changes since 2.1.0:
> > https://github.com/apache/incubator-trafficcontrol/
> compare/RELEASE-2.1.0...RELEASE-2.2.0-RC2
> >
> > This corresponds to git:
> > Hash: 6ea85056a1a69973be4a74b82d602df29f21f42d
> > Tag: RELEASE-2.2.0-RC2
> >
> > Which can be verified with the following: git tag -v RELEASE-2.2.0-RC2
> >
> > My code signing key is available here:
> > http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F&op=vindex
> >
> > Make sure you refresh from a key server to get all relevant signatures.
> >
> > The source .tar.gz file, pgp signature (.asc signed with my key from
> > above), md5 and sha1 checksums are provided here:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/
> trafficcontrol/2.2.0/RC2
> >
> >
> > Thanks!
>
>

Re: ATC Spring Summit 2018 Registration and CFP

[Dave Neuman]

I just wanted to let everyone know that I have updated updated the wiki
page with hotel and transportation information.

Thanks to everyone that has signed up and I look forward to more people
signing up.

Thanks,
Dave

On Sat, Feb 24, 2018 at 9:26 AM, Dave Neuman  wrote:

> Hey All,
> It's my pleasure to announce that Apache Traffic Control will be having
> our spring summit on April 24 and 25 in Boxborough (Boston), Massachusetts!
> If you want to learn more about ATC, get some questions answered by
> members of the community, or just hang out with us for a few days, please
> see the following wiki page to RSVP:  https://cwiki.apache.org/
> confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+
> Boxborough%2C+MA.
> <https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA>
>
> This email also servers as a CFP (Call for papers/presentations), if you
> have a great idea for a presentation let us know at
> summ...@trafficcontrol.incubator.apache.org
>  by April 1, 2018.  We will
> work on publishing a schedule as soon as we start getting submissions.
>
> Any questions just let me know.
>
> Thanks and I look forward to seeing everyone there!
>
> Dave
>
>

[VOTE] Traffic Control graduation to TLP

[Dave Neuman]

 Hey All,

After a great discussion amongst the Apache Traffic Control PPMC, reviewing
the graduation checklist[1], updating the podling status page[2], and
updating the project website to ensure the whimsy podling website checks
pass[3], I would like to call a vote for Apache Traffic Control graduating
to a top level project.

Apache Traffic Control entered the incubator on July 12, 2016.  Since then
we have announced 4 releases, nominated 4 new committers, organized 3
summits, had almost 8,000 commits from 63 different contributors, and --
most importantly -- we have grown and diversified our community.  Apache
Traffic Control is a healthy project that is already acting like an Apache
top level project, so we should take the next step.

If we agree that we should graduate to a top level project, the next steps
will be to pick the initial PMC chair for the TLP and draft a Resolution
for the PPMC and IPMC to vote upon.

Please take a minute to vote on wheter or not Traffic Control should
graduate to a Top Level Project by responding with one of the following:

[ ] +1 Apache Traffic Control should graduate.
[ ] +0 No opinion
[ ] -1 Apache Traffic Control should not graduate (please provide the
reason)

The VOTE will be opened for at least the next 72 hours.  Per Apache
guidelines[4] I will also be notifying the incubator mailing list that a
community vote is under way.

Thanks,
Dave


[1]
https://incubator.apache.org/guides/graduation.html#graduation_check_list
[2] http://incubator.apache.org/projects/trafficcontrol.html
[3] https://whimsy.apache.org/pods/project/trafficcontrol
[4]
https://incubator.apache.org/guides/graduation.html#community_graduation_vote

Re: [VOTE] CHANGELOG.md file (second try)

[Dave Neuman]

+1

On Tue, Feb 27, 2018 at 14:50 Jeremy Mitchell  wrote:

> I like that format. Bullets seems nice and simple with external links where
> more info is required.
>
> I would be in favor of a PR to add these sections so it's easy for the next
> person to add a bullet to the relevant section.
>
> On Tue, Feb 27, 2018 at 2:15 PM, Rawlin Peters 
> wrote:
>
> > Hey folks,
> >
> > So I used the influxdb changelog as an example format, but @dew has
> > shown me this popular project for changelog convention:
> > http://keepachangelog.com/en/1.0.0/. For example see the project
> > changelog: https://github.com/olivierlacan/keep-a-changelog/
> > blob/master/CHANGELOG.md.
> >
> > Since we now have a changelog, it would be best to have a standard,
> > agreed-upon format for it so that we can keep it consistent for every
> > release.
> >
> > Basically it means every release has its own section (with an
> > "unreleased" section at the top), and everything will be
> > bullet-pointed underneath one of these sections for every release:
> > - "Added" for new features.
> > - "Changed" for changes in existing functionality.
> > - "Deprecated" for soon-to-be removed features.
> > - "Removed" for now removed features.
> > - "Fixed" for any bug fixes.
> > - "Security" in case of vulnerabilities.
> >
> > For example with my per-DS routing name upgrade notes currently in the
> > changelog, I would add that to the "Added" section and link to the
> > upgrade notes in our docs.
> >
> >  What do you all think? All in favor of accepting this keepachangelog
> > format?
> >
> > - Rawlin
> >
> >
> >
> > On Thu, Feb 8, 2018 at 2:29 PM, Rawlin Peters 
> > wrote:
> > > I went ahead and created one:
> > > https://github.com/apache/incubator-trafficcontrol/pull/1865. Please
> > > review and merge if you are okay with the current format. I'm not sure
> > > if we want to go back and add a list of all the new features in 2.2 or
> > > not, but please add to the CHANGELOG.md file if you have any pending
> > > release notes like 2.2 upgrade gotchas you'd like to get in.
> > >
> > > Thanks,
> > > Rawlin
> > >
> > > On Wed, Feb 7, 2018 at 4:07 PM, Dave Neuman  wrote:
> > >> Hey Rawlin,
> > >> I think Steve was starting to work on one, so we will see what he
> says.
> > >> If he doesn't have one started, I think you can go ahead and create
> one.
> > >>
> > >> Thanks,
> > >> Dave
> > >>
> > >> On Wed, Feb 7, 2018 at 4:04 PM, Rawlin Peters <
> rawlin.pet...@gmail.com>
> > >> wrote:
> > >>
> > >>> Hey all,
> > >>>
> > >>> So it appears this vote passed in favor of adding a CHANGELOG.md file
> > >>> without having a changelog label in GitHub. Is anyone currently
> > >>> working on one?
> > >>>
> > >>> With the 2.2 release planned for 2/12/18, I'd like to at least put in
> > >>> some upgrade release notes about Per-Delivery-Service Routing Names.
> > >>> If no one has a CHANGELOG.md in progress, I'll take the liberty to
> > >>> start one and add those release notes in there (using
> > >>> https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md as
> an
> > >>> example template).
> > >>>
> > >>> -Rawlin
> > >>>
> > >>> On Wed, Jan 10, 2018 at 10:35 AM, Chris Lemmons 
> > >>> wrote:
> > >>> > [X] +1 to adding a changelog.MD file
> > >>> > [] -1 to adding a changelog.MD file
> > >>> >
> > >>> > That said, I'm only in favour of it if we're fastidious about
> > >>> > requiring changelog updates on every single PR. A PR should either
> > >>> > provide a reasonable changelog entry, or, in the body of the PR,
> > >>> > justify it's absence. A simple "This bugfix does not require a
> > >>> > changelog entry." is sufficient for trivial bugfixes. That's plenty
> > >>> > for a reviewer to quickly either agree or decide to request (or
> > >>> > provide) an entry.
> > >>> >
> > >>> > If we add the changelog file, we need to update the contributing
> file
> > >>> > to 

Re: Google Summer of Code 2018 Mentor Registration

[Dave Neuman]

I think any of the perl -> go API stuff would be great.

On Mon, Feb 26, 2018 at 10:19 AM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> I agree, this would be a great way to grow the community.
>
> Do we have a list of marked issues in Github that would be good candidates?
>
> Or perhaps we can brainstorm some issues here on the mailer?
>
> —Eric
>
> > On Feb 24, 2018, at 5:18 PM, Phil Sorber  wrote:
> >
> > I think we should do this.
> >
> > -- Forwarded message -
> > From: Ulrich Stärk 
> > Date: Sat, Feb 24, 2018 at 2:19 PM
> > Subject: Google Summer of Code 2018 Mentor Registration
> > To: 
> > Cc: d...@community.apache.org 
> >
> >
> > Dear PMCs,
> >
> > I'm happy to announce that the ASF has made it onto the list of accepted
> > organizations for
> > Google Summer of Code 2018! [1,2]
> >
> > It is now time for mentors to sign up, so please pass this email on to
> your
> > community and
> > podlings. If you aren’t already subscribed to
> ment...@community.apache.org
> > you should do so now else
> > you might miss important information.
> >
> > Mentor signup requires two steps: mentor signup in Google's system [3]
> and
> > PMC acknowledgement.
> >
> > If you want to mentor a project in this year's SoC you will have to
> >
> > 1. Be an Apache committer.
> > 2. Request an acknowledgement from the PMC for which you want to mentor
> > projects. Use the below
> > template and *do not forget to copy ment...@community.apache.org*. We
> will
> > use the email adress you
> > indicate to send the invite to be a mentor for Apache.
> >
> > PMCs, read carefully please.
> >
> > We request that each mentor is acknowledged by a PMC member. This is to
> > ensure the mentor is in good
> > standing with the community. When you receive a request for
> > acknowledgement, please ACK it and cc
> > ment...@community.apache.org
> >
> > Lastly, it is not yet too late to record your ideas in Jira (see my
> > previous emails for details).
> > Students will now begin to explore ideas so if you haven’t already done
> so,
> > record your ideas
> > immediately!
> >
> > Cheers,
> >
> > Uli
> >
> > mentor request email template:
> > 
> > to: private@.apache.org
> > cc: ment...@community.apache.org
> > subject: GSoC 2018 mentor request for 
> >
> >  PMC,
> >
> > please acknowledge my request to become a mentor for Google Summer of
> Code
> > 2018 projects for Apache
> > .
> >
> > I would like to receive the mentor invite to 
> >
> > 
> >
> > 
> >
> > [1] https://summerofcode.withgoogle.com/organizations/
> > [2] https://summerofcode.withgoogle.com/organizations/5718432427802624/
> > [3] https://summerofcode.withgoogle.com/
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
>
>

ATC Spring Summit 2018 Registration and CFP

[Dave Neuman]

Hey All,
It's my pleasure to announce that Apache Traffic Control will be having our
spring summit on April 24 and 25 in Boxborough (Boston), Massachusetts!
If you want to learn more about ATC, get some questions answered by members
of the community, or just hang out with us for a few days, please see the
following wiki page to RSVP:
https://cwiki.apache.org/confluence/display/TC/ATC+Spring+Summit+-+April+2018%2C+Boxborough%2C+MA.


This email also servers as a CFP (Call for papers/presentations), if you
have a great idea for a presentation let us know at
summ...@trafficcontrol.incubator.apache.org
 by April 1, 2018.  We will
work on publishing a schedule as soon as we start getting submissions.

Any questions just let me know.

Thanks and I look forward to seeing everyone there!

Dave

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC1

[Dave Neuman]

Hi Steve, for the upgrade did you go from 2.1 -> 2.2?

On Wed, Feb 21, 2018 at 10:15 AM, Steve Malenfant 
wrote:

> +1
>
> Upgraded the following succesfully to RC1:
> Traffic Ops
> Traffic Portal
> Traffic Monitor (from java to golang)
> Traffic Router
> Traffic Stats
>
> I only opened a single issue related with some required parameter for
> Traffic Monitor. But if used according to the default RASCAL profiles, no
> problem. Logs are specific. Issue is #1902.
>
> Steve
>
> On Wed, Feb 14, 2018 at 4:01 PM, Robert Butts  wrote:
>
> > Hello All,
> >
> > I've prepared a release for v2.2.0-RC1
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> least
> > 3 +1 PPMC votes are cast.
> >
> > [ ] +1 Approve the release
> >
> > [ ] -1 Do not release this package because ...
> >
> > Changes since 2.1.0:
> > https://github.com/apache/incubator-trafficcontrol/
> > compare/RELEASE-2.1.0...RELEASE-2.2.0-RC1
> >
> > This corresponds to git:
> >  Hash: ea549797d98c4fe96e484c9e88f82e2d7f876c1e
> >  Tag: RELEASE-2.2.0-RC1
> >
> > Which can be verified with the following: git tag -v RELEASE-2.2.0-RC1
> >
> > My code signing key is available here:
> > http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F&op=vindex
> >
> > Make sure you refresh from a key server to get all relevant signatures.
> >
> > The source .tar.gz file, pgp signature (.asc signed with my key from
> > above), md5 and sha1 checksums are provided here:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/
> trafficcontrol/2.2.0/RC1
> >
> >
> > Thanks!
> >
>

Re: Traffic Ops API Swagger Doc

[Dave Neuman]

Sounds good.  I look forward to seeing it merged into our repo.
I guess this means there will need to be a PR to remove our current API
docs as they get moved to swagger.

On Tue, Feb 20, 2018 at 8:40 AM, Jeremy Mitchell 
wrote:

> I think this all sounds very promising. Some advantages that I see are:
>
> - docs never drift from API implementation (currently our docs get out of
> sync real fast)
> - this provides yet another interface -
> https://app.swaggerhub.com/apis/dewrich/traffic-ops_api/1.3 -  (in
> addition
> to TP) to interact with the API
> - a great way to demonstrate / educate developers on the capabilities of
> the api
>
> plus, i heard some bonus features that could be really interesting:
>
> - auto generation of a TO golang client. can we deprecate the old TO client
> in favor of an auto-generated one? The current TO client never seems to
> stay in sync with the api
> - generating server stubs
>
> imo our api can never be fully auto-generated because of the business logic
> that needs to be accounted forbut it would be pretty neat if all we had
> to do was "define" the api in a yaml file and that yaml file would spit out
> documentation, tests, clients (be it golang or java or whatever), and
> server side code (stubs) and then all we could focus on writing code
> specific to business logic.
>
> my guess is to really do this right, we'd have to rev the api version to
> 2.0 to make the api more swagger friendly...tools (swagger) like
> consistency and our api is far from consistent...
>
> jeremy
>
> On Wed, Feb 14, 2018 at 10:08 AM, Durfey, Ryan 
> wrote:
>
> > I am +1 on the swagger concept.  This makes working with APIs much easier
> > for non-developer staff and makes it easier to educate customers as well.
> >
> > Ryan DurfeyM | 303-524-5099
> > CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com > cdn_supp...@comcast.com>
> >
> > From: Dewayne Richardson 
> > Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> > dev@trafficcontrol.incubator.apache.org>
> > Date: Wednesday, February 14, 2018 at 9:34 AM
> > To: "dev@trafficcontrol.incubator.apache.org" <
> > dev@trafficcontrol.incubator.apache.org>
> > Subject: Traffic Ops API Swagger Doc
> >
> > We've been working diligently on the TO Golang Rewrite
> >  project
> to
> > obviously rewrite the Perl into Go, but also to improve our Testing and
> > Documentation efforts.  I presented the idea of using Swagger several
> > summits (years) ago about using Swagger to help drive our Traffic Ops API
> > documentation.  Since then Swagger has evolved and is becoming the de
> facto
> > standard for building (the potential for generating TO Golang Client and
> > Server stubs is now available) and documenting REST APIs.
> >
> > I would like to propose going forward that we use Swagger for future API
> > level documentation (because it can be generated out of our Golang
> > code/structs).  The below resources point out a TO API version 1.3 (the
> > version we decided to rev for the rewritten Golang endpoints).  The
> intent
> > behind 1.3 is obviously an improved version of the API (entirely backward
> > compatible to 1.2), but also to give us a starting point for building the
> > API doc in Swagger.
> >
> > The following resources are my examples:
> >
> > Swagger has several implementations and I chose go-swagger
> >  because it has more Golang
> > features.
> >
> > *Sample TO API doc *
> >
> > https://app.swaggerhub.com/apis/dewrich/traffic-ops_api/1.3
> >
> >
> > *Sample TO Golang code with embedded doc*
> >
> > Generated from the combination of these Golang documentation "hooks"
> > (there's current a go-swagger bug that prevents the doc from being tied
> > directly into the handlers)
> > https://github.com/dewrich/incubator-trafficcontrol/tree/
> > swagger-demo/traffic_ops/traffic_ops_golang/docs
> >
> > And the *asns.go*, *cdns.go*, *divisions.go*, *regions.go* and
> > *statuses.go*
> > structs in my branch here:
> > https://github.com/dewrich/incubator-trafficcontrol/tree/
> > swagger-demo/lib/go-tc
> >
> >
> > *TO Client Generated from Swagger*
> >
> > This new Golang package is only a sample of a TO client generated (based
> > upon the the code generated swagger.json
> >  > trafficcontrol/blob/swagger-demo/traffic_ops/traffic_ops_
> > golang/docs/swagger.json > dewrich/incubator-trafficcontrol/blob/swagger-
> > demo/traffic_ops/traffic_ops_golang/docs/swagger.json>>
> > )
> >
> > https://github.com/dewrich/incubator-trafficcontrol/tree/
> > swagger-demo/traffic_ops/traffic_ops_golang/toclient
> > https://github.com/dewrich/incubator-trafficcontrol/tree/
> > swagger-demo/traffic_ops/traffic_ops_golang/toclient/main.go
> >
> > The hope with tying the documentation closer to the code will help with
> > keeping the API docs up-to-date,

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC0

[Dave Neuman]

Hey Jeff,
I can take a look at that PR.
Thanks,
Dave

On Tue, Feb 13, 2018 at 4:15 PM, Jeff Elsloo  wrote:

> I just submitted the following PR to resolve the issues stemming from
> PR 1720: https://github.com/apache/incubator-trafficcontrol/pull/1877
> --
> Thanks,
> Jeff
>
>
> On Tue, Feb 13, 2018 at 3:25 PM, Jeff Elsloo  wrote:
> > -1 due to the following PR breaking the Traffic Router build:
> > https://github.com/apache/incubator-trafficcontrol/pull/1720
> >
> > I'm looking into the issue now and hope to have it resolved soon.
> > --
> > Thanks,
> > Jeff
> >
> >
> > On Tue, Feb 13, 2018 at 11:56 AM, Robert Butts  wrote:
> >> Hello All,
> >>
> >> I've prepared a release for v2.2.0-RC0
> >>
> >> The vote is open for at least 72 hours and passes if a majority of at
> least
> >> 3 +1 PPMC votes are cast.
> >>
> >> [ ] +1 Approve the release
> >>
> >> [ ] -1 Do not release this package because ...
> >>
> >> Changes since 2.1.0:
> >> https://github.com/apache/incubator-trafficcontrol/
> compare/RELEASE-2.1.0...RELEASE-2.2.0-RC0
> >>
> >> This corresponds to git:
> >>  Hash: 9730e9a25e9e665a0873d2f2fb04c97491e60131
> >>  Tag: RELEASE-2.2.0-RC0
> >>
> >> Which can be verified with the following: git tag -v RELEASE-2.2.0-RC0
> >>
> >> My code signing key is available here:
> >> http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F&op=vindex
> >>
> >> Make sure you refresh from a key server to get all relevant signatures.
> >>
> >> The source .tgz file, pgp signature (.asc signed with my key from
> >> above), md5 and sha1 checksums are provided here:
> >>
> >> https://dist.apache.org/repos/dist/dev/incubator/
> trafficcontrol/2.2.0/RC0/
> >>
> >> Thanks!
>

Re: Immutable DS CDN - resolving Riak/Postgres data coherency

[Dave Neuman]

I think I can get on board with not allowing a user to change the CDN.  If
you want to change the CDN you need to delete your DS and re-create it or
create a new DS with a different XML_ID and a regex that matches the first
DS.

We have gone back and forth several times on deleting the keys from riak
when you delete a DS.  Each time we decide not to make the change for one
reason or another.  The worry is that if you delete a DS and then decide
that it was a mistake you now have to generate a whole new certificate
which could cost real money.  I am not sure that use-case is common enough
to warrant us not deleting the certificates for a DS.  For now I am +1 on
deleting the certificates when a DS is deleted.

Thanks,
Dave

On Tue, Feb 13, 2018 at 12:14 PM, Nir Sopher  wrote:

>  Hi,
>
> I created a delivery service and later on realized it is in the wrong CDN.
> I then changed the CDN.
> The ssl-keys record in the riak kept referring to the old CDN, even if I
> generated new certificates. Traffic router was therefore unable to pull the
> certificate.
>
> See issue 1847
> 
>
> A fix to this issue can be done by changing the code so the record in the
> Riak is updated along with the DS update.
> However, this does not really make sense - if the CDN has changed, the
> domain usually changes as well and the certificate is no longer valid.
>
> Therefore, I suggest to entirely block DS CDN change [see
> https://github.com/apache/incubator-trafficcontrol/pull/1872]
> .
> Additionally, I added a PR for ssl-keys deletion up-on DS deletion, so
> deleting the DS and recreating it would not cause similar issues.
>
> Would appreciate community input for other alternatives.
>
> Thanks,
> Nir
>

Re: Connection leaks traffic stats -> influxdb

[Dave Neuman]

hmm, ok.  Can you try running that master version of Traffic Stats and let
me know if you still see the same issue?


On Mon, Feb 12, 2018 at 7:29 AM, Nir Sopher  wrote:

> Thanks Dave,
> I'm working with traffic stats 2.1.0 and influx 1.2.2. Tried also with
> influx 1.4.3 and found the same issues.
> OS: Centos 7.4-1708
> Nir
>
> On Mon, Feb 12, 2018 at 2:00 AM, Dave Neuman  wrote:
>
> > Hi Nir,
> > I have not seen this issue and I do have some setups with Traffic Stats
> and
> > InfluxDB on the same server.
> > A couple of questions:
> >   - What version of Traffic Stats are you running?
> >   - What version of InfluxDB are you running?
> >   - What version of OS are you running?
> >
> > Thanks,
> > Dave
> >
> >
> > On Sun, Feb 11, 2018 at 12:52 PM, Nir Sopher  wrote:
> >
> > > Hi,
> > >
> > > On my setup, traffic-stats is installed on the same server as the
> > influxdb
> > > server.
> > > We have noticed that the number of open sockets, from stats to influx,
> is
> > > constantly increasing,
> > > All connections are at state "ESTABLISHED".
> > >
> > > Did anyone encounter a similar issue?
> > > I'm familiar with https://issues.apache.org/jira/browse/TC-373 but
> > believe
> > > it is a different case.
> > >
> > > Thanks,
> > > Nir
> > >
> >
>

Re: Connection leaks traffic stats -> influxdb

[Dave Neuman]

Hi Nir,
I have not seen this issue and I do have some setups with Traffic Stats and
InfluxDB on the same server.
A couple of questions:
  - What version of Traffic Stats are you running?
  - What version of InfluxDB are you running?
  - What version of OS are you running?

Thanks,
Dave


On Sun, Feb 11, 2018 at 12:52 PM, Nir Sopher  wrote:

> Hi,
>
> On my setup, traffic-stats is installed on the same server as the influxdb
> server.
> We have noticed that the number of open sockets, from stats to influx, is
> constantly increasing,
> All connections are at state "ESTABLISHED".
>
> Did anyone encounter a similar issue?
> I'm familiar with https://issues.apache.org/jira/browse/TC-373 but believe
> it is a different case.
>
> Thanks,
> Nir
>

Re: [VOTE] CHANGELOG.md file (second try)

[Dave Neuman]

Hey Rawlin,
I think Steve was starting to work on one, so we will see what he says.
If he doesn't have one started, I think you can go ahead and create one.

Thanks,
Dave

On Wed, Feb 7, 2018 at 4:04 PM, Rawlin Peters 
wrote:

> Hey all,
>
> So it appears this vote passed in favor of adding a CHANGELOG.md file
> without having a changelog label in GitHub. Is anyone currently
> working on one?
>
> With the 2.2 release planned for 2/12/18, I'd like to at least put in
> some upgrade release notes about Per-Delivery-Service Routing Names.
> If no one has a CHANGELOG.md in progress, I'll take the liberty to
> start one and add those release notes in there (using
> https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md as an
> example template).
>
> -Rawlin
>
> On Wed, Jan 10, 2018 at 10:35 AM, Chris Lemmons 
> wrote:
> > [X] +1 to adding a changelog.MD file
> > [] -1 to adding a changelog.MD file
> >
> > That said, I'm only in favour of it if we're fastidious about
> > requiring changelog updates on every single PR. A PR should either
> > provide a reasonable changelog entry, or, in the body of the PR,
> > justify it's absence. A simple "This bugfix does not require a
> > changelog entry." is sufficient for trivial bugfixes. That's plenty
> > for a reviewer to quickly either agree or decide to request (or
> > provide) an entry.
> >
> > If we add the changelog file, we need to update the contributing file
> > to include the new guidelines.
> >
> > On Wed, Jan 10, 2018 at 9:14 AM, Jeremy Mitchell 
> wrote:
> >> Yes, I was about to mention milestones. Why not leverage Github
> milestones
> >> on issues/PRs? We talked about using milestones at the last TC summit to
> >> determine the scope of a release. Now is our chance to do that.
> >>
> >> Milestones can be applied to issues or PRs. I tend to create issues for
> >> everything I do, so I would put the milestone on the issue but others
> can
> >> simply put a milestone on their PR (if there is no related issue).
> Either
> >> way, it tags the items we want included in the changelog. And then the
> RM
> >> can build the changelog from the milestones. Easy peasy.
> >>
> >> Jeremy
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Jan 9, 2018 at 4:56 PM, Leif Hedstrom  wrote:
> >>
> >>>
> >>>
> >>> > On Jan 9, 2018, at 10:22 AM, Dave Neuman  wrote:
> >>> >
> >>> > Looks like this thread died over the holidays.  Let me try to bring
> it
> >>> back
> >>> > up before we cut a 2.2 branch.
> >>> > Can you please respond with *just* the following:
> >>> >
> >>> > [X] +1 to adding a changelog.MD file
> >>> > [] -1 to adding a changelog.MD file
> >>> >
> >>> > [] +1 to adding a changelog label in github
> >>> > [X] -1 to adding a changelog label in github
> >>> >
> >>>
> >>>
> >>> To add to the previous thread / thoughts. I feel reasonably strongly
> that
> >>> having a changelog label in Github is not useful. In the ATS
> community, we
> >>> can *barely* get people to set the Milestone properly, and I feel that
> the
> >>> Milestone is a much more important thing to keep accurate than anything
> >>> else. And, to be normalized, you don’t want to duplicate this info :-).
> >>>
> >>> So, what we do is have the RM be like a hawk over the Milestones, and
> then
> >>> run Phil’s fancy pants script to generate the ChangeLog from the
> Milestones
> >>> on all PRs closed.
> >>>
> >>> Cheers,
> >>>
> >>> — leif
> >>>
> >>> > Thanks,
> >>> > Dave
> >>> >
> >>> > On Fri, Dec 15, 2017 at 9:14 AM, Dewayne Richardson <
> dewr...@gmail.com>
> >>> > wrote:
> >>> >
> >>> >> +1 on the CHANGELOG.md as well, but I like having the changelog
> label
> >>> >> because it helps streamline it's creation.  I also think the labels
> are
> >>> >> valuable because they help summarize the parts of the repo that
> changed
> >>> and
> >>> >> keeps the concept closer to the repository (where the real change
> is).
> >>> >>
> >>> >> -Dew
> >>> >>
> >>> >> O

Re: ATS

[Dave Neuman]

Hi Satheesh,
Are you asking about the algorithm for Mid to Origin communication in a
multi site origin configuration?
thanks,
Dave

On Tue, Feb 6, 2018 at 7:08 AM, Satheeshkumar 
wrote:

> Hi,
>
> Which algorithms are you using traffic server apart from Round Robin
>
> Thanks
>
> Satheesh
>

Re: ATS Algorithm

[Dave Neuman]

Hi Satheesh,
Are you asking about the algorithm for Mid to Origin communication in a
multi site origin configuration?

On Thu, Feb 1, 2018 at 22:03 Satheeshkumar  wrote:

> Hi,
>
>
> Which algorithms are you using traffic server  apart from Round Robin
>
> Thanks
>
> Satheesh R
>

Re: TC 2.2 Release - Outstanding Issues

[Dave Neuman]

OK, so in that case I would still lobby that the current issue be moved to
2.3 because setting server.xml back to BIO does not fix the leak, it just
makes it less likely to happen to someone running the default
configuration.
I am ok with referencing that issue with the BIO PR, but the real fix will
not come until 2.3.


On Tue, Jan 30, 2018 at 11:33 AM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> His PR will update server.xml back to BIO
>
> —Eric
>
> > On Jan 30, 2018, at 12:03 PM, David Neuman 
> wrote:
> >
> > Jeff is planning to open a PR to actually fix the leak or to update the
> > server.xml to use the BIO connector?
> >
> > On Tue, Jan 30, 2018 at 9:39 AM, Eric Friedrich (efriedri) <
> > efrie...@cisco.com> wrote:
> >
> >> Thanks Dave-
> >>  I’d like to keep it as a must-have in 2.2. We had a severe issue in
> >> production with the NIO connection when deploying 2.1. Jeff M is
> planning
> >> to open a PR to fix it in the 2.2 release.
> >>
> >> I understand the issue will be moot after upgrading to Tomcat, but the
> >> current 2.1 release has crippling TR scale problems out of the box and
> I’d
> >> like to avoid that with 2.2 given how small and low risk the fix is
> >>
> >> —Eric
> >>
> >>> On Jan 29, 2018, at 5:36 PM, Dave Neuman  wrote:
> >>>
> >>> Thanks Rob,
> >>> I think `916 [TC-197] File descriptor leak caused by NIO protocol
> >>> connector` should be moved to 2.3.  This issue will be resolved with
> the
> >>> upgrade to Tomcat 8.5.x.
> >>> I don't think we should hold up the release for `1356 Step by Step
> >>> installation guide for new users`.  I think it can be moved to 2.3 as
> >>> well.
> >>> I took a look at the issues in 2.3 and I am fine with what's there
> >> staying
> >>> there.
> >>>
> >>> Thanks,
> >>> Dave
> >>>
> >>> On Mon, Jan 29, 2018 at 11:47 AM, Robert Butts  wrote:
> >>>
> >>>> There are no `major` bugs without milestones, now.
> >>>>
> >>>> Many issues without milestones were moved from 2.1 to 2.2, and I moved
> >> them
> >>>> to 2.3 indiscriminately. We should verify they're ok to not be in 2.2.
> >>>>
> >>>> Traffic Ops
> >>>> --
> >>>> 1026 [TC-191] Steering DS API should use standard response codes as
> >> defined
> >>>> in API guidelines
> >>>> 913 ort does not restart ATS when it should
> >>>> 911 Invalid DS regex causes nasty exception and unexpected results
> >> Github
> >>>> Issue #514
> >>>> 905 Inactive delivery services are added to remap.config
> >>>> 902 api/1.2/deliveryservices/:id/routing.json hangs when Traffic
> >> Router is
> >>>> unreachable
> >>>> 899 IPv6 Origin Configuration Not Allowed
> >>>> 898 Clone DS assignments button on Server times out
> >>>> 896 Traffic Router statistics are not aggregated
> >>>> 892 GenIso can't handle concurrent requests
> >>>> 891 error_url required in the url_sig file
> >>>> 890 Should use "dest_ip" instead of "dest_domain" in "parent.config"
> and
> >>>> "cache.config" when ofqdn is ip
> >>>> 888 cacheurl_qstring.conf file is not generated when qstringIgnore=1
> and
> >>>> location profile parameter is missing for edge/mid cache
> >>>> 885 Fix regression issues caused by TC-187
> >>>> 882 Deleting a DS thru the TO API should also delete all SSL keys (if
> >>>> applicable)
> >>>>
> >>>> Traffic Router
> >>>> --
> >>>> 914 Failed to restart tomcat in Traffic Router when failed to get SSL
> >> keys
> >>>> 907 Traffic Router requires at least one cache assigned to at least
> one
> >> DS
> >>>> for TLD zone generation
> >>>>
> >>>>
> >>>> There are 11 open issues in the 2.2 Milestone:
> >>>>
> >>>> Code
> >>>> --
> >>>> 1777 TO golang -- api/1.3/parameters?orderby=id produces an error
> >>>> 1620 API: Server API sets xmpp_id to null
> >>>> 1397 ORT tries to get ats_uid before installing trafficserver
> >>>> 1042 [TC-242] tm_user.username and role should be NOT NULL in the db
> >>>> 986 [TC-544] TR should de-dupe Reponse Headers when sending a Steering
> >>>> response.
> >>>> 916 [TC-197] File descriptor leak caused by NIO protocol connector
> >>>>
> >>>> Documentation
> >>>> --
> >>>> 1356 Step by Step installation guide for new users
> >>>> 1173 'Multi Site Origin Algorithm' is removed in delivery service UI
> in
> >>>> traffic_ops in TC-2.1
> >>>> 1135 Traffic Server administration docs are out of date
> >>>> 1130 cacheurl is deprecated in ATS 7.x
> >>>>
> >>>> Licensing
> >>>> --
> >>>> 1750 /traffic_ops/app/public/images/ contains non-free images
> >>>>
> >>>>
> >>>> Do we still feel like we can have all these fixed for a 2.2 Release
> in 2
> >>>> weeks? Say, Monday, February 12?
> >>>>
> >>>> Are there any cases moved to 2.3 that need to be moved back and done
> in
> >>>> 2.2?
> >>>>
> >>>> Thanks,
> >>>>
> >>
> >>
>
>

Re: TC 2.2 Release - Outstanding Issues

[Dave Neuman]

Thanks Rob,
I think `916 [TC-197] File descriptor leak caused by NIO protocol
connector` should be moved to 2.3.  This issue will be resolved with the
upgrade to Tomcat 8.5.x.
I don't think we should hold up the release for `1356 Step by Step
installation guide for new users`.  I think it can be moved to 2.3 as
well.
I took a look at the issues in 2.3 and I am fine with what's there staying
there.

Thanks,
Dave

On Mon, Jan 29, 2018 at 11:47 AM, Robert Butts  wrote:

> There are no `major` bugs without milestones, now.
>
> Many issues without milestones were moved from 2.1 to 2.2, and I moved them
> to 2.3 indiscriminately. We should verify they're ok to not be in 2.2.
>
> Traffic Ops
> --
> 1026 [TC-191] Steering DS API should use standard response codes as defined
> in API guidelines
> 913 ort does not restart ATS when it should
> 911 Invalid DS regex causes nasty exception and unexpected results Github
> Issue #514
> 905 Inactive delivery services are added to remap.config
> 902 api/1.2/deliveryservices/:id/routing.json hangs when Traffic Router is
> unreachable
> 899 IPv6 Origin Configuration Not Allowed
> 898 Clone DS assignments button on Server times out
> 896 Traffic Router statistics are not aggregated
> 892 GenIso can't handle concurrent requests
> 891 error_url required in the url_sig file
> 890 Should use "dest_ip" instead of "dest_domain" in "parent.config" and
> "cache.config" when ofqdn is ip
> 888 cacheurl_qstring.conf file is not generated when qstringIgnore=1 and
> location profile parameter is missing for edge/mid cache
> 885 Fix regression issues caused by TC-187
> 882 Deleting a DS thru the TO API should also delete all SSL keys (if
> applicable)
>
> Traffic Router
> --
> 914 Failed to restart tomcat in Traffic Router when failed to get SSL keys
> 907 Traffic Router requires at least one cache assigned to at least one DS
> for TLD zone generation
>
>
> There are 11 open issues in the 2.2 Milestone:
>
> Code
> --
> 1777 TO golang -- api/1.3/parameters?orderby=id produces an error
> 1620 API: Server API sets xmpp_id to null
> 1397 ORT tries to get ats_uid before installing trafficserver
> 1042 [TC-242] tm_user.username and role should be NOT NULL in the db
> 986 [TC-544] TR should de-dupe Reponse Headers when sending a Steering
> response.
> 916 [TC-197] File descriptor leak caused by NIO protocol connector
>
> Documentation
> --
> 1356 Step by Step installation guide for new users
> 1173 'Multi Site Origin Algorithm' is removed in delivery service UI in
> traffic_ops in TC-2.1
> 1135 Traffic Server administration docs are out of date
> 1130 cacheurl is deprecated in ATS 7.x
>
> Licensing
> --
> 1750 /traffic_ops/app/public/images/ contains non-free images
>
>
> Do we still feel like we can have all these fixed for a 2.2 Release in 2
> weeks? Say, Monday, February 12?
>
> Are there any cases moved to 2.3 that need to be moved back and done in
> 2.2?
>
> Thanks,
>

Re: Golang Proxy Validation Dependencies

[Dave Neuman]

+1

On Tue, Jan 16, 2018 at 12:58 Jan van Doorn  wrote:

> +1 on using libs.
>
> > On Jan 16, 2018, at 10:52 AM, Dan Kirkwood  wrote:
> >
> > +1 -- agree with Jeff -- the validation of the fields of
> > deliveryservice is something that is incomplete in the Perl
> > traffic_ops.
> >
> > These libraries make for concise code to do the validation so it will
> > be easier to extend without much extra code.   It will not be called
> > on every API function,  but only once on each POST/PUT which are a
> > small minority of calls.   It also need not be used in every case.
> > That, to me,  makes the reflection argument much less of a concern.
> >
> > I would like to see it go in sooner than Friday,  but won't argue that
> point..
> >
> > -dan
> >
> >
> > On Tue, Jan 16, 2018 at 10:10 AM, Dewayne Richardson 
> wrote:
> >> So, it's been a few days on this topic and I'd like to call a vote for
> the
> >> dependencies listed in this thread.  Please vote +1 or -1 by Noon
> Friday so
> >> that we can move forward the Golang Proxy development.
> >>
> >> Thanks,
> >>
> >> -Dew
> >>
> >> On Thu, Jan 11, 2018 at 10:53 AM, Jeff Elsloo 
> wrote:
> >>
> >>> I don't think we should assume anything about the performance just
> >>> because it uses reflection. Yes, traditionally reflection is
> >>> computationally expensive, however, when used properly the penalty can
> >>> be negligible. I don't think we have enough understanding of these
> >>> libraries to know whether there is a concerning performance penalty.
> >>>
> >>> As Dewayne said, create, update and delete actions represent a tiny
> >>> fraction of the overall requests into TO. Given that the majority of
> >>> these actions are performed by humans, I would be shocked if there was
> >>> a perceptible performance difference with the reflection based
> >>> validation in place. It's not like we're trying to validate enormous
> >>> and complex objects here; we're talking 20 fields or so for any given
> >>> post.
> >>>
> >>> I'm +1 on using validation libraries such as these even if they use
> >>> reflection, provided that we do not see dramatic changes in
> >>> performance. I think that's highly unlikely in this case.
> >>> --
> >>> Thanks,
> >>> Jeff
> >>>
> >>>
> >>> On Thu, Jan 11, 2018 at 10:07 AM, Chris Lemmons 
> >>> wrote:
>  True, but how many of those out-of-the-box checks are both useful and
>  relevantly complex?
> 
>  To me, the cool part of ozzo is the way it collects the output and
>  formats it. That's unfortunately also the computationally expensive
>  part.
> 
>  On Thu, Jan 11, 2018 at 9:49 AM, Dewayne Richardson <
> dewr...@gmail.com>
> >>> wrote:
> > Please keep in mind that we do not Create/Update/Delete very often in
> > Traffic Ops, so the performance penalty for Validation should be
> taken
> >>> into
> > consideration.  I also don't want to re-invent all of those
> >>> out-of-the-box
> > field level checks by hand when I can just use them from here:
> > https://github.com/asaskevich/govalidator#list-of-functions
> >
> > -Dew
> >
> > On Thu, Jan 11, 2018 at 9:24 AM, Chris Lemmons 
> >>> wrote:
> >
> >> I like the output style, but I'm a bit concerned on the performance
> >> front. ozzo appears to do all it's magic with heavy use of
> reflection,
> >> which is often a slow spot in go. Most places, it wouldn't matter
> >> much, but this will be called on every element of every API
> function,
> >> so a nod toward performance may be in order. Have we done some
> >> measurement to see whether this adds a relevant amount of overhead
> to
> >> the calls? Or are the calls still dominated by the DB lookup?
> >>
> >> Relatedly, is this a major advantage over something like this:
> >>
> >> if ds.Active == nil { errMsgs = append(errMsgs, `"active" must be
> >> provided`) }
> >>
> >> On Thu, Jan 11, 2018 at 8:49 AM, Dewayne Richardson <
> >>> dewr...@apache.org>
> >> wrote:
> >>> We've been moving along with more functionality in the Golang
> proxy,
> >> mostly
> >>> the Read's up until now, comparatively TO does much fewer
> >>> Create/Updates.
> >>> Our current task is to circle back and start implementing the
> >>> (C)reate,
> >>> (U)pdate, and (D)eletes.  One of the obvious needs for the this
> task
> >>> are
> >>> validation rules.  I've been doing research to figure out the
> >>> cleanest
> >> and
> >>> most maintainable way to rewrite the Perl validation rules in Go.
> >>>
> >>> TC Issue for tracking
> >>> https://github.com/apache/incubator-trafficcontrol/issues/1756
> >>>
> >>> These are the two dependencies I'd like to leverage and provide
> >>> feedback:
> >>>
> >>> Both are MIT Licenses
> >>> Uses normal programming constructs rather than error-prone struct
> >>> tags to
> >>> specify how data should be validated.
> >>> https://github.com/go-ozzo/oz

[DISCUSS] Traffic Control high level graduation plan

[Dave Neuman]

 Hey All,
A few of us have been informally discussing a plan for graduating from the
Apache Incubator and I thought now would be a good time to get the plan out
to a larger audience and solicit feedback.  We have been incubating for
about 18 months — since July 12, 2016 —  and it is my goal to see if we can
graduate by May 1, 2018 (in time to celebrate at our yet-to-be-planned
spring summit)!  I think this is a very attainable goal, and if we all
agree this is what we want to do, I will do everything I can to get us
there.

If you are interested in what Apache requires to graduate, you can read the
Incubator graduation guide[1] or take a look at the talk I did at our fall
summit[2].  It is a fairly straight forward and well defined process. There
aren’t many guides for knowing when you are ready to graduate, I think that
is something the project “feels” and decides that they want to do.
However, there are things that you must prove you can do as a project
before you can graduate.  All of the details are in the links above.

Here is the high level, informal plan that I think gets us to a May
graduation.  I know people tend to freak out when they see dates, but I
tried to keep them reasonable when I (mostly) made them up.

*TC -> Graduation*

   -  Release 2.1 through the IPMC and announced by 1/19
   -
  - The release was sent to the incubator about a week ago (1/2) and we
  have yet to receive any votes, hopefully that changes in the
next week with
  some help from our mentors.
   - Traffic Control 2.2 to IPMC vote by 3/1
   -
  - This release should remove our JSON.org dependency which I believe
  is the last dependency that is not compatible with Apache.
   - Project Vote for Graduation by 3/1
   - Update Incubation status page[3] and website checklist[4] by 3/30
   - Prepare Charter for graduation from incubator by 3/30
   - IPMC graduation vote requested by 4/1
   - Resolution to Apache board by 5/1


Obviously this plan is very high level, and it is intended to be, since we
don’t know what we don’t know yet.  I think the key to making this work is
to get our 2.1 and 2.2 releases through the IPMC without many, or any,
licensing issues.  This will hopefully give the IPMC some more confidence
in us as a project and help make the graduation process easier.

If you have any questions, comments, or concerns please let me know.  We
are a community and I want this to be a community decision that everyone
feels good about.

Thanks,
Dave

[1] http://incubator.apache.org/guides/graduation.html
[2] https://goo.gl/QiGekn
[3] http://incubator.apache.org/projects/trafficcontrol.html
[4] https://whimsy.apache.org/pods/project/trafficcontrol

Re: [VOTE] CHANGELOG.md file (second try)

[Dave Neuman]

Looks like this thread died over the holidays.  Let me try to bring it back
up before we cut a 2.2 branch.
Can you please respond with *just* the following:

[] +1 to adding a changelog.MD file
[] -1 to adding a changelog.MD file

[] +1 to adding a changelog label in github
[] -1 to adding a changelog label in github

Thanks,
Dave

On Fri, Dec 15, 2017 at 9:14 AM, Dewayne Richardson 
wrote:

> +1 on the CHANGELOG.md as well, but I like having the changelog label
> because it helps streamline it's creation.  I also think the labels are
> valuable because they help summarize the parts of the repo that changed and
> keeps the concept closer to the repository (where the real change is).
>
> -Dew
>
> On Thu, Dec 14, 2017 at 3:01 PM, Robert Butts 
> wrote:
>
> > +1. To clarify, I'm +1 on having the "changelog" label, to help whoever
> > manually goes thru and builds the CHANGELOG.md.
> >
> > But I agree with @neuman I don't think we can automate this. Titles are
> too
> > short, some changes need longer explanations and some don't, only a human
> > can figure out how important something is to users; a high priority bug
> fix
> > could still be low-impact, or vica-versa. Much as I dislike manual
> things,
> > this really needs human judgement. And we absolutely need a good
> Changelog
> > with each Release.
> >
> > On Thu, Dec 14, 2017 at 2:36 PM, Dave Neuman  wrote:
> >
> > > Thanks for putting that together Dewayne. I was just starting to do
> that
> > > myself when I saw it was already done.
> > > As a developer this is fine, I can see a list of PRs and click on each
> > one
> > > to see the whole conversation.  I can comb through them and get a
> general
> > > sense for what changed.
> > >
> > > However, as an operator and user of Traffic Control (which I mostly am
> > > these days) I am -1 for the following reasons:
> > > 1) only committers can assign labels to issues and pull requests.  This
> > > means that the committers need to be cognizant of the issues/PRs they
> are
> > > reviewing and apply the change log label;
> > > 2) the title of a PR only gives so much information about a change, if
> I
> > > want more information I have to click on each individual one
> > > 3) If I am not a developer, or someone who is very familiar with our
> > > project, it is hard for me to ascertain from this list which changes
> are
> > > super-important or have some operational considerations attached to
> them.
> > > These are the issues I really care about.
> > > 4) When I go to do an upgrade, it's a lot easier to copy/paste a nice
> > > bulleted list of what changed then it is to try to take a list of PRs
> and
> > > turn it into a high level list of what's important.
> > >
> > > We need a solution that gives someone what they need at a glance.
> > Something
> > > that can be copy/pasted out or easily linked to.  IMO not all of our
> > users
> > > are super technical or involved in the day to day so we shouldn't just
> > > point them at a list of PRs and say "figure it out"; we should make it
> > easy
> > > for them to figure out.
> > >
> > > I have seen lots of alternatives suggested to what Steve has proposed,
> > but
> > > I haven't seen anyone state why they don't like what Steve has
> > proposed?  I
> > > think what he is proposing is pretty standard across major Github
> > projects
> > > that I have seen.  I understand that we can introduce some additional
> > > inconvenience with having to manually write what your feature or bug
> fix
> > > does, and there could be some conflicts, but isn't it important to
> > clearly
> > > portray what has changed?  I don't think we need a changelog.md entry
> to
> > > every PR, in fact I hope we don't...we need a changelog.md entry any
> > time
> > > we add a new feature, any time we have some operational considerations
> > that
> > > need to be communicated, or any time that we fix a bug from a previous
> > > release.
> > >
> > >
> > > On Thu, Dec 14, 2017 at 2:02 PM, Jeremy Mitchell <
> mitchell...@gmail.com>
> > > wrote:
> > >
> > > > This label idea would require everyone to go back and find their PRs
> > that
> > > > were closed after Aug 4th (the date 2.1 branch was created) and
> attach
> > > the
> > > > 'change log' label and the 2.2 mile

Re: Move Docs to readthedocs.io ?

[Dave Neuman]

Sounds good to me, +1.

On Tue, Jan 2, 2018 at 12:23 PM, Jan van Doorn  wrote:

> I propose we move our docs to readthedocs - like :
> http://incubator-trafficcontrol.readthedocs.io/en/latest/ (this is setup
> w my clone).
>
> This will allow us to have multiple versions of docs online, do automatic
> updates of the released and latest docs and will get us the "Edit on
> Github" button that Ryan requested ( https://github.com/apache/incu
> bator-trafficcontrol/issues/1625 ).
>
>
> Thoughts?
>
>
> JvD
>
>

Re: Podling Report Reminder - January 2018

[Dave Neuman]

Hey All,
I have updated the podling report here:
https://wiki.apache.org/incubator/January2018

Please let me know if you see anything that may need some changes or
anything that I may have missed that you think we should add.

Thanks!
Dave

On Mon, Jan 1, 2018 at 9:19 AM,  wrote:

> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
>
> The board meeting is scheduled for Wed, 17 January 2018, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, January 03).
>
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
>
> --
>
> Your report should contain the following:
>
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> *   A list of the three most important issues to address in the move
> towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
>
> This should be appended to the Incubator Wiki page at:
>
> https://wiki.apache.org/incubator/January2018
>
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
>
> Mentors
> ---
>
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
>
> Incubator PMC
>

Re: Two different Delivery Services using the same host regexp: A suggested Traffic Monitor code change

[Dave Neuman]

Oren, you can find documentation on the Stats over HTTP plugin can be found
here:
https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/stats_over_http.en.html#admin-plugins-stats-over-http

On Sun, Dec 31, 2017 at 1:35 AM, Oren Shemesh  wrote:

> Thanks Ryan, Robert and Dave for your responses.
>
> Dave, can you send a pointer to any documentation/text available regarding
> 'Stats over HTTP' ?
>
> I believe I can consider the overall response to the change I am proposing
> as positive :-)
>
> Robert, from my experience I would like to avoid adding additional
> configurations to a system, in cases where the system can auto-detect the
> proper configuration.
> Any configuration added is another chance for someone making a mistake.
>
> With the proposal I have made, so configuration is needed: TM auto-detects
> the type of astats information (DS name / entire DS domain) based on a
> single 'if' statement which queries a single scalar value.
> This also means that, assuming my proposed code change is valid, there can
> be no performance issues.
>
> Also, I do not know what 'Stats over HTTP' is, but I hope it keeps the job
> of classifying Client HTTP transactions to a DS in the cache (ATS in our
> case), avoiding the need to re-classify it in TM.
>
> (Note: In my mind, the fact that TM currently does this job, based on a
> *single* hostName regex per DS, makes the entire feature of having multiple
> regexps per DS very limited in use. Which is a shame, based on the effort
> invested in the DB model, TO API, and TR code).
>
> Thanks a lot guys !
>
>
> On Sat, Dec 30, 2017 at 7:33 PM, Dave Neuman  wrote:
>
> > Hi Oren,
> > Sorry for the slow response, I think what you are proposing sounds
> > reasonable, so +1.  I would, however, like to make sure that we aren't
> > affecting the performance of TM too much in terms of both CPU usage (with
> > 1000+ caches) and time to poll all caches/aggregate statistics.
> >
> > Additionally, I don't think we should be adding new functionality to
> astats
> > at all. The plan is to move towards the Stats Over HTTP plugin in the
> > future, so we should focus on making Traffic Monitor do what we need it
> to
> > do now, and add new functionality to Stats over HTTP if it doesn't
> > currently exist.  I do think it would be nice to have Traffic Monitor
> > support some sort of canonical stats interface instead of
> > astats/stats_over_http, and I am sure there are several other features
> > would be nice to have as well, but I don't think we should be muddying
> the
> > waters with that right now.
> >
> >
> > On Wed, Dec 27, 2017 at 12:24 PM, Robert Butts  >
> > wrote:
> >
> > > I'd be +1 if we extend Astats/stats_over_http to have the DS name.
> > >
> > > It's easy to extend the Monitor to get the name from a field, if it's
> > > available. And it should be faster than the current method. But, Astats
> > > doesn't currently support it, and in fact, I don't believe ATS has a
> good
> > > way to associate an identifier (DS name) with a Remap Rule. Can anyone
> > > confirm?
> > >
> > > That said, if we're extending `stats_over_http`, I'd really like to see
> > it
> > > extended to serve CSV (ideally with the DS name in a field, as above),
> > when
> > > the request has an `Accept: text/csv` header. Astats only has a single
> > > level of JSON, and they're all numbers. So there's no reason to use
> JSON
> > > over CSV, and CSV is drastically simpler and faster to parse.
> Especially
> > if
> > > we break each `.` component of the stat into its own CSV field. The
> > Monitor
> > > is CPU-bound, so there's a good chance we'd see a noticeable
> performance
> > > improvement, which translates to a tangible poll time improvement.
> > >
> > > Also @orens if we can't reasonably extend ATS Astats, we can still
> > support
> > > your use case for your own cache, by having a separate code path in the
> > > Monitor for your "stats", and adding a "stats type" number or enum to
> the
> > > Server table (or ideally a new table for "cache servers", since it only
> > > applies to caches). So, the Monitor would look at that field (possibly
> > > adding it to `monitoring.json` or `CRConfig.json`), to determine how to
> > > parse a given server's stats.
> > >
> > > We've discussed a "stat version" field anyway, for different Asta

Re: Two different Delivery Services using the same host regexp: A suggested Traffic Monitor code change

[Dave Neuman]

Hi Oren,
Sorry for the slow response, I think what you are proposing sounds
reasonable, so +1.  I would, however, like to make sure that we aren't
affecting the performance of TM too much in terms of both CPU usage (with
1000+ caches) and time to poll all caches/aggregate statistics.

Additionally, I don't think we should be adding new functionality to astats
at all. The plan is to move towards the Stats Over HTTP plugin in the
future, so we should focus on making Traffic Monitor do what we need it to
do now, and add new functionality to Stats over HTTP if it doesn't
currently exist.  I do think it would be nice to have Traffic Monitor
support some sort of canonical stats interface instead of
astats/stats_over_http, and I am sure there are several other features
would be nice to have as well, but I don't think we should be muddying the
waters with that right now.


On Wed, Dec 27, 2017 at 12:24 PM, Robert Butts 
wrote:

> I'd be +1 if we extend Astats/stats_over_http to have the DS name.
>
> It's easy to extend the Monitor to get the name from a field, if it's
> available. And it should be faster than the current method. But, Astats
> doesn't currently support it, and in fact, I don't believe ATS has a good
> way to associate an identifier (DS name) with a Remap Rule. Can anyone
> confirm?
>
> That said, if we're extending `stats_over_http`, I'd really like to see it
> extended to serve CSV (ideally with the DS name in a field, as above), when
> the request has an `Accept: text/csv` header. Astats only has a single
> level of JSON, and they're all numbers. So there's no reason to use JSON
> over CSV, and CSV is drastically simpler and faster to parse. Especially if
> we break each `.` component of the stat into its own CSV field. The Monitor
> is CPU-bound, so there's a good chance we'd see a noticeable performance
> improvement, which translates to a tangible poll time improvement.
>
> Also @orens if we can't reasonably extend ATS Astats, we can still support
> your use case for your own cache, by having a separate code path in the
> Monitor for your "stats", and adding a "stats type" number or enum to the
> Server table (or ideally a new table for "cache servers", since it only
> applies to caches). So, the Monitor would look at that field (possibly
> adding it to `monitoring.json` or `CRConfig.json`), to determine how to
> parse a given server's stats.
>
> We've discussed a "stat version" field anyway, for different Astats
> versions. For example, we're looking into combining the System stats into
> the Ats key, and we'd also like to be able to experiment with different
> formats (CSV, Protobuf, etc). I think it's a good feature for the CDN in
> general, to make stat polling more flexible.
>
>
> On Wed, Dec 27, 2017 at 12:21 PM, Durfey, Ryan 
> wrote:
>
> > Oren,
> >
> > This is a great conversation to have. I can’t speak to the best solution,
> > but allowing our servers to have a single SSL cert that could be shared
> > across delivery services would save us a lot of time, money, and
> > operational resources. From a product perspective this would be highly
> > beneficial to the platform especially since all services are eventually
> > moving to SSL.
> >
> > Key Benefits:
> >
> >   1.  Instant Service Builds: All new services could use SSL immediately,
> > no 2-3 business day delays in ordering SSL certs.
> >  *   This gets us a step closer to instant SSL service builds without
> > the need to implement something like “letsencrypt”.
> >   2.  Operations Load: Reducing the management of a constant flow of
> > orders and renewals for SSL certs would save operations resources and
> time.
> >   3.  Cost Reduction: A reduction in SSL certs equates to reduction in
> > purchase and renewal costs.
> >
> >
> >
> > Ryan DurfeyM | 303-524-5099
> > CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com > cdn_supp...@comcast.com>
> >
> >
> > From: Oren Shemesh 
> > Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> > dev@trafficcontrol.incubator.apache.org>
> > Date: Wednesday, December 27, 2017 at 2:49 AM
> > To: "dev@trafficcontrol.incubator.apache.org" <
> > dev@trafficcontrol.incubator.apache.org>
> > Subject: Two different Delivery Services using the same host regexp: A
> > suggested Traffic Monitor code change
> >
> > Hi TC Dev people,
> >
> > We would like to avoid having to issue a specific SSL certificate for
> every
> > DS, as is needed today.
> >
> > (Reminder: Every DS needs a separate certificate because The domains used
> > by the DS are tr.. and
> > .., and wild-card certs support only a
> > single *, so every cert is issued to *.., which
> makes
> > it DS-specific).
> >
> > When configuring two different DSes to use the same host regexp, and
> > configuring additional path regexps to differentiate between them, it is
> > possible to overcome this issue.
> >
> > For example: DS 'my-ds1' can have host regexp .*\.my-ds\..* , and path
> > regexp /ds1/.* (Both with order 0), and DS 'my

Re: Podling Report Reminder - January 2018

[Dave Neuman]

Oh man, by 1/3!  I’ll see what I can do.  Hopefully we can get 2.1 over to
the IPMC before then.

On Sat, Dec 23, 2017 at 15:49  wrote:

> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
>
> The board meeting is scheduled for Wed, 17 January 2018, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, January 03).
>
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
>
> --
>
> Your report should contain the following:
>
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> *   A list of the three most important issues to address in the move
> towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
>
> This should be appended to the Incubator Wiki page at:
>
> https://wiki.apache.org/incubator/January2018
>
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
>
> Mentors
> ---
>
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
>
> Incubator PMC
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC3

[Dave Neuman]

+1

On Wed, Dec 20, 2017 at 8:33 AM, Hank Beatty  wrote:

> Hello All,
>
> I've prepared a release for v2.1.0-RC3
>
> The vote is open for at least 72 hours and passes if a majority of at
> least 3 +1 PPMC votes are cast.
>
> [ ] +1 Approve the release
>
> [ ] -1 Do not release this package because ...
>
> Changes since 2.0.0:
> https://github.com/apache/incubator-trafficcontrol/compare/
> 2.0.x...RELEASE-2.1.0-RC3
>
> This corresponds to git:
>   Hash: 1dcd512f7e2b4898b090837cd3f260e453896e32
>   Tag: RELEASE-2.1.0-RC3
>
> Which can be verified with the following: git tag -v RELEASE-2.1.0-RC3
>
> My code signing key is available here:
> https://pgp.mit.edu/pks/lookup?op=get&search=0x920152B94E0CC77C
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), md5 and sha512 checksums are provided here:
>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.1.0/RC3
>
> The new proposed download page can be found here:
>
> https://trafficcontrol.incubator.apache.org/downloads/index-new.html
>
> Thanks!
>

Re: Remove file with invalid license

[Dave Neuman]

I merged it, you need to do a backport to 2.1 as well.

On Tue, Dec 19, 2017 at 9:16 AM, Robert Butts 
wrote:

> PR updating the license:
> https://github.com/apache/incubator-trafficcontrol/pull/1681
>
> On Tue, Dec 19, 2017 at 9:13 AM, Chris Lemmons  wrote:
>
> > https://github.com/danielmiessler/SecLists is now licensed MIT.
> > Thanks, Eric, for talking to Daniel Miessler for us and getting this
> > taken care of!
> >
> > On Mon, Dec 18, 2017 at 1:56 PM, Chris Lemmons 
> wrote:
> > > Excellent, Eric. That neatly cleans up the problem. I do think we
> > > should merge my PR (1677), regardless, if for no other reason than to
> > > honour the authors' attribution request.
> > >
> > > On Mon, Dec 18, 2017 at 1:47 PM, Eric Friedrich (efriedri)
> > >  wrote:
> > >> I emailed the owner of the password file earlier today and he agreed
> to
> > change or dual-license the project to MIT.
> > >>
> > >> —Eric
> > >>
> > >>> On Dec 18, 2017, at 3:40 PM, Phil Sorber  wrote:
> > >>>
> > >>> Rob,
> > >>>
> > >>> Just because we remove it for now doesn't mean we have to leave it
> out
> > >>> forever. I encourage you to contribute to the thread on the legal
> > mailing
> > >>> list to make your case or at least get an understanding of their
> > >>> requirements. The ASF does tend to lean toward conservative
> > interpretations.
> > >>>
> > >>> Thanks.
> > >>>
> > >>> On Mon, Dec 18, 2017 at 12:08 PM Robert Butts <
> > robert.o.bu...@gmail.com>
> > >>> wrote:
> > >>>
> >  That's correct. No RPM, unfortunately. License is here:
> >  https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project.
> > 
> >  -1 on downloading during rpmbuild, or especially postinstall. Both
> > pose a
> >  security risk. Moreover, it makes our build or install dependent on
> > the
> >  internet and a particular website. Neither building nor installing
> > should
> >  require either internet or a particular website; we should be
> working
> > to
> >  get away from that, not towards it.
> > 
> >  I'd prefer to find something Apache is ok with vendoring, if we have
> > to.
> >  Though, ideally we'd keep this one, Daniel Miessler is a well-known
> > name in
> >  the security community.
> > 
> > 
> >  On Mon, Dec 18, 2017 at 11:51 AM, Dan Kirkwood 
> > wrote:
> > 
> > > Thanks,  Eric..Then it's possible we could download it during
> > > rpmbuild or postinstall.
> > >
> > > On Mon, Dec 18, 2017 at 11:40 AM, Eric Friedrich (efriedri)
> > >  wrote:
> > >> It can be downloaded from Github.
> > >>
> > >> I think this is the file (Rob correct me if I picked the wrong
> >  variant):
> > > https://github.com/danielmiessler/SecLists/blob/
> > > master/Passwords/10_million_password_list_top_10.txt
> > >>
> > >> —Eric
> > >>
> > >> On Dec 18, 2017, at 1:38 PM, Dan Kirkwood  >  >  dang
> > > o...@gmail.com>> wrote:
> > >>
> > >> Rob,   is there a specific download location for this file?   I
> see
> > it
> > >> referenced as "Projects/OWASP SecLists Project",  but didn't find
> it
> > >> with a quick search.   Is it possible it's provided by an rpm we
> > could
> > >> list as a dependency rather than including in our source?
> > >>
> > >> -dan
> > >>
> > >> On Mon, Dec 18, 2017 at 11:11 AM, Robert Butts <
> >  robert.o.bu...@gmail.com
> > > > wrote:
> > >> I'd really like to keep this, or replace it with a similar file
> from
> > >> another source. Which I'd be willing to investigate, if necessary.
> > >>
> > >> Having a good blacklist of most-common passwords specifically puts
> > > Traffic
> > >> Ops in compliance with NIST SP 800-63B.
> > >>
> > >> I also don't understand the objections, the Apache Legal FAQ
> >  specifically
> > >> says CC-SA is permissible, and doesn't say anything about being
> > limited
> > > to
> > >> binary (which would be odd, CC is designed for text, not binary).
> > >> https://www.apache.org/legal/resolved.html#cc-sa
> > >>
> > >> I'd vote we wait for the legal resolution, or find a suitable
> > > replacement,
> > >> in order to remain in NIST compliance.
> > >>
> > >>
> > >> On Mon, Dec 18, 2017 at 10:55 AM, David Neuman <
> >  david.neuma...@gmail.com
> > >>
> > >> wrote:
> > >>
> > >> Hey all,
> > >> I don't know if you have been following the release 2.1 thread on
> > the
> > >> incubator list [1] , but we have been given a -1 vote by the IPMC
> > for
> > >> having a file in our release [2] that has an incompatible license.
> >  There
> > >> is some debate about the license, and we have reached out to Legal
> > for
> > > more
> > >> information [3] (thanks Eric!), but we haven't heard back from
> legal
> >  yet.
> > >> Instead of waiting for legal to get back to us, I would lik

Re: Remove file with invalid license

[Dave Neuman]

I personally don't want to see us hold up this release any longer,
especially for something like this.  If folks really want to use this file,
it's easy enough to have puppet put the file in place and use it in your
own Traffic Control installation.  We can add documentation suggesting as
much as well.  Rob, if you think you can find a suitable replacement in a
decent timeframe then be my guest.  Otherwise, I think we should replace
the file with a blank file (or create our own version) and move on.
If legal comes back and decides the file is ok, we can re-introduce it in
the 2.2 release.

--Dave

On Mon, Dec 18, 2017 at 12:08 PM, Robert Butts 
wrote:

> That's correct. No RPM, unfortunately. License is here:
> https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project.
>
> -1 on downloading during rpmbuild, or especially postinstall. Both pose a
> security risk. Moreover, it makes our build or install dependent on the
> internet and a particular website. Neither building nor installing should
> require either internet or a particular website; we should be working to
> get away from that, not towards it.
>
> I'd prefer to find something Apache is ok with vendoring, if we have to.
> Though, ideally we'd keep this one, Daniel Miessler is a well-known name in
> the security community.
>
>
> On Mon, Dec 18, 2017 at 11:51 AM, Dan Kirkwood  wrote:
>
> > Thanks,  Eric..Then it's possible we could download it during
> > rpmbuild or postinstall.
> >
> > On Mon, Dec 18, 2017 at 11:40 AM, Eric Friedrich (efriedri)
> >  wrote:
> > > It can be downloaded from Github.
> > >
> > > I think this is the file (Rob correct me if I picked the wrong
> variant):
> > https://github.com/danielmiessler/SecLists/blob/
> > master/Passwords/10_million_password_list_top_10.txt
> > >
> > > —Eric
> > >
> > > On Dec 18, 2017, at 1:38 PM, Dan Kirkwood  dang
> > o...@gmail.com>> wrote:
> > >
> > > Rob,   is there a specific download location for this file?   I see it
> > > referenced as "Projects/OWASP SecLists Project",  but didn't find it
> > > with a quick search.   Is it possible it's provided by an rpm we could
> > > list as a dependency rather than including in our source?
> > >
> > > -dan
> > >
> > > On Mon, Dec 18, 2017 at 11:11 AM, Robert Butts <
> robert.o.bu...@gmail.com
> > > wrote:
> > > I'd really like to keep this, or replace it with a similar file from
> > > another source. Which I'd be willing to investigate, if necessary.
> > >
> > > Having a good blacklist of most-common passwords specifically puts
> > Traffic
> > > Ops in compliance with NIST SP 800-63B.
> > >
> > > I also don't understand the objections, the Apache Legal FAQ
> specifically
> > > says CC-SA is permissible, and doesn't say anything about being limited
> > to
> > > binary (which would be odd, CC is designed for text, not binary).
> > > https://www.apache.org/legal/resolved.html#cc-sa
> > >
> > > I'd vote we wait for the legal resolution, or find a suitable
> > replacement,
> > > in order to remain in NIST compliance.
> > >
> > >
> > > On Mon, Dec 18, 2017 at 10:55 AM, David Neuman <
> david.neuma...@gmail.com
> > >
> > > wrote:
> > >
> > > Hey all,
> > > I don't know if you have been following the release 2.1 thread on the
> > > incubator list [1] , but we have been given a -1 vote by the IPMC for
> > > having a file in our release [2] that has an incompatible license.
> There
> > > is some debate about the license, and we have reached out to Legal for
> > more
> > > information [3] (thanks Eric!), but we haven't heard back from legal
> yet.
> > > Instead of waiting for legal to get back to us, I would like to propose
> > > that we instead remove this file from our release.  The file in
> question
> > is
> > > just a list of weak passwords and I feel like we can easily include a
> > blank
> > > file, or a file with a couple passwords that we generate, and
> individual
> > > installs of Traffic Control can replace this file as they see fit.
> This
> > > will
> > > remove issue of having an incompatible license in our release and
> should
> > > also not require us to do a code change.  The downside of removing this
> > > file is that we will need to create another 2.1 release candidate and
> go
> > > through the vote process again.  I would really like to see us get 2.1
> > > released before the end of the year, and at this point our chances are
> > > looking pretty slim.  So, does anyone object to removing this file from
> > our
> > > release?  If not, I will put an issue into github, remove the file, and
> > > back port the change so that we can get another 2.1 release candidate
> > out.
> > >
> > > Thanks,
> > > Dave
> > >
> > >
> > > [1]
> > > https://lists.apache.org/thread.html/c211f049e3d68af90196c30f6b6d31
> > > a67b3072029dea1efe7d35c9dc@%3Cdev.trafficcontrol.apache.org%3E
> > > [2]
> > > apache-trafficcontrol-2.1.0-incubating/traffic_ops/app/
> > > conf/invalid_passwords.txt
> > > [3] https://issues.apa

Re: [VOTE] CHANGELOG.md file (second try)

[Dave Neuman]

Thanks for putting that together Dewayne. I was just starting to do that
myself when I saw it was already done.
As a developer this is fine, I can see a list of PRs and click on each one
to see the whole conversation.  I can comb through them and get a general
sense for what changed.

However, as an operator and user of Traffic Control (which I mostly am
these days) I am -1 for the following reasons:
1) only committers can assign labels to issues and pull requests.  This
means that the committers need to be cognizant of the issues/PRs they are
reviewing and apply the change log label;
2) the title of a PR only gives so much information about a change, if I
want more information I have to click on each individual one
3) If I am not a developer, or someone who is very familiar with our
project, it is hard for me to ascertain from this list which changes are
super-important or have some operational considerations attached to them.
These are the issues I really care about.
4) When I go to do an upgrade, it's a lot easier to copy/paste a nice
bulleted list of what changed then it is to try to take a list of PRs and
turn it into a high level list of what's important.

We need a solution that gives someone what they need at a glance. Something
that can be copy/pasted out or easily linked to.  IMO not all of our users
are super technical or involved in the day to day so we shouldn't just
point them at a list of PRs and say "figure it out"; we should make it easy
for them to figure out.

I have seen lots of alternatives suggested to what Steve has proposed, but
I haven't seen anyone state why they don't like what Steve has proposed?  I
think what he is proposing is pretty standard across major Github projects
that I have seen.  I understand that we can introduce some additional
inconvenience with having to manually write what your feature or bug fix
does, and there could be some conflicts, but isn't it important to clearly
portray what has changed?  I don't think we need a changelog.md entry to
every PR, in fact I hope we don't...we need a changelog.md entry any time
we add a new feature, any time we have some operational considerations that
need to be communicated, or any time that we fix a bug from a previous
release.


On Thu, Dec 14, 2017 at 2:02 PM, Jeremy Mitchell 
wrote:

> This label idea would require everyone to go back and find their PRs that
> were closed after Aug 4th (the date 2.1 branch was created) and attach the
> 'change log' label and the 2.2 milestone to the appropriate ones, right?
> And then that link dew provide would be an accurate picture of what has
> changed between 21. and 2.2...
>
> of course, ignore PRs that don't affect the "interface" like "license
> changes", right?
>
> i like the idea...
>
> On Thu, Dec 14, 2017 at 1:59 PM, Dewayne Richardson 
> wrote:
>
> > As a POC for the Change Log label follow this link:
> >
> > https://github.com/apache/incubator-trafficcontrol/
> > pulls?q=is%3Apr+is%3Aclosed+label%3A%22change+log%22+milestone%3A2.2.0
> >
> > -Dew
> >
> > On Thu, Dec 14, 2017 at 10:48 AM, Gelinas, Derek <
> > derek_geli...@comcast.com>
> > wrote:
> >
> > > I'm +1 for the label as well.
> > >
> > > > On Dec 14, 2017, at 12:29 PM, Robert Butts  >
> > > wrote:
> > > >
> > > > +1 on a "changelog" label. Seems like that would make it a lot easier
> > for
> > > > the person writing it up. Easier to skip things like code maintenance
> > > that
> > > > have no interface effect.
> > > >
> > > > On Thu, Dec 14, 2017 at 10:14 AM, Dewayne Richardson <
> > dewr...@gmail.com>
> > > > wrote:
> > > >
> > > >> Another idea would be to include a new CHANGELOG label that you
> could
> > > tack
> > > >> onto specific PR's that you wanted to be included (as well as
> grouped
> > > >> within Milestones) as the high level features that went into the
> > > release.
> > > >> As for the gotchas, I think those should be Github issues because to
> > me
> > > >> those were bugs.
> > > >>
> > > >> -Dew
> > > >>
> > > >> On Thu, Dec 14, 2017 at 10:01 AM, Jeremy Mitchell <
> > > mitchell...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> I agree. Very readable. I also like the idea of a either creating a
> > > >>> CHANGELOG.md for each component...or one CHANGELOG.md with sections
> > for
> > > >>> each component.
> > > >>>
> > > >>

Re: [VOTE] CHANGELOG.md file (second try)

[Dave Neuman]

Have you taken a look at some Changelogs of other github projects?  Here
are a few from other projects we use in Traffic Control:
- Docker Compose: https://github.com/docker/compose/blob/master/CHANGELOG.md
- InfluxDB: https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md
- Grafana: https://github.com/grafana/grafana/blob/master/CHANGELOG.md
- Ansible: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md

See how easy to read those are and how they provide a lot of information
without having to wade through hundreds of issues and pull requests?  Some
of them also have links to issues for new features, as well as bug fixes
that are in the current release.  I think all of them are easy to read and
can give a user a quick overview of what is in the new release. I think
it's fine to add a link to all the issues if we want, but I think
ultimately we want to create something like what I have linked to above.
We might also want to break out our CHANGELOG.md by component to provide
even more readability.

I know our first inclination is to try to automate everything, but
sometimes it makes sense to do things manually so that you can create a
better output.



On Thu, Dec 14, 2017 at 8:55 AM, Jeremy Mitchell 
wrote:

> What if CHANGLOG.md includes 2 things:
>
> 1. a link to 2.2 issues (i.e.
> https://github.com/apache/incubator-trafficcontrol/
> issues?q=is%3Aopen+is%3Aissue+milestone%3A2.2.0
> 2. a bulleted list of 2.2 gotchas (i.e. Traffic Ops Golang doesn't connect
> to a Riak with self-signed certificates; Riak security grant needs updated;
> upgrade param needed for ds routing names, etc, etc...)
>
> But again this requires everyone to create issues (with a milestone) in
> which one or more PR's can be attached to.
>
> Dave, you said "If you are developing a new feature you could easily end up
> with 5 or more PRs"
>
> So in this case, I'd expect 1 issue and 5 PR's linked to that 1 issue...
>
> Jeremy
>
> On Thu, Dec 14, 2017 at 8:40 AM, Dave Neuman  wrote:
>
> > I think it's fine to include all of our PRs and issues in a github
> > milestone, and we should do that, but I don't think that we want to
> include
> > every single PR in our changelog.  When we have tried that in the past we
> > have realized that it gets to be so much information that it's not
> useful.
> > A good example of why is a new feature. If you are developing a new
> feature
> > you could easily end up with 5 or more PRs: one to introduce the feature,
> > one to add some more functionality, several to fix bugs with it, etc.
> > Instead of having a line in the changelog for each one of those PRs, we
> > should just have one line that says "introduced feature X" with maybe a
> > blurb about what it is and any release notes that an operator would need
> to
> > know.  This way the file in concise and easy to understand by anyone
> > wanting to use a new version of our product.  I think it's also important
> > to include what bug fixes (since the previous release) that we have
> fixed.
> > Those are the reasons why I tend to lean towards a manual changelog.  It
> > gives us the ability to control how much information goes into the
> > changelog and the flexibility to make sure it is useful.
> >
> > On Thu, Dec 14, 2017 at 8:13 AM, Jeremy Mitchell 
> > wrote:
> >
> > > Why not leverage Github issues/milestones to determine the scope of
> each
> > > release? Per our CONTRIBUTING.md
> > > <https://github.com/apache/incubator-trafficcontrol/blob/
> > > master/CONTRIBUTING.md>
> > > :
> > >
> > > "If you have improvements (enhancements or bug fixes) for Traffic
> > Control,
> > > start by creating an issue
> > > <https://github.com/apache/incubator-trafficcontrol/issues>..."
> > >
> > > That implies that all PR's should be mapped to an issue although we do
> > not
> > > enforce this but if we did it would be easy to put each issue into a
> > > milestone (2.2 for example) and then pull a github report at any time.
> > >
> > > Orrather than creating an issue, put a good title/description on
> your
> > > PR and then the PR can be assigned to the milestone instead.
> > >
> > > It just seems like that's what milestones are for so why not use them?
> > >
> > > Jeremy
> > >
> > >
> > >
> > > On Wed, Dec 13, 2017 at 3:28 PM, Dave Neuman 
> wrote:
> > >
> > > > I am +1 on this approach, I know it's manual and there could be
> > conflicts
> > > > and it's a bit o

Re: [VOTE] CHANGELOG.md file (second try)

[Dave Neuman]

I think it's fine to include all of our PRs and issues in a github
milestone, and we should do that, but I don't think that we want to include
every single PR in our changelog.  When we have tried that in the past we
have realized that it gets to be so much information that it's not useful.
A good example of why is a new feature. If you are developing a new feature
you could easily end up with 5 or more PRs: one to introduce the feature,
one to add some more functionality, several to fix bugs with it, etc.
Instead of having a line in the changelog for each one of those PRs, we
should just have one line that says "introduced feature X" with maybe a
blurb about what it is and any release notes that an operator would need to
know.  This way the file in concise and easy to understand by anyone
wanting to use a new version of our product.  I think it's also important
to include what bug fixes (since the previous release) that we have fixed.
Those are the reasons why I tend to lean towards a manual changelog.  It
gives us the ability to control how much information goes into the
changelog and the flexibility to make sure it is useful.

On Thu, Dec 14, 2017 at 8:13 AM, Jeremy Mitchell 
wrote:

> Why not leverage Github issues/milestones to determine the scope of each
> release? Per our CONTRIBUTING.md
> <https://github.com/apache/incubator-trafficcontrol/blob/
> master/CONTRIBUTING.md>
> :
>
> "If you have improvements (enhancements or bug fixes) for Traffic Control,
> start by creating an issue
> <https://github.com/apache/incubator-trafficcontrol/issues>..."
>
> That implies that all PR's should be mapped to an issue although we do not
> enforce this but if we did it would be easy to put each issue into a
> milestone (2.2 for example) and then pull a github report at any time.
>
> Orrather than creating an issue, put a good title/description on your
> PR and then the PR can be assigned to the milestone instead.
>
> It just seems like that's what milestones are for so why not use them?
>
> Jeremy
>
>
>
> On Wed, Dec 13, 2017 at 3:28 PM, Dave Neuman  wrote:
>
> > I am +1 on this approach, I know it's manual and there could be conflicts
> > and it's a bit of a PITA, but I think it actually has some benefits in
> that
> > a human can actually enter in important release notes that are readable
> and
> > make sense.
> > That being said if someone is willing to make an automated approach work,
> > that allows us to keep track of changes at a reasonable level (not per
> > commit, not necessarily even per PR), then I could be +1 on that as well.
> > I would need to someone volunteer to make it work before I give my +1
> > though.
> > Either way, we REALLY need a changelog that is updated regularly with
> > important information.
> >
> > --Dave
> >
> > On Wed, Dec 13, 2017 at 3:00 PM, Steve Malenfant 
> > wrote:
> >
> > > Hey All,
> > >
> > > There has been a vote on not maintaining a CHANGELOG file in the past
> and
> > > seems like we leaned toward an automated process. I believe none of
> them
> > > had happened (please correct me if not).
> > >
> > > I have been upgrading Traffic Control from 2.1 to 2.2 this week and
> found
> > > numerous gotchas.
> > >
> > > Some examples of things I ran into and luckily I was able to get good
> > > support from the Slack channels. Here is a few example of possible
> > breaking
> > > changes :
> > >
> > > - Delivery Service prefixes disappeared after upgrade, was not handled
> in
> > > postinstall (requires special attention, this was on this forum and
> well
> > > documented on the mailing list)
> > > - Traffic Ops Golang doesn't connect to a Riak with self-signed
> > > certificates
> > > - Riak security grant needs updated
> > > - cdn.conf configuration change
> > > - Traffic Portal required for new features (URI Signing)
> > > - cachekey plugin instead of cacheurl
> > >
> > > There was great enhancements made in 2.2 needs to be noticed by current
> > and
> > > new users.  If we are looking to get more engagement, that's probably
> the
> > > #1 thing to do. I usually go and read about all the other components
> > which
> > > we use around the Traffic Control CDN (Influx, Elastic, Grafana,
> etc...)
> > >
> > > So let me re-quote what Dave has sent and ask the same question again.
> > >
> > > ==
> > > Hey All,
> > > One thing we discussed at the meetup was the addition of a 

Re: [VOTE] CHANGELOG.md file (second try)

[Dave Neuman]

I am +1 on this approach, I know it's manual and there could be conflicts
and it's a bit of a PITA, but I think it actually has some benefits in that
a human can actually enter in important release notes that are readable and
make sense.
That being said if someone is willing to make an automated approach work,
that allows us to keep track of changes at a reasonable level (not per
commit, not necessarily even per PR), then I could be +1 on that as well.
I would need to someone volunteer to make it work before I give my +1
though.
Either way, we REALLY need a changelog that is updated regularly with
important information.

--Dave

On Wed, Dec 13, 2017 at 3:00 PM, Steve Malenfant 
wrote:

> Hey All,
>
> There has been a vote on not maintaining a CHANGELOG file in the past and
> seems like we leaned toward an automated process. I believe none of them
> had happened (please correct me if not).
>
> I have been upgrading Traffic Control from 2.1 to 2.2 this week and found
> numerous gotchas.
>
> Some examples of things I ran into and luckily I was able to get good
> support from the Slack channels. Here is a few example of possible breaking
> changes :
>
> - Delivery Service prefixes disappeared after upgrade, was not handled in
> postinstall (requires special attention, this was on this forum and well
> documented on the mailing list)
> - Traffic Ops Golang doesn't connect to a Riak with self-signed
> certificates
> - Riak security grant needs updated
> - cdn.conf configuration change
> - Traffic Portal required for new features (URI Signing)
> - cachekey plugin instead of cacheurl
>
> There was great enhancements made in 2.2 needs to be noticed by current and
> new users.  If we are looking to get more engagement, that's probably the
> #1 thing to do. I usually go and read about all the other components which
> we use around the Traffic Control CDN (Influx, Elastic, Grafana, etc...)
>
> So let me re-quote what Dave has sent and ask the same question again.
>
> ==
> Hey All,
> One thing we discussed at the meetup was the addition of a CHANGELOG.md
> file to the project.   This file will contain changes that are made to the
> project including bug fixes and new features. (e.g.
> https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md).  Adding
> this file means that we will now require each PR to contain an update to
> the CHANGELOG.md file, and our documentation will need to be updated
> accordingly.
> I thought it would be good to open a vote for adding this file, and if it
> passes, I will update the documentation and add a CHANGELOG.md file.
>
> Thanks,
> Dave
> ==
>
> I'm a +1 on CHANGELOG, but I'm not heavy creating PRs which kind influence
> my vote.
>
> Steve
>

Re: Changing max_dns_answers default

[Dave Neuman]

Hey Dylan,
I think since we currently default to 0 (all) and we don't want to
re-invent the wheel right now, I think 5 sounds like a reasonable default.

Thanks,
Dave

On Tue, Dec 5, 2017 at 8:21 AM, Durfey, Ryan 
wrote:

> Not sure if EDNS(0) extensions would make a difference here.
>
> The real issue for caching is balancing load across many caches while
> restricting content to as few caches as possible to maintain cache
> efficiency.  Too few DNS answers risks load piling up on a few caches and
> overrunning them (though this is unlikely except in the case of very high
> throughput).  Too many DNS answers (much more likely) spreads your
> service’s content across too many caches and increases the cache churn and
> risk of hitting cold caches and having poor service performance.
>
> I spoke with our DNS team about a year ago about EDNS(0) relative to
> client sub-netting (ECS) and it was not embraced due to the fact that it
> made their recursion jump by several orders of magnitude and broke the DNS
> system.  Not sure if they plan to use EDNS(0) for other things, but not
> sure how that would factor into the load on the caches and need to spread
> that load via additional IP responses, but please educate me if you know
> something about this.
>
> In an ideal world TR monitors the popularity of a service based on
> incoming request counts per second and potentially expands or contracts IP
> response.  Given DNS caching that may be difficult to judge accurately, but
> we may be able to use it to differentiate between a “1” and “4” response.
> I thought I cut a request for that a while back, but I can’t find it so I
> created a new one: https://github.com/apache/incubator-trafficcontrol/
> issues/1614
>
> Ryan DurfeyM | 303-524-5099
> CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com cdn_supp...@comcast.com>
>
>
> From: "Eric Friedrich (efriedri)" 
> Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> Date: Monday, December 4, 2017 at 6:18 PM
> To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>, "jasonwtuc...@gmail.com" <
> jasonwtuc...@gmail.com>
> Subject: Re: Changing max_dns_answers default
>
> Does EDNS0 (which TR already supports) reduce the severity of this
> problem? If so, could TR do an auto detection on if the sending resolver
> supports EDNS0 when deciding how big to make the response?
>
> —Eric
>
> On Dec 4, 2017, at 5:31 PM, Jason Tucker  jasonwtuc...@gmail.com>> wrote:
> HTTP-routing seems to go to the opposite end of the spectrum - the default
> is to use a dispersion of "1", which gives best cache efficiency as Ryan
> mentions. I think the behavior in this regard should be somewhat similar
> between HTTP and DNS routing.
> __Jason
> On Mon, Dec 4, 2017 at 10:19 PM, Durfey, Ryan  mailto:ryan_dur...@comcast.com>>
> wrote:
> I like the idea of code that makes it always under the threshold and I
> think this is a good feature to add, but from a practical perspective we
> always want the max dns response to be the minimum viable for cache
> efficiency.  Most of our services (95%+) should be set to 1, 2, 3, or 4
> correlated to throughput of the service.  Making the default set to as many
> as possible ensures that unless you are paying close attention you will
> have terrible cache efficiency.  I would advocate for 2 or 3 since this
> would cover the majority of our services, keep cache efficiency reasonable,
> and work for most other applications as well.  I would also advocate to add
> the threshold check in case someone goes too high or sets it to 0.
> *Ryan Durfey*M | 303-524-5099 <(303)%20524-5099>
> CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or
> cdn_supp...@comcast.com
> *From: *Jason Tucker mailto:jasonwtuc...@gmail.com
> >>
> *Reply-To: *"dev@trafficcontrol.incubator.apache.org v...@trafficcontrol.incubator.apache.org>" <
> dev@trafficcontrol.incubator.apache.org trafficcontrol.incubator.apache.org>>, "jasonwtuc...@gmail.com jasonwtuc...@gmail.com>" <
> jasonwtuc...@gmail.com>
> *Date: *Monday, December 4, 2017 at 3:10 PM
> *To: *Phil Sorber mailto:sor...@apache.org>>
> *Cc: *"dev@trafficcontrol.incubator.apache.org v...@trafficcontrol.incubator.apache.org>" <
> dev@trafficcontrol.incubator.apache.org trafficcontrol.incubator.apache.org>>
> *Subject: *Re: Changing max_dns_answers default
> I can't comment on the development effort for that (or the compute /
> latency overhead that it might add to TR), but I think having a default
> variable that could be set per TC installation doesn't seem unreasonable.
> __Jason
> On Mon, Dec 4, 2017 at 9:11 PM, Phil Sorber mailto:sorb
> e...@apache.org>> wrote:
> What about adding code that would count the bytes dynamically and make
> sure it keeps under the threshold? Maybe even make that the behavior for
> the current def

Re: Traffic Control with ATS 7+

[Dave Neuman]

Hi Satheesh,
I think your question is best asked on the traffic server mailing list.  I
would try u...@trafficserver.apache.org.  You can find more information on
connecting with the Traffic Server community here:  http://trafficserver.
apache.org/

Thanks,
Dave

On Wed, Nov 29, 2017 at 5:49 AM, satheeshsr...@gmail.com <
satheeshsr...@gmail.com> wrote:

> Hi,
>
> How to configure Trafficserver cluster configuration
>
> Thanks
> Satheesh R
> On 2017-11-22 03:35, Chris Lemmons  wrote:
> > As we continue the work of getting Traffic Control to work properly
> > with ATS 7 and forward, we're having to re-work some of the ways we
> > manipulate cache keys. The crux of the issue is that cacheurl was
> > deprecated in 6 and has been removed in 7. Cacheurl was replaced with
> > cachekey in 6. That unfortunately will make supporting both 5 and 7 a
> > bit tricky. There are a few options for maintaining compatibility, but
> > I thought I'd ask... would anyone find themselves sad if, at some
> > point, Traffic Control stopped working with version 5 of ATS? And if
> > not, what might be the best way to manage that?
> >
>

Re: Traffic Server

[Dave Neuman]

Hi Satheesh,
I think you question is best asked on the traffic server mailing list.  I
would try u...@trafficserver.apache.org.  You can find more information on
connecting with the Traffic Server community here:
http://trafficserver.apache.org/

Thanks,
Dave

On Wed, Nov 29, 2017 at 6:01 AM, satheeshsr...@gmail.com <
satheeshsr...@gmail.com> wrote:

> Dear All,
>
> Hope doing good
>
> Could you please guide me how to apache traffic server install AWS
>
> Thanks in Advance
> Satheesh R
>
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC2

[Dave Neuman]

Replying to the correct email this time!

+1 However
We need to add a release note suggesting that traffic stats works best with
influxdb version < 1.3.x.  As of 1.3.x InfluxDB now returns a 400 response
when the client attempts to write points that are outside of the retention
policy.  When this happens, Traffic Stats seems to hold on to the "old"
points and attempts to write them again on the next POST.  This causes what
is essentially a memory leak in Traffic Stats since it continues to hold
onto and tries to write stats that are outside of the retention policy.
This may or may not affect a user, depending upon which stats they are
trying to write to influxdb.  For example, we write the wrap_count to
influxdb, this is a stat that does not often change within 24 hours, so we
see the memory leak with stats not written on each poll of traffic stats.

In versions < 1.3.x InfluxDB would still not write the point, but it would
accept the write request and just drop the points outside of the retention
policy on the floor.

This is fixed here:
https://github.com/apache/incubator-trafficcontrol/pull/1289and will be in
the next release of traffic control.

Also, we should note that you need to set selinux to "unenforcing" in order
to get the build to work, otherwise you fail on permissions erros.  You can
do this with
`setenforce 0` as root.


Thanks,
Dave

On Mon, Nov 20, 2017 at 12:50 Dan Kirkwood  wrote:

> +1 -- I checked signature, checksums,  build, fresh install of traffic_ops.
>
> -dan
>
> On Wed, Nov 15, 2017 at 7:21 AM, Hank Beatty  wrote:
> > Yes, of course. How does Friday 11/17 or Monday 20/17 sound?
> >
> > On 11/14/2017 04:09 PM, Dave Neuman wrote:
> >>
> >> Hey Hank,
> >> It looks like you have the votes you need to pass, but can you leave it
> >> open a little longer for those of us that haven't gotten a chance to
> test
> >> yet?
> >>
> >> Thanks,
> >> Dave
> >>
> >> On Tue, Nov 14, 2017 at 12:47 PM, Eric Friedrich (efriedri) <
> >> efrie...@cisco.com> wrote:
> >>
> >>> I’m +1 as well
> >>>
> >>> Checked out:
> >>> - signatures/checksums (Hank is your key signed yet?)
> >>> - licenses
> >>> - build
> >>>
> >>> —Eric
> >>>
> >>>
> >>>> On Nov 14, 2017, at 2:36 PM, Nir Sopher  wrote:
> >>>>
> >>>> +1
> >>>> We were able to build traffic-control, install and connect OPs,
> >>>
> >>> Portal-V2,
> >>>>
> >>>> Monitor (Golang), Router and Stats.
> >>>> Also got a redirect.
> >>>> Note that I missed the last commit ("Change cdn.name to
> cdn.domain_name
> >>>
> >>> in
> >>>>
> >>>> DeliveryServiceInfoForDomainList"), but as far as I see it could not
> >>>
> >>> break
> >>>>
> >>>> the installation.
> >>>> Nir
> >>>>
> >>>> On Tue, Nov 14, 2017 at 8:10 PM, Eric Friedrich (efriedri) <
> >>>> efrie...@cisco.com> wrote:
> >>>>
> >>>>> Thanks Matt-
> >>>>>   I found another LEGAL ticket (https://issues.apache.org/
> >>>>> jira/browse/LEGAL-330) based on a Google version of the PATENTS file
> >>>
> >>> this
> >>>>>
> >>>>> time.
> >>>>>
> >>>>> Looks like things are OK to use then.
> >>>>>
> >>>>> —Eric
> >>>>>
> >>>>> On Nov 14, 2017, at 12:50 PM, Mills, Matthew <
> matthew_mi...@comcast.com
> >>>
> >>> <
> >>>>>
> >>>>> mailto:matthew_mi...@comcast.com>> wrote:
> >>>>>
> >>>>> FYI, Go itself has the same file
> >>>>>
> >>>>> https://github.com/golang/go/blob/master/PATENTS
> >>>>>
> >>>>>
> >>>>> On 11/14/17, 10:36:43 AM, "Eric Friedrich (efriedri)" <
> >>>
> >>> efrie...@cisco.com>
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>>I’ve been going through licensing for the 2.1 release and found
> this
> >>>>> file:
> >>>>>./traffic_stats/vendor/golang.org/x/net/PATENTS >>>>> golang.org/x/net/PATENTS>
> >>>>>
> >>>>>This looks like it places some of the same restrictions that
> caused
> >>>
> >>> the
> >>>>>
> >>>>> whole Facebook React.js and rocksDb controversy a few months ago.
> >>>>>Fun reading here: https://issues.apache.org/jira/browse/LEGAL-303
> >>>>>There’s some in depth discussion of the detailed Facebook
> license, I
> >>>>> can’t even begin to speculate how that compares to this Google
> >>>
> >>> conditional
> >>>>>
> >>>>> patent grant.
> >>>>>
> >>>>>We can see what the IPMC/Legal thinks or maybe just remove the
> code?
> >>>>>
> >>>>>—Eric
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC2

[Dave Neuman]

Hey Hank,
It looks like you have the votes you need to pass, but can you leave it
open a little longer for those of us that haven't gotten a chance to test
yet?

Thanks,
Dave

On Tue, Nov 14, 2017 at 12:47 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> I’m +1 as well
>
> Checked out:
> - signatures/checksums (Hank is your key signed yet?)
> - licenses
> - build
>
> —Eric
>
>
> > On Nov 14, 2017, at 2:36 PM, Nir Sopher  wrote:
> >
> > +1
> > We were able to build traffic-control, install and connect OPs,
> Portal-V2,
> > Monitor (Golang), Router and Stats.
> > Also got a redirect.
> > Note that I missed the last commit ("Change cdn.name to cdn.domain_name
> in
> > DeliveryServiceInfoForDomainList"), but as far as I see it could not
> break
> > the installation.
> > Nir
> >
> > On Tue, Nov 14, 2017 at 8:10 PM, Eric Friedrich (efriedri) <
> > efrie...@cisco.com> wrote:
> >
> >> Thanks Matt-
> >>  I found another LEGAL ticket (https://issues.apache.org/
> >> jira/browse/LEGAL-330) based on a Google version of the PATENTS file
> this
> >> time.
> >>
> >> Looks like things are OK to use then.
> >>
> >> —Eric
> >>
> >> On Nov 14, 2017, at 12:50 PM, Mills, Matthew  <
> >> mailto:matthew_mi...@comcast.com>> wrote:
> >>
> >> FYI, Go itself has the same file
> >>
> >> https://github.com/golang/go/blob/master/PATENTS
> >>
> >>
> >> On 11/14/17, 10:36:43 AM, "Eric Friedrich (efriedri)" <
> efrie...@cisco.com>
> >> wrote:
> >>
> >>   I’ve been going through licensing for the 2.1 release and found this
> >> file:
> >>   ./traffic_stats/vendor/golang.org/x/net/PATENTS >> golang.org/x/net/PATENTS>
> >>
> >>   This looks like it places some of the same restrictions that caused
> the
> >> whole Facebook React.js and rocksDb controversy a few months ago.
> >>   Fun reading here: https://issues.apache.org/jira/browse/LEGAL-303
> >>   There’s some in depth discussion of the detailed Facebook license, I
> >> can’t even begin to speculate how that compares to this Google
> conditional
> >> patent grant.
> >>
> >>   We can see what the IPMC/Legal thinks or maybe just remove the code?
> >>
> >>   —Eric
> >>
> >>
> >>
> >>
> >>
>
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC2

[Dave Neuman]

Weekends count, Dewayne!
Plus it says AT LEAST 72 hours :).

On Fri, Nov 10, 2017 at 13:30 Dewayne Richardson  wrote:

> Nice work 72 hours on a Friday!
>
> On Fri, Nov 10, 2017 at 11:21 AM, Hank Beatty  wrote:
>
> > Hello All,
> >
> > I've prepared a release for v2.1.0-RC1
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> > least 3 +1 PPMC votes are cast.
> >
> > [ ] +1 Approve the release
> >
> > [ ] -1 Do not release this package because ...
> >
> > Changes since 2.0.0:
> > https://github.com/apache/incubator-trafficcontrol/compare/
> > 2.0.x...RELEASE-2.1.0-RC2
> >
> > This corresponds to git:
> >   Hash: cac666ef7f0626ea8180e976b07fa841d53f755f
> >   Tag: RELEASE-2.1.0-RC2
> >
> > Which can be verified with the following: git tag -v RELEASE-2.1.0-RC1
> >
> > My code signing key is available here:
> > https://pgp.mit.edu/pks/lookup?op=get&search=0x920152B94E0CC77C
> >
> > The source .tar.gz file, pgp signature (.asc signed with my key from
> > above), md5 and sha512 checksums are provided here:
> >
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.1.0/RC2
> >
> >
> > Thanks!
> >
>

Re: Solution for Apply Geo/VPN Restrictions to CLIENT_STEERING/STEERING Delivery Services

[Dave Neuman]

Hey Hongfei,
Thanks for the email.  To be honest I saw that geo blocking was not in the
UI, so I added it without really thinking about the implications in Traffic
Router, that is my fault.
I think I am on board with Cisco's implementation and I look forward to it
being contributed back to Traffic Control.

Thanks,
Dave

On Thu, Nov 2, 2017 at 4:34 PM, Hongfei Zhang (hongfezh)  wrote:

> Hi Folks,
>
> Two months ago,  We (Cisco) branched off 2.1.x for our next release. We
> noticed the geo restrictions functionality was not supported for steering
> services. Since some of our customers are using the blocking features
> extensively (CZF, National geo blocking, regional geo blocking, vpn
> blocking) and will be using steering services, we decided to enable the
> blocking functionality. The work was completed a few weeks ago on our
> fork.  We recently noticed https://github.com/apache/
> incubator-trafficcontrol/pull/1458 “Cannot set geo restrictions on
> CLIENT_STEERING delivery services” seemed to try address the same issue.
>
> The open source implementation however differs from ours in a significant
> way and I want to bring this up so we can understand the use cases and
> desired behavior better.
>
>
>   1.  Open source took the straightforward approach where operator
> explicitly configure geo restriction for steering service,  traffic router
> then enforce them on steering service only. Disclaimer - I can’t find any
> evidence where such enforcement exists in master today and I assuming this
> is WIP (TrafficRouter code doesn’t check any geo blocking attributes for
> steering service itself). It does however explicitly ignore the target’s
> service’s setting https://github.com/apache/incubator-trafficcontrol/blob/
> master/traffic_router/core/src/main/java/com/comcast/cdn/
> traffic_control/traffic_router/core/router/TrafficRouter.java#L468 .
>
>
> To end user the blocking features works in a way I call “Overwriting” –
> steering service’s setting overwrites those of the target services’s. If
> steering services is not configured as geo blocking, then it becomes wide
> open regardless of targets’ settings. So operator must configure these
> settings, most likely duplicate them from target DSs’ if they need to
> enforce same geo blocking for steering service. Although requiring extra
> steps to configure, this approach does give operator the flexibility to
> enforce geo restriction options for steering service that is different from
> those defined for targets.
>
>
>   1.  Cisco’s implementation, in addition to added support for
> regional/vpn restrictions, took a different approach. We do not require
> operator to configure geo restriction for steering service (hidden from
> UI), and changed the Router code to iterate through the target DSs and
> apply the various restrictions on each. If a target DS is configured to be
> blocked, its caches will not be added in the “locations” response.
>
> To end user the blocking features works in a way I call “Inheriting” –
> steering service inherits blocking ability from the target DSs.  Our view
> is that steering service is a virtual service to add service resiliency and
> it is only meaningful/useful when overlaid on top of real services,
> therefore this inheritance behavior might be desirable. From a restriction
> enforcement perspective,  it is simpler since target service’s restrictions
> is always in effect. It does not however provide any flexibility to
> bypass/overwriting the target DSs’ settings.
>
> Since our open source community , especially Comcast folks have extensive
> operational experiences, I would like to hear your take. To me the most
> importantly questions is: What is end user (operator)’s perception about
> steering service concept? – Is it just another FULL service they need/want
> to provision that will have its only individual characters or it is just
> simply an OVERLAY mechanism that gives them additional service resiliency?
>
> There are certainly options to make the two co-exist (invoke 1 after 2,
> let user configure/choose one over the other, etc) but an answer to above
> question can guide us to provide the “right” solution. The answer will also
> helps us deciding other existing DS feature’s applicability to steering.
>
> Thanks,
> -Hongfei
>
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC1

[Dave Neuman]

Yeah, every PR should have a milestone

On Thu, Oct 26, 2017 at 11:42 AM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Do PRs/issues that don’t have a milestone assigned still end up in this
> changelog? I know theres a bunch more that went into 2.1 that isn’t in this
> list.
>
> Should we make sure that every PR/Issue is assigned a milestone before its
> merged?
>
> > On Oct 26, 2017, at 12:52 PM, Hank Beatty  wrote:
> >
> > Thanks Phil this is very nice.
> >
> > Both of these scripts use the "milestones" to generate the changelog.
> Currently there are 21 issues associated with the 2.1.0 milestone.
> >
> > Here is the output of the one in TC:
> >
> > Changes with Traffic Control 2.1.0
> >  #878 - [TC-488] Docs - Multi Site Origin not up to date
> >  #879 - [TC-490] mso.qstring_handling parameter is checked but not
> documented
> >  #880 - [TC-489] Multi Site Origin - Invalid default values for multiple
> config params
> >  #901 - [TC-377] Default profiles for EDGE and MID are missing after
> initial install
> >  #906 - [TC-327] ConfigFiles.pm detects blank as not null and tries to
> gen files GH #1090
> >  #909 - [TC-301] creating https delivery service and not setting to
> active still looks for cert. Github Issue #1086
> >  #912 - [TC-169] TR download the RGB file continuously when the same RGB
> file on server
> >  #915 - [TC-116] remap.config order is different on master (postgres)
> than it is on 1.8.
> >  #980 - [TC-552] Global parameters may be duplicated when seeds.sql is
> run
> >  #988 - [TC-514] ORT: Change Traffic Ops hostname in middle of ORT run
> >  #1001 - [TC-408] Documentation for creating ssl keys is missing a field.
> >  #1090 - [TC-518] ToCDUCheck and ToCHRCheck: Value formatted as float
> instead of int
> >  #1115 - [TC-429] - TP - removes map due to license incompatibility
> >  #1118 - POST /api/1.2/deliveryserviceserver doesn't update header
> rewrite, regex remap and cacheurl
> >  #1167 - [BACKPORT][TC-518] ToCDUCheck and ToCHRCheck: Value formatted
> as float instead of int #1090
> >  #1168 - [BACKPORT][TC-514] ORT: Change Traffic Ops hostname in middle
> of ORT run
> >  #1195 - [Issue-1189] - Backport to 2.1.x - delivery service tenancy is
> forced on creation and update if use_tenancy is on
> >  #1375 - BACKPORT - fix docs for Deliveryservice/sslkeys/generate and
> deliveryservice/ssl…
> >  #1386 - Traffic Portal V2 main menu has two rows labeled "Tenants"
> >
> >
> > On 10/26/2017 11:55 AM, Phil Sorber wrote:
> >> I believe this one has had a little more love recently and does things
> like
> >> only include merged pull requests, etc.
> >> https://github.com/apache/trafficserver/blob/master/tools/changelog.pl
> >> On Thu, Oct 26, 2017 at 9:52 AM Phil Sorber  wrote:
> >>> You guys mean like this?
> >>>
> >>>
> >>> https://github.com/apache/incubator-trafficcontrol/blob/
> master/misc/changelog.pl
> >>>
> >>> On Thu, Oct 26, 2017 at 8:39 AM Hank Beatty 
> wrote:
> >>>
>  I was thinking of starting with something like this:
>  https://github.com/skywinder/github-changelog-generator#
> output-example.
>  I will also look at the github-changes that Steve mentions.
> 
>  Hank
> 
>  On 10/26/2017 08:48 AM, Steve Malenfant wrote:
> > Do we have a sample from a script that would create a change log
> based
>  on
> > pull request only? I tried `github-changes` yesterday but it seemed
> to
>  work
> > only with the older releases (<1.8). Although I haven't spent much
> time
>  on
> > it.
> >
> > We should probably only list the high level changes such as new
>  features,
> > improvements, important fixes and breaking changes (relates to
>  operations
> > action required).
> >
> > Few things we should note as well :
> > - How to upgrade from pre-2.0 releases
> > - What are the upgrade procedures (run postinstall for example)
> > - Profiles locations (not included in 2.x basic install anymore)
> >
> > I'm sure some of those are documented already, might just requires
> > references.
> >
> > Steve
> >
> >
> >
> > On Wed, Oct 25, 2017 at 8:06 AM, Hank Beatty 
>  wrote:
> >
> >> Hello Steve,
> >>
> >> The release notes are still being worked on. I am also looking for
> >> suggestions on how the release notes should be formatted, and how
> they
> >> might be auto-generated. If you have any, please let me know.
> >>
> >> Regards,
> >> Hank
> >>
> >> On 10/24/2017 07:26 AM, Steve Malenfant wrote:
> >>
> >>> Is there any Release Notes associated with this release? 1,337
>  changes and
> >>> the link above will only display 250 of them.
> >>>
> >>> Steve
> >>>
> >>> On Mon, Oct 23, 2017 at 4:01 PM, Hank Beatty 
>  wrote:
> >>>
> >>> Hello All,
> 
>  I've prepared a release for v2.1.0-RC1
> 
>  The vote is open for at least 72 ho

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC1

[Dave Neuman]

+1 to Steve's recommendation.  Hank/Steve, let me know what you need help
with.

On Thu, Oct 26, 2017 at 6:48 AM, Steve Malenfant 
wrote:

> Do we have a sample from a script that would create a change log based on
> pull request only? I tried `github-changes` yesterday but it seemed to work
> only with the older releases (<1.8). Although I haven't spent much time on
> it.
>
> We should probably only list the high level changes such as new features,
> improvements, important fixes and breaking changes (relates to operations
> action required).
>
> Few things we should note as well :
> - How to upgrade from pre-2.0 releases
> - What are the upgrade procedures (run postinstall for example)
> - Profiles locations (not included in 2.x basic install anymore)
>
> I'm sure some of those are documented already, might just requires
> references.
>
> Steve
>
>
>
> On Wed, Oct 25, 2017 at 8:06 AM, Hank Beatty  wrote:
>
> > Hello Steve,
> >
> > The release notes are still being worked on. I am also looking for
> > suggestions on how the release notes should be formatted, and how they
> > might be auto-generated. If you have any, please let me know.
> >
> > Regards,
> > Hank
> >
> > On 10/24/2017 07:26 AM, Steve Malenfant wrote:
> >
> >> Is there any Release Notes associated with this release? 1,337 changes
> and
> >> the link above will only display 250 of them.
> >>
> >> Steve
> >>
> >> On Mon, Oct 23, 2017 at 4:01 PM, Hank Beatty 
> wrote:
> >>
> >> Hello All,
> >>>
> >>> I've prepared a release for v2.1.0-RC1
> >>>
> >>> The vote is open for at least 72 hours and passes if a majority of at
> >>> least 3 +1 PPMC votes are cast.
> >>>
> >>> [ ] +1 Approve the release
> >>>
> >>> [ ] -1 Do not release this package because ...
> >>>
> >>> Changes since 2.0.0:
> >>> https://github.com/apache/incubator-trafficcontrol/compare/
> >>> 2.0.x...RELEASE-2.1.0-RC1
> >>>
> >>> This corresponds to git:
> >>>   Hash:6ea2ca86d07c16a3b3ca419dd56b975059271206 <(505)%20927-1206>
> >>> <(505)%20927-1206>
> >>>   Tag: RELEASE-2.1.0-RC1
> >>>
> >>> Which can be verified with the following: git tag -v RELEASE-2.1.0-RC1
> >>>
> >>> My code signing key is available here:
> >>> https://pgp.mit.edu/pks/lookup?op=get&search=0x582D3F6E79270895
> >>>
> >>> Make sure you refresh from a key server to get all relevant signatures.
> >>>
> >>> The source .tar.gz file, pgp signature (.asc signed with my key from
> >>> above), md5 and sha512 checksums are provided here:
> >>> https://dist.apache.org/repos/dist/dev/incubator/trafficcont
> >>> rol/2.1.0/RC1
> >>>
> >>> Thanks!
> >>>
> >>>
> >>>
> >>
>

Re: Promote Golang Traffic Monitor to Default

[Dave Neuman]

I don't think the rpm upgrade will take care of this for you.  This will be
a one-time manual upgrade.

On Mon, Oct 23, 2017 at 2:59 PM, Hongfei Zhang (hongfezh) <
hongf...@cisco.com> wrote:

> Hi,
>
> We noticed the new Go Monitor uses two config files and these files are
> incompatible with the Java implementation. Some config directive's name
> also changed.  Will/should the rpm upgrade be able to take care of the
> config file conversion/split?
>
> Thanks,
> -Hongfei
>
> -Original Message-
> From: Nir Sopher [mailto:n...@qwilt.com]
> Sent: Monday, October 23, 2017 3:34 PM
> To: dev@trafficcontrol.incubator.apache.org
> Subject: Re: Promote Golang Traffic Monitor to Default
>
> Hi,
>
> What would be the content of 2.2?
> If we want to have very limited content as suggested in the summit, I
> would suggest to leave Java TM, removing it only on TC 2.3.
>
> If the 2.2 version has substantial content, I would see leaving the old TM
> as part of the release as a liability. Old TM should be adjusted to the
> changes and tested regularly.
> So in this case, if there are no automated tests to cover its
> functionality, I would suggest to remove Java TM from the code base.
>
> Nir
>
> On Mon, Oct 23, 2017 at 5:58 PM, Jeff Elsloo  wrote:
>
> > Hi all,
> >
> > Apologies for the delay, and thanks to Rob for submitting PR 1427 to
> > take care of this. I just merged his PR and that means that
> > `traffic_monitor` has been renamed to `traffic_monitor_java` and
> > `traffic_monitor_golang` has been renamed to `traffic_monitor` (thanks
> > Rob!). This means that we are now one step closer to formally retiring
> > the Java version of Traffic Monitor.
> >
> > Before proposing a vote, I'd like to get a feel for how quickly we can
> > do the formal retirement. We're currently working on 2.1 so that means
> > that we could retire it as early as 2.2. If we want to be more
> > conservative, we could keep both with the renamed structure for 2.2,
> > and remove the Java version in 2.3. This is the direction I'm leaning,
> > though I'd like to hear from interested parties first.
> >
> > Thoughts?
> > --
> > Thanks,
> > Jeff
> >
> >
> > On Mon, Jul 24, 2017 at 8:23 AM, Jeff Elsloo  wrote:
> > > It sounds like we do not have any -1s on this, so I'm going to
> > > assume we're good to make this change. I have some other things to
> > > focus on at the moment, but will try to get this done as time
> > > permits. I'll send another email out with details when I go to make
> > > the change, and will allow some time before pushing anything in case
> > > someone has concerns.
> > > --
> > > Thanks,
> > > Jeff
> > >
> > >
> > > On Mon, Jul 17, 2017 at 2:14 PM, Dave Neuman 
> wrote:
> > >> +1 on the rename
> > >>
> > >> On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn 
> > wrote:
> > >>
> > >>> +1
> > >>>
> > >>> On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson
> > >>> 
> > >>> wrote:
> > >>>
> > >>> > When:   Read · Mon, Jul 17.
> > >>> > <https://timyo.com/?utm_source=expectationheader&utm_medium=emai
> > >>> > l>
> > >>> > [image: Timyo expectation line]
> > >>> > +1
> > >>> >
> > >>> > On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo 
> > wrote:
> > >>> >
> > >>> > > For the most part, it's a drop in replacement for the Java
> > >>> > > version, and based on our own experience it seems to work
> > >>> > > exactly as the
> > Java
> > >>> > > version would, including co-existence. There is a TO API
> > >>> > > dependency for monitoring.json that the Java version does not
> > >>> > > have, and I'm
> > not
> > >>> > > sure what the history is with that endpoint and how far back
> > >>> > > we
> > could
> > >>> > > remain compatible. Traffic Router does not care what version
> > >>> > > of Traffic Monitor it talks to, as the format of
> > >>> > > cr-states.json has
> > not
> > >>> > > changed. Same goes for TM and ATS. I believe we had
> > >>> > > co-existence running in production going back to the 1.8.x
> releases.
> > >>> >

Re: ATC Fall Summit 2017

[Dave Neuman]

Thanks to all of those that attended the summit.  We had a very productive
couple of days full of presentations, discussion, and fun!
If you were a presenter, please post your slides here:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74684528
If you were not a presenter, you can find slides at the link above.

Thanks!
Dave


On Mon, Sep 25, 2017 at 6:05 PM, Dave Neuman  wrote:

> My apologies, the summit is three weeks away not two!  Sorry for any
> confusion.
>
> --Dave
>
> On Mon, Sep 25, 2017 at 15:40 Dave Neuman  wrote:
>
>> Hey all,
>> The Traffic Control fall summit is just 2 weeks away!  I have updated the
>> schedule section of the wiki page, you can check it out here:
>> https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta.
>> You will notice that breakfast and lunch are provided so make sure to give
>> a big thanks to Hank and Steve for making that happen.  If you are reading
>> this and haven't signed up for the summit but want to, you still have time;
>> just follow the link above to see the sign up page as well.  We also have a
>> couple of open slots for presentations/talks so if you see something that
>> is missing that you would like to present or talk about let me know so I
>> can get it on the schedule.  I look forward to seeing everyone in two weeks!
>>
>> Thanks,
>> Dave
>>
>> On Tue, Sep 12, 2017 at 9:36 AM, Dave Neuman  wrote:
>>
>>> Final reminder that our CFP (Call For Presentations) ends on Friday
>>> 9/15.  This just needs to be a sentence or two about what you plan to
>>> present and how much time you need.  You can send your proposal to
>>> summ...@trafficcontrol.incubator.apache.org.  Let me know if you have
>>> any questions.
>>>
>>> Thanks!
>>> Dave
>>>
>>> On Tue, Sep 5, 2017 at 10:15 AM, Dave Neuman  wrote:
>>>
>>>> Hey all,
>>>> This is a reminder to sign up for our fall summit if you plan to attend
>>>> and haven't already.  Details and sign up here:
>>>> https://cwiki.apache.org/confluence/display/TC/Fall+
>>>> 2017+Summit+-+Atlanta
>>>>
>>>>
>>>> <https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta>Also,
>>>> if you are attending, please consider giving a presentation.  If you plan
>>>> to give a presentation, let us know by sending an email to
>>>> summ...@trafficcontrol.incubator.apache.org.
>>>>
>>>> Thanks,
>>>> Dave
>>>>
>>>> On Tue, Aug 15, 2017 at 8:15 AM, Dave Neuman  wrote:
>>>>
>>>>> Hey All,
>>>>> It’s that time of the year again; Apache Traffic Control (incubating)
>>>>> will be having our fall summit on October 17 and 18 in Atlanta, Georgia!
>>>>> Please see the following wiki page and rsvp:
>>>>> https://cwiki.apache.org/confluence/display/TC/Fall+
>>>>> 2017+Summit+-+Atlanta
>>>>>
>>>>> This email also servers as a CFP, if you have a great idea for a
>>>>> presentation let me know at neu...@apache.org by September 15th.  I
>>>>> will share your submissions with the other members of the PMC and we will
>>>>> publish a schedule before the event.
>>>>>
>>>>> Any questions just let me know.
>>>>>
>>>>> Thanks,
>>>>> Dave
>>>>>
>>>>
>>>>
>>>
>>

Re: Anonymous IP Blocking Flowchart

[Dave Neuman]

+1, I think the wiki is good for WIP and then once you submit a PR for the
feature, put it in the docs.  We probably should take some time to
re-organize our docs.

On Fri, Oct 20, 2017 at 9:20 AM, Durfey, Ryan 
wrote:

> I would say if it is work in progress it would go in the wiki.  Once
> formally released to open source it would go here:
> http://trafficcontrol.apache.org/docs/latest/index.html .
>
> Ryan DurfeyM | 303-524-5099
> CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com cdn_supp...@comcast.com>
>
>
> From: "Eric Friedrich (efriedri)" 
> Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> Date: Friday, October 20, 2017 at 8:58 AM
> To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> Subject: Re: Anonymous IP Blocking Flowchart
>
> Where do we think our “design docs” (diagrams and text) belong?
>
> One option is the Wiki, but that can get stale so I’d toss it out there
> that PRs should include the obvious user facing docs, but also a design doc
> section as well
>
> -Eric
>
>
> On Oct 20, 2017, at 10:23 AM, Jeff Elsloo mailto:elsl
> o...@apache.org>> wrote:
> Hey Eric,
> Thanks for sending this out. Hopefully we can build more of these
> diagrams in the future to include in the docs. I'll try to put
> something similar together for the stuff I've been working on.
> --
> Thanks,
> Jeff
> On Thu, Oct 19, 2017 at 1:55 PM, Eric Friedrich (efriedri)
> mailto:efrie...@cisco.com>> wrote:
> Just realized the first diagram I put up was outdated
> The response to anonymous IP blocking is actually configurable between a
> slate (302 redirect to a new URL) and a 403
> —Eric
> On Oct 19, 2017, at 10:53 AM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
> Here is flowchart requested at the summit. I’ll put this diagram along
> with the rest of the slides up soon
> Its a link to a PNG despite the horribly formatted URL
> https://cisco.box.com/s/4rwd6kk069vdmzxpp2ak0vt2elds0ufc
> —Eric
>
>
>

Re: Traffic Ops API Semantic Versioning

[Dave Neuman]

Traffic ops currently does not handle versioning very well.  I think we do
support 1.1 and 1.2 versions of the API, but I think there are only a few
(maybe asns and deliveryservices) that are actually different.
Versioning is something we look to improve as we move to the golang version
of the API.

On Thu, Oct 12, 2017 at 6:50 AM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Does Traffic Ops expose a semantic version number as part of its API?
>
> http://semver.org/
> "Given a version number MAJOR.MINOR.PATCH, increment the:
>
>   1.  MAJOR version when you make incompatible API changes,
>   2.  MINOR version when you add functionality in a backwards-compatible
> manner, and
>   3.  PATCH version when you make backwards-compatible bug fixes.
>
> “
>
> We have some TO clients and would like to improve their backwards
> compatibility. Without this version number, it is not easy to determine
> which fields in the API are supported by any given version.
>
> Thanks,
> Eric
>
>

Re: change to cdn.conf

[Dave Neuman]

In the future it would be nice to send a note to the dev list before it's
merged.

Thanks,
Dave

On Thu, Oct 5, 2017 at 11:37 AM, Dan Kirkwood  wrote:

> Hi, all..
>
> With our ongoing effort to move Traffic Ops from the Perl Mojolicious
> framework to Go,   one thing that's hampered this effort is
> duplication of configuration.   The cdn.conf has always been in Perl
> hash form.
>
> To prevent the need to parse Perl constructs in Go,  I've introduced a
> change that reads it instead in JSON,  which can easily be read by
> both Go and Perl:
> https://github.com/apache/incubator-trafficcontrol/pull/1350
>
> The change is actually fairly simple and does not change the Perl side
> at all,  but all configuration is now together.   I still kept the
> database configuration separate.
>
> This change will go in to Traffic Ops 2.2.   The release notes will
> describe the change and how to change the configuration when
> upgrading.
>
> Any comments or suggestions to this change are welcome..
>
> -dan
>

Re: Traffic Router Fails to Server HTTPs Requests

[Dave Neuman]

Hmm...we did see this problem a long time ago (pre 2.0) where GC was
happening on the TR which caused HTTPS requests to stop.  Are you able to
reproduce?  If so, can you see what the box is doing while your requests
are timing out?  Can you check if that is when GC is running? Also, are you
running TR with the recommended settings from the docs[1]?

[1]
http://trafficcontrol.apache.org/docs/latest/admin/traffic_router.html#tuning-recommendations

Thanks,
Dave

On Mon, Oct 2, 2017 at 7:26 AM, Nir Ichye  wrote:

> It looks like the file wasn't sent.
>
> Here's a link:
> https://drive.google.com/file/d/0BxjguXxlqH0XZTdUUDA5RWpwTzg/
> view?usp=sharing
>
> Thanks.
>
>
> On Mon, Oct 2, 2017 at 4:19 PM Nir Ichye  wrote:
>
> > Hi,
> >
> > I'm working with TC 2.1 (commit 3980b41797c8f2b616277df4b74e73a011c48869)
> and
> > DS that supports both HTTP and HTTPs.
> > All worked well and suddenly HTTPs requests got timeout while at the same
> > time HTTP worked well.
> >
> > I sniffed on the client side and saw that the server doesn't respond with
> > Server Hello although the Client Hello packet was received (I can see the
> > ack).
> > Cap is attached.
> >
> > After a while, I couldn't reproduce the issue anymore.
> > Unfortunately, I don't have a cap from the server-side and couldn't find
> > any clue for an issue in the logs.
> >
> > Has anyone ran into this issue?
> > Any ideas what could have cause this and how to avoid it in the future?
> >
> > Thanks,
> > Nir.
> >
> >
>

Re: Apache Cwiki vs. Github Wiki vs. Github Docs

[Dave Neuman]

I agree with Jan.  I don't see what moving to github wiki really does for
us that cwiki can't, as a matter of fact it will probably cause other
issues like only committers can edit it.   I also agree that we should have
better and more formal docs; especially ones that help new users get ATC
installed quickly.



On Tue, Sep 26, 2017 at 17:10 Jan van Doorn  wrote:

> I think we still need a place to document things like meet ups and the
> likes? I like the “less formal” feel of a wiki, and think the docs should
> be more “official”, and part of the release.
>
> Some people have started putting documentation in the README.md with the
> code, and while I think that’s better than no documentation, I think a
> project like ours should have official user and admin guides as part of the
> release. We have been letting that part slip a little bit, but just giving
> up on it seems too easy for me…
>
> So I don’t like 1. Or 1. :-) I think we should stay on the apache Cwiki
> for informal notes and beef up our rst docs for admins and users.
>
> Rgds,
> JvD
>
>
> > On Sep 26, 2017, at 2:56 PM, Durfey, Ryan 
> wrote:
> >
> > All,
> >
> > Given the move to Github, I think we should consider moving out of
> Apache Cwiki.  While I think this is a far superior wiki to the offering
> from Github, I think unifying everything in one environment is a better
> overall approach.  I also wanted to consider foregoing the wiki altogether
> and suggest pushing this documentation into a new “beta” or “design”
> section under our docs in
> http://trafficcontrol.apache.org/docs/latest/index.html .  This would
> unify us into a single documentation format, simplify the transition from
> design to publication, and eliminate the need to support a wiki altogether.
> >
> > Would love feedback on this:
> >
> >  1.  Move to Github wiki
> >
> > Or
> >
> >  1.  Move to a new “beta” section under
> http://trafficcontrol.apache.org/docs/latest/index.html
> >
> > Ryan Durfey
> > Sr. Product Manager - CDN | Comcast Technology Solutions
> > 1899 Wynkoop Ste. 550 | Denver, CO 80202
> > M | 303-524-5099
> > ryan_dur...@comcast.com
> > CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com cdn_supp...@comcast.com>
> >
>
>

Re: ATC Fall Summit 2017

[Dave Neuman]

My apologies, the summit is three weeks away not two!  Sorry for any
confusion.

--Dave

On Mon, Sep 25, 2017 at 15:40 Dave Neuman  wrote:

> Hey all,
> The Traffic Control fall summit is just 2 weeks away!  I have updated the
> schedule section of the wiki page, you can check it out here:
> https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta.
> You will notice that breakfast and lunch are provided so make sure to give
> a big thanks to Hank and Steve for making that happen.  If you are reading
> this and haven't signed up for the summit but want to, you still have time;
> just follow the link above to see the sign up page as well.  We also have a
> couple of open slots for presentations/talks so if you see something that
> is missing that you would like to present or talk about let me know so I
> can get it on the schedule.  I look forward to seeing everyone in two weeks!
>
> Thanks,
> Dave
>
> On Tue, Sep 12, 2017 at 9:36 AM, Dave Neuman  wrote:
>
>> Final reminder that our CFP (Call For Presentations) ends on Friday
>> 9/15.  This just needs to be a sentence or two about what you plan to
>> present and how much time you need.  You can send your proposal to
>> summ...@trafficcontrol.incubator.apache.org.  Let me know if you have
>> any questions.
>>
>> Thanks!
>> Dave
>>
>> On Tue, Sep 5, 2017 at 10:15 AM, Dave Neuman  wrote:
>>
>>> Hey all,
>>> This is a reminder to sign up for our fall summit if you plan to attend
>>> and haven't already.  Details and sign up here:
>>> https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta
>>>
>>>
>>> <https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta>Also,
>>> if you are attending, please consider giving a presentation.  If you plan
>>> to give a presentation, let us know by sending an email to
>>> summ...@trafficcontrol.incubator.apache.org.
>>>
>>> Thanks,
>>> Dave
>>>
>>> On Tue, Aug 15, 2017 at 8:15 AM, Dave Neuman  wrote:
>>>
>>>> Hey All,
>>>> It’s that time of the year again; Apache Traffic Control (incubating)
>>>> will be having our fall summit on October 17 and 18 in Atlanta, Georgia!
>>>> Please see the following wiki page and rsvp:
>>>> https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta
>>>>
>>>> This email also servers as a CFP, if you have a great idea for a
>>>> presentation let me know at neu...@apache.org by September 15th.  I
>>>> will share your submissions with the other members of the PMC and we will
>>>> publish a schedule before the event.
>>>>
>>>> Any questions just let me know.
>>>>
>>>> Thanks,
>>>> Dave
>>>>
>>>
>>>
>>
>

Re: ATC Fall Summit 2017

[Dave Neuman]

Hey all,
The Traffic Control fall summit is just 2 weeks away!  I have updated the
schedule section of the wiki page, you can check it out here:
https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta.
You will notice that breakfast and lunch are provided so make sure to give
a big thanks to Hank and Steve for making that happen.  If you are reading
this and haven't signed up for the summit but want to, you still have time;
just follow the link above to see the sign up page as well.  We also have a
couple of open slots for presentations/talks so if you see something that
is missing that you would like to present or talk about let me know so I
can get it on the schedule.  I look forward to seeing everyone in two weeks!

Thanks,
Dave

On Tue, Sep 12, 2017 at 9:36 AM, Dave Neuman  wrote:

> Final reminder that our CFP (Call For Presentations) ends on Friday 9/15.
> This just needs to be a sentence or two about what you plan to present and
> how much time you need.  You can send your proposal to
> summ...@trafficcontrol.incubator.apache.org.  Let me know if you have any
> questions.
>
> Thanks!
> Dave
>
> On Tue, Sep 5, 2017 at 10:15 AM, Dave Neuman  wrote:
>
>> Hey all,
>> This is a reminder to sign up for our fall summit if you plan to attend
>> and haven't already.  Details and sign up here:
>> https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta
>>
>>
>> <https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta>Also,
>> if you are attending, please consider giving a presentation.  If you plan
>> to give a presentation, let us know by sending an email to
>> summ...@trafficcontrol.incubator.apache.org.
>>
>> Thanks,
>> Dave
>>
>> On Tue, Aug 15, 2017 at 8:15 AM, Dave Neuman  wrote:
>>
>>> Hey All,
>>> It’s that time of the year again; Apache Traffic Control (incubating)
>>> will be having our fall summit on October 17 and 18 in Atlanta, Georgia!
>>> Please see the following wiki page and rsvp:
>>> https://cwiki.apache.org/confluence/display/TC/Fall+2017+Su
>>> mmit+-+Atlanta
>>>
>>> This email also servers as a CFP, if you have a great idea for a
>>> presentation let me know at neu...@apache.org by September 15th.  I
>>> will share your submissions with the other members of the PMC and we will
>>> publish a schedule before the event.
>>>
>>> Any questions just let me know.
>>>
>>> Thanks,
>>> Dave
>>>
>>
>>
>

Re: Podling Report Reminder - October 2017

[Dave Neuman]

I've got this.

On Sat, Sep 23, 2017 at 07:11  wrote:

> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
>
> The board meeting is scheduled for Wed, 18 October 2017, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, October 04).
>
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
>
> --
>
> Your report should contain the following:
>
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> *   A list of the three most important issues to address in the move
> towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
>
> This should be appended to the Incubator Wiki page at:
>
> https://wiki.apache.org/incubator/October2017
>
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
>
> Mentors
> ---
>
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
>
> Incubator PMC
>

Re: Public resources in Traffic Ops

[Dave Neuman]

Anything in the "public" directory is made public so that other components
(llike Traffic Router) can get to it without authentication.
It is recommended that you have some ACLs in front of Traffic Ops to limit
who/what can access it.



On Tue, Sep 19, 2017 at 1:52 AM, Nir Ichye  wrote:

> Hi,
>
> It seems that several files in TO can be accessed without credentials. This
> includes:
> - Coverage Zone File (http[s]:///routing/coverage-zone.json)
> - server.key (http[s]:///routing/server.key)
> - and other files in the public folder.
>
> Can you tell if the files are public on purpose and if this could be a
> security issue?
>
> Thanks,
> Nir.
>

Re: ATC Fall Summit 2017

[Dave Neuman]

Final reminder that our CFP (Call For Presentations) ends on Friday 9/15.
This just needs to be a sentence or two about what you plan to present and
how much time you need.  You can send your proposal to
summ...@trafficcontrol.incubator.apache.org.  Let me know if you have any
questions.

Thanks!
Dave

On Tue, Sep 5, 2017 at 10:15 AM, Dave Neuman  wrote:

> Hey all,
> This is a reminder to sign up for our fall summit if you plan to attend
> and haven't already.  Details and sign up here:
> https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta
>
> <https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta>Also,
> if you are attending, please consider giving a presentation.  If you plan
> to give a presentation, let us know by sending an email to
> summ...@trafficcontrol.incubator.apache.org.
>
> Thanks,
> Dave
>
> On Tue, Aug 15, 2017 at 8:15 AM, Dave Neuman  wrote:
>
>> Hey All,
>> It’s that time of the year again; Apache Traffic Control (incubating)
>> will be having our fall summit on October 17 and 18 in Atlanta, Georgia!
>> Please see the following wiki page and rsvp:
>> https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta
>>
>> This email also servers as a CFP, if you have a great idea for a
>> presentation let me know at neu...@apache.org by September 15th.  I will
>> share your submissions with the other members of the PMC and we will
>> publish a schedule before the event.
>>
>> Any questions just let me know.
>>
>> Thanks,
>> Dave
>>
>
>

Re: traffic_ops postinstall/rpm update changes

[Dave Neuman]

+1

On Wed, Sep 6, 2017 at 1:47 PM, Gelinas, Derek 
wrote:

> +1
>
> On Sep 6, 2017, at 3:40 PM, Dan Kirkwood mailto:dan
> g...@apache.org>> wrote:
>
> Hi all..
>
> With Traffic Ops 2.2,   we will be adding a couple of keys to the
> cdn.conf.   Our initial thought was to add that change to postinstall,
> but that process has become unwieldy and difficult to maintain.
>
> What we propose to do instead is update the cdn.conf in the release
> with these changes -- any existing installation will not replace the
> existing cdn.conf,  but create a cdn.conf.rpmnew.
>
> It will be up to the administrator of the installation to make the
> appropriate changes to the cdn.conf based on the contents of that
> rpmnew file.   This will be true for other config file changes in the
> future as well.
>
> At most installations,  the handling of those config files is likely
> to be handled by a configuration management system like puppet or
> ansible.   The recommendation would be to update the file using that
> mechanism so it is consistently applied.
>
> With that in mind,  I'm planning on simplifying postinstall by
> removing any "update" features.   It would be used only for initial
> installs.   If the rpm is an update to an existing install,  the "run
> postinstall" message would not be produced.
>
> Does anyone have concerns with this plan?   I should have a PR for
> review later this week.
>
> thanks..  Dan Kirkwood
>
>

Re: ATC Fall Summit 2017

[Dave Neuman]

Hey all,
This is a reminder to sign up for our fall summit if you plan to attend and
haven't already.  Details and sign up here:  https://cwiki.apache.org/
confluence/display/TC/Fall+2017+Summit+-+Atlanta

<https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta>Also,
if you are attending, please consider giving a presentation.  If you plan
to give a presentation, let us know by sending an email to
summ...@trafficcontrol.incubator.apache.org.

Thanks,
Dave

On Tue, Aug 15, 2017 at 8:15 AM, Dave Neuman  wrote:

> Hey All,
> It’s that time of the year again; Apache Traffic Control (incubating) will
> be having our fall summit on October 17 and 18 in Atlanta, Georgia!
> Please see the following wiki page and rsvp:  https://cwiki.apache.org/
> confluence/display/TC/Fall+2017+Summit+-+Atlanta
>
> This email also servers as a CFP, if you have a great idea for a
> presentation let me know at neu...@apache.org by September 15th.  I will
> share your submissions with the other members of the PMC and we will
> publish a schedule before the event.
>
> Any questions just let me know.
>
> Thanks,
> Dave
>

Re: Is multiple subdomains fully supported?

[Dave Neuman]

No problem.

```1) HOST_REGEXP 1 will be: “.*\.foo.bar.com”?  Or explicitly “
movie.foo.bar.com”?```
It will need to explicitly need to be a FQDN of a CNAME so `
movie.foo.bar.com`


```2) I think currently the certificate generated by Traffic Ops not
supported SAN. Does this mean we need to generate the SSL certificate from
another place, and paste it to Traffic Ops only?```

Yeah, if you want to create it will a SAN you will need to do it manually.
You can do it using the Openssl command.

Can you open a ticket to update the docs for HOST_REGEXP and also to add
SAN support to Traffic Ops?  I think that's something that we need to
support.


Thanks,
Dave

On Thu, Aug 31, 2017 at 9:35 PM, Zhilin Huang (zhilhuan)  wrote:

> Hey Dave,
>
> Yes, it is much clearer for me now. Thank you very much for the
> clarification!
>
> BTW, based on your example, how could we do the configuration?
>
> 1) HOST_REGEXP 1 will be: “.*\.foo.bar.com”?  Or explicitly “
> movie.foo.bar.com”?
>
> 2) I think currently the certificate generated by Traffic Ops not
> supported SAN. Does this mean we need to generate the SSL certificate from
> another place, and paste it to Traffic Ops only?
>
> It would be much helpful if we can reword in the document for HOST_REGEXP
> > 1. How could we open a ticket? Create a github issue?
>
> Thanks,
> Zhilin
>
>
>
> On 8/31/17, 10:37 PM, "Dave Neuman"  wrote:
>
> Hey Zhilin,
>
> The HOST_REGEXP > 0 is not used the same as HOST_REGEXP = 0.  I
> understand
> this is confusing, but it is what it is.  We should probably get a
> ticket
> in to change the behavior or wording so that it is less confusing.
> The HOST_REGEXP > 0 is meant to be a CNAME.  So, if you have a CDN
> with the
> domain name `example.com` and a HOST_REGEXP 0 of `.*\.movies\.*` you
> could
> have a HOST_REGEXP 1 of `movies.foo.bar.com` which will be a CNAME to
> `
> movies.example.com`.  This will need to be configured in a different
> DNS
> server (the one for `bar.com`) and will also need to be a SAN in the
> DS
> certificate.  Then when the client looks up `different.domain.com`
> they
> will be pointed  at `tr.movies.example.com` and TR will do the right
> thing.
>
> I hope that helps?  If not, let me know.
>
>
> Thanks,
> Dave
>
>
>
> On Tue, Aug 29, 2017 at 10:52 PM, Zhilin Huang (zhilhuan) <
> zhilh...@cisco.com> wrote:
>
> > BTW, would you mind to give an example on how you are using
> HOST_REGEXP >
> > 0 in your production?
> >
> > We thought HOST_REGEXP > 0 should be very similar to HOST_REGEXP =
> 0, but
> > sounds like it is not the case.
> >
> > Thanks,
> > Zhilin
> >
> >
> > On 8/30/17, 12:46 PM, "Zhilin Huang (zhilhuan)" 
> > wrote:
> >
> > Hi Dave,
> >
> > Thanks a lot for your response!
> >
> > Sorry, I am not quite catch up with you. I am still confused
> about how
> > HOST_REGEXP will work in the production, may need more clarification:
> >
> > 1)  “To support CNAMES from domains outside of the Traffic
> Control top
> > level DNS domain, enter multiple HOST_REGEXP lines”:
> >
> > What does this mean about “outside of the Traffic Control top
> level
> > DNS domain”, will the CNAME still be response by Traffic Router?
> >
> > If yes, then looks like it could only work to replace “tr” or
> “edge”
> > field. For example, a CDN with domain name “example.com”, and  DS
> with
> > HOST_REGEXP 0 “.*\.movie\..*” and HOST_REGEXP 1 “.*\.aliens\.*”, a
> zone
> > file “movie.example.com.” will be created. So traffic router could
> only
> > serve DNS request for “*.movie.example.com”. Does this mean “
> > aliens.movie.example.com” will be a CNAME for “tr.movie.example.com”?
> I
> > think domain name like “tr.aliens.example.com” could not be
> resolved by
> > Traffic Router, correct?
> >
> > 2) “we use HOST_REGEXP > 0 as CNAMES which would be domains we
> are not
> > authoritative for and we don't control.”:
> > Does this mean the CNAMES are not managed by Traffic Router, and
> need
> > be configured in other DNS servers? If yes, how could that work for
> HTTPS?
> > Take the above example, if DNS query for “tr.aliens.example.com”
> would be
> > response as CNAME of “tr.movie.example.com” by outside DNS server,
> then
> > Traffic Router will resp

Re: Initial setup for development

[Dave Neuman]

Hey Michael,
I have built a "CDN in a box" before using KVM and a physical server but I
haven't ever tried to build one in AWS.  I think you will need at least 3
VMs to make this happen.  The first one should be able to run all of the TC
components (Traffic Ops, Postgres, Traffic Monitor, Traffic Router) and you
will need at least two caches.  We require at least a two tier CDN with at
least one EDGE and one MID server.  It might be a little difficult getting
all of the TC components running on one VM, but I think it can be done.

Sorry, we don't really have a how-to on doing what you are trying to do,
but I (and hopefully others) are more than happy to help here.

Thanks,
Dave

On Thu, Aug 31, 2017 at 2:54 PM, Michael Talyansky <
michael.talyan...@ericsson.com> wrote:

> Hi,
>
> I am trying to set up development and testing environment on AWS. So far,
> I have two VMs, one running postgres, and one on which I built
> trafficcontrol. I will need to set up at least one caching node, so I can
> test the whole system.
>
> Has anyone done something similar before, and if so, is there a pointer to
> a sample configuration of how to do this with the least amount of VMs?
>
> Thanks in advance!
>

Re: Is multiple subdomains fully supported?

[Dave Neuman]

Hey Zhilin,

The HOST_REGEXP > 0 is not used the same as HOST_REGEXP = 0.  I understand
this is confusing, but it is what it is.  We should probably get a ticket
in to change the behavior or wording so that it is less confusing.
The HOST_REGEXP > 0 is meant to be a CNAME.  So, if you have a CDN with the
domain name `example.com` and a HOST_REGEXP 0 of `.*\.movies\.*` you could
have a HOST_REGEXP 1 of `movies.foo.bar.com` which will be a CNAME to `
movies.example.com`.  This will need to be configured in a different DNS
server (the one for `bar.com`) and will also need to be a SAN in the DS
certificate.  Then when the client looks up `different.domain.com` they
will be pointed  at `tr.movies.example.com` and TR will do the right thing.

I hope that helps?  If not, let me know.


Thanks,
Dave



On Tue, Aug 29, 2017 at 10:52 PM, Zhilin Huang (zhilhuan) <
zhilh...@cisco.com> wrote:

> BTW, would you mind to give an example on how you are using HOST_REGEXP >
> 0 in your production?
>
> We thought HOST_REGEXP > 0 should be very similar to HOST_REGEXP = 0, but
> sounds like it is not the case.
>
> Thanks,
> Zhilin
>
>
> On 8/30/17, 12:46 PM, "Zhilin Huang (zhilhuan)" 
> wrote:
>
> Hi Dave,
>
> Thanks a lot for your response!
>
> Sorry, I am not quite catch up with you. I am still confused about how
> HOST_REGEXP will work in the production, may need more clarification:
>
> 1)  “To support CNAMES from domains outside of the Traffic Control top
> level DNS domain, enter multiple HOST_REGEXP lines”:
>
> What does this mean about “outside of the Traffic Control top level
> DNS domain”, will the CNAME still be response by Traffic Router?
>
> If yes, then looks like it could only work to replace “tr” or “edge”
> field. For example, a CDN with domain name “example.com”, and  DS with
> HOST_REGEXP 0 “.*\.movie\..*” and HOST_REGEXP 1 “.*\.aliens\.*”, a zone
> file “movie.example.com.” will be created. So traffic router could only
> serve DNS request for “*.movie.example.com”. Does this mean “
> aliens.movie.example.com” will be a CNAME for “tr.movie.example.com”? I
> think domain name like “tr.aliens.example.com” could not be resolved by
> Traffic Router, correct?
>
> 2) “we use HOST_REGEXP > 0 as CNAMES which would be domains we are not
> authoritative for and we don't control.”:
> Does this mean the CNAMES are not managed by Traffic Router, and need
> be configured in other DNS servers? If yes, how could that work for HTTPS?
> Take the above example, if DNS query for “tr.aliens.example.com” would be
> response as CNAME of “tr.movie.example.com” by outside DNS server, then
> Traffic Router will response for further DNS query for “
> tr.movie.example.com”. The client will still use “tr.aliens.example.com”
> in the HTTPS request, therefore the SSL certificate will still not work
> since no SSL SAN configured.
>
> Thanks,
> Zhilin
>
>
>
> On 8/29/17, 11:32 PM, "Dave Neuman"  wrote:
>
> This doc states To support CNAMES from domains outside of the
> Traffic
> Control top level DNS domain, enter multiple HOST_REGEXP lines,
> which shows
> that we intended HOST_REGEXP > 0 to be for CNAMES.
>
> http://trafficcontrol.apache.org/docs/latest/admin/traffic_
> ops/using.html?highlight=host_regexp#delivery-service-regexp
> ​
>
> On Tue, Aug 29, 2017 at 9:29 AM, Dave Neuman 
> wrote:
>
> > Hi Zhilin,
> > Sorry for not responding sooner.
> >
> > I answered your questions inline below.  Let me know what other
> questions
> > you have.
> >
> > Thanks,
> > Dave
> >
> > On Mon, Aug 28, 2017 at 8:32 PM, Zhilin Huang (zhilhuan) <
> > zhilh...@cisco.com> wrote:
> >
> >> Hmm, no response…
> >>
> >> I think I should suppose no one is using multiple subdomains in
> >> production. Please response if I am wrong.
> >>
> >> Thanks,
> >> Zhilin
> >>
> >>
> >> On 8/25/17, 3:12 PM, "Zhilin Huang (zhilhuan)" <
> zhilh...@cisco.com>
> >> wrote:
> >>
> >> Hi folks,
> >>
> >> The multiple subdomain (HOST_REGEXP) looks not working in
> TC version
> >> we are using. However, after checking the code in latest master
> branch, I
> >> would suspect if this is fully supported:
> >>
> >> 1. Based on t

Re: Is multiple subdomains fully supported?

[Dave Neuman]

This doc states To support CNAMES from domains outside of the Traffic
Control top level DNS domain, enter multiple HOST_REGEXP lines, which shows
that we intended HOST_REGEXP > 0 to be for CNAMES.

http://trafficcontrol.apache.org/docs/latest/admin/traffic_ops/using.html?highlight=host_regexp#delivery-service-regexp
​

On Tue, Aug 29, 2017 at 9:29 AM, Dave Neuman  wrote:

> Hi Zhilin,
> Sorry for not responding sooner.
>
> I answered your questions inline below.  Let me know what other questions
> you have.
>
> Thanks,
> Dave
>
> On Mon, Aug 28, 2017 at 8:32 PM, Zhilin Huang (zhilhuan) <
> zhilh...@cisco.com> wrote:
>
>> Hmm, no response…
>>
>> I think I should suppose no one is using multiple subdomains in
>> production. Please response if I am wrong.
>>
>> Thanks,
>> Zhilin
>>
>>
>> On 8/25/17, 3:12 PM, "Zhilin Huang (zhilhuan)" 
>> wrote:
>>
>> Hi folks,
>>
>> The multiple subdomain (HOST_REGEXP) looks not working in TC version
>> we are using. However, after checking the code in latest master branch, I
>> would suspect if this is fully supported:
>>
>> 1. Based on the code, Traffic Router may not fully support
>> HOST_REGEXP with “set_number” not equal 0. The cr-config generated will
>> only include the first HOST_REGEXP into the “domains” field for each
>> delivery service. So the auto-zones will not be generated for other
>> HOST_REGEXP.
>>
>
> Correct, the regex is in the CrConfig but not in the domains section.  The
> HOST_REGEXP > 0 is intended (at least the way we use it) for CNAMEs on
> other domains.  Since the CNAMEs are not on the domain the TR is
> authoritative for, the TR cannot manage zones for them.
>
>
>>
>> 2. For HTTPS delivery service, the SSL certificate will only be
>> generated for the first HOST_REGEXP.
>>
>
> Correct, again we use HOST_REGEXP > 0 as CNAMES which would be domains we
> are not authoritative for and we don't control.
>
>
>> Have anyone of you are using multiple HOST_REGEXP in your delivery
>> services? Please correct me if my understanding is wrong.
>>
>> If we want to fully support multiple subdomain (HOST_REGEXP), should
>> we do:
>>
>> For item 1) above, expand all HOST_REGEXP and add into “domains”
>> field for each delivery service in “cr-config”. Is there any special reason
>> to only include the first one?
>>
>
> Yes, we put CNAMEs in this field so TR could not be authoritative for
> those zones.  You would need to do some check to make sure that TR can
> actually manage the zone before adding including it in the domains section.
>
>
>>
>> For item 2) above, add SAN in SSL certificate for all HOST_REGEXP
>> other than the first one (set_number == 0)?
>>
>
> See above.
>
>
>> Thanks,
>> Zhilin
>>
>>
>>
>>
>>
>

Re: Is multiple subdomains fully supported?

[Dave Neuman]

Hi Zhilin,
Sorry for not responding sooner.

I answered your questions inline below.  Let me know what other questions
you have.

Thanks,
Dave

On Mon, Aug 28, 2017 at 8:32 PM, Zhilin Huang (zhilhuan)  wrote:

> Hmm, no response…
>
> I think I should suppose no one is using multiple subdomains in
> production. Please response if I am wrong.
>
> Thanks,
> Zhilin
>
>
> On 8/25/17, 3:12 PM, "Zhilin Huang (zhilhuan)"  wrote:
>
> Hi folks,
>
> The multiple subdomain (HOST_REGEXP) looks not working in TC version
> we are using. However, after checking the code in latest master branch, I
> would suspect if this is fully supported:
>
> 1. Based on the code, Traffic Router may not fully support HOST_REGEXP
> with “set_number” not equal 0. The cr-config generated will only include
> the first HOST_REGEXP into the “domains” field for each delivery service.
> So the auto-zones will not be generated for other HOST_REGEXP.
>

Correct, the regex is in the CrConfig but not in the domains section.  The
HOST_REGEXP > 0 is intended (at least the way we use it) for CNAMEs on
other domains.  Since the CNAMEs are not on the domain the TR is
authoritative for, the TR cannot manage zones for them.


>
> 2. For HTTPS delivery service, the SSL certificate will only be
> generated for the first HOST_REGEXP.
>

Correct, again we use HOST_REGEXP > 0 as CNAMES which would be domains we
are not authoritative for and we don't control.


> Have anyone of you are using multiple HOST_REGEXP in your delivery
> services? Please correct me if my understanding is wrong.
>
> If we want to fully support multiple subdomain (HOST_REGEXP), should
> we do:
>
> For item 1) above, expand all HOST_REGEXP and add into “domains” field
> for each delivery service in “cr-config”. Is there any special reason to
> only include the first one?
>

Yes, we put CNAMEs in this field so TR could not be authoritative for those
zones.  You would need to do some check to make sure that TR can actually
manage the zone before adding including it in the domains section.


>
> For item 2) above, add SAN in SSL certificate for all HOST_REGEXP
> other than the first one (set_number == 0)?
>

See above.


> Thanks,
> Zhilin
>
>
>
>
>

Re: [VOTE] Bugtracking in Github Issues

[Dave Neuman]

I thought we already had a vote on this?  Maybe I am thinking of the "move
to github" vote which I assumed to be all-encompassing.
Anyway, +1

On Mon, Aug 28, 2017 at 10:43 AM, Dan Kirkwood  wrote:

> +1
>
> On Mon, Aug 28, 2017 at 10:38 AM, Eric Friedrich (efriedri)
>  wrote:
> > We currently use JIRA Issues to track all of the Traffic Control bugs.
> >
> > Now that we have write access to Github, we can move back to GH Issues
> for bug tracking.
> >
> > This will be a better workflow because its one fewer tool and account to
> have to interact with. This will hopefully lower the bar for new
> contributors to file bugs and engage with the product. We can also help use
> it (along with the milestones) to create more useful changelogs and release
> notes.
> >
> > A possible downside is that the Issues are maybe less flexible than JIRA
> in terms of permissions, workflow, fields, etc. However, we were using
> Issues before we entered the incubator and that was fine for us. Hopefully
> no one has developed an attachment for JIRA in the last year.
> >
> >
> > Please Vote +1 to move to Github Issues or -1 to stay on Jira. I’ll
> assume a lazy consensus if there aren’t enough votes.
> >
> > —Eric
> >
> >
>

Re: Preventing routing to individual caches

[Dave Neuman]

I believe using CCR_IGNORE would mean the caches aren't monitored by
Traffic Monitor, and we don't want that.
I don't really like any of the options but I don't have time or desire to
think of something better.  So, if I had to choose one of the options
presented, I would choose 5 -- putting a column on the profile table.

On Thu, Aug 24, 2017 at 8:40 AM, Gelinas, Derek 
wrote:

> I’m not sure it would work, but I’ll look into it.
>
> Assuming it does not, does anyone have any strong feelings about any of
> the choices?  My personal preference is to use option 3 or option 1, or to
> use ccr_ignore.
>
> 1) Server table flag - when marked, nothing is routed to the host at
> all.  Not as configurable as option 3, but more so than option 2.  Faster
> than option 2 as it would be returned with existing search results and
> could be easily filtered on.  Minor UI change only.
> 2) Profile parameter - when marked, nothing is routed to any host
> with this profile.  Heavy handed, and would require additional profile
> parameter lookups when generating the crconfig, so it'd slow it down. No UI
> change.
> 3) deliveryservice_servers table flag - an additional column that is
> true by default.  When desired, the user could pull up a sub-window within
> the delivery service configuration that would present a list of the hosts
> which have been assigned to the delivery service (and are not of org
> type).  The user could deselect the desired hosts, setting the DSS routing
> value to false.  This server would then be ignored when generating the
> crconfig data for that specific delivery service.  This would be the most
> configurable option, and should be as quick as option 1, but would require
> the most extensive code changes.
> 4) Column in the “type” table. Like option 1, this would apply at the
> server level.
> 5) Column in the “profile” table.  Like option 2, this would apply at the
> profile level.
>
>
> > On Aug 23, 2017, at 5:53 PM, rawlin.pet...@gmail.com <
> rawlin_pet...@comcast.com> wrote:
> >
> > What about the server status CCR_IGNORE ("Server is ignored by traffic
> router.") that already exists? It doesn't appear to be checked when
> generating CRConfig right now, but maybe it should be?
> >
> > --Rawlin
> >
> > On 2017-08-22 11:45, "Gelinas, Derek"  wrote:
> >> Iâ?Td agree with you if this was designed to drain, but this is
> intended as a permanent state for a pretty good long list of caches.
> >>
> >> DG
> >>
> >>> On Aug 22, 2017, at 1:28 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
> >>>
> >>> What about a modification of option 1- adding a new state per server.
> >>>
> >>> Instead of ADMIN_DOWN, it could be â?oREPORTED_DRAINâ?  to indicate
> the difference
> >>>
> >>> â?"Eric
> >>>
>  On Aug 22, 2017, at 1:14 PM, Gelinas, Derek <
> derek_geli...@comcast.com> wrote:
> 
>  Thatâ?Ts actually the workaround weâ?Tre using at the moment -
> setting them to admin_down.  Thatâ?Ts a temporary measure, though - we want
> something more permanent.
> 
>  DG
> > On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
> >
> > How does your use case differ from marking a server as offline in
> Traffic Ops and snapshotting?
> >
> > Thats the easiest way I can think of to get a server in this state
> >
> > â?"Eric
> >
> >> On Aug 22, 2017, at 1:00 PM, Gelinas, Derek <
> derek_geli...@comcast.com> wrote:
> >>
> >> Weâ?Tve run across a situation in which we need certain caches to
> simultaneously have map rules for a delivery service, but not actually have
> those caches routed to when requests are made via traffic router.
> Essentially, this means removing the delivery service from the cacheâ?Ts
> info in the crconfig file.
> >>
> >> Thereâ?Ts been a bit of internal debate about the best ways to do
> this, and Iâ?Td like to collect some opinions on the matter.
> >>
> >> 1) Server table flag - when marked, nothing is routed to the host
> at all.  Not as configurable as option 3, but more so than option 2.
> Faster than option 2 as it would be returned with existing search results
> and could be easily filtered on.  Minor UI change only.
> >> 2) Profile parameter - when marked, nothing is routed to any host
> with this profile.  Heavy handed, and would require additional profile
> parameter lookups when generating the crconfig, so itâ?Td slow it down. No
> UI change.
> >> 3) deliveryservice_servers table flag - an additional column that
> is true by default.  When desired, the user could pull up a sub-window
> within the delivery service configuration that would present a list of the
> hosts which have been assigned to the delivery service (and are not of org
> type).  The user could deselect the desired hosts, setting the DSS routing
> value to false.  This server would then be ignored when generating the
> crconfig data for that specific delivery service.  This would be the most
> co

Re: Adding support for per-DeliveryService routing names

[Dave Neuman]

me column to the DeliveryService table.
> >> > > > 2. Update the routing_name for DNS Delivery Services to
> “edge”.
> >> > > > 3. Update the routing_name of non-DNS Delivery Services to the
> >> value
> >> > of a
> >> > > > temporary upgrade parameter associated with the Delivery
> >> Service’s CDN
> >> > > (if
> >> > > > the upgrade parameter doesn’t exist, the routing_names will
> >> remain
> >> > null).
> >> > > > 4. Update the remaining null routing_names to “tr”.
> >> > > > 5. Make the routing_name column non-null and add a non-empty
> >> > constraint.
> >> > > >
> >> > > > So these would be an operator’s pre-upgrade steps:
> >> > > > 1. Verify if a custom http.routing.name has been configured
> for
> >> > Traffic
> >> > > > Routers in their CDNs.
> >> > > > 2. If custom http.routing.name, do the following. Otherwise,
> no
> >> > > > pre-upgrade steps needed (for per-DS routing names at least):
> >> > > > a. create a parameter named “upgrade_http_routing_name”
> >> with the
> >> > > value
> >> > > > of the target CDN’s custom http.routing.name
> >> > > > b. associate this parameter to the TR_PROFILE belonging to
> >> the
> >> > target
> >> > > > CDN
> >> > > > c. repeat steps 2a and 2b for each CDN using a custom
> >> > > > http.routing.name
> >> > > >
> >> > > > This would keep everything working the same post-upgrade as it
> >> did
> >> > > > pre-upgrade, and from that point on you’d be able to change a
> >> Delivery
> >> > > > Service’s routing name to any arbitrary hostname (without
> >> periods).
> >> > > >
> >> > > > --Rawlin
> >> > > >
> >> > > > On 8/14/17, 4:22 PM, "Dave Neuman"  wrote:
> >> > > >
> >> > > > I don't think that solves the issue Rawlin was describing.
> >> The
> >> > issue
> >> > > > that
> >> > > > Rawlin was describing is that someone has already defined
> a
> >> > different
> >> > > > routing name in traffic_router/http.properties which is no
> >> longer
> >> > > > going to
> >> > > > be used after the upgrade.  The upgrade needs to somehow
> >> know about
> >> > > > this
> >> > > > other routing name and use that when it creates the
> >> database column
> >> > > and
> >> > > > populates it with the pre-defined defaults (edge, tr).
> >> > > >
> >> > > > Also, creating a global param doesn't help those with more
> >> than 1
> >> > > CDN.
> >> > > >
> >> > > > On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <
> >> > > > mitchell...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > Adding a temp parameter would work but I worry that
> >> someone won't
> >> > > > read the
> >> > > > > upgrade documentation and forget to create this
> temporary
> >> > parameter
> >> > > > before
> >> > > > > running the upgrade.
> >> > > > >
> >> > > > > Here's another option.
> >> > > > >
> >> > > > > Create 2 global TO parameters (http.routing.name and
> >> > > > dns.routing.name
> >> > > > > <http://http.routing.name/>) that default to tr and
> edge
> >> > > > respectively and
> >> > > > > make the ds.routing_name an optional field.
> >> > > > >
> >> > > > > in seeds.sql
> >> > > > >
> >> > > > > insert into parameter (name, config_file, value) values
&

ATC Fall Summit 2017

[Dave Neuman]

 Hey All,
It’s that time of the year again; Apache Traffic Control (incubating) will
be having our fall summit on October 17 and 18 in Atlanta, Georgia!
Please see the following wiki page and rsvp:
https://cwiki.apache.org/confluence/display/TC/Fall+2017+Summit+-+Atlanta

This email also servers as a CFP, if you have a great idea for a
presentation let me know at neu...@apache.org by September 15th.  I will
share your submissions with the other members of the PMC and we will
publish a schedule before the event.

Any questions just let me know.

Thanks,
Dave

Re: Adding support for per-DeliveryService routing names

[Dave Neuman]

I don't think that solves the issue Rawlin was describing.  The issue that
Rawlin was describing is that someone has already defined a different
routing name in traffic_router/http.properties which is no longer going to
be used after the upgrade.  The upgrade needs to somehow know about this
other routing name and use that when it creates the database column and
populates it with the pre-defined defaults (edge, tr).

Also, creating a global param doesn't help those with more than 1 CDN.

On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell 
wrote:

> Adding a temp parameter would work but I worry that someone won't read the
> upgrade documentation and forget to create this temporary parameter before
> running the upgrade.
>
> Here's another option.
>
> Create 2 global TO parameters (http.routing.name and dns.routing.name
> <http://http.routing.name/>) that default to tr and edge respectively and
> make the ds.routing_name an optional field.
>
> in seeds.sql
>
> insert into parameter (name, config_file, value) values ('
> http.routing.name',
> 'global', 'tr') ON CONFLICT (name, config_file, value) DO NOTHING;
> insert into parameter (name, config_file, value) values ('dns.routing.name
> ',
> 'global', 'edge') ON CONFLICT (name, config_file, value) DO NOTHING;
>
> in code (warning. ugly pseudo code to follow):
>
> function getRoutingName(ds) {
> return ds.routing_name if not null
> if (ds.type = HTTP) {
> return parameter.http.routing.name
> } else
> return parameter.dns.routing.name
> }
> }
>
> Just my 2 cents.
>
> On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman  wrote:
>
> > Good info Rawlin.
> > My vote would be for a parameter to be used during the upgrade.  We can
> set
> > a param called `upgrade_routing_name` or something similiar so that it is
> > obvious that it is a param used for upgrade only.  We should also
> document
> > that A) the param needs to be set before upgrade and B) TR will now
> ignore
> > the setting in the config file.  Ideally we would remove the param from
> the
> > default config and the need for the param in the code.
> >
> > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
> rawlin_pet...@comcast.com>
> > wrote:
> >
> > > Hey all,
> > >
> > > I’ve dug through this a bit more, and defaulting a new
> > > DeliveryService.routing_name
> > > column to ‘tr’ for HTTP delivery services presents an upgrade issue if
> a
> > > CDN has
> > > chosen to use a custom “http.routing.name” parameter for the Traffic
> > > Routers
> > > in that CDN (by editing the http.properties files of the Traffic
> > Routers).
> > >
> > > For instance, if “http.routing.name” has been set to “ccr”, the new
> > > routing name
> > > “tr” will break all of the clients using the old “ccr” delivery service
> > > URL.
> > >
> > > Basically we need to provide a one-time upgrade step to allow CDNs
> using
> > a
> > > custom
> > > “http.routing.name” to default the new routing_name column to that
> value
> > > for
> > > existing HTTP delivery services. What would be the best way to do this?
> > > Some options
> > > might be:
> > > 1. Add a profile parameter to the TR_PROFILE for that CDN. On upgrade,
> > > read that
> > > parameter and use it to update the routing_name for existing HTTP
> > > delivery services.
> > > After upgrade, you can safely remove the profile parameter.
> > > 2. Let the upgrade automatically default the routing_name to ‘tr’ or
> > > ‘edge’. After
> > > upgrading, manually update each HTTP delivery service to use the
> > > current
> > > “http.routing.name” in use (we could provide an API endpoint to
> > “bulk
> > > update” the
> > > routing names for all HTTP delivery services in a CDN).
> > >
> > > Note this is not an exhaustive list, this is a just a couple options
> that
> > > have come up in
> > > discussion so far. Feel free to add any more ideas to this list.
> > >
> > > After the upgrade has been completed, the “http.routing.name”
> parameter
> > > in the
> > > Traffic Router’s “http.properties” file will be ignored (same with the
> “
> > > dns.routing.name”
> > > parameter in “dns.properties” which I’m not sure can even be changed
> > > safely today).
> > >
> > > Thoughts?
> > >
> > > --Rawlin
> > >
> > > On 8/4/17,

Re: Adding support for per-DeliveryService routing names

[Dave Neuman]

Good info Rawlin.
My vote would be for a parameter to be used during the upgrade.  We can set
a param called `upgrade_routing_name` or something similiar so that it is
obvious that it is a param used for upgrade only.  We should also document
that A) the param needs to be set before upgrade and B) TR will now ignore
the setting in the config file.  Ideally we would remove the param from the
default config and the need for the param in the code.

On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin 
wrote:

> Hey all,
>
> I’ve dug through this a bit more, and defaulting a new
> DeliveryService.routing_name
> column to ‘tr’ for HTTP delivery services presents an upgrade issue if a
> CDN has
> chosen to use a custom “http.routing.name” parameter for the Traffic
> Routers
> in that CDN (by editing the http.properties files of the Traffic Routers).
>
> For instance, if “http.routing.name” has been set to “ccr”, the new
> routing name
> “tr” will break all of the clients using the old “ccr” delivery service
> URL.
>
> Basically we need to provide a one-time upgrade step to allow CDNs using a
> custom
> “http.routing.name” to default the new routing_name column to that value
> for
> existing HTTP delivery services. What would be the best way to do this?
> Some options
> might be:
> 1. Add a profile parameter to the TR_PROFILE for that CDN. On upgrade,
> read that
> parameter and use it to update the routing_name for existing HTTP
> delivery services.
> After upgrade, you can safely remove the profile parameter.
> 2. Let the upgrade automatically default the routing_name to ‘tr’ or
> ‘edge’. After
> upgrading, manually update each HTTP delivery service to use the
> current
> “http.routing.name” in use (we could provide an API endpoint to “bulk
> update” the
> routing names for all HTTP delivery services in a CDN).
>
> Note this is not an exhaustive list, this is a just a couple options that
> have come up in
> discussion so far. Feel free to add any more ideas to this list.
>
> After the upgrade has been completed, the “http.routing.name” parameter
> in the
> Traffic Router’s “http.properties” file will be ignored (same with the “
> dns.routing.name”
> parameter in “dns.properties” which I’m not sure can even be changed
> safely today).
>
> Thoughts?
>
> --Rawlin
>
> On 8/4/17, 10:19 AM, "Peters, Rawlin"  wrote:
>
> @Dave @JvD
>
> Thanks for the feedback. I think I can get on board with defaulting
> the DS columns to ‘edge’ and ‘tr’. I was thinking the CDN columns might be
> useful if the user just wants to set it CDN-wide and not individually on
> each DS, but I guess if we default it as part of the upgrade migration, we
> should also provide an API endpoint to set the routing names on all DSes in
> a CDN to a single value, thus still providing a “per-CDN” option. Would a
> “bulk” update also be useful, in case a user wants to update a handful of
> DSes to the same routing names at once?
>
> @JvD Re: TR_PROFILE vs. DS_PROFILE
> The default would come from a TR_PROFILE linked to the CDN, and the
> override would come from a DS_PROFILE linked to that specific DS. I looked
> into those options to cover all my bases, but I think adding columns to at
> least the DS table and not touching profiles at all is the better option.
>
> -Rawlin
>
> On 8/4/17, 8:04 AM, "Jan van Doorn"  wrote:
>
> Agree with Dave on
>
> [*DN] we should default the database column to "edge" for DNS and
> "tr" for*
> *http.  Then we don't have to do the null check.*
>
> If we do that, we can make the columns mandatory, and it makes
> sense
> they're not in the DS_PROFILE. Also makes it so we don't have to
> have a CDN
> wide setting. (and Rawlin, I think you mean to say DS_PROFILE
> rather than
> TR_PROFILE type to add the param to if we chose to do that?? Or
> was it the
> default that goes into TR_PROFILE and the override into
> DS_PROFILE?).
> In any case - if we make the columns NOT NULL and default them to
> "tr" and
> "edge", I'm +1 on columns in the deliveryservice table.
>
>
>
> Cheers,
> JvD
>
> On Fri, Aug 4, 2017 at 7:12 AM Eric Friedrich (efriedri) <
> efrie...@cisco.com>
> wrote:
>
> > Hey Rawlin-
> >   Zhilin has also been working on a very similar feature which
> was
> > proposed on this mailer last month:
> > https://lists.apache.org/thread.html/
> 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%
> 3Cdev.trafficcontrol.apache.org%3E
> > <
> > https://lists.apache.org/thread.html/
> 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> > >
> >
> > Can you please work him to ensure we don’t duplicate work and
> that if both
> > solutions are needed they will work together?
> >
> > On Aug 3, 2017, at 3:57 PM, Peters, Rawlin <
> rawlin_pet...@comcast.com
> > 

Re: [jira] [Created] (TC-187) Update delivery service makes SSL keys invalid

[Dave Neuman]

You are a committer too, Hank! ;)

On Thu, Aug 10, 2017 at 1:26 PM, Hank Beatty  wrote:

> It looks like this one is ready to be merged. Can someone please take a
> look at this PR https://github.com/apache/incu
> bator-trafficcontrol/pull/360?
>
> Thanks,
> Hank
>
>
>
>
>  Forwarded Message 
> Subject:[jira] [Created] (TC-187) Update delivery service makes
> SSL keys invalid
> Date:   Tue, 14 Mar 2017 06:27:41 + (UTC)
> From:   Zhilin Huang (JIRA) 
> Reply-To:   dev@trafficcontrol.incubator.apache.org
> To: iss...@trafficcontrol.incubator.apache.org
>
>
>
> Zhilin Huang created TC-187:
> ---
>
>  Summary: Update delivery service makes SSL keys invalid
>  Key: TC-187
>  URL: https://issues.apache.org/jira/browse/TC-187
>  Project: Traffic Control
>   Issue Type: Bug
>   Components: Traffic Ops
> Reporter: Zhilin Huang
> Assignee: Zhilin Huang
>
>
> Modify xml-id or subdomain in a https delivery service will make existing
> SSL keys invalid.
>
> And there is problem to generate keys if using "http and https" together
> with 1 host_regex, and 1 path_regex.
>
> BTW, the certificate returned by RESTful API is not consistent with that
> GUI.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
>

Re: [jira] [Created] (TC-151) Delivery Service XML IDs should be limited to lower-case letters

[Dave Neuman]

This looks like a feature request and not a bug.

On Thu, Aug 10, 2017 at 8:20 AM, Hank Beatty  wrote:

> Does anyone know if this has been fixed? If not, are we planning in fixing
> it for 2.1?
>
> Thanks,
> Hank
>
>
>
>
>  Forwarded Message 
> Subject:[jira] [Created] (TC-151) Delivery Service XML IDs should
> be limited to lower-case letters
> Date:   Thu, 16 Feb 2017 08:10:41 + (UTC)
> From:   Oren Shemesh (JIRA) 
> Reply-To:   dev@trafficcontrol.incubator.apache.org
> To: iss...@trafficcontrol.incubator.apache.org
>
>
>
> Oren Shemesh created TC-151:
> ---
>
>  Summary: Delivery Service XML IDs should be limited to
> lower-case letters
>  Key: TC-151
>  URL: https://issues.apache.org/jira/browse/TC-151
>  Project: Traffic Control
>   Issue Type: Bug
>   Components: Traffic Ops
> Affects Versions: 1.7.0
> Reporter: Oren Shemesh
> Priority: Minor
>
>
> The DNS system is case-insensitive. Since a delivery service XML ID is
> used as part of the FQDN of the cache being redirected to, two different
> DSs cannot differ only by case.
> This leads to the conclusion that it is best if we limit the XML IDs of
> delivery services to be lower-case only.
> This would achieve the following:
> 1. Make domain names used by TC 'conventional' (i.e. lower-case only)
> 2. Remove the possibility of a case-conflict between DSs
> 3. Currently, Traffic Router does not behave correctly when a DS XML ID
> contains upper case letters. Limiting to lower-case would prevent the need
> to fix this :-)
>
> Current problems with TR behaviour, when an XML ID contains opper-case
> letter are:
> 1. The TR sends a redirect to a host FQDN which contains a lower-case
> version of the DS XML ID
> 2. The TR does not resolve the lower-case version of the host FQDN.
>
> Here is an example to demo current bug in TR. DS XML ID is
> opencachehub-DT, TR redirects to opencachehub-dt, and then refused to
> resolve the cache name using this DS (a lot of irrelevant data was removed
> fro this text):
>
>
> $ curl -L -s -D - http://tr.opencachehub-DT.stag
> e-cdn.tc-stage.cqloud.com/video01.mp4 -v
> * Connected to tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com
> (54.244.152.242) port 80 (#0)
>
>> GET /video01.mp4 HTTP/1.1
>> Host: tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com
>> Accept: */*
>>
>> < HTTP/1.1 302 Moved Temporarily
> < Location: http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.
> cqloud.com/video01.mp4
> < Content-Length: 0
>
> <
> * Connection #0 to host tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com
> left intact
> * Issue another request to this URL: 'http://p39-edge-lab.opencache
> hub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4'
> * getaddrinfo(3) failed for p39-edge-lab.opencachehub-dt.s
> tage-cdn.tc-stage.cqloud.com:80
> * Couldn't resolve host 'p39-edge-lab.opencachehub-dt.
> stage-cdn.tc-stage.cqloud.com'
>
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
>

Re: [jira] [Updated] (TC-118) Traffic Ops should get it's name from some confioguration when generating CrConfig

[Dave Neuman]

To my knowledge it has not been fixed and will not be fixed for 2.1.

On Thu, Aug 10, 2017 at 8:09 AM, Hank Beatty  wrote:

> Does anyone know if this has been fixed? If not, are we planning in fixing
> it for 2.1?
>
> Thanks,
> Hank
>
>
>
>
>  Forwarded Message 
> Subject:[jira] [Updated] (TC-118) Traffic Ops should get it's name
> from some confioguration when generating CrConfig
> Date:   Wed, 14 Jun 2017 19:00:01 + (UTC)
> From:   Ryan Durfey (JIRA) 
> Reply-To:   dev@trafficcontrol.incubator.apache.org
> To: iss...@trafficcontrol.incubator.apache.org
>
>
>
>  [ https://issues.apache.org/jira/browse/TC-118?page=com.atlass
> ian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Ryan Durfey updated TC-118:
> ---
> Labels: configuration crconfig  (was: )
>
> Traffic Ops should get it's name from some confioguration when generating
>> CrConfig
>> 
>> --
>>
>> Key: TC-118
>> URL: https://issues.apache.org/jira/browse/TC-118
>> Project: Traffic Control
>>  Issue Type: Bug
>>  Components: Traffic Ops
>>Affects Versions: 1.7.0
>>Reporter: Oren Shemesh
>>Priority: Minor
>>  Labels: configuration, crconfig
>>
>> The code that generates the CrConfig has a problem when creating the
>> "stat" section.
>> It fills values for that section, such as "tm_host", based on the HTTP
>> headers found in the request that triggered the CrConfig snapshot:
>> Here is a snippet from traffic_ops/app/lib/UI/Topology.pm:
>> $data_obj->{'stats'}->{'tm_path'}= $self->req->url->path->{'path'
>> };
>> $data_obj->{'stats'}->{'tm_host'}= $self->req->headers->host;
>> I find this to be a problem for two reasons:
>> This code assumes that it is being run from the context of an HTTP
>> transaction, which to me sounds like contaminating the logic of actually
>> creating the CrConfig with details from the upper layer which currently
>> uses this logic. For example, if one would want to run this code from a
>> different path (Maybe in a unit test), it would be a problem.
>> If the traffic ops is accessed through a NAT, then the host name known to
>> the HTTP client issuing the 'Snapshot CrConfig' request is not necessarily
>> the same as the traffic ops host name known to the other components of the
>> system, e.g. the traffic router that uses this information.
>> (This is how I found out about this problem - we are experimenting with
>> deploying TC in the cloud (Amazon EC2) and the host name visible to the
>> outside world is not the same as the host names used internally)
>> I believe that tm_host should come from the database (Currently there is
>> no entry from the traffic ops itself, but such an entry can be created for
>> this purpose), or from cdn.conf.
>>
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>
>

Re: New Committer - Rob Butts

[Dave Neuman]

Congratulations, Rob!

On Thu, Aug 10, 2017 at 5:26 AM, Eric Friedrich  wrote:

> The Project Management Committee (PMC) for Apache Traffic Control
> (incubating)
> has invited Rob Butts to become a committer and we are pleased
> to announce that he has accepted.
>
> Rob began his Traffic Control contributions in November of 2015. Rob's
> contributions are wide ranging from Dockerization and build processes, to
> experimental Traffic Ops and most importantly the GoLang evolution of
> Traffic Monitor. Rob is active within the community, participating in
> mailing list threads and presenting at ApacheCon summits.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
> Being a PMC member enables assistance with the management
> and to guide the direction of the project.
>

Open Issues against 2.1

[Dave Neuman]

Hey All,

I was looking at Jira and noticed that we have 53 unresolved issues against
TC 2.1 [1].  Of these 53, 6 are Critical or Blocker.  I know that we Hank
just cut the 2.1 branch and is thinking about putting out an RC0.  In my
opinion we need to address these issues before RC0 is released for
testing.  If you have some time can you please take a look at the open
issues and help out by either submitting a PR, moving to a different
release, or closing the issue if it truly is resolved?

Thanks,
Dave



[1] https://issues.apache.org/jira/browse/TC-489?filter=12341560

Re: Edge server default config

[Dave Neuman]

I added the link to the downloads page after I sent my email.  It was only
in the docs before that.
So, it is more obvious now ;)

--Dave

On Tue, Aug 8, 2017 at 6:56 AM, Dewayne Richardson 
wrote:

> When:   Read · Tue, Aug 8.
> <https://timyo.com/?utm_source=expectationheader&utm_medium=email>
> [image: Timyo expectation line]
> There is a link on the downloads page that shows "Default Profiles"
> http://trafficcontrol.incubator.apache.org/downloads/index.html
>
> As well as "Admin Guide"
> http://trafficcontrol.incubator.apache.org/docs/latest/admin/traffic_ops/
> default_profiles.html
>
> Where else could I add the link to make it obvious?
>
> -Dew
>
>
>
> On Fri, Aug 4, 2017 at 9:40 AM, Dave Neuman  wrote:
>
> > We really should make it so you can navigate to those through the
> Downloads
> > page on our website.  Right now you have to know about them or get the
> link
> > for the docs.
> >
> > --Dave
> >
> > On Fri, Aug 4, 2017 at 8:57 AM, Burak Sarp  >
> > wrote:
> >
> > > yes thats it,
> > > thanks,Sarp
> > >
> > > On Friday, August 4, 2017 5:35 PM, Dewayne Richardson <
> > > dewr...@gmail.com> wrote:
> > >
> > >
> > >  When:  Read · Fri, Aug 4.
> > > <https://timyo.com/?utm_source=expectationheader&utm_medium=email>
> > > [image: Timyo expectation line]
> > > I think this is what you are talking about:
> > >
> > > http://trafficcontrol.incubator.apache.org/docs/
> > latest/admin/traffic_ops/
> > > default_profiles.html?highlight=default
> > >
> > > -Dew
> > >
> > > On Fri, Aug 4, 2017 at 8:22 AM, Burak Sarp
>  > >
> > > wrote:
> > >
> > > > Hi,
> > > > I am using latest version of ops,Actually i need the default config
> > files
> > > > for trafficserver while installation, where they come from?
> > > > ThanksSarp
> > > >
> > > >
> > > > Sent from Yahoo Mail for iPhone
> > > >
> > > >
> > > > On Friday, August 4, 2017, 5:14 PM, Gelinas, Derek <
> > > > derek_geli...@comcast.com> wrote:
> > > >
> > > > By default config do you mean the configuration after trafficserver
> > > > installation or the files as generated by traffic ops?  What version
> of
> > > > traffic ops?
> > > >
> > > > On Aug 4, 2017, at 10:13 AM, Burak Sarp  <
> > > > mailto:sarp_bu...@yahoo.com.INVALID>> wrote:
> > > >
> > > >
> > > > Hi all,
> > > > How can i reach edge server's default config?Such as cache.config or
> > > > storage.config etc.
> > > > Thanks,Sarp
> > > >
> > > > Sent from Yahoo Mail for iPhone
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>

Re: Edge server default config

[Dave Neuman]

We really should make it so you can navigate to those through the Downloads
page on our website.  Right now you have to know about them or get the link
for the docs.

--Dave

On Fri, Aug 4, 2017 at 8:57 AM, Burak Sarp 
wrote:

> yes thats it,
> thanks,Sarp
>
> On Friday, August 4, 2017 5:35 PM, Dewayne Richardson <
> dewr...@gmail.com> wrote:
>
>
>  When:  Read · Fri, Aug 4.
> 
> [image: Timyo expectation line]
> I think this is what you are talking about:
>
> http://trafficcontrol.incubator.apache.org/docs/latest/admin/traffic_ops/
> default_profiles.html?highlight=default
>
> -Dew
>
> On Fri, Aug 4, 2017 at 8:22 AM, Burak Sarp 
> wrote:
>
> > Hi,
> > I am using latest version of ops,Actually i need the default config files
> > for trafficserver while installation, where they come from?
> > ThanksSarp
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Friday, August 4, 2017, 5:14 PM, Gelinas, Derek <
> > derek_geli...@comcast.com> wrote:
> >
> > By default config do you mean the configuration after trafficserver
> > installation or the files as generated by traffic ops?  What version of
> > traffic ops?
> >
> > On Aug 4, 2017, at 10:13 AM, Burak Sarp  > mailto:sarp_bu...@yahoo.com.INVALID>> wrote:
> >
> >
> > Hi all,
> > How can i reach edge server's default config?Such as cache.config or
> > storage.config etc.
> > Thanks,Sarp
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> >
>
>
>

Re: Adding support for per-DeliveryService routing names

[Dave Neuman]

@Eric
It looks like Zhilin's proposal is for custom delivery service domains (eg
instead of "tr.foo.domain.com" you can have "tr.foo.otherdomain.com") while
Rawlins is for custom routing names (eg instead of "tr.foo.domain.com" you
can have "bar.foo.domain.com").  I think the two features are similar but
different.  Would you agree or am I misunderstanding?
@Rawlin and @Zhilin if you have WIP code maybe you could open a WIP PR and
we can take a look to see if there will be conflicts?

--Dave

On Fri, Aug 4, 2017 at 8:59 AM, Durfey, Ryan 
wrote:

> Yeah, I just rethought that.
>
> I was envisioning   http://servicename.customername.cdn_domain/  where we
> could get a cert for “*.customername.cdn_domain/” for multiple customer
> services.
>
> However, we currently have to use the format http://servicename-
> cusotmername.cdn_domain/ where a wildcard cert would not be applicable.
>
> Apologies for the confusion.
>
>
> Ryan DurfeyM | 303-524-5099
> CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com cdn_supp...@comcast.com>
>
>
> From: David Neuman 
> Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> Date: Friday, August 4, 2017 at 8:40 AM
> To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> Subject: Re: Adding support for per-DeliveryService routing names
>
> @Ryan:
>
> “edge.” Limits our ability to use wildcard ssl certs for DNS routed
> services for similar customer services which can save a lot of time, cost,
> and hassle.
>
> Can you explain more?  I don't see the need for wildcard certs when Traffic
> Router returns only one FQDN for a DNS routed Deliveryservice?  If you are
> talking about a "future feature" then we should worry about that then.
>
> On Fri, Aug 4, 2017 at 8:09 AM, Durfey, Ryan  mailto:ryan_dur...@comcast.com>>
> wrote:
>
> Random thought on this…
>
> “edge.” Limits our ability to use wildcard ssl certs for DNS routed
> services for similar customer services which can save a lot of time, cost,
> and hassle.
> “tr.” Makes sense for HTTP 302 routed services because you can use
> wildcard certs for the server hostname that replaces the “tr.” in the
> domain.  Is it worth considering “tr.” for http routed and nothing for DNS
> routed ie. “xml-id.cdn_domain”?
>
> Ryan DurfeyM | 303-524-5099
> CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com cdn_supp...@comcast.com> cdn_supp...@comcast.com>
>
>
> From: Jan van Doorn mailto:j...@knutsel.com>>
> Reply-To: "dev@trafficcontrol.incubator.apache.org trafficcontrol.incubator.apache.org>" <
> dev@trafficcontrol.incubator.apache.org trafficcontrol.incubator.apache.org>>
> Date: Friday, August 4, 2017 at 8:04 AM
> To: "dev@trafficcontrol.incubator.apache.org trafficcontrol.incubator.apache.org>" <
> dev@trafficcontrol.incubator.apache.org trafficcontrol.incubator.apache.org>>
> Subject: Re: Adding support for per-DeliveryService routing names
>
> Agree with Dave on
>
> [*DN] we should default the database column to "edge" for DNS and "tr" for*
> *http.  Then we don't have to do the null check.*
>
> If we do that, we can make the columns mandatory, and it makes sense
> they're not in the DS_PROFILE. Also makes it so we don't have to have a CDN
> wide setting. (and Rawlin, I think you mean to say DS_PROFILE rather than
> TR_PROFILE type to add the param to if we chose to do that?? Or was it the
> default that goes into TR_PROFILE and the override into DS_PROFILE?).
> In any case - if we make the columns NOT NULL and default them to "tr" and
> "edge", I'm +1 on columns in the deliveryservice table.
>
> Cheers,
> JvD
>
> On Fri, Aug 4, 2017 at 7:12 AM Eric Friedrich (efriedri) <
> efrie...@cisco.com >>
> wrote:
>
> Hey Rawlin-
> Zhilin has also been working on a very similar feature which was
> proposed on this mailer last month:
> https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f
> 3897da37ef5b24ac452a17cabb@%3Cdev.trafficcontrol.apache.org%3E 3897da37ef5b24ac452a17cabb@%3Cdev.trafficcontrol.apache.org%3E>
> <
> https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f
> 3897da37ef5b24ac452a17cabb@
> >
>
> Can you please work him to ensure we don’t duplicate work and that if both
> solutions are needed they will work together?
>
> On Aug 3, 2017, at 3:57 PM, Peters, Rawlin  mailto:rawlin_pet...@comcast.com><
> mailto:rawlin_pet...@comcast.com>
>  %3e> comcast.com%3e%3e>>
> wrote:
>
> Sorry, Outlook converted my numbered list poorly. I’ve corrected the
> numbering (items 1-3) below.
>
> On 8/3/17, 1:52 PM, "Peters, Rawlin"  rawlin_pet...@comcast.com> rawlin_pet...@comcast.com> r

Re: Adding support for per-DeliveryService routing names

[Dave Neuman]

Inline

On Thu, Aug 3, 2017 at 1:57 PM, Peters, Rawlin 
wrote:

> Sorry, Outlook converted my numbered list poorly. I’ve corrected the
> numbering (items 1-3) below.
>
> On 8/3/17, 1:52 PM, "Peters, Rawlin"  wrote:
>
> Hello All,
>
> I’ve been working on adding support for configurable per-CDN and
> per-DeliveryService routing names [1] (what are currently
> hardcoded/defaulted to ‘edge’ and ‘tr’ for DNS and HTTP Delivery Services,
> respectively), and I have a few things to propose.
>
>
>   1.  Add a column to the CDN table for the DNS and HTTP routing names.
>
>
>
> I’ve currently been working off the assumption that per-CDN routing
> names would be configurable by adding ‘http.routing.name’ and ‘
> dns.routing.name’ parameters to a profile of type TR_PROFILE using the
> ‘CRConfig.json’ config file. To me this seems like bad UX because the user
> has to click through multiple steps and fill in multiple fields in the UI
> just to change the CDN’s routing names. It also requires joining a few
> different tables in the DB just to find the parameters per-CDN. For that
> reason, I think it would be better if ‘dns_routing_name’ and
> ‘http_routing_name’ were added as columns of the ‘cdn’ table, and changing
> them via the UI would follow the same process as choosing the CDN’s domain
> name. Because the routing names would be the CDN-wide defaults, the ‘Edit
> CDN’ window feels like the most natural place to put it.
>
> [DN] +1 from me


>
>   2.  Values for per-DeliveryService routing names could live in one
> of a couple different areas:
>  *   New columns in the delivery_service table
>  *   Parameters in a DS Profile
>
> As the developer, my vote would be for Option A because it seems like
> it would lead to cleaner code in Traffic Ops because the routing names
> would be readily-available when handling a DeliveryService. You wouldn’t
> have to also fetch its profile then dig through it to find the routing
> names. A downside could be that adding columns to an already-overcrowded
> table isn’t ideal.
>
> Option B is less appealing to me but might have some advantages such
> as keeping the number of columns down in the DeliveryService table.
> However, DS Profiles currently seem to be geared more towards the
> Multi-site Origin feature in generating specific ATS configuration
> (parent.config) and less towards a “junk drawer for optional config”. As
> the routing names would affect the entire DS and multiple config files, it
> doesn’t seem right to have it as a profile parameter using ‘CRConfig.json’
> as the config file. I wasn’t around when DS Profiles were introduced, so if
> you are more familiar with their purpose/origin and think this is a good
> fit for them, I’d like to hear your advice.
>
>
[DN] I don't really mind either way, but I lean towards adding a column to
the DS table.  Just because we already have a lot of columns isn't a good
reason to not add another one.  I assume that in most of the places that we
are setting the routing name we already have the DS "object" in memory so
it would probably avoid an extra call to the database to get a parameter.

>
>   3.  If per-DeliveryService routing names are not set explicitly for
> a DS (i.e. the column is null), then the DS will use the per-CDN routing
> names as a default. If the per-CDN routing names are unset, they will
> default to the current values of ‘edge’ and ‘tr’. So the lookup hierarchy
> would be DS.routing_names -> CDN.routing_names -> default ‘edge/tr’.
>

[DN] we should default the database column to "edge" for DNS and "tr" for
http.  Then we don't have to do the null check.

>
> I’d like to know what you think of these proposals, and any
> advice/feedback is welcome.
>
> Best regards,
> Rawlin
>
> [1] https://issues.apache.org/jira/browse/TC-287
>
>
>

Re: Starting the 2.1 Branch for Next Release of TC

[Dave Neuman]

+1 from me.  Thanks Hank.


On Tue, Aug 1, 2017 at 6:58 AM, Hank Beatty  wrote:

> Hello All,
>
> How does getting all the changes in this week and I'll cut the 2.1 branch
> first thing Monday morning (8/7/17 6AM Eastern)?
>
> Thanks,
> Hank
>
>
> On 07/31/2017 03:58 PM, Dave Neuman wrote:
>
>> Hey Hank,
>> Are you still planning on cutting a release sometime this week?
>> I have a few PRs that I was planning on merging and wanted to see if I
>> have
>> some time.
>>
>> Thanks,
>> Dave
>>
>> On Tue, Jul 18, 2017 at 2:46 PM, Nir Sopher  wrote:
>>
>> Hi Hank,
>>> With guidance and review by Jeremy, we are working on the first phase of
>>> tenancy for version 2.1.
>>> Tenants were already introduced to the TC database, and next to get in
>>> are
>>> the tenancy based access control enforcement - for users as well as
>>> delivery services.
>>> We expect it to be fully in master within 2 weeks.
>>> Thanks,
>>> Nir
>>>
>>>
>>> On Tue, Jul 18, 2017 at 3:33 PM, Hank Beatty  wrote:
>>>
>>> Good Morning,
>>>>
>>>> I am very excited to be the Release Manager for the 2.1 version of TC.
>>>>
>>>> We are getting ready to start the 2.1 branch of TC. We would like to do
>>>> this in the next 2 weeks.
>>>>
>>>> Are there any know issues that would prevent this from happening?
>>>>
>>>> Are there any features that can be wrapped up and go into this version?
>>>>
>>>> Any other comments or suggestions?
>>>>
>>>> Thanks,
>>>> Hank
>>>>
>>>>
>>>
>>

Re: Starting the 2.1 Branch for Next Release of TC

[Dave Neuman]

Hey Hank,
Are you still planning on cutting a release sometime this week?
I have a few PRs that I was planning on merging and wanted to see if I have
some time.

Thanks,
Dave

On Tue, Jul 18, 2017 at 2:46 PM, Nir Sopher  wrote:

> Hi Hank,
> With guidance and review by Jeremy, we are working on the first phase of
> tenancy for version 2.1.
> Tenants were already introduced to the TC database, and next to get in are
> the tenancy based access control enforcement - for users as well as
> delivery services.
> We expect it to be fully in master within 2 weeks.
> Thanks,
> Nir
>
>
> On Tue, Jul 18, 2017 at 3:33 PM, Hank Beatty  wrote:
>
> > Good Morning,
> >
> > I am very excited to be the Release Manager for the 2.1 version of TC.
> >
> > We are getting ready to start the 2.1 branch of TC. We would like to do
> > this in the next 2 weeks.
> >
> > Are there any know issues that would prevent this from happening?
> >
> > Are there any features that can be wrapped up and go into this version?
> >
> > Any other comments or suggestions?
> >
> > Thanks,
> > Hank
> >
>

Re: Can you fix your footers?

[Dave Neuman]

The website has been updated:  http://trafficcontrol.apache.org/index.html

Thanks,
Dave

On Mon, Jul 31, 2017 at 7:28 AM, Dave Neuman  wrote:

> Hi John,
> I can take care of it today.
>
> Thanks,
> Dave
>
> On Sun, Jul 30, 2017 at 1:36 PM, John D. Ament 
> wrote:
>
>> Dear TrafficControl,
>>
>> Would you mind fixing the footers on your website?  We've updated the
>> incubator logo months ago, and the disclaimer only appears on your
>> homepage
>> (not on other pages).
>>
>> John
>>
>
>

Re: Can you fix your footers?

[Dave Neuman]

Hi John,
I can take care of it today.

Thanks,
Dave

On Sun, Jul 30, 2017 at 1:36 PM, John D. Ament 
wrote:

> Dear TrafficControl,
>
> Would you mind fixing the footers on your website?  We've updated the
> incubator logo months ago, and the disclaimer only appears on your homepage
> (not on other pages).
>
> John
>

Re: Proposal for PR requirements

[Dave Neuman]

I personally don't think that we should require a Jira for every single
PR.  I think blanket statements like "you must create a Jira ticket for
each PR", while made with good intentions, are too hard to enforce, don't
take every situation into account, and are sometimes a deterrent to new
contributors.  If Joe somebody from the internet wants to submit a PR, we
should welcome it and not say "we are not accepting this without first
creating a Jira account and then creating a Jira ticket".

The changelog thing is a real problem.  We had a plan to have an
auto-generated changelog, but that was reliant on us moving to full github
which we haven't done yet.  I think maybe the changelog conversation might
need to be re-visited.

Have you taken a look at our contributing guide[1] on github?  It already
outlines a lot of the things you are proposing here and I think its the
best place to have our PR requirements.

I like Jason's idea, though not sure if it is possible.

[1]
https://github.com/apache/incubator-trafficcontrol/blob/master/CONTRIBUTING.md

Thanks,
Dave

On Tue, Jul 18, 2017 at 8:08 PM, Jason Tucker 
wrote:

> Do you know if the the apache jenkins instance supports PR-triggered
> builds? If so, then repo branches can be protected so that PRs can only be
> merged if the build status is successful. Might be a good safeguard to have
> in place, if we have the ability to enable it on the jenkins side.
>
> __Jason
>
> On Wed, Jul 19, 2017 at 12:19 AM, Gelinas, Derek <
> derek_geli...@comcast.com>
> wrote:
>
> > As the project grows in complexity and the speed of updates, we're
> finding
> > a real need for changelogs and a reduction in the number of commits.  At
> > this time, creating a changelog over even a short period of time is a
> > tedious and time consuming activity, and it is making even incremental
> > updates difficult for us here at Comcast.
> >
> > I would like to propose the following:
> >
> >
> >   *   Each PR must have a linked jira issue.  This is as simple as
> > creating the ticket and then adding [TC-XXX] to the beginning of the PR
> > title.  The jira ticket title should briefly describe the fix or new
> > feature in a manner which lends itself to inclusion in a changelog.
> >   *   Large changes should have as much information as possible about the
> > nature of the change and how this change affects the system.
> >   *   Testing should be done on all changes before the PR is submitted!
> > Please do not submit anything that has not been fully tested, regardless
> of
> > how simple or obvious it may seem.  You are the first line of defense
> > against bugs!  If the work is not yet complete, be sure to add [WIP] to
> the
> > title of the PR.
> >   *   Commits should be squashed as much as possible before the PR is
> > submitted.  27 commits for minor changes make review and later analysis
> > very difficult.  Commit messages should be descriptive so it is clear
> what
> > was changed.
> >   *   New features or changes to functionality should include
> > documentation changes whenever possible.
> >   *   Integration testing should be included whenever possible - we now
> > have automated integration testing, so this is another valuable method to
> > isolate bugs before they hit the field.
> >   *   When in doubt, be clear about what you are doing!
> >
> > I would also like to propose that if these requirements are not met
> > without specific reasoning, PRs should be rejected until they are
> corrected.
> >
> > Derek
> >
>

Re: 2.1 RM

[Dave Neuman]

Awesome, thanks Hank!
Now that we have a RM, I think we can start the conversation of when to
branch.  For your first task as RM do you want to do that, or do you want
me to?
Thanks,
Dave

On Mon, Jul 17, 2017 at 2:12 PM, Dewayne Richardson 
wrote:

> When:   Read · Mon, Jul 17.
> <https://timyo.com/?utm_source=expectationheader&utm_medium=email>
> [image: Timyo expectation line]
> Yes, Hank thank you!
>
> On Mon, Jul 17, 2017 at 1:28 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
> > Hey Hank-
> >   Many Thanks. Your RM baseball cap will be in the mail!
> >
> > I need to clean up the Release Management wiki page a bit for you. I’ll
> > try to do that in the next few days.
> >
> > When’s the release branch get pulled? ;-)
> >
> > —Eric
> >
> >
> >
> > > On Jul 17, 2017, at 3:03 PM, Dan Kirkwood  wrote:
> > >
> > > Thanks,  Hank..feel free to ping either me or Eric if anything is
> > > unclear in the release manager notes.
> > >
> > > -dan
> > >
> > > On Mon, Jul 17, 2017 at 12:56 PM, Hank Beatty 
> > wrote:
> > >> Hi Dave,
> > >>
> > >> I would like to volunteer.
> > >>
> > >> Thanks,
> > >> Hank
> > >>
> > >> On 07/05/2017 03:38 PM, Dave Neuman wrote:
> > >>>
> > >>> Hey All,
> > >>> Now that 2.0 has officially passed the project and IPMC vote (YAY!),
> > it's
> > >>> time to start thinking about 2.1.  I don't think we have identified a
> > >>> release manager for the 2.1 release yet, would anyone like to
> > volunteer?
> > >>>
> > >>> Thanks,
> > >>> Dave
> > >>>
> > >>
> >
> >
>

Re: Promote Golang Traffic Monitor to Default

[Dave Neuman]

+1 on the rename

On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn  wrote:

> +1
>
> On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson 
> wrote:
>
> > When:   Read · Mon, Jul 17.
> > 
> > [image: Timyo expectation line]
> > +1
> >
> > On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo  wrote:
> >
> > > For the most part, it's a drop in replacement for the Java version,
> > > and based on our own experience it seems to work exactly as the Java
> > > version would, including co-existence. There is a TO API dependency
> > > for monitoring.json that the Java version does not have, and I'm not
> > > sure what the history is with that endpoint and how far back we could
> > > remain compatible. Traffic Router does not care what version of
> > > Traffic Monitor it talks to, as the format of cr-states.json has not
> > > changed. Same goes for TM and ATS. I believe we had co-existence
> > > running in production going back to the 1.8.x releases.
> > >
> > > Keep in mind that the intent is to drive users toward using the Golang
> > > component by default starting with the 2.1.0 (or maybe 2.2.0?) release
> > > while still allowing one to build, run, or contribute to the Java
> > > version until our next major release (3.0.0). The intent is not to
> > > give people a drop in replacement that works with prior versions; we
> > > have not tested that thoroughly across all versions, and while it
> > > might work, we should think of the Golang Traffic Monitor as a 2.0.x
> > > and onward component. I think that statement holds for most of our
> > > components; we wouldn't want to run a 1.7 Traffic Stats with a 2.0.0
> > > Traffic Ops system. 1.7 is ancient, and have we ever really done
> > > backward compatibility testing with versions?
> > >
> > > To this end, if we do decide to make the Golang version the default in
> > > the future, at a minimum we will need to provide release notes that
> > > explain how to convert the Java configuration to the Golang version's
> > > config. Ideally we would provide a simple script to convert the
> > > configuration for our users, potentially running it as a postinstall
> > > scriptlet in the RPM if the Java version is already installed.
> > > Theoretically we could `yum upgrade traffic_monitor` and seamlessly
> > > move from Java to Golang.
> > > --
> > > Thanks,
> > > Jeff
> > >
> > >
> > > On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
> > >  wrote:
> > > > I think I remember Rob making this point in Miami, but all of TMs
> APIs
> > > (REST, CRConfig, Health.json, etc…) are identical between the Java and
> > > Golang version, right?
> > > >
> > > > What about compatibility with earlier versions of TC?
> > > >
> > > > For example:
> > > > - Can a TC1.7 traffic ops configure a Golang TM?
> > > > - Does the Golang TM have any dependencies on a certain version of
> > > TrafficServer or astats?
> > > > - Whats the minimum required version of Traffic Router to use the
> > Golang
> > > TM?
> > > > - I know Golang TMs can gossip with Java TMs, but can we mix versions
> > > here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?
> > > >
> > > > —Eric
> > > >
> > > >
> > > >> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo  wrote:
> > > >>
> > > >> Hi all,
> > > >>
> > > >> We currently have two versions of Traffic Monitor: Java and golang.
> > > >> When we build all components, as far as I know, it results in a race
> > > >> condition between the two, as the resulting RPMs have the same
> > > >> filename. A PR[1] was opened to address the issue and the approach
> was
> > > >> to add `_go` to the version string used for the golang version's
> RPM.
> > > >>
> > > >> Rob and I both think we (Comcast) have enough experience running the
> > > >> golang version that we have identified and corrected any major
> issues
> > > >> and that it is stable enough to be the preferred Traffic Monitor
> hence
> > > >> forth.
> > > >>
> > > >> Therefore, I propose that within the project's directory structure,
> > we:
> > > >>  1) rename traffic_monitor to traffic_monitor_legacy
> > > >>  2) rename traffic_monitor_golang to traffic_monitor
> > > >>
> > > >> ..then work with the person that submitted the PR to take the same
> > > >> approach, except change the Java version's RPM name to contain
> > > >> `_legacy`.
> > > >>
> > > >> I realize that this is a fairly significant change, the type that we
> > > >> typically reserve for major releases. The next major release, 3.0.0,
> > > >> is likely to be some time out in the future, and I don't know that
> we
> > > >> need to wait for it in order to make this change.
> > > >>
> > > >> How does the group feel about the above proposal, and executing on
> it
> > > >> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
> > > >> actually prepare the 3.0.0 release, we can remove the Java version
> > > >> from the codebase entirely. Obviously this could impact anyone that
> > > >> has automated CI syst

2.1 RM

[Dave Neuman]

Hey All,
Now that 2.0 has officially passed the project and IPMC vote (YAY!), it's
time to start thinking about 2.1.  I don't think we have identified a
release manager for the 2.1 release yet, would anyone like to volunteer?

Thanks,
Dave

Re: Support custom routing selection logics

[Dave Neuman]

Have you taken a look at how we did the neustar geo location provider
integration?  That should give you some ideas.

On Fri, Jun 23, 2017 at 10:58 AM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Thanks John-
>   A few more questions:
>
>- Are there any extensions to the Track class needed here?
>
>- Can we indicate in the access log how the plugins caused the request
> to be routed? If a plugin wanted to add additional detail to a Track object
> is that possible?
>
>- Can a plugin interact with the stats API at all (if we want to see
> how many requests the plugin is serving or what the status of the
> connection between plugin and external system is)?
>
>- I assume the plugin may need to have some context associated with it.
> Do you have a prototype of what the callback made to the plugin will look
> like?
>
> Also just for information because I think its an important point- such a
> plugin would be statically compiled into the TR “jar"
>
> —Eric
>
>
>
> > On Jun 23, 2017, at 10:49 AM, John Shen (weifensh) 
> wrote:
> >
> > Traffic Router currently support Coverage Zone File based routing and
> Geolocation based routing. We are planning to add another type of routing
> selection logic. Since this part of code will not be put into open source
> code, we are considering how to integrate the new routing selection code
> into current TR.
> >
> > One solution is to make Traffic Router support routing selection
> plugins. Then we implement our new routing selection logic as a plugin,
> which is still statically built into the TR package. Other types of new
> routing selection plugins could also be integrated into TR easily. The plan
> is to add several hooks in the method of:
> > protected List TrafficRouter::selectCaches(final Request
> request, final DeliveryService ds, final Track track);
> >
> > There could be 4 possible hooks to be added: PRE_CZF_HOOK,
> POST_CZF_HOOK, PRE_GEO_HOOK, and POST_GEO_HOOK. They will be processed
> during different stages in TrafficRouter::selectCaches(). Plugins could be
> registered in each hook. If there are multiple plugins in each hook, they
> will be processed in the order of how they are registered. Any plugin
> returning non-empty caches means a cache selection is successful for a
> certain request, thus no further plugin or CZF/GEO based routing is needed
> for the request.
> >
> > Any plugin will be created and registered during system initialization.
> A possible point to do so is when ConfigHandler is initialized. And a
> plugin would have following interfaces:
> > loadConfig(); // called when CRConfig is updated
> > selectCaches(); // called in TrafficRouter::selectCaches() hooks
> >
> > Please help to comment this proposal. Thanks.
> >
> > Best regards,
> > John
> >
>
>