Thanks Sylvain and Morgan for taking the lead to address the important issue.
From Sylvain’s calculation, the resource needed is already the size of our whole Windriver lab ☺. And you may need to consider working hours is about 1/3 of a day, developer may not want to wait until 2nd day to see the verification results. But I think 2 hour testing time can be reduced if we only need to check basics in pre-merge verification. To me the concern was actually to ask committers to merge Helm charts change caused by the image version update for every commit. As I said yesterday, OOM team committers need to merge over 100 commits a day. I think we need a mechanism to remove the human bottleneck here. Also, as you mentioned yesterday this change would take time to implement. I hope we can have phased approach to address the immediate needs in Dublin first. Regards, -Yang From: [email protected] [mailto:[email protected]] Sent: Friday, February 15, 2019 3:45 AM To: Yang Xu (Yang, Fixed Network) <[email protected]>; Phil Robb <[email protected]>; Gary Wu <[email protected]>; RICHOMME Morgan TGI/OLN <[email protected]> Cc: [email protected]; Jessica Wagantall <[email protected]>; Kenny Paul <[email protected]>; [email protected]; [email protected]; Paul Vaduva <[email protected]>; Adolfo Perez-Duran <[email protected]>; [email protected]; RICHOMME Morgan TGI/OLN <[email protected]>; DEBEAU Eric TGI/OLN <[email protected]>; Catherine LEFEVRE <[email protected]> Subject: Re: [onap-discuss] [integration][oom]ONAP docker image version discussion Hello, During yesterday presentation, we proposed that every merge from a project triggers a (or several) docker build with a tag including the gerrit_id. A successful buil would trigger a change in OOM with the new version of docker in OOM (it’s a lot clearer in the slides 😉). Some raised the issue that it may require a lot of resources to do that. Phil also asked what we would need to do that during ONAP DDF in Paris early this year. I did some “math” to evaluate the need: Date Number of merge (cumulative) Number of merge (between the date and the next one) September 1st 9700 2600 October 1st 7100 1950 November 1st 5150 2200 December 1st 2950 1000 January 1st 1950 1250 February 1st 700 We then see that the “worst” (or the most productive) month was September with 2600 merge. Let’s say that 25 days were effective in the month (not counting the Saturday but all the other days), we have 104 merge per day. Deploying OOM and testing it is taking less than 2 hours today, so we would need ~9 platforms (104/12) to perform the test in a reasonable time With this worst case scenario, we need 9 Kubernetes cluster for this gating. For information, our OpenStack platform inside Orange is hosting currently 8 ONAP and we have the following: 3 servers for OpenStack control (could be 1) 9 computes nodes (and by the way thanks again Huawei as half of them are lent by you ☺) : 2 times 16 cores and 256G RAM 3 storage nodes I then believe that the entry cost is not that big and that would improve a lot the quality of ONAP code. Regards, --- Sylvain Desbureaux De : <[email protected]<mailto:[email protected]>> au nom de Yang Xu <[email protected]<mailto:[email protected]>> Répondre à : <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>> Date : mercredi 13 février 2019 à 17:25 À : "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Objet : [onap-discuss] [integration][oom]ONAP docker image version discussion Dear all, Integration team is testing master branch with staging docker images, and we face some issues of docker image versioning used by ONAP deployment. Orange team has a proposal (see attached) and we are going to discuss it in the meeting. Thanks, -Yang (Integration PTL) _________________________________________________________________________________________________________________________ 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. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15588): https://lists.onap.org/g/onap-discuss/message/15588 Mute This Topic: https://lists.onap.org/mt/29783544/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
