Re: ONAP: communication components.
Michael O'Brien <frank.obrien@...>
We discussed this briefly during the PTL call this morning – you bring up a good point – we need to revisit the dependency tree (static, deployment, runtime, compile time) – to get a good view of the system – there are several pages in the wiki – we should meet over this – Friday is a more open day, lets discuss this in the TSC.
The diagram is a screencap of the original lucidchart diagram – there is no more to it – I just ran a full 3.0.0-ONAP deployment, did the following 2 commands to get pods and nodeports – I don’t plan on doing this manual diagram again – it was about 12h over a couple days – since 3.x was stable – it was a good time for snapshot – and I needed a diagram in which to enumerate log compliance (libraries, format, sidecars, shipping etc…) – there are no REST level API dependencies or deploy time pod dependencies in that diagram – just extraction of the DB layer from the pods.
Kubectl get pods –all-namespaces
Kubectl get services –all-namespaces
Hi, that diagram only shows links from the filebeat sidecars into the logstash port on the ELK stack pods – for log streaming.
I’ll keep any changes on the main page in https://wiki.onap.org/display/DW/Cloud+Native+Deployment
You would be more interested in the levels of coms and compile dependencies between the pods.
I created that diagram in lucidchart (for speed of drawing – easier than in gliffy) – it was a 1-time for casablanca – I am working on automating a live version as part of a dashboard.
For static compile dependencies you can mine the pom.xml files
For static pod dependencies you can mine the deployment yamls in the oom dir – this is how I derived the partial chart of pod dependencies enforced on deployment startup.
Most interesting would be the dynamic REST calls between the components – this would require going through all the code – or pulling the logs/metrics from the k8s stack during operations (would require 100% code coverage though) - Another option would be to either instrument/weave the rest controllers or more likely mine the logs generated during these saturation calls – easier to just browse the code – writing a parsing tool would be better but would likely take as much time as doing a pass through the code – like I did for the OOM dependencies.
Sorry for the late reply – I have to triage/queue the work I do as I am currently overallocated.
From: natacha.mach@... <natacha.mach@...>
Sent: Monday, February 11, 2019 4:51 AM
To: Michael O'Brien <Frank.Obrien@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>
Subject: ONAP: communication components.
We have had a discussion with Pawel within SECCOM regarding the relevance to elaborate a communication matrix between ONAP components.
In attached is a file that you transmitted : if it is possible to reuse this document, would you have the original file, that we could rely on in order to start the study regarding the communication flows between ONAP components?
Many thanks and regards
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service