Re: Traffic Server Secondary Streaming IPs Design

I would prefer a consistent way to store all interface and IP address information. Its good database design practice to store similar information in similar tables (i.e. all IP info in 1 table) rather than keep some IPs in the server table and some IPs in another table. I also think this

Re: Traffic Control Last-resort Routing

Hey John- 1)“Last Resort Alternate domain” is incredibly similar to the Bypass FQDN. I’d rather see us enhance the Bypass FQDN with an optional scheme and port number, rather than add something so close in functionality. 2) Is there a definite need for the “To content origin” checkbox? If this

Re: Question about the poll model of the Traffic Monitor

Hi Dave, I could not find the edit button on this page. Looks like I do not have the authority to add the doc. Thanks, Zhilin On 03/04/2018, 2:43 AM, "David Neuman" wrote: Hi Zhilin, Is it possible to get this design doc added to our wiki? I create a

Re: Traffic Server Secondary Streaming IPs Design

Hi Nir, Thanks a lot for your comments! As Eric stated, we are using a secondary (streaming) IP to serve specific delivery service. In other words, a primary or secondary IP is assigned to a specific delivery service. So there is no traffic move. For your comments: > Why not, instead of

Re: Traffic Server Secondary Streaming IPs Design

Hi Mark, Thanks for your comments. Please check my reply in another thread: If we all agreed to use unified tables for all IPs and/or interfaces: primary, management, secondary, then there need to be two tables: IP and interface. And in the server table, we need to replace the original

[VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC3

Hello All, I've prepared a release for v2.2.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.1.0:

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

-1 :( Removing the x/crypto fixes the previous issue regarding both crypto inclusion and compatibility, but we also have to remove the references from the LICENSE file. Weasel says these are the problems: Error Extra-License!

Updated TO API guidelines

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

Podling Report Reminder - April 2018

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

Re: Traffic Server Secondary Streaming IPs Design

Updated the DB schema in section 3.1.1.4 Thanks, Zhilin On 04/04/2018, 11:02 AM, "Zhilin Huang (zhilhuan)" wrote: Good points. I am happy to make this change in the design doc. Thanks, Zhilin On 03/04/2018, 8:17 PM, "Eric Friedrich

Re: Traffic Server Secondary Streaming IPs Design

Good points. I am happy to make this change in the design doc. Thanks, Zhilin On 03/04/2018, 8:17 PM, "Eric Friedrich (efriedri)" wrote: I would prefer a consistent way to store all interface and IP address information. Its good database design practice to store

Re: Traffic Control Last-resort Routing

Hey Eric, Thanks a lot for your comments. Please refer to my reply inline. Thanks, John On 2018/4/3, 8:36 PM, "Eric Friedrich (efriedri)" wrote: Hey John- 1)“Last Resort Alternate domain” is incredibly similar to the Bypass FQDN. I’d rather see us enhance the

Re: Question about the poll model of the Traffic Monitor

Thanks, Eric. It works. I added the design doc which links to the google doc. Thanks, Zhilin On 03/04/2018, 8:19 PM, "Eric Friedrich (efriedri)" wrote: Zhilin- I added you to the Wiki permissions. Please try again —Eric > On Apr 3, 2018, at

Re: Traffic Server Secondary Streaming IPs Design

+1 Note that beyond the DB, the change should also be reflected into the cr-config. As I see it, a flexible model may be built of the below items: 1 - Edge server. 2- Interface 3. IPs The Interface (or should it be called "delivery unit") is the element we redirect the traffic to and which is