Yes, we use the master branch and right now we are working on on-boarding
the services you mentioned and doing basic health checks with the Robot app.
Then, since we use TOSCA we can add additional TOSCA nodes that can verify
an ONAP deployment beyond the basic tests (I discussed this capability of
additional verification on the weekly OOM meetings).

Thanks,
Shay

On Fri, Sep 22, 2017 at 10:21 PM, Yunxia Chen <helen.c...@huawei.com> wrote:

> Thank you Shay!
> Did you test the rest of projects, sdc, said, mso,
> portal, vid, appc, sdnc with ONAP code master branch in
> the community? I understand you tested DCAE of ECOMP .
>
> Any basic functionalities other than health check?
>
> (Yes, please keep the good work of testing and let us
> know the latest progress. )
> Thank you!
> Helen Chen
>
>
> Sent from Helen's cell phone.
> *From: *Shay Naeh
> *To: *Yunxia Chen;
> *Cc: *Christopher Donley (Chris); Roger Maitland; Eric Debeau; onap-tsc;
> *Subject: *Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for
> Amsterdam Release
> *Time: *2017-09-22 12:04:51
>
>
> Hi Yunxia,
>
> Here is the lןnk to the TOSCA blueprint, it includes the "robot" ONAP
> service which checks the health of the other components
> https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob
> ;f=onap-blueprint.yaml;h=699312bea8a0312d91194a13a83997c14d46b2a1;hb=HEAD
>
> Regarding DCAE, it works for AT&T at ECOMP and collects KPIs, but we
> haven;t tested it yet in ONAP. We will keep posting updates and that is
> part of the plan.
>
> Thanks,
> Shay
>
>
> On Fri, Sep 22, 2017 at 7:36 PM, Yunxia Chen <helen.c...@huawei.com>
> wrote:
>
>> Hi, Shay,
>>
>> Thanks for this info. Could you please give a little bit more details on
>> what do you mean:
>>
>> “We were able to launch ONAP services successfully”, did you do any basic
>> functionally testing? For example, try to on boarding a simple service with
>> our use cases, checking if DCAE collects any data, etc.?
>>
>> And which version of ONAP do you use?
>>
>>
>>
>> Regards,
>>
>>
>>
>> Helen Chen
>>
>>
>>
>> *From: *<onap-tsc-boun...@lists.onap.org> on behalf of Shay Naeh <
>> sh...@cloudify.co>
>> *Date: *Friday, September 22, 2017 at 9:28 AM
>> *To: *"Christopher Donley (Chris)" <christopher.don...@huawei.com>,
>> Roger Maitland <roger.maitl...@amdocs.com>, Eric Debeau <
>> eric.deb...@orange.com>, onap-tsc <onap-tsc@lists.onap.org>
>> *Subject: *Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for
>> Amsterdam Release
>>
>>
>>
>> + ONAP-TSC
>>
>>
>>
>> On Fri, Sep 22, 2017 at 6:53 PM, Shay Naeh <sh...@cloudify.co> wrote:
>>
>> We would like to report on the latest deployment status of  OOM with
>> TOSCA and Cloudify
>> <https://wiki.onap.org/display/DW/OOM+with+TOSCA+and+Cloudify>:
>>
>>
>> 1. DCAE:  runs with Cloudify
>>
>> 2. Cloudify deploys Kubernetes on OpenStack, Baremetal etc.
>>
>> 3. Cloudify deploys ONAP micro services on top of Kubernetes
>>
>> - The latest status is that we were able to launch ONAP services
>> successfully (we have encountered a few issues with MSO app regarding the
>> environment, correct images, ready.py validation checks, etc. and thanks to
>> Mandeep Khinda help they are solved now)
>>
>>
>>
>> We've updated the OOM user guide
>> <https://wiki.onap.org/display/DW/OOM+with+TOSCA+and+Cloudify> on how to
>> run ONAP using this approach. This is still a WIP, will update with more
>> details as we progress.
>>
>>
>>
>> Thanks,
>>
>> Shay
>>
>>
>>
>>
>>
>>
>>
>> ---------- Forwarded message ---------
>> From: Yunxia Chen <helen.c...@huawei.com>
>> Date: Thu, 21 Sep 2017 at 0:06
>> Subject: Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam
>> Release
>> To: Christopher Donley (Chris) <christopher.don...@huawei.com>, Roger
>> Maitland <roger.maitl...@amdocs.com>, eric.deb...@orange.com <
>> eric.deb...@orange.com>, onap-tsc@lists.onap.org <onap-tsc@lists.onap.org
>> >
>>
>>
>>
>> Hi, Chris,
>>
>> I hope it could be decide asap since we don’t have enough resource to
>> work on both solution. From this week, Integration projects and other
>> projects already started the pairing / integration testing in Integration
>> lab: we really need a tool which is working for our test, right now, we are
>> using heat template.
>>
>>
>>
>> Ideally, I hope that we have both OOM and Heat work before Amsterdam
>> release. I know OOM team works very hard to meet Amsterdam date: especially
>> last two weeks, I was with them and saw how hard they are working and how
>> helpful they are (especially Mike Elliott). But even from yesterday’s
>> meeting I had with few projects, which declared finished the integration
>> with OOM, by few minutes’ code level review, we found that they still have
>> quick some bugs, one of the projects missed two docker images and other one
>> has duplicated entries.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Helen Chen
>>
>>
>>
>> *From: *<onap-tsc-boun...@lists.onap.org> on behalf of "Christopher
>> Donley (Chris)" <christopher.don...@huawei.com>
>> *Date: *Wednesday, September 20, 2017 at 1:49 PM
>> *To: *Roger Maitland <roger.maitl...@amdocs.com>, Eric Debeau <
>> eric.deb...@orange.com>, onap-tsc <onap-tsc@lists.onap.org>
>>
>>
>> *Subject: *Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for
>> Amsterdam Release
>>
>>
>>
>> By when do we need to make this decision?  I thought we said we’d wait
>> until the code freeze next week to see how much progress we’ve made.
>>
>>
>>
>> Chris
>>
>>
>>
>> *From:* onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-bounces@lists
>> .onap.org] *On Behalf Of *Roger Maitland
>> *Sent:* Wednesday, September 20, 2017 1:13 PM
>> *To:* eric.deb...@orange.com; onap-tsc@lists.onap.org
>> *Subject:* Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for
>> Amsterdam Release
>>
>>
>>
>> I’ll add to this conversation from the OOM team’s point of view.
>>
>>
>>
>> The OOM team is continuing with the more efficient Kubernetes deployment
>> option for ONAP and at this point have on-boarded all projects except for
>> DCAE Gen 2, Usecase UI (both of which are in progress) and VFC (which is
>> under review in gerrit).  OOM is deployed in the Integration lab where we
>> will continue to validate the firewall use case to prove equivalency with
>> the VM deployment option.
>>
>>
>>
>> OOM provides many benefits including handling interproject startup
>> dependencies, floating IP addresses, coexisting instances of ONAP, all
>> while using the provided hardware resources as efficiently as possible.  We
>> believe the community will find OOM very useful when working with ONAP but
>> we understand there is a small learning curve.
>>
>>
>>
>> Roger Maitland
>>
>> OOM Project
>>
>> *From:* onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-bounces@lists
>> .onap.org <onap-tsc-boun...@lists.onap.org>] *On Behalf Of *
>> eric.deb...@orange.com
>> *Sent:* Wednesday, September 20, 2017 3:26 PM
>> *To:* onap-tsc@lists.onap.org
>> *Subject:* [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam
>> Release
>>
>>
>>
>> Hello
>>
>>
>>
>> We agree that Heat template for OpenEcomp was first designed to run on
>> Rackspace environment. However, the Heat template evolved to remove the
>> Rackspace dependencies and I believe that the various tests we can produce
>> on various OpenStack solutions in the community should eliminate the bugs
>> as much as possible.
>>
>>
>>
>> We must consolidate at least one solution working for Amsterdam Release and 
>> I agree with Jason that is important to make ONAP easy to deploy and we must 
>> put some efforts for the installer documentation and the associated test 
>> cases to validate that the installation is OK.
>>
>>
>>
>> Regards
>>
>>
>>
>> Eric
>>
>> _________________________________________________________________________________________________________________________
>>
>>
>>
>> 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
>>
>> _______________________________________________
>> ONAP-TSC mailing list
>> ONAP-TSC@lists.onap.org
>> https://lists.onap.org/mailman/listinfo/onap-tsc
>>
>>
>>
>>
>>
>
>
_______________________________________________
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Reply via email to