Re: [onap-discuss][onap-tsc][OOM] PTL Election for OOM

2018-07-18 Thread Roger Maitland
+1

From:  on behalf of Mandeep Khinda 

Reply-To: "onap-disc...@lists.onap.org" , Mandeep 
Khinda 
Date: Wednesday, July 18, 2018 at 3:48 PM
To: Mike Elliott , David Sauvageau 
, "ONAP-TSC@lists.onap.org" , 
"onap-disc...@lists.onap.org" 
Subject: Re: [onap-discuss][onap-tsc][OOM] PTL Election for OOM

+1
On Wed, 2018-07-18 at 17:52 +, Mike Elliott wrote:
Dear ONAP OOM Committers,

I would like to nominate myself as Project Technical Lead (PTL) for the ONAP 
Operations Manager (OOM) project.

I have been a very active member of the OOM project since its inception. Active 
in both its architecture and as a top committer on the project. Over the last 
year, I standardized the Helm chart template for the ONAP community and 
delivered many of the Helm charts on behalf of the project teams. I also held a 
number of workshops, education and debugging sessions with the project teams 
and worked very closely with the integration team to help ensure the successful 
delivery of ONAP on OOM in the Beijing release.

We have a fantastic team and a great community, with a lot of smart, 
experienced and dedicated people. I’m really looking forward to working with 
this team to deliver on Casablanca and beyond!  And I would very much like to 
do that as your PTL.

Thanks very much for your consideration,
Mike Elliott


From:  on behalf of David Sauvageau 

Date: Tuesday, July 10, 2018 at 1:45 PM
To: "onap-disc...@lists.onap.org" , 
"ONAP-TSC@lists.onap.org" 
Subject: [onap-discuss][onap-tsc][OOM] PTL Election for OOM

Dear ONAP OOM Committers,

As mandated by ONAP process, PTL elections must be held at least once a year.   
You can read more details here: 
https://wiki.onap.org/display/DW/Annual+Community+Elections

If you are interested in the Integration PTL position.  Please reply to all to 
do self-nomination.

We will close the self-nomination window by 23:59 PDT July 18th, Wednesday, 
2018.  Further instructions will be sent out to the committers on the election 
procedure.  The final result will be announced on the ONAP lists before the end 
of this week.

Regards,
David Sauvageau

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
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

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 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3434): https://lists.onap.org/g/ONAP-TSC/message/3434
Mute This Topic: https://lists.onap.org/mt/23219123/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/ONAP-TSC/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[onap-tsc] Casablanca release participation - OOM

2018-06-07 Thread Roger Maitland
TSC:

Please be advised that ONAP Operations Manager (OOM) plans to participate in 
the Casablanca release.

Thanks,
Roger Maitland

Thanks,
Roger Maitland
[/Users/rogerm/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1747887980]
Amdocs a Platinum member of 
ONAP<https://www.amdocs.com/open-network/nfv-powered-by-onap>
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


Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam Release

2017-09-27 Thread Roger Maitland
Here is a quick update on OOM status.  All projects but usecase-ui have been 
on-boarded with OOM.  Most of the projects have their containers up and we’re 
working on validating the deployment.

Cheers,
Roger
[cid:image001.png@01D337B2.50DEA030]

From: Roger Maitland
Sent: Monday, September 25, 2017 12:13 PM
To: Yunxia Chen ; onap-tsc 
Subject: RE: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam 
Release

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 ):


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> 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Yunxia Chen
Sent: Friday, September 22, 2017 5:08 PM
To: onap-tsc mailto: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


Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam Release

2017-09-25 Thread Roger Maitland
Hi Bin,

We worked with some of your teammates to create the original deployment spec 
when the framework and vio plugins were the only ones available so we have 
those 2 containers up.  I’ve sent you a private email with detailed 
instructions on how to get the two new plugins on-board – we’re happy to work 
with you on this.

Cheers,
Roger

From: Yang, Bin [mailto:bin.y...@windriver.com]
Sent: Monday, September 25, 2017 12:30 PM
To: Roger Maitland ; Yunxia Chen 
; onap-tsc 
Subject: RE: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam 
Release

Hi Roger,

   I observed that multicloud was marked as ‘Deployment Spec 
Complete” as well as ‘Container Up’.
Maybe I am out of conversation between you and Xinhui, and I am not sure if you 
knew that for R1, MultiCloud consists of 4 microservices, hence 4 containers: 
Multicloud broker, Multicloud plugin for OpenStack Ocata, Multicloud plugin for 
Mitaka (Wind River’s release), Multicloud plugin for VMware VIO.
I am not sure if all of them are deployed via OOM,  could you help check that? 
And if something were missing, could you do me a favor to add missing ones or 
let me know how I can help.

Thanks.

Best Regards,
Bin Yang,Solution Readiness Team,Wind River
Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189
Skype: yangbincs993

From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Roger Maitland
Sent: Monday, September 25, 2017 6:13 PM
To: Yunxia Chen; onap-tsc
Subject: Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam 
Release

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> 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Yunxia Chen
Sent: Friday, September 22, 2017 5:08 PM
To: onap-tsc mailto: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 

Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam Release

2017-09-25 Thread Roger Maitland
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 
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

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 

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc


Re: [onap-tsc] [tsc]Vote: ONAP Deployment Proposal for Amsterdam Release

2017-09-20 Thread Roger Maitland
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-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 
<https://www.amdocs.com/about/email-disclaimer>
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc