Re: Traffic Server Secondary Streaming IPs Design

Thanks a lot for the comments, Rob and Dew. The secondary IP feature will modify following existing APIs: GET /api/1.2/deliveryserviceserver POST /api/1.2/deliveryserviceserver GET /api/1.2/deliveryservices/:id/servers POST /api/1.2/deliveryservices/:xml_id/servers CRConfig related APIs ATS

Re: Traffic Server Secondary Streaming IPs Design

I agree with Rob, please explore the Go implementation, we're reaching critical mass (most of the critical foundational routes are complete) with the API endpoints written in Go with the big one /deliveryservices being the biggest and most important to complete. -Dew On Fri, Apr 20, 2018 at 8:37

Re: Traffic Server Secondary Streaming IPs Design

@weifensh We're hoping to have most of the API endpoints, not including ATS config files, in the next month or so. I'm currently working on `deliveryservices`, and @dylanvoltz is on `servers`, the two biggest, and they're both mostly done. They should be code-complete by the end of next week, and

Re: Traffic Server Secondary Streaming IPs Design

Hi Nir and all, Do you know when will the full GO version of Traffic Ops be ready in the master branch? The reason I raise this question is that we are starting to implement this feature, and if some of the APIs involving this feature are still in Perl and will not be ported to GO very soon,

Re: Traffic Server Secondary Streaming IPs Design

To be clear, "immutable" here means the IP could not be removed, but allow modification. And streaming "priority" is better be Delivery Service based than server based. Thanks, Zhilin On 10/04/2018, 4:12 PM, "Zhilin Huang (zhilhuan)" wrote: Hey Nir, Thanks

Re: Traffic Server Secondary Streaming IPs Design

Hey Nir, Thanks a lot for your comments. Please see my replies inline. On 10/04/2018, 3:14 AM, "Nir Sopher" wrote: Hey Zhilin, Regarding the ports configuration. Even though I believe modeling will be cleaner if the port and IP are set together, you are

Re: Traffic Server Secondary Streaming IPs Design

@Robert I didn’t notice the health poll is for the cache, thanks for pointing this out. If so, it should work. On 4/4/18, 10:23 PM, "Robert Butts" wrote: @nbaoping > So I suggest the change to the current TM to be like: > 1) Separate the current

Re: Traffic Server Secondary Streaming IPs Design

Hey Zhilin, Regarding the ports configuration. Even though I believe modeling will be cleaner if the port and IP are set together, you are probably correct - it is reasonable to consider the Port per IP flexibility as a future extension and avoid it for now. Still, I would suggest to at-least

Re: Traffic Server Secondary Streaming IPs Design

Hi Nir, As there is only 1 ATS instance inside an edge server, the port should be a common setting. Currently ATS service will be bind to 0.0.0.0:, we do not see any benefit to change this. Thanks, Zhilin On 05/04/2018, 12:34 AM, "Nir Sopher" wrote: Eric, Great, IP

Re: Traffic Server Secondary Streaming IPs Design

Due to this change, the Traffic Ops APIs may also need change: (GET/POST/PUT/DELETE) /api/1.2/servers/{:svrId}/2ndintfs Need change Suggestion: /api/1.2/servers/{:svrId}/interfaces (GET/POST/PUT/DELETE) /api/1.2/servers/{:svrId}/2ndips Don't need change. Thanks, Jifeng On

Re: Traffic Server Secondary Streaming IPs Design

Eric, Great, IP as delivery unit. Note that I believe the port is part of this unit, and not a common settings to all IPs in the interface. +1 for Rob's suggestion (stats are collected on the interface level, and health/heartbeat on the ip level) Rob/Jeff I believe we need to verify this entire

Re: Traffic Server Secondary Streaming IPs Design

@nbaoping > So I suggest the change to the current TM to be like: > 1) Separate the current polling of cache servers into two different pollings, one for the keep alive, the other for the stat query. The Golang Monitor already does this. We call it the "health" and "stat" polls in the code. The

Re: Traffic Server Secondary Streaming IPs Design

Hey Nir- For our particular use case, we are looking at making an IP the delivery unit. We would like to use a single interface with multiple IPs. DSs would be assigned to one of the IPs on that interface. Interface (or IP) priority does not come into play here as there is no failover

Re: Traffic Server Secondary Streaming IPs Design

Hi guys, It’s really exciting that we are moving to one flexible solution to have the IP and interface tables separately. Based on this, I have some ideas for the change of the Traffic Monitor(TM). Actually, the TM have two different purposes to polling the cache servers. One is to make sure

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

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 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 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

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

For our particular use case, it is important that if a secondary IP is down, the traffic does not move to the primary IP. This use case relates to use of the source IP address to differentiate traffic for billing purposes. We don’t want traffic to move to the primary IP as this would

Re: Traffic Server Secondary Streaming IPs Design

Hi Zhilin, I took a quick look into the spec. Hope to have the opportunity to dive deeper into it soon so we can further discuss it. For now I have a 2 questions. In the spec, you refer to "secondary interfaces", and you have a list of secondary interfaces added. IIUC the secondary interfaces

Traffic Server Secondary Streaming IPs Design

Hi Guys, This was originally posted in another discussion. Resend this in a standalone topic to catch more awareness. The link for the design doc: https://docs.google.com/document/d/1vgq-pGNoLLYf7Y3cu5hWu67TUKpN5hucrp-ZS9nSsd4/edit?usp=sharing Short summary for the feature design: --- There is