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) <[email protected]>
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)" <[email protected]>
> 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)" <[email protected]>
> wrote:
>
> Updated the DB schema in section 3.1.1.4
>
> Thanks,
> Zhilin
>
>
> On 04/04/2018, 11:02 AM, "Zhilin Huang (zhilhuan)" <
> [email protected]> 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)" <
> [email protected]> 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) <
> [email protected]> 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" <
> [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
> >>>
> >>>
> >>
> >
> >
>
>
>
>
>
>
>
>
>
>
