Helen, the OOM status was not up to date on the page you listed (there are many status pages). I’ve updated your page and created the following summary ( https://wiki.onap.org/display/DW/OOM+Deployment+Status ): [cid:image001.png@01D335F4.1B1E76B0]
As mentioned by Yury and Borislav, the AAI configuration used by OOM has been validated by the AAI team. If the VM deployment has these extra components you might want to confirm they are needed in a VM deployment. We did see the change to dgbuilder and are adapting. Although DCAE gen 1 isn’t officially part of the Amsterdam release the OOM has containerized DCAE gen 1 such that it can be used for ONAP validation while DCAE gen 2 is in development. OOM has been able to pull in some of the Consul monitoring originally targeted at the Beijing release. The Consul servers are up and the message router is reporting green so we have a good start. Note that Consul monitoring is effectively a continuous health check that is visible in the Consul UI. Cheers, Roger From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Yunxia Chen Sent: Friday, September 22, 2017 5:08 PM To: onap-tsc <onap-tsc@lists.onap.org> Subject: Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam Release The latest update for ONAP installation testing inside Integration Lab as of 09/22, 2:30 PM EST, (the whole team works very fast ☺, that is very good!) From the wiki below (which have code needed to be installed for Amsterdam release for our best knowledge), there are 17 (16 + ROBOT) (be careful, these are NOT all the project), namely: AAI, APPC, CLAMP, DCAE GEN2 + HOLMES, MESSAGE ROUTER (DMAAP), ROBOT, MSB, MULTI-VIM, UUI, POLICY, PORTAL, SDNC, SDC, SO, VFC, VID, VNFSDK. 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=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=KgFIQiUJzSC0gUhJaQxg8eC3w16GC3sKgWIcs4iIee0&m=m0BFagIzLDbEj_XSLBsO-mSP6aPtvX0ipSf0wgkeRQ4&s=rSiwRkmj-H7EYUa0p3iwOFcHSTW-NHrAWs_HcLqu2CE&e=> Projects currently in Heat: 16. Projects currently in OOM: 14. For Heat, all those OpenECOMP components have been tested for a while, any issues right now functionalities wise should not depend on the heat installation, while the test for OPEN-O components added recently is going on. The OPEN-O containers are all up, but we haven’t tested if they work as expected (have asked the teams to check, from my OPEN-O integration experience, I know it should be fine since it is almost exactly the same as before from env perspective) We can’t tell about stability of installation via OOM, we noticed the following gaps in OOM though: * Three AAI containers are missing, namely attos/dmaap, docker_file_kafka, wurstmeister_zookeeper. These containers are also in the Message Router component, so we don’t know if the OOM team redirected AAI to talk to that bus. If so, that should be fine; * The dgbuilder image used in APPC and SDNC is old. That is no longer in use. There’s a new one called onap/ccsdk-dgbuilder-image/0.1-STAGING-latest; * The configuration of DCAE GEN1 controller may be broken because it expects to create CDAP/Postgrees/Collector components, while in the OOM-based approach CDAP/Postgrees/Collector are created by OOM. This will not be an issue when DCAE GEN1 will be replaced with DCAE GEN2. Marco and Yang, please add your comments since you are continuing testing them at this moment as well. (I am off heading to Paris) Thank you and see you at Paris, Helen Chen 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
