To be clear, "immutable" here means the IP could not be removed, but allow
modification.
And streaming "priority" is better be Delivery Service based than server based.
Thanks,
Zhilin
On 10/04/2018, 4:12 PM, "Zhilin Huang (zhilhuan)" <zhilh...@cisco.com> wrote:
Hey Nir,
Thanks a lot for your comments. Please see my replies inline.
On 10/04/2018, 3:14 AM, "Nir Sopher" <n...@qwilt.com> wrote:
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.
ZH> I understand your consideration about the flexibility. But I still
think port is a server lever configuration, do not see the needs of multiple
ports in the near future. Anyway, if we want to add port configured together
with IP, it is easy to add a new field into the json of RESTful API or
cr-config, since adding new field is easy to be backward compatible. So I would
like to leave this change to future when there is use case required.
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
ZH> I went thru those APIs again, and agree with your points. The design
doc has been updated to reflect this change in section 3.1.1.3 and 3.1.1.4. A
little different than your suggestion is I used "ips" instead of
"delivery-units" to allow manipulation of management IP and ILO IP as well.
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).
ZH> I think there must be a so called "default" streaming IP bind with a
server until server deleted. A server with no streaming is useless. That's how
I understand the "primary" IP, which is immutable with a server. A "secondary"
streaming IP could be add and removed afterwards.
For the streaming IP priority, I think it is out of the scope of this
feature, we could add that in some future features. The concept streaming
"priority" itself could be co-existing with the "primary/secondary" concept, in
different dimension. The priority is a streaming load balance concept. And any
streaming IP, no matter primary or secondary, could assign a higher priority
than others.
The old /api/1.2/servers/{:svrId} API can be backward compatible. We
need
to think it through but just an example:
ZH> Agree, I would like the old APIs will not see the "secondary" IPs and
interfaces. No behavior change.
- 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
> >>>
> >>>
> >>
> >
> >
>
>
>
>
>
>
>
>
>
>
