Hi, I think, we agreed that we target HEAT deployment and that we may revisit this decision during our f2f meeting, based on OOM progress achieved by then.
Jamil, as for v2 of Rel-1, I think we still need to decide what will be future of those projects marked as non-MVP, in case they are not included in Amsterdam (Release-1) eventually – e.g. whether we introduce a concept of advanced versions for Rel-2 or move all remained contents into Beijing (Rel-2). I believe this is one of the decisions we will have to make next week as well, while discussing M4. Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:image001.png@01D3313C.3AFF6050] From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of jamil.cha...@orange.com Sent: Tuesday, September 19, 2017 10:55 AM To: GILBERT, MAZIN E (MAZIN E) <ma...@research.att.com>; Lingli Deng <denglin...@chinamobile.com> Cc: onap-tsc@lists.onap.org P <onap-tsc@lists.onap.org> Subject: Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam Release Hello I don’t remember that we have agreed to initiate a vote on this topic. As mentioned by Mazin we have agreed to have in priority Heat but without excluding OOM which I hope will be ready for a v2 of Rel-1. Regards Jamil De : onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] De la part de GILBERT, MAZIN E (MAZIN E) Envoyé : mardi 19 septembre 2017 05:15 À : Lingli Deng Cc : onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> P Objet : Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam Release Lingli, and Team, When the TSC met 2 weeks back to discuss Heat and OOM, it was agreed that Heat is the plan of record as it is the more mature solution while Helen and the integration team evaluates the OOM solution in the meantime. Heat was always the plan of record for Amsterdam while the target solution is OOM. So Helen’s note should not be a surprise to anyone. Helen’s assessment based on PTL feedback today was that Amsterdam is not ready for OOM even though it may be a simpler solution. I was on the call today and heard the feedback. Moving ahead with OOM per feedback received from PTLs and Helen’s assessment is a significant risk to Amsterdam. OOM will remain the solution for Beijing. This discussion has gone on for too long, and it is time for the TSC to make some difficult decisions to de-risk Amsterdam. thanks Mazin On Sep 18, 2017, at 10:57 PM, Lingli Deng <denglin...@chinamobile.com<mailto:denglin...@chinamobile.com>> wrote: Hi Huabing and Helen, I believe this page is supposed to track the current status for each project integration with OOM/HEAT. https://wiki.onap.org/display/DW/ONAP+Installation+Strategy+for+Release+A<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ONAP-2BInstallation-2BStrategy-2Bfor-2BRelease-2BA&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=KSR6PrsZRiEmjmaij5MmjZycgerqLf-CNiNMJg6x4WU&s=39nqZ6NVspMGVN3hhixnuW9Edrnta5m1pSozzK_jkbc&e=> I agree need input from PTL on assessing the transition and make sure it could be done in time. Thanks, Lingli From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of zhao.huab...@zte.com.cn<mailto:zhao.huab...@zte.com.cn> Sent: 2017年9月19日 10:08 To: helen.c...@huawei.com<mailto:helen.c...@huawei.com> Cc: onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> Subject: Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam Release Hi Helen and all, As a ONAP developer, I have some concerns about this proposal: Firstly, the kubernetes approach OOM currently adopted is much simpler and more lightweight than heat template approach because every component is just a docker container. If we switch to heat way, It will be very hard for community developer and potential ONAP user to play with ONAP because it will need much more resources to bring up the ONAP system. If anyone want to try ONAP, they might have to rent a dozen of vm from public cloud. This will significantly increase the difficulty and cost for trying ONAP, as ONAP community, we want to encourage people to test and use ONAP, this obviously is not what we want to see. Secondly, some projects may have no experience on heat template approach, so it will add a lot of extra works for them. At the same time, most of them already have kubernetes deployment ready. As far as I know(please correct me if I'm wrong), these projects(or sub-projects) include MSB, Holmes, ESR,VF-C, Multi-Cloud, workflow-designer, CLI, etc. I suggest we carefully think over the impact to the projects and community before make this decision. My two cents. Thanks, Huabing Original Mail Sender: <helen.c...@huawei.com<mailto:helen.c...@huawei.com>>; To: <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>; Date: 2017/09/19 08:03 Subject: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam Release Dear ONAP TSC Members, We had several discussion sessions regarding “Heat template vs OOM” with PTLs, a lot of emails follow ups in past 4+ weeks, and we also tested OOM and Heat template in Integration lab in past two weeks. Here are our conclusions: 1. Heat template deployment is more mature than OOM with Kubernetes at this moment 2. Most of the OpenECOMP projects have done integration test with Heat template while Kubernetes based has not done any 3. PTLs / key developers feel less comfortable to “learn” a new tool at this time Based on above reasons, Integration team recommends to use Heat template as ONAP platform deployment strategy in Amsterdam Release. Please send your email vote for “whether you approve using Heat template as ONAP platform deployment strategy in Amsterdam Release”, options are: +1: approve 0: no opinion -1: disapprove Due: 9/20/2017, 6:00PM PDT. Kenny, please help us collect the result. The result will impact our integration testing priority and integration lab resource allocation priority. Regards, Helen Chen _______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org<mailto:ONAP-TSC@lists.onap.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=KSR6PrsZRiEmjmaij5MmjZycgerqLf-CNiNMJg6x4WU&s=JqX3STNDf0aFULBkDOCsgxS0u2W7xLmRl2Sr0OjfPzs&e= _________________________________________________________________________________________________________________________ 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. 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 <https://www.amdocs.com/about/email-disclaimer>
_______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
