In Beijing, ISTIO presentation was concentrated on
- Benefits of ISTIO - How CN industry using ISTIO - Applying ISTIO to ONAP to get the productivity benefits. Kiran and I provided a method to migrate to ISTIO project by project. Two discussion points emerged: 1. ISTIO across all projects: One feedback that came up is to migrate all projects at once using ISTIO auto-injection capability. Discussion went on to see whether any ONAP deployment admin like to use some other service mesh instead of ISTIO or use existing MSB+AAFCA+AAFRBAC. Many argued that that kind of flexibility is not needed. But at the same time, many felt that it is good to provide option of ISTIO vs current method. 2. Overhead of ISTIO side car (Envoy): Size of SC is typically in 10s of Mbytes (which is quite small as it is developed in C++ and Go). With 140 services today in ONAP, memory requirement for all side car can go up by few Giga bytes (If the side car is 20Mbyes, then additional overhead is 140*20 = 2.8Gbyes). Thought it looks small, Few felt that whether SC can be embedded in application container to reduce container overhead. ISTIO certainly provides this capability and hence we thought we should explore this in R4 at least. Action items taken: - What are the challenges to make ISTIO for all projects? What changes are required in applications that use existing K8S facilities or MSB facilities? - What changes are required in projects that use AAF CA and that enabled secure communications: o Should there be ONAP wide option (such use ISTIO vs no-ISTIO) and based on that the ONAP applications use local TLS or depend on Envoy? Kiran and I will explore and get back. Thanks Srini -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10905): https://lists.onap.org/g/onap-discuss/message/10905 Mute This Topic: https://lists.onap.org/mt/23170773/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
