[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r404428525
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,829 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* If it is an IPv6 address
+*/
+ address: string;
+
+ /**
+* The netmask used by the address.
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* The maximum allowed bandwidth for this interface to be considered
"healthy"
+* by Traffic Monitor.
+*
+* This has no effect if `monitor` is not true.
+* Values are in kb/s.
+* The value `0` means "no limit".
+*/
+ maxBandwidth: bigint;
Review comment:
So you want to move the concept of the bandwidth limit partially out of
profiles/parameters. It feels a bit odd to split the implementation like that,
but ok. Instead of fixed caps, could it be either percentage or fixed
reservation? That would allow us to fix the loophole with bonded interfaces in
various link state mixes down the road.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r402534747
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,829 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* If it is an IPv6 address
+*/
+ address: string;
+
+ /**
+* The netmask used by the address.
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* The maximum allowed bandwidth for this interface to be considered
"healthy"
+* by Traffic Monitor.
+*
+* This has no effect if `monitor` is not true.
+* Values are in kb/s.
+* The value `0` means "no limit".
+*/
+ maxBandwidth: bigint;
Review comment:
Even though it could help, I'm not a fan of moving this to TODB because it's
making more state and more opportunity for humans to do it wrong.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r402531848
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,829 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* If it is an IPv6 address
+*/
+ address: string;
+
+ /**
+* The netmask used by the address.
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* The maximum allowed bandwidth for this interface to be considered
"healthy"
+* by Traffic Monitor.
+*
+* This has no effect if `monitor` is not true.
+* Values are in kb/s.
+* The value `0` means "no limit".
+*/
+ maxBandwidth: bigint;
Review comment:
There is a minor bug #2500 where it's impossible for astats to figure it
out, and a gap where link aggregate member statuses aren't taken into account.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r402528794
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,829 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* If it is an IPv6 address
+*/
+ address: string;
+
+ /**
+* The netmask used by the address.
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* The maximum allowed bandwidth for this interface to be considered
"healthy"
+* by Traffic Monitor.
+*
+* This has no effect if `monitor` is not true.
+* Values are in kb/s.
+* The value `0` means "no limit".
+*/
+ maxBandwidth: bigint;
Review comment:
That number hasn't been present in the database before as it's derived by
the astats plugin to ATS based on which interface name you ask for.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r398212025
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,666 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* Any "mask" should be present here as a CIDR-notation suffix.
+*/
+ address: string;
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* The name of the interface device on the server e.g. eth0.
+*/
+ name: string;
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* Whether or not Traffic Monitor should monitor this particular
interface.
+*/
+ monitor: boolean;
+ /**
+* The interface's Maximum Transmission Unit.
+* If this is 'null' it is assumed that the interface's MTU is not
known/is
+* irrelevant.
+*/
+ mtu: 1500 | 9000 | null;
+}
+```
+We don't have a real data model for ATC, so what follows is an approximately
+defined representation of a "server" that is valid within certain contexts. The
+modifications made to it for the purposes of the changes herein proposed should
+be considered valid in those same contexts - whatever they may be.
+
+```typescript
+interface Server {
+
+ cachegroup?: string | null;
+ cachegroupId: number;
+ cdnId:number;
+ cdnName?: string | null;
+ domainName: string;
+ guid?:string | null;
+ hostName: string;
+ httpsPort?: number | null;
+ id?: number;
+
+ // ILO things aren't being moved in because they also require a
+ // username/password that aren't used by any other interface type.
+ iloIpAddress?: string | null;
+ iloIpGateway?: string | null;
+ iloIpNetmask?: string | null;
+ iloPassword?: string | null;
+ iloUsername?: string | null;
+
+ /**
+* New field containing additional interfaces.
+* It is illegal for a server to not have at least one interface.
+*/
+ interfaces: Array & {0: Interface};
+ lastUpdated?: string;
+
+ // notice not here: mgmtIpAddress, mgmtIpGateway, mgmtIpNetmask
+ // these will be moved into the interfaces property
+
+ offlineReason: string;
+ physLocation?: string | null;
+ physLocationId: number;
+ profile?:string | null;
+ profileDesc?:string | null;
+ profileId: number;
+ revalPending?: boolean;
+ rack?: string | null;
+ routerHostName?: string | null;
+ routerPortName?: string | null;
+ status?: string | null;
+ statusId:number;
+ tcpPort: number;
+ type?: string | null;
+ typeId: number;
+ updPending?: boolean;
+ xmppId?: string | null;
+ xmppPassword?: string | null;
+}
+```
+
+`/monitoring` payloads and CDN Snapshots are purposely un-ve
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r398207409
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,666 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* Any "mask" should be present here as a CIDR-notation suffix.
+*/
+ address: string;
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* The name of the interface device on the server e.g. eth0.
+*/
+ name: string;
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* Whether or not Traffic Monitor should monitor this particular
interface.
+*/
+ monitor: boolean;
+ /**
+* The interface's Maximum Transmission Unit.
+* If this is 'null' it is assumed that the interface's MTU is not
known/is
+* irrelevant.
+*/
+ mtu: 1500 | 9000 | null;
+}
+```
+We don't have a real data model for ATC, so what follows is an approximately
+defined representation of a "server" that is valid within certain contexts. The
+modifications made to it for the purposes of the changes herein proposed should
+be considered valid in those same contexts - whatever they may be.
+
+```typescript
+interface Server {
+
+ cachegroup?: string | null;
+ cachegroupId: number;
+ cdnId:number;
+ cdnName?: string | null;
+ domainName: string;
+ guid?:string | null;
+ hostName: string;
+ httpsPort?: number | null;
+ id?: number;
+
+ // ILO things aren't being moved in because they also require a
+ // username/password that aren't used by any other interface type.
+ iloIpAddress?: string | null;
+ iloIpGateway?: string | null;
+ iloIpNetmask?: string | null;
+ iloPassword?: string | null;
+ iloUsername?: string | null;
+
+ /**
+* New field containing additional interfaces.
+* It is illegal for a server to not have at least one interface.
+*/
+ interfaces: Array & {0: Interface};
+ lastUpdated?: string;
+
+ // notice not here: mgmtIpAddress, mgmtIpGateway, mgmtIpNetmask
+ // these will be moved into the interfaces property
+
+ offlineReason: string;
+ physLocation?: string | null;
+ physLocationId: number;
+ profile?:string | null;
+ profileDesc?:string | null;
+ profileId: number;
+ revalPending?: boolean;
+ rack?: string | null;
+ routerHostName?: string | null;
+ routerPortName?: string | null;
+ status?: string | null;
+ statusId:number;
+ tcpPort: number;
+ type?: string | null;
+ typeId: number;
+ updPending?: boolean;
+ xmppId?: string | null;
+ xmppPassword?: string | null;
+}
+```
+
+`/monitoring` payloads and CDN Snapshots are purposely un-ve
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r397335664
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,666 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* Any "mask" should be present here as a CIDR-notation suffix.
+*/
+ address: string;
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* The name of the interface device on the server e.g. eth0.
+*/
+ name: string;
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* Whether or not Traffic Monitor should monitor this particular
interface.
+*/
+ monitor: boolean;
+ /**
+* The interface's Maximum Transmission Unit.
+* If this is 'null' it is assumed that the interface's MTU is not
known/is
+* irrelevant.
+*/
+ mtu: 1500 | 9000 | null;
+}
+```
+We don't have a real data model for ATC, so what follows is an approximately
+defined representation of a "server" that is valid within certain contexts. The
+modifications made to it for the purposes of the changes herein proposed should
+be considered valid in those same contexts - whatever they may be.
+
+```typescript
+interface Server {
+
+ cachegroup?: string | null;
+ cachegroupId: number;
+ cdnId:number;
+ cdnName?: string | null;
+ domainName: string;
+ guid?:string | null;
+ hostName: string;
+ httpsPort?: number | null;
+ id?: number;
+
+ // ILO things aren't being moved in because they also require a
+ // username/password that aren't used by any other interface type.
+ iloIpAddress?: string | null;
+ iloIpGateway?: string | null;
+ iloIpNetmask?: string | null;
+ iloPassword?: string | null;
+ iloUsername?: string | null;
+
+ /**
+* New field containing additional interfaces.
+* It is illegal for a server to not have at least one interface.
+*/
+ interfaces: Array & {0: Interface};
+ lastUpdated?: string;
+
+ // notice not here: mgmtIpAddress, mgmtIpGateway, mgmtIpNetmask
+ // these will be moved into the interfaces property
+
+ offlineReason: string;
+ physLocation?: string | null;
+ physLocationId: number;
+ profile?:string | null;
+ profileDesc?:string | null;
+ profileId: number;
+ revalPending?: boolean;
+ rack?: string | null;
+ routerHostName?: string | null;
+ routerPortName?: string | null;
+ status?: string | null;
+ statusId:number;
+ tcpPort: number;
+ type?: string | null;
+ typeId: number;
+ updPending?: boolean;
+ xmppId?: string | null;
+ xmppPassword?: string | null;
+}
+```
+
+`/monitoring` payloads and CDN Snapshots are purposely un-ve
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r396861690
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,670 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* Any "mask" should be present here as a CIDR-notation suffix.
+*/
+ address: string;
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* The name of the interface device on the server e.g. eth0.
+*/
+ name: string;
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* Whether or not Traffic Monitor should monitor this particular
interface.
+*/
+ monitor: boolean;
+ /**
+* The interface's Maximum Transmission Unit.
+* If this is 'null' it is assumed that the interface's MTU is not
known/is
+* irrelevant.
+*/
+ mtu: 1500 | 9000 | null;
+}
+```
+We don't have a real data model for ATC, so what follows is an approximately
+defined representation of a "server" that is valid within certain contexts. The
+modifications made to it for the purposes of the changes herein proposed should
+be considered valid in those same contexts - whatever they may be.
+
+```typescript
+interface Server {
+
+ cachegroup?: string | null;
+ cachegroupId: number;
+ cdnId:number;
+ cdnName?: string | null;
+ domainName: string;
+ guid?:string | null;
+ hostName: string;
+ httpsPort?: number | null;
+ id?: number;
+
+ // ILO things aren't being moved in because they also require a
+ // username/password that aren't used by any other interface type.
+ iloIpAddress?: string | null;
+ iloIpGateway?: string | null;
+ iloIpNetmask?: string | null;
+ iloPassword?: string | null;
+ iloUsername?: string | null;
+
+ /**
+* New field containing additional interfaces.
+* It is illegal for a server to not have at least one interface.
+*/
+ interfaces: Array & {0: Interface};
+ lastUpdated?: string;
+
+ // notice not here: mgmtIpAddress, mgmtIpGateway, mgmtIpNetmask
+ // these will be moved into the interfaces property
Review comment:
How do you represent a server with two public and two private interface
(used for different private networks)?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r396860375
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,670 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* Any "mask" should be present here as a CIDR-notation suffix.
+*/
+ address: string;
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* The name of the interface device on the server e.g. eth0.
+*/
+ name: string;
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* Whether or not Traffic Monitor should monitor this particular
interface.
+*/
+ monitor: boolean;
+ /**
+* The interface's Maximum Transmission Unit.
+* If this is 'null' it is assumed that the interface's MTU is not
known/is
+* irrelevant.
+*/
+ mtu: 1500 | 9000 | null;
+}
+```
+We don't have a real data model for ATC, so what follows is an approximately
+defined representation of a "server" that is valid within certain contexts. The
+modifications made to it for the purposes of the changes herein proposed should
+be considered valid in those same contexts - whatever they may be.
+
+```typescript
+interface Server {
+
+ cachegroup?: string | null;
+ cachegroupId: number;
+ cdnId:number;
+ cdnName?: string | null;
+ domainName: string;
+ guid?:string | null;
+ hostName: string;
+ httpsPort?: number | null;
+ id?: number;
+
+ // ILO things aren't being moved in because they also require a
+ // username/password that aren't used by any other interface type.
+ iloIpAddress?: string | null;
+ iloIpGateway?: string | null;
+ iloIpNetmask?: string | null;
+ iloPassword?: string | null;
+ iloUsername?: string | null;
+
+ /**
+* New field containing additional interfaces.
+* It is illegal for a server to not have at least one interface.
+*/
+ interfaces: Array & {0: Interface};
+ lastUpdated?: string;
+
+ // notice not here: mgmtIpAddress, mgmtIpGateway, mgmtIpNetmask
+ // these will be moved into the interfaces property
+
+ offlineReason: string;
+ physLocation?: string | null;
+ physLocationId: number;
+ profile?:string | null;
+ profileDesc?:string | null;
+ profileId: number;
+ revalPending?: boolean;
+ rack?: string | null;
+ routerHostName?: string | null;
+ routerPortName?: string | null;
+ status?: string | null;
+ statusId:number;
+ tcpPort: number;
+ type?: string | null;
+ typeId: number;
+ updPending?: boolean;
+ xmppId?: string | null;
+ xmppPassword?: string | null;
+}
+```
+
+`/monitoring` payloads and CDN Snapshots are purposely un-ve
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r396676787
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,670 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* Any "mask" should be present here as a CIDR-notation suffix.
+*/
+ address: string;
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* The name of the interface device on the server e.g. eth0.
+*/
+ name: string;
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* Whether or not Traffic Monitor should monitor this particular
interface.
+*/
+ monitor: boolean;
+ /**
+* The interface's Maximum Transmission Unit.
+* If this is 'null' it is assumed that the interface's MTU is not
known/is
+* irrelevant.
+*/
+ mtu: 1500 | 9000 | null;
+}
+```
+We don't have a real data model for ATC, so what follows is an approximately
+defined representation of a "server" that is valid within certain contexts. The
+modifications made to it for the purposes of the changes herein proposed should
+be considered valid in those same contexts - whatever they may be.
+
+```typescript
+interface Server {
+
+ cachegroup?: string | null;
+ cachegroupId: number;
+ cdnId:number;
+ cdnName?: string | null;
+ domainName: string;
+ guid?:string | null;
+ hostName: string;
+ httpsPort?: number | null;
+ id?: number;
+
+ // ILO things aren't being moved in because they also require a
Review comment:
We might consider changing the nomenclature around iLo to OOB as that's an
HP specific term for an out-of-band management interface.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r396684665
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,670 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* Any "mask" should be present here as a CIDR-notation suffix.
+*/
+ address: string;
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* The name of the interface device on the server e.g. eth0.
+*/
+ name: string;
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* Whether or not Traffic Monitor should monitor this particular
interface.
+*/
+ monitor: boolean;
+ /**
+* The interface's Maximum Transmission Unit.
+* If this is 'null' it is assumed that the interface's MTU is not
known/is
+* irrelevant.
+*/
+ mtu: 1500 | 9000 | null;
+}
+```
+We don't have a real data model for ATC, so what follows is an approximately
+defined representation of a "server" that is valid within certain contexts. The
+modifications made to it for the purposes of the changes herein proposed should
+be considered valid in those same contexts - whatever they may be.
+
+```typescript
+interface Server {
+
+ cachegroup?: string | null;
+ cachegroupId: number;
+ cdnId:number;
+ cdnName?: string | null;
+ domainName: string;
+ guid?:string | null;
+ hostName: string;
+ httpsPort?: number | null;
+ id?: number;
+
+ // ILO things aren't being moved in because they also require a
+ // username/password that aren't used by any other interface type.
+ iloIpAddress?: string | null;
+ iloIpGateway?: string | null;
+ iloIpNetmask?: string | null;
+ iloPassword?: string | null;
+ iloUsername?: string | null;
+
+ /**
+* New field containing additional interfaces.
+* It is illegal for a server to not have at least one interface.
+*/
+ interfaces: Array & {0: Interface};
+ lastUpdated?: string;
+
+ // notice not here: mgmtIpAddress, mgmtIpGateway, mgmtIpNetmask
+ // these will be moved into the interfaces property
Review comment:
This would mean you could also model out-of-band management the same way as
mgmtIpAddress etc.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r396679725
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,670 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* Any "mask" should be present here as a CIDR-notation suffix.
+*/
+ address: string;
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* The name of the interface device on the server e.g. eth0.
+*/
+ name: string;
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* Whether or not Traffic Monitor should monitor this particular
interface.
+*/
+ monitor: boolean;
+ /**
+* The interface's Maximum Transmission Unit.
+* If this is 'null' it is assumed that the interface's MTU is not
known/is
+* irrelevant.
+*/
+ mtu: 1500 | 9000 | null;
+}
+```
+We don't have a real data model for ATC, so what follows is an approximately
+defined representation of a "server" that is valid within certain contexts. The
+modifications made to it for the purposes of the changes herein proposed should
+be considered valid in those same contexts - whatever they may be.
+
+```typescript
+interface Server {
+
+ cachegroup?: string | null;
+ cachegroupId: number;
+ cdnId:number;
+ cdnName?: string | null;
+ domainName: string;
+ guid?:string | null;
+ hostName: string;
+ httpsPort?: number | null;
+ id?: number;
+
+ // ILO things aren't being moved in because they also require a
+ // username/password that aren't used by any other interface type.
+ iloIpAddress?: string | null;
+ iloIpGateway?: string | null;
+ iloIpNetmask?: string | null;
+ iloPassword?: string | null;
+ iloUsername?: string | null;
+
+ /**
+* New field containing additional interfaces.
+* It is illegal for a server to not have at least one interface.
+*/
+ interfaces: Array & {0: Interface};
+ lastUpdated?: string;
+
+ // notice not here: mgmtIpAddress, mgmtIpGateway, mgmtIpNetmask
+ // these will be moved into the interfaces property
+
+ offlineReason: string;
+ physLocation?: string | null;
+ physLocationId: number;
+ profile?:string | null;
+ profileDesc?:string | null;
+ profileId: number;
+ revalPending?: boolean;
+ rack?: string | null;
+ routerHostName?: string | null;
+ routerPortName?: string | null;
+ status?: string | null;
+ statusId:number;
+ tcpPort: number;
+ type?: string | null;
+ typeId: number;
+ updPending?: boolean;
+ xmppId?: string | null;
+ xmppPassword?: string | null;
+}
+```
+
+`/monitoring` payloads and CDN Snapshots are purposely un-ve
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r396678662
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,670 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* Any "mask" should be present here as a CIDR-notation suffix.
+*/
+ address: string;
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* The name of the interface device on the server e.g. eth0.
+*/
+ name: string;
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* Whether or not Traffic Monitor should monitor this particular
interface.
+*/
+ monitor: boolean;
+ /**
+* The interface's Maximum Transmission Unit.
+* If this is 'null' it is assumed that the interface's MTU is not
known/is
+* irrelevant.
+*/
+ mtu: 1500 | 9000 | null;
+}
+```
+We don't have a real data model for ATC, so what follows is an approximately
+defined representation of a "server" that is valid within certain contexts. The
+modifications made to it for the purposes of the changes herein proposed should
+be considered valid in those same contexts - whatever they may be.
+
+```typescript
+interface Server {
+
+ cachegroup?: string | null;
+ cachegroupId: number;
+ cdnId:number;
+ cdnName?: string | null;
+ domainName: string;
+ guid?:string | null;
+ hostName: string;
+ httpsPort?: number | null;
+ id?: number;
+
+ // ILO things aren't being moved in because they also require a
+ // username/password that aren't used by any other interface type.
+ iloIpAddress?: string | null;
+ iloIpGateway?: string | null;
+ iloIpNetmask?: string | null;
+ iloPassword?: string | null;
+ iloUsername?: string | null;
+
+ /**
+* New field containing additional interfaces.
+* It is illegal for a server to not have at least one interface.
+*/
+ interfaces: Array & {0: Interface};
+ lastUpdated?: string;
+
+ // notice not here: mgmtIpAddress, mgmtIpGateway, mgmtIpNetmask
+ // these will be moved into the interfaces property
Review comment:
Where? Should there be an purpose field on an interface?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [trafficcontrol] jhg03a commented on a change in pull request #4521: Multi-interface Servers blueprint
jhg03a commented on a change in pull request #4521: Multi-interface Servers
blueprint
URL: https://github.com/apache/trafficcontrol/pull/4521#discussion_r396682959
##
File path: blueprints/multi-interface-servers.md
##
@@ -0,0 +1,666 @@
+
+# Additional Server Interfaces
+
+## Problem Description
+Multiple network interfaces may be used by cache servers to service requests.
+However, these cannot be expressed as parts of the current "server" object.
+Specifically, assuming each interface has its own IP address, then each would
+need to be treated as a separate cache server. This means that getting clients
+to use one when the other is unavailable requires manual intervention.
+
+## Proposed Change
+Instead, cache servers should be configurable with numerous network interfaces
+monitored by Traffic Monitor that are all associated with the server, each
+having its own associated network information e.g. IP Address, but Traffic
+Router should only be aware of the "main" interface on which the cache server
+listens for connections.
+
+The specific use-case outlined above, obviously, entails some management be
done
+on the cache servers to actually support multiple interfaces answering to the
+same "main" IP address and this should be considered outside of
+ATC's scope of operation.
+
+## Data Model Impact
+The proposed structure of each of these interfaces is given below as a pair of
+TypeScript[1](#typescript) interfaces:
+```typescript
+interface IPAddress {
+ /**
+* The actual IP (v4 or v6) address which is used by an interface.
+* Any "mask" should be present here as a CIDR-notation suffix.
+*/
+ address: string;
+
+ /**
+* The IP (v4 or v6) address of the gateway used by this IP address.
+*/
+ gateway: string;
+
+ /**
+* Tells whether or not this address of this interface is the server's
+* "service" address.
+* At least one address of EXACTLY ONE interface MUST have this set to
+* 'true' for a server.
+*/
+ serviceAddress: boolean;
+}
+
+interface Interface {
+ /**
+* The name of the interface device on the server e.g. eth0.
+*/
+ name: string;
+ /**
+* These will be all of the IPv4/IPv6 addresses assigned to the
interface,
+* including gateways and "masks".
+* It is illegal for an interface to not have at least one associated IP
+* address.
+*/
+ ipAddresses: Array & {0: IPAddress};
+ /**
+* Whether or not Traffic Monitor should monitor this particular
interface.
+*/
+ monitor: boolean;
+ /**
+* The interface's Maximum Transmission Unit.
+* If this is 'null' it is assumed that the interface's MTU is not
known/is
+* irrelevant.
+*/
+ mtu: 1500 | 9000 | null;
+}
+```
+We don't have a real data model for ATC, so what follows is an approximately
+defined representation of a "server" that is valid within certain contexts. The
+modifications made to it for the purposes of the changes herein proposed should
+be considered valid in those same contexts - whatever they may be.
+
+```typescript
+interface Server {
+
+ cachegroup?: string | null;
+ cachegroupId: number;
+ cdnId:number;
+ cdnName?: string | null;
+ domainName: string;
+ guid?:string | null;
+ hostName: string;
+ httpsPort?: number | null;
+ id?: number;
+
+ // ILO things aren't being moved in because they also require a
+ // username/password that aren't used by any other interface type.
+ iloIpAddress?: string | null;
+ iloIpGateway?: string | null;
+ iloIpNetmask?: string | null;
+ iloPassword?: string | null;
+ iloUsername?: string | null;
+
+ /**
+* New field containing additional interfaces.
+* It is illegal for a server to not have at least one interface.
+*/
+ interfaces: Array & {0: Interface};
+ lastUpdated?: string;
+
+ // notice not here: mgmtIpAddress, mgmtIpGateway, mgmtIpNetmask
+ // these will be moved into the interfaces property
+
+ offlineReason: string;
+ physLocation?: string | null;
+ physLocationId: number;
+ profile?:string | null;
+ profileDesc?:string | null;
+ profileId: number;
+ revalPending?: boolean;
+ rack?: string | null;
+ routerHostName?: string | null;
+ routerPortName?: string | null;
+ status?: string | null;
+ statusId:number;
+ tcpPort: number;
+ type?: string | null;
+ typeId: number;
+ updPending?: boolean;
+ xmppId?: string | null;
+ xmppPassword?: string | null;
+}
+```
+
+`/monitoring` payloads and CDN Snapshots are purposely un-ve
