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 module the cr-config with the Port
specified per IP (delivery-unit). It is more flexible as well as simplify
the router and monitor code.


Regarding the crud of the server configuration, I believe the API should
change, but with backward compatibility.
Maybe we should have
(GET/POST/PUT/DELETE)  /api/1.2/servers/{:svrId}/interfaces
And
(GET/POST/PUT/DELETE)  /api/1.2/servers/{:svrId}/
interfaces/{:ifId}/delivery-units

These APIs will allow us to manipulate all interfaces and all IPs
(delivery-units). Note that as I see it, there is no special "primary" IP
(but IPs has priorities).

The old /api/1.2/servers/{:svrId} API can be backward compatible. We need
to think it through but just an example:

   - Server "GET" will return the IP of the server's delivery unit with the
   lowest ID
   - Server "PUT" will allow empty IP, but if IP is set, it verify there is
   exactly 1 IP record for the server, and work against it. O.w. fails.

Another option can be to have a global param that enables multiple IPs per
server.  When enabled, API changes - IP is removed from the server API.

Nir



On Sun, Apr 8, 2018 at 9:18 AM, Zhilin Huang (zhilhuan) <zhilh...@cisco.com>
wrote:

> 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 least.
>
> Thanks,
> Zhilin
>
>
> 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.
>
>     Thanks,
>     Jifeng
>
>     On 04/04/2018, 11:56, "Zhilin Huang (zhilhuan)" <zhilh...@cisco.com>
> wrote:
>
>         Updated the DB schema in section 3.1.1.4
>
>         Thanks,
>         Zhilin
>
>
>         On 04/04/2018, 11:02 AM, "Zhilin Huang (zhilhuan)" <
> zhilh...@cisco.com> 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 (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.
>
>
>                 —Eric
>
>
>
>                 > 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 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" <
> 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 management
>                 >    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 "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) <
>                 >> 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:
>                 >>>
> 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
>                 >>>
>                 >>>
>                 >>
>                 >
>                 >
>
>
>
>
>
>
>
>
>
>

Reply via email to