Hi Jifeng,

I do not think we need to change the APIs. Current CRUD /api/1.2/servers will 
configure the primary IP and interface. 

I do not think we want to change this due to:
1) backward compatibility
2) there should always be a default (primary) IP and interface configured when 
creating a server. It is not reasonable a server created with no IP/Interface 
configured. So current CRUD /api/1.2/servers APIs are good enough.
3) only people want multiple IPs and interfaces need to call new APIs or new 
API formats.

So I think we can change the data/DB inside, but keep the APIs not affected at 


On 05/04/2018, 9:06 AM, "Jifeng Yang (jifyang)" <jify...@cisco.com> wrote:

    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.
    On 04/04/2018, 11:56, "Zhilin Huang (zhilhuan)" <zhilh...@cisco.com> wrote:
        Updated the DB schema in section
        On 04/04/2018, 11:02 AM, "Zhilin Huang (zhilhuan)" <zhilh...@cisco.com> 
            Good points. I am happy to make this change in the design doc.
            On 03/04/2018, 8:17 PM, "Eric Friedrich (efriedri)" 
<efrie...@cisco.com> wrote:
                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 refactoring will give us greater flexibility 
for more changes in the future. Outside of this particular use case, we might 
have additional features like sharing edges between public/private networks or 
having multiple (equal priority) streaming interfaces on a cache.
                These future features would be easier if the interface data and 
IP data is all organized into separate tables. 
                I’d also like to see the delivery service to IP mapping be a 
many to many mapping in the DB. For this particular feature we will only assign 
a single IP (and we can restrict that in the API if we want), but I am near 
certain that in the future we would like the ability to assign a DS to multiple 
IPs on the same cache. 
                > On Apr 3, 2018, at 2:42 AM, Zhilin Huang (zhilhuan) 
<zhilh...@cisco.com> wrote:
                > Hi Mark,
                > Thanks for your comments. Please check my reply in another 
                > 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 
"interface_xxx", "ip_xxx", "ip6_xxx" fields with a "primary_ip_id" field. And 
do similar things to management IP.
                > Thanks,
                > Zhilin
                > On 03/04/2018, 7:08 AM, "Mark Torluemke" 
<mtorlue...@apache.org> wrote:
                >    I would support an 'interfaces' table (adding some sort of 
a 'type' column)
                >    that would include moving the management and lights out 
                >    interfaces to that table as well.
                >    Cheers,
                >    Mark
                >    On Mon, Apr 2, 2018 at 2:39 PM, Nir Sopher 
<n...@qwilt.com> wrote:
                >> 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 are used as long as they are 
available, and
                >> when down, you move to the primary interface.
                >> Why not, instead of holding a secondary interfaces table, 
move all
                >> interfaces to a separate table? Primary and secondary.
                >> For each interface you can hold:
                >>   - Server id
                >>   - name (e.g. eth0)
                >>   - IPv6
                >>   - IPv4
                >>   - Priority (Integer as flexible as you wish: e.g. "1" for 
                >>   "2" for "primary" in your example,)
                >> Additionally, it is not clear to me what happens if one of 
the interfaces
                >> fails?
                >> Does every interface has a unique DNS name? If an interface 
fails, are
                >> redirects
                >> sent only to the available (secondary) interfaces?
                >> Thanks,
                >> Nir
                >> On Mon, Apr 2, 2018 at 10:21 AM, Zhilin Huang (zhilhuan) <
                >> zhilh...@cisco.com
                >>> wrote:
                >>> 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:
                >>> -ZS9nSsd4/edit?usp=sharing
                >>> Short summary for the feature design:
                >>> ---
                >>> There is feature request from market to add secondary IPs 
support on edge
                >>> cache servers, and the functionality to assign a delivery 
service to a
                >>> secondary IP of an edge cache.
                >>> This feature requires Traffic Ops implementation to support 
secondary IP
                >>> configuration for edge cache, and delivery service 
assignment to
                >> secondary
                >>> IP.
                >>> Traffic Monitor should also monitor connectivity of 
secondary IPs
                >>> configured. And Traffic Router needs support to resolve 
streamer FQDN to
                >>> secondary IP assigned in a delivery service.
                >>> Traffic Server should record the IP serving client request. 
And should
                >>> reject request to an unassigned IP for a delivery service.
                >>> This design has taken compatibility into consideration: if 
no secondary
                >> IP
                >>> configured, or some parts of the system has not been 
upgraded to the
                >>> version supports this feature, the traffic will be served 
by primary IPs
                >> as
                >>> before.
                >>> ---
                >>> Much appreciated and welcome to any comments. If no major 
objections, we
                >>> planned to start coding this week.
                >>> Thanks,
                >>> Zhilin

Reply via email to