Hi Marcus, Thanks for the reply. I will follow up on your first two points:
1. I did not complain about performance or optimization. I complained about redundancy and reinventing wheels. What bothers me is that ONAP eats 100GB of space and what actually offers in return? Where is the functionality? 2. Maybe there are use-cases which ONAP can handle but are they usable in practice or are they just a one-shot demo? There is this article https://www.sdxcentral.com/articles/news/bell-canada-first-to-deploy-open-source-onap-in-production/2017/12/ claiming that ONAP Amsterdam was ready for production (two years ago) – is ONAP Dublin used in production? Quo vadis ONAP? I think that my understanding of a platform just differs. Lets have a look on kubernetes: https://kubernetes.io/docs/concepts/overview/components/ There are clear components which each of them is necessary for kubernetes to work properly: * Kube-apiserver * Etcd * Kube-scheduler * Kube-controller-manager If you kill etcd then kubernetes lose its state – apiserver will lose its backend and everything going to crash. Also there is API specification: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/ That is the reason why companies like rancher can make its own implementation of kubernetes with their own components. How ONAP compares to this? -- Best regards, Petr Ospalý From: [email protected] [mailto:[email protected]] Sent: Friday, July 12, 2019 12:52 PM To: Ospaly Petr <[email protected]>; [email protected] Subject: Re: [onap-discuss] ONAP as a platform Hi Petr, I think you bring-up some interesting points. Let me give my perspective on those 1) new platforms are always less optimized, I am not concerned about that, time will show. First designs are made for good architecture, not for optimized operation, that come later. I have seen too many system designs, which were optimized for performance or operation, which failed to deliver. 2) On the platform topic, ONAP has been shown to work for diverse set of use cases, so from that perspective I guess it is good enough of a platform. 3) I believe where you have a point is that several projects reused in ONAP might need to be well separated out and more used then developed into them (or those requirements should be Brough upstream. 4) Also I believe that some choices of tools and components could be revised in view of many external projects meanwhile have more matured over time, but they were not available or immature at the time the decisions have been taken. Kind regards, Marcus -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18027): https://lists.onap.org/g/onap-discuss/message/18027 Mute This Topic: https://lists.onap.org/mt/32429722/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
