Dear ONAPer,
There are a few ongoing discussions about service mesh in parallel, it would be
great if we could combine the efforts and work together to figure out the plan
for Casablanca :-).
Service mesh, more specificly, Istio is the main focus of MSB project for the
next release. we welcome people who're interested join MSB weekly meeting to
discuss this topic.
I'm running a doodle poll for this meeting, please choose your most convenient
time slots. https://doodle.com/poll/wr5axdityuieq32b
Thanks,
Huabing
原始邮件
发件人：赵化冰10201488
收件人： <[email protected]>;
抄送人： <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>;
<[email protected]>;
日 期 ：2018年04月20日 11:05
主 题 ：Re:RE: Service Mesh in ONAP
Hi guys,
I totally agree on the great discussion here, when I presented this proposal to
Architecture tiger team during ONS, my suggestion was that the service mesh
should to be transparent to the ONAP application and it should not be
mandatory.
I think It would be more efficient to combine the efforts, I proposed a break
session and PoC demo during the Beijing developer event, @Tal and @Ramki, maybe
we could work together on that?
Thanks,
Huabing
发件人：RamkiKrishnan <[email protected]>
收件人：Roger Maitland <[email protected]>Tal Liron <[email protected]>
抄送人：Sauvageau, David <[email protected]>Michael O'Brien
<[email protected]>Mike Elliott <[email protected]>ParvizYegani
<[email protected]>Zhao Huabing10201488;Vul, Alex
<[email protected]>Manoj K Nair <[email protected]>Addepalli,
Srinivasa R <[email protected]>
日 期 ：2018/04/20 02:53
主 题 ：RE: Service Mesh in ONAP
Hi Roger, Tal,
Great discussions on this topic so far.
The idea is clearly not to use sidecar as a method to “fix” messaging in a
highly available system.
Yes, A/B testing and live upgrades is an area where service mesh brings sharp
value.
--
Thanks,
Ramki
From: Roger Maitland [mailto:[email protected]]
Sent: Thursday, April 19, 2018 11:22 AM
To: Tal Liron <[email protected]>
Cc: Ramki Krishnan <[email protected]>; Sauvageau, David
<[email protected]>; Michael O'Brien <[email protected]>; Mike
Elliott <[email protected]>; Parviz Yegani <[email protected]>;
[email protected]; Vul, Alex <[email protected]>; Manoj K Nair
<[email protected]>; Addepalli, Srinivasa R
<[email protected]>
Subject: Re: Service Mesh in ONAP
Hi Tal,
I agree with you here, my concern isn’t with the extra sidecar but the sidecar
as a method to “fix” messaging in a highly available system.
Are the devops benefits you mention to do with how upgrades are handled?
Cheers,
Roger
From: Tal Liron <[email protected]>
Date: Thursday, April 19, 2018 at 10:52 AM
To: Roger Maitland <[email protected]>
Cc: Ramki Krishnan <[email protected]>, David Sauvageau
<[email protected]>, Michael O'Brien <[email protected]>, Mike
Elliott <[email protected]>, Parviz Yegani <[email protected]>,
"[email protected]" <[email protected]>, "Vul, Alex"
<[email protected]>, Manoj K Nair <[email protected]>, "Addepalli,
Srinivasa R" <[email protected]>
Subject: Re: Service Mesh in ONAP
Hi Roger,
I assume you take issue not so much with the sidecar per se (it's just a
container), but specifically with what's in it: a proxy (Envoy). If that's the
case, I do agree that Envoy is the critical component in service mesh and
introduces a new point of failure. Even a developer with 1 year of experience
should be worried about that. :)
You raise good points about messaging. I definitely agree that the arguments
for service meshes should have nothing to do with assisting messaging or
providing it with any features. Logging, too, is not a good result from a
service mesh: the mesh knows nothing about application logic. All it can tell
you is that communication happened, not that it was processed, which can be
useful but is not a source of truth.
There are a lot of bad demos out there about what a service mesh is and what it
provides, and they all promise the wrong things. Generally, all arguments for a
service mesh should have nothing to do with application benefits. It's all
about the infrastructure. The mesh is a tool for devops, not app devs, and it
should always be optional. I think our approach should be not to recommend
service mesh for ONAP, but to acknowledge that some ONAP users will benefit
from it, and thus we just want make sure that ONAP is "service mesh ready."
I do see the mesh being useful during integration testing. And that's the right
place to test "service mesh readiness," rather than in each ONAP component
separately.
Everyone -- I believe we should be having these discussions publicly. It's
especially confusing because MSB (Huabing) is working on its own mesh
presentation, which I think is indeed more attuned to infrastructure benefits.
On Thu, Apr 19, 2018 at 9:11 AM, Roger Maitland <[email protected]>
wrote:
Hi Ramki,
Based on my 30+ years of experience in building highly available systems I do
not support the sidecar architecture. Depending on a sidecar for messaging in
a highly-available system is very much like saying that just because Outlook is
running on my laptop my other applications must be okay. My strong
recommendation if we want to improve the messaging capabilities of ONAP is to
work on an end-to-end transaction model. One step towards this is to modify
DMaaP to enable the native Kafka client such that the full power of the commit
architecture can be realized. This would allow failed containers to be healed
and complete partial end-to-end flows by re-fetching partially complete
transactions (AAI has partial support for this). There are many other messaging
systems that address these issues (e.g. ActiveMQ) if you’d like to have an
alternative to Kafka.
There are other interesting ideas in this presentation:
Using a service abstraction to load-balance across multiple backend containers
– a feature already supported in ONAP as virtually all messaging end-points are
Kubernetes services already. Dynamic clustering and Rolling upgrades are
already supported.
There are ONAP proposals for versioned APIs that can also be supported with the
current Kubernetes load-balancer architecture as there are many load-balancer
options including customization should we need it.
Centralized logging is already implemented in ONAP. Currently a sidecar is
used for log shipping but Michael O’Brien will be proposing the use of a
Kubernetes Daemonset to locate a single shipper on each node, possibly making
the shipper configurable (so Fluentd could be used instead of the current
Filebeat impmentation).
The Logging project also implements a tracing capability. From what I remember
of Zipkin it requires changes at the sources which would be challenging. You
should talk to Michael in depth about this type of change.
There are (at least) two metric visualization systems already: Kibana for logs
and Consul for health (both real-time). Prometheus is a popular alternative so
if there are operators that would really like to use it we should add it to
the feature list.
Given ONAP has many higher priority issues that need to be addressed (like
end-to-end transaction management) and much of the functionality proposed here
is already supported the community would get more bang for the buck if you
refocused your proposal.
Cheers,
Roger
From: Ramki Krishnan <[email protected]>
Date: Wednesday, April 18, 2018 at 8:30 PM
To: David Sauvageau <[email protected]>, Michael O'Brien
<[email protected]>, Mike Elliott <[email protected]>, Roger
Maitland <[email protected]>, Parviz Yegani
<[email protected]>, "[email protected]"
<[email protected]>, "Vul, Alex" <[email protected]>, Manoj K Nair
<[email protected]>, "Addepalli, Srinivasa R"
<[email protected]>, "[email protected]" <[email protected]>
Subject: Service Mesh in ONAP
Please find deck attached on “Service Mesh in ONAP” to present in the
architecture sub-committee on 4/24 (next Tuesday). Looking forward to your
comments and thoughts at your earliest convenience, would be glad to meet over
a call as needed. If I missed somebody, please include them in this discussion.
A lot of the material in this deck originates from the presentation (me, David
et al.) at the ONAP Santa Clara Event “Towards a Comprehensive ONAP Operations
Management Solution,”
https://wiki.onap.org/download/attachments/16002054/ONAP-comprehensive-oom-v1.pdf?version=1&modificationDate=1513963503000&api=v2.
Thanks,
Ramki
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
