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 "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" <[email protected]> wrote: I would support an 'interfaces' table (adding some sort of a 'type' column) that would include moving the management and lights out management interfaces to that table as well. Cheers, Mark On Mon, Apr 2, 2018 at 2:39 PM, Nir Sopher <[email protected]> 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 "secondary", > "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) < > [email protected] > > 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: > > https://docs.google.com/document/d/1vgq-pGNoLLYf7Y3cu5hWu67TUKpN5hucrp > > -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 > > > > >
