@weifensh We're hoping to have most of the API endpoints, not including ATS config files, in the next month or so. I'm currently working on `deliveryservices`, and @dylanvoltz is on `servers`, the two biggest, and they're both mostly done. They should be code-complete by the end of next week, and then maybe a week for testing. Most of the rest are straightforward DB->JSON->HTTP mappings without much logic, they should go pretty fast.
Do you have a list of endpoints you'll have to modify for this feature? We can certainly prioritize them, if you give us a list. Will you be modifying any ATS config files generated by Traffic Ops? Those are lower on our list, but again, if you have some, we can definitely prioritize them. I'd highly recommend not doing anything new in Perl. At Comcast, we just recently allocated people for Self Service, and that's going to require all endpoints in Go, so the Perl->Go migration just got bumped to the top of our priority list. Since we're not using this "Secondary IP" feature, it's going to be harder for us to be sure it's working right when we transliterate Perl to Go, and we're likely to break it for you, and we'll have to figure out why. It'll just be more painful for everyone to do new things in Perl. You can also convert Perl endpoints to Go yourself, as you need to modify them, if you like. Just be sure to coordinate with us, so we don't duplicate work. On Fri, Apr 20, 2018 at 3:57 AM, John Shen (weifensh) <[email protected]> wrote: > Hi Nir and all, > > Do you know when will the full GO version of Traffic Ops be ready in the > master branch? The reason I raise this question is that we are starting to > implement this feature, and if some of the APIs involving this feature are > still in Perl and will not be ported to GO very soon, we are planning > implement them in the Perl. For other APIs, we will implement them in GO. > Is there any objection to this plan? > > Thanks, > John > > > On 2018/4/10, 4:22 PM, "Zhilin Huang (zhilhuan)" <[email protected]> > wrote: > > 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)" <[email protected]> > wrote: > > Hey Nir, > > Thanks a lot for your comments. Please see my replies inline. > > On 10/04/2018, 3:14 AM, "Nir Sopher" <[email protected]> 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) < > [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 > > >>> > > >>> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
