Date   

Re: Zero commit removal Request and Seperate the committer for parsers repo of Modeling project

Catherine LEFEVRE
 

Good morning Deng Hui,

 

 

I do not see any concern to move existing committers as you have suggested

What it is important is to update INFO.yaml file and send a request to the ONAP Helpdesk

 

To remove committers, you do not need TSC approval

 

Here is additional information from TSC Charter - https://wiki.onap.org/display/DW/ONAP+Technical+Community+Document#ONAPTechnicalCommunityDocument-3.2.2.3RemovingCommitters

 

3.2.2.3     Removing Committers

A Committer may voluntarily resign from a project by making a public request to the PTL to resign (via the project and ONAP-TSC email lists).

A Committer for a project who is disruptive, or has been inactive on that project for an extended period (e.g., six or more months) may have his or her Committer status revoked by the project’s Project Technical Leader or by 2/3 super-majority vote of the project’s committers.

The Project Technical Leader is responsible for informing the Technical Steering Committee (TSC) of any committers who are removed or resign via the ONAP-TSC email list.

Former committers removed for reasons other than being disruptive may be listed as ‘Emeritus Committers’.  That title expresses gratitude for their service, but conveys none of the privileges of being a Committer.

 

 

Best regards

Catherine

 

 


Re: slide deck for TSC on possible evolution of version management

Catherine LEFEVRE
 

Thank you Morgan for your feedback.
I have added an entry for today's agenda
If we are running out of time then I will reschedule it for Feb 28th

KR
Catherine

-----Original Message-----
From: morgan.richomme@orange.com [mailto:morgan.richomme@orange.com]
Sent: Thursday, February 21, 2019 11:01 AM
To: jwagantall@linuxfoundation.org; gary.i.wu@huawei.com; Lefevre, Catherine <catherine.lefevre@intl.att.com>; OBRIEN, FRANK MICHAEL <frank.obrien@amdocs.com>; Yang.Xu3@huawei.com
Cc: DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@orange.com>; onap-discuss@lists.onap.org; mike.elliott@amdocs.com; DEBEAU Eric TGI/OLN <eric.debeau@orange.com>; probb@linuxfoundation.org; alexis.de_talhouet@bell.ca; ROBERT René TGI/OLN <rene.robert@orange.com>
Subject: Re: slide deck for TSC on possible evolution of version management

Hi Catherine

no problem to share the slide deck during TSC meeting if Yang is OK.
we did not get lots of feedback so far but it is a mid/long term approach.

/Morgan

Le mercredi 20 février 2019 à 21:06 +0000, Lefevre, Catherine a écrit :
Good evening Morgan and Team,

If time allows, I was wondering if you would like to present your
vision to the TSC tomorrow.
Or if you are still in the process collecting feedback from PTL.
I think it would be great that you share your vision in the coming
weeks

Best regards
Catherine

-----Original Message-----
From: morgan.richomme@orange.com [mailto:morgan.richomme@orange.com]
Sent: Thursday, February 07, 2019 12:00 PM
To: jwagantall@linuxfoundation.org; gary.i.wu@huawei.com; Lefevre,
Catherine <catherine.lefevre@intl.att.com>; OBRIEN, FRANK MICHAEL <
frank.obrien@amdocs.com>; Yang.Xu3@huawei.com
Cc: alexis.de_talhouet@bell.ca; ROBERT René TGI/OLN <
rene.robert@orange.com>; mike.elliott@amdocs.com;
onap-discuss@lists.onap.org; DEBEAU Eric TGI/OLN <
eric.debeau@orange.com>; DESBUREAUX Sylvain TGI/OLN <
sylvain.desbureaux@orange.com>; probb@linuxfoundation.org
Subject: slide deck for TSC on possible evolution of version
management

Hi,

we would like to exchange on this slide deck and discuss if it could
help to enforce the gate stability.
It echoes Yang's comment on
https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_bro
wse_SDC-2D2096&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZglJ8LOeAfevY7wWaSx
imhFMAzXaMdza5QYCg-DW6SU&m=oiGNqul3rMTi3fxLo2Sr1-guqgMsQR66j6NN5f4DeRc
&s=yx1jTm3bylR1aZ_0zq9bZ1TGd1Usmc1bPtb3lO2jtBA&e=
as the TSC meeting format is today more unofficial due to Chinese new
year, we can do it during this meeting or later during integration or
OOM meeting.

any comment welcome

/Morgan

_____________________________________________________________________
____________________________________________________

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

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.


Re: slide deck for TSC on possible evolution of version management

Morgan Richomme
 

Hi Catherine

no problem to share the slide deck during TSC meeting if Yang is OK.
we did not get lots of feedback so far but it is a mid/long term
approach.

/Morgan

Le mercredi 20 février 2019 à 21:06 +0000, Lefevre, Catherine a écrit :
Good evening Morgan and Team,

If time allows, I was wondering if you would like to present your
vision to the TSC tomorrow.
Or if you are still in the process collecting feedback from PTL.
I think it would be great that you share your vision in the coming
weeks

Best regards
Catherine

-----Original Message-----
From: morgan.richomme@orange.com [mailto:morgan.richomme@orange.com]
Sent: Thursday, February 07, 2019 12:00 PM
To: jwagantall@linuxfoundation.org; gary.i.wu@huawei.com; Lefevre,
Catherine <catherine.lefevre@intl.att.com>; OBRIEN, FRANK MICHAEL <
frank.obrien@amdocs.com>; Yang.Xu3@huawei.com
Cc: alexis.de_talhouet@bell.ca; ROBERT René TGI/OLN <
rene.robert@orange.com>; mike.elliott@amdocs.com;
onap-discuss@lists.onap.org; DEBEAU Eric TGI/OLN <
eric.debeau@orange.com>; DESBUREAUX Sylvain TGI/OLN <
sylvain.desbureaux@orange.com>; probb@linuxfoundation.org
Subject: slide deck for TSC on possible evolution of version
management

Hi,

we would like to exchange on this slide deck and discuss if it could
help to enforce the gate stability.
It echoes Yang's comment on
https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_SDC-2D2096&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZglJ8LOeAfevY7wWaSximhFMAzXaMdza5QYCg-DW6SU&m=oiGNqul3rMTi3fxLo2Sr1-guqgMsQR66j6NN5f4DeRc&s=yx1jTm3bylR1aZ_0zq9bZ1TGd1Usmc1bPtb3lO2jtBA&e=
as the TSC meeting format is today more unofficial due to Chinese new
year, we can do it during this meeting or later during integration or
OOM meeting.

any comment welcome

/Morgan

_____________________________________________________________________
____________________________________________________

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

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.


How to create a ONAP service in SDC from docker-compose file or kubernetes files #sdc

Santiago <srodriguez@...>
 

Hi all,

Finally I was able to install a minimum version of ONAP platform (Casablanca release).

I've been working in a service based in docker-compose.yaml file and I could generate kubernetes services/deployments/jobs files too.

Now I want to create this service in ONAP. How can I do it? Is there any step by step guide? What is the easy way?
I've been searching in documentation but is very generalistic or it doesn't exist anymore.

Thank you.

Best Regards, Santi


Re: [aai] Upper limit size for storing string in Schema

Keong Lim
 

Hi Srini and Dileep,

I do not know the limits in the code or schema, but I have tested in a Casablanca system on a pnf object:

- successful PUT and GET with 1k length string (pnf-name2 field)
- successful PUT and GET with 10k length string (pnf-name2 field)
- successful PUT and GET with 100k length string (pnf-name2 field)
- successful DELETE at the end

and yes, I counted each and every character in that string!
(with some help from Notepad++ which shows number of characters selected and highlights other matches).

The initial PUT was done with curl like this:

curl --verbose --silent --insecure --user AAI:AAI --header 'Accept: application/json' --header 'X-TransactionId: testaai' --header 'Content-Type: application/json' --header 'X-FromAppId: AAI' --request PUT --data '{"pnf-name":"pnf-test-3","pnf-name2":"${LONGSTRING}","pnf-id":"test-id-3","equip-type":"test-type-3","resource-version":""}' https://${AAI-IP}:30233/aai/v14/network/pnfs/pnf/pnf-test-3

and subsequent PUT updates with curl like this:

curl --verbose --silent --insecure --user AAI:AAI --header 'Accept: application/json' --header 'X-TransactionId: testaai' --header 'Content-Type: application/json' --header 'X-FromAppId: AAI' --request PUT --data '{"pnf-name":"pnf-test-3","pnf-name2":"${LONGERSTRING}","pnf-id":"test-id-3","equip-type":"test-type-3","resource-version":"${RESVER}"}' https://${AAI-IP}:30233/aai/v14/network/pnfs/pnf/pnf-test-3?resource-version=${RESVER}


Of course, even if AAI can technically handle strings of such length, there are no guarantees that other components can follow suit, so the overall scenario may still fail.

Keong

On Thu, Feb 21, 2019 at 09:23 AM, Srini wrote:


Hi,

Any update for us here. Based on your response, we need to think about
alternatives.
Please let us know.

Thanks in advance.
Srini

From: KAJUR, HARISH V [mailto:vk250x@att.com]
Sent: Tuesday, February 19, 2019 11:05 AM
To: Ranganathan, Dileep <dileep.ranganathan@intel.com>; FORSYTH, JAMES
<jf2512@att.com>; onap-discuss@lists.onap.org; Addepalli, Srinivasa R
<srinivasa.r.addepalli@intel.com>
Cc: AGGARWAL, MANISHA <amanisha@att.com>; MAHARAJH, ROBBY <rx2202@att.com>;
NAIK, SOUMYA <sn207c@att.com>
Subject: RE: [aai] Upper limit size for storing string in Schema

+Robby, Manisha, Soumya

From: Ranganathan, Dileep
<dileep.ranganathan@intel.com<mailto:dileep.ranganathan@intel.com>>
Sent: Tuesday, February 19, 2019 1:50 PM
To: KAJUR, HARISH V <vk250x@att.com<mailto:vk250x@att.com>>; FORSYTH, JAMES
<jf2512@att.com<mailto:jf2512@att.com>>;
onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; Addepalli,
Srinivasa R
<srinivasa.r.addepalli@intel.com<mailto:srinivasa.r.addepalli@intel.com>>
Subject: [aai] Upper limit size for storing string in Schema

Hi AAI team,

We would like to store an arbitrarily long string (~10K string size) in the
AAI schema. Is this possible to store this long string in AAI schema?
What is the upper limit size for storing string in aai schema.

Thanks,
Dileep


Re: [aai] Upper limit size for storing string in Schema

Srini
 

Hi,

 

Any update for us here. Based on your response, we need to think about alternatives.

Please let us know.

 

Thanks in advance.

Srini

 

From: KAJUR, HARISH V [mailto:vk250x@...]
Sent: Tuesday, February 19, 2019 11:05 AM
To: Ranganathan, Dileep <dileep.ranganathan@...>; FORSYTH, JAMES <jf2512@...>; onap-discuss@...; Addepalli, Srinivasa R <srinivasa.r.addepalli@...>
Cc: AGGARWAL, MANISHA <amanisha@...>; MAHARAJH, ROBBY <rx2202@...>; NAIK, SOUMYA <sn207c@...>
Subject: RE: [aai] Upper limit size for storing string in Schema

 

+Robby, Manisha, Soumya

 

From: Ranganathan, Dileep <dileep.ranganathan@...>
Sent: Tuesday, February 19, 2019 1:50 PM
To: KAJUR, HARISH V <vk250x@...>; FORSYTH, JAMES <jf2512@...>; onap-discuss@...; Addepalli, Srinivasa R <srinivasa.r.addepalli@...>
Subject: [aai] Upper limit size for storing string in Schema

 

Hi AAI team,

 

We would like to store an arbitrarily long string (~10K string size) in the AAI schema. Is this possible to store this long string in AAI schema?

What is the upper limit size for storing string in aai schema.

 

Thanks,

Dileep

 


Re: slide deck for TSC on possible evolution of version management

Catherine LEFEVRE
 

Good evening Morgan and Team,

If time allows, I was wondering if you would like to present your vision to the TSC tomorrow.
Or if you are still in the process collecting feedback from PTL.
I think it would be great that you share your vision in the coming weeks

Best regards
Catherine

-----Original Message-----
From: morgan.richomme@orange.com [mailto:morgan.richomme@orange.com]
Sent: Thursday, February 07, 2019 12:00 PM
To: jwagantall@linuxfoundation.org; gary.i.wu@huawei.com; Lefevre, Catherine <catherine.lefevre@intl.att.com>; OBRIEN, FRANK MICHAEL <frank.obrien@amdocs.com>; Yang.Xu3@huawei.com
Cc: alexis.de_talhouet@bell.ca; ROBERT René TGI/OLN <rene.robert@orange.com>; mike.elliott@amdocs.com; onap-discuss@lists.onap.org; DEBEAU Eric TGI/OLN <eric.debeau@orange.com>; DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@orange.com>; probb@linuxfoundation.org
Subject: slide deck for TSC on possible evolution of version management

Hi,

we would like to exchange on this slide deck and discuss if it could help to enforce the gate stability.
It echoes Yang's comment on https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_SDC-2D2096&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZglJ8LOeAfevY7wWaSximhFMAzXaMdza5QYCg-DW6SU&m=oiGNqul3rMTi3fxLo2Sr1-guqgMsQR66j6NN5f4DeRc&s=yx1jTm3bylR1aZ_0zq9bZ1TGd1Usmc1bPtb3lO2jtBA&e=
as the TSC meeting format is today more unofficial due to Chinese new year, we can do it during this meeting or later during integration or OOM meeting.

any comment welcome

/Morgan

_________________________________________________________________________________________________________________________

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.


Re: [SO] vfModule model IDs - what are they all for?

Gil Bullard <wb5674@...>
 

Srini,

I think we caused some confusion with our VNF examples to illustrate the meaning of “customization id” when your original question related to VF Modules (VFMs).  A VNF is certainly different than a VFM.  See explanation in the diagram below. 

 

We should have used a VF Module example for “customization id”.  If there exists a certain VNF type that can be comprised of multiple instances of the same VF Module type, then each of those VF Module instances would get a unique “customization id”.

 

For your VSP question, see below.

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Srini
Sent: Wednesday, February 20, 2019 9:48 AM
To: BULLARD, GIL <wb5674@...>; onap-discuss@...; Multanen, Eric W <eric.w.multanen@...>
Cc: LU, TINGTING <tl2062@...>; FREEMAN, BRIAN D <bf1936@...>; SMOKOWSKI, STEVEN <ss835w@...>; SONSINO, OFIR <ofir.sonsino@...>
Subject: Re: [onap-discuss] [SO] vfModule model IDs - what are they all for?

 

Hi Gil and Ting,

 

Thank you so much for this response. We were trying to find the right documentation to understand these concepts for a while.  Thanks for the pointers to the detailed documents. Will try to understand more with internal team and get back if there are any questions.

 

One set of questions though J

I see VNF and VFM terminology. Are they both same in SDC?  In your email, you referred VNF and hence the question.

 

Also, there is one more term VSP (Vendor Software Package) in SDC. How does onboarding of VSP manifest as VNF or VFM?

 

Again, any simple explanation of these terms (VSP, VNF, VFM) and how they are related to each other is really appreciated.

 

Thanks

Srini

 

 

 

 

From: BULLARD, GIL [mailto:wb5674@...]
Sent: Wednesday, February 20, 2019 2:47 AM
To: onap-discuss@...; Multanen, Eric W <eric.w.multanen@...>
Cc: LU, TINGTING <tl2062@...>; FREEMAN, BRIAN D <bf1936@...>; SMOKOWSKI, STEVEN <ss835w@...>; SONSINO, OFIR <ofir.sonsino@...>; Addepalli, Srinivasa R <srinivasa.r.addepalli@...>
Subject: RE: [SO] vfModule model IDs - what are they all for?

 

Eric,

 

SDC’s data model is published at:

https://wiki.onap.org/display/DW/SDC+Data+model

If you download the Amsterdam data model file, the descriptions of these IDs are on page 50.

 

E.g., if a VNFx is used in 3 different SDC Service types, that VNFx will have:

  • A single unique model-invariant-id
  • A model-version-id per version of VNFx.
  • 3 model-customization-ids, one for each “use” of VNFx within a given SDC Service.

 

When the VNFx descriptor is onboarded from the vendor, it would indicate the allowed values for a given configuration parameter.  For example, in Version 1 of VNFx the allowed values could be {A, B, C}, whereas in Version 2 of VNFx the allowed values could be {A, B, C, D}.

 

When someone “drags” VNFx into various Services, they could “customize” this such as:

  • In the context of Service A, the Service designer may want to restrict parameter value “B”, thus allowing only values {A, C, D}
  • Similar with Service B and C, they would be allowed to specify their own “customization” within their respective service contexts.

 

FYI:

SDC has a comprehensive project site on ONAP, where you can find almost everything about current SDC implementation:

https://wiki.onap.org/display/DW/Service+Design+and+Creation+%28SDC%29+Portal

 

Gil Bullard & Ting Lu

 

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Multanen, Eric W
Sent: Friday, February 15, 2019 7:44 PM
To: onap-discuss@...
Subject: [onap-discuss] [SO] vfModule model IDs - what are they all for?

 

When I look at the SO vnf adapter code that creates vfModules – it is using the model-customization-id as a key parameter to identify the model of the vfmodule.

 

Is there a document or wiki that explains the differences and uses of the various vfmodule model identifiers?

 

I see that vfmodules have 3 IDs that correspond to IDs in the SDC catalog for the vfmodule:

 

What I see in AAI vfmodule:

     "model-invariant-id": "e4caddaa-ba67-4322-bd41-fd177719aaf1",

     "model-version-id": "3f8a329d-19e3-4d7e-bc64-549b7083b330",

     "model-customization-id": "1d2f2f51-bc64-444b-8f32-ba058105d1b0",

 

What I see in SDC (the VF_MODULES_METADATA artifact specifically)

    "vfModuleModelInvariantUUID": "e4caddaa-ba67-4322-bd41-fd177719aaf1",

   "vfModuleModelUUID": "3f8a329d-19e3-4d7e-bc64-549b7083b330",

    "vfModuleModelCustomizationUUID": "1d2f2f51-bc64-444b-8f32-ba058105d1b0"

 

I guess the invariant ID stays constant through different versions.

 

I’m not so clear on the difference between the version and customization and why one vs the other would be used in a given situation.

 

 

Thanks,

Eric


Re: aaf-service authz keyspace not found - Casablanca

kranthi guttikonda
 

I am seeing the same issue with master branch as well and consistently. Please help me to resolve this issue

 

Thanks,
Kranthi

 

From: Kranthi Guttikonda <kranthi.guttikonda@...>
Date: Wednesday, February 20, 2019 at 10:34 AM
To: "onap-discuss@..." <onap-discuss@...>
Subject: aaf-service authz keyspace not found - Casablanca

 

Hi Team,

 

I am seeing an issue with onap Casablanca release with AAF-service container

 

I see aaf-cs started properly but aaf-service returns ‘authz’ keyspace not found error and all other pods are failing

 

I have created a question in Wiki with logs https://wiki.onap.org/questions/58229873/aaf-service-authz-keyspace-not-found---casablanca

 

Any help would be great.

 

Thanks,
Kranthi


Re: [ONAP] Orange openlab upgrade casablanca to casablanca maintenance release

Michael O'Brien <frank.obrien@...>
 

Last time I deployed on Monday, sdnc-ansible fails on Casablanca and Dublin – didn’t test oof.

For 3.0.1-ONAP -the tag is not cut yet until the docker versions from the manifest or any workarounds are merged into oom by the teams.

Once the tag is cut you can clone with -b 3.0.1-ONAP

 

However, Mike will send a mail – as I think there is confusion in ONAP on what exactly is 3.0.1-ONAP

 

I would expect that someone from outside onap just clones oom using tag 3.0.1-ONAP and they are good – however there may be unmerged-to-oom-helm-charts changes in the integration csv override that are required on top of this – this might make sense for dev in Dublin but not Casablanca.

 

Propose: we sync the manifest with oom before we tag 3.0.1-ONAP – if there are any changes then we may need an entire new integration test cycle to declare the Casablanca branch good before we tag it.  Orange has raised most of this on Monday – I recommend we discuss this at the TSC before we cut 3.0.1

 

/michael

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Morgan Richomme
Sent: Tuesday, February 19, 2019 5:31 AM
To: xiao_xi.zhan@...; ZZZ Onap OPENLAB <onap.openlab@...>; mohamedlamine.traore@...; nthomas@...; Harshith.Bariki@...; barnali@...; sharangn@...; PM00501616@...; d035007@...; mark.harrison.uk69@...; James_Bryant@...; rajeev@...; Chao.Kan@...; GARCIA CESPEDES, Francisco javier OSP <franciscojavier.garcia@...>; PAWLAK Pawel O-PL <pawel.pawlak3@...>; MASTALERZ Wojciech O-PL <wojciech.mastalerz@...>; BRAUD Arnaud TGI/OLN <arnaud.braud@...>; srupanagunta@...; surveraj0612@...; jian.4.li@...; MINODIER David TGI/OLN <david.minodier@...>; Anuj.Singh@...; Syed_ah@...; ROZIECKI Arnaud OLN/QOP <arnaud.roziecki@...>; cprecup@...; alaslan@...; SKORUPA Marian O-PL <marian.skorupa@...>; KOWALCZYK Emil O-PL <emil.kowalczyk@...>; GEEREBAERT Matthieu TGI/OLS <matthieu.geerebaert@...>; HASPEKIAN Goar TGI/OLN <goar.haspekian@...>; Mandar.Ghogale@...; DEBEAU Eric TGI/OLN <eric.debeau@...>; adrian.osullivan@...; Kyrylo_Iarosh@...; vijay.ramachandran@...; kevin.mcdonnell@...; Francesco.Cuzzoni@...; Karthikeyan_M39@...; DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@...>; ROBERT René TGI/OLN <rene.robert@...>; LY Amadou Houndaisse OLN/QOP <amadouhoundaisse.ly@...>; WECHSLER Philippe TGI/OLN <philippe.wechsler@...>; Achilles.Devilla@...; Michael O'Brien <Frank.Obrien@...>; EDEL Nicolas TGI/OLN <nicolas.edel@...>; SERKIES Bartek O-PL <bartek.serkies@...>; rajiva@...; pedro.benito@...; p.mentel@...; LABIDURIE Nathalie TGI/OLN <nathalie.labidurie@...>; HOCHET Remi TGI/OLN <remi.hochet@...>; marco.ferrero@...; ROBERT Ludovic TGI/OLS <ludovic.robert@...>; BARS Remi TGI/OLN <remi.bars@...>; NISHI_MATHUR@...; CANEVALI Alexis OLN/QOP <alexis.canevali@...>; CLAQUIN Marc TGI/OLN <marc.claquin@...>; Prakash.Ramchandran@...; Mielowski Rafał 2 - ORPL <rafal.mielowski2@...>; lukasz.urbanski@...; GALIPOT Francis TGI/OLS <francis.galipot@...>; UllasKumar_Y@...; s.dehghanzadeh@...; SANCHEZ VILCHEZ Jose Manuel TGI/OLN <jose2.sanchez@...>; HAMID Mahmoud Ext OBS/CSO <maabdelhamid.ext@...>; JANASZKA Tomasz O-PL <tomasz.janaszka@...>; FRINDRICH Ondrej O-SK/ITN <ondrej1.frindrich@...>; SEVILLA Karine TGI/OLN <karine.sevilla@...>; sanchita@...; DESTRE Christian TGI/OLN <christian.destre@...>; donaldh@...; GOARZIN Lionel TGI/OLN <lionel.goarzin@...>; Ing-Wher_Chen@...; Ali.Fouladgar@...; Ning.So@...; BERRICHE Wassim TGI/OLN <wassim.berriche@...>; ROSSANT Olivier DTRS/DREAM <olivier.rossant@...>; BURSZTYNOWSKI Dariusz O-PL <dariusz.bursztynowski@...>; SEAUDI Abdelmuhaimen O-EG/HRCS <abdelmuhaimen.seaudi@...>; GAREL Romain TGI/OLN <romain.garel@...>; CROSSON David TGI/OLS <david.crosson@...>; PANEK Grzegorz O-PL <grzegorz.panek@...>; oguzhan.ceylan@...; fbrockne@...; nuno-t-simoes@...; Manojava_Bhagavathula@...; LAPLAUD Nicolas TGI/OLS <nicolas.laplaud@...>; SS820F@...; WALY Mohamed O-EG/HRCS <mohamed.waly@...>; luc.vermoesen@...; OSIŃSKI Tomasz O-PL <tomasz.osinski2@...>; Pawłowski Michał 1 - Hurt <michal.pawlowski1@...>; SIVAN Nicolas TGI/OLN <nicolas.sivan@...>; serkan.costu@...; Adnan.Saleem@...; Luis.Suarez@...; alessandro.dalessandro@...; taranjit_singh@...; SLAVKOVSKÝ Adrián O-SK/ITN <adrian.slavkovsky@...>; Kannan.Raman@...; onap-discuss@...; RAJEWSKI Lukasz O-PL <lukasz.rajewski@...>; PERZO Thibault TGI/OLN <thibault.perzo@...>; Jerome.THIERY@...; HUET Vincent TGI/OLN <vincent.huet@...>; Muhammad.Siddiqui@...; antoine.bernard@...; KERRIEN Isabelle TGI/OLN <isabelle.kerrien@...>; MURAT.TURPCU@...; yog.vashishth@...; OUZZIF Meryem TGI/OLN <meryem.ouzzif@...>; tommy.guario@...; HARDY Thierry TGI/OLN <thierry.hardy@...>; DENISIEWICZ Andrzej O-PL <andrzej.denisiewicz@...>; chgump@...; BLAISONNEAU David TGI/OLN <david.blaisonneau@...>; chenxdu@...; sahin.renckes@...; OCENAS Martin O-SK/ITN <martin.ocenas@...>; AS00500801@...; GIMBERT Romain TGI/OLS <romain.gimbert@...>; romain.dutot@...; JEZEQUEL Mickael TGI/OLN <mickael.jezequel@...>; Kwiecień Krzysztof 1 - ORPL <krzysztof.kwiecien1@...>; MIELCZAREK Slawomir O-PL <slawomir.mielczarek@...>; Liming.Meng@...; eh552t@...
Cc: Trevor Tait <Trevor.Tait@...>; Loic.LEGAL@...; Phillip Leigh <Phillip.Leigh@...>; Sharon Chisholm <Sharon.Chisholm@...>; Geora Barsky <georab@...>; J.Ram Balasubramanian <J.Ram.Balasubramanian@...>; onap-openlab@...; Yong Chen <Yong.Chen@...>; Prudence Au <Prudence.Au@...>; Shiba Liber <Shiba.Liber@...>
Subject: Re: [onap-discuss] [ONAP] Orange openlab upgrade casablanca to casablanca maintenance release

 

Hi Michael

 

thanks for the feedback.

Our Casablanca chain is based on casablanca tag (not 3.0.1-ONAP)

would you recommend to move to 3.0.1-ONAP?

does the casablanca tag not correspond to the last stable version?

I am still not fully clear with the different versions.

 

Using this tag, on our daily casablanca chain, we do not have error on pomba anymore (last night CI run).

 

onap-dmaap-dbc-pg-0                                            1/1       Running            0          10h

onap-dmaap-dbc-pg-1                                            0/1       Running            103        10h

onap-dmaap-dbc-pgpool-546dd7b4db-dbf9z                         1/1       Running            0          10h

onap-dmaap-dbc-pgpool-546dd7b4db-vlflq                         1/1       Running            0          10h

onap-dmaap-dmaap-bus-controller-789f469845-nf64v               1/1       Running            0          10h

onap-dmaap-dmaap-dr-db-676df89b46-q4hw8                        1/1       Running            0          10h

onap-dmaap-dmaap-dr-node-74bbf5fdc9-gvh5f                      0/1       Running            157        10h

onap-dmaap-dmaap-dr-prov-6978bb9b44-pjlpc                      1/1       Running            0          10h

onap-dmaap-message-router-6bbd6b7544-sg45k                     1/1       Running            0          10h

onap-dmaap-message-router-kafka-f4c9d4898-vqswv                1/1       Running            0          10h

onap-dmaap-message-router-zookeeper-76b96bdfc5-x5gj9           1/1       Running            0          10h

onap-sdnc-sdnc-dmaap-listener-6d566f5cb8-942zx                 1/1       Running            0          10h

onap-pomba-pomba-aaictxbuilder-6d84cdff87-btc6z                2/2       Running            0          9h

onap-pomba-pomba-contextaggregator-95476848d-c9jh7             1/1       Running            0          9h

onap-pomba-pomba-data-router-6794b78d59-hjkl4                  1/1       Running            0          9h

onap-pomba-pomba-elasticsearch-5f9f6cdbcf-5p89t                1/1       Running            0          9h

onap-pomba-pomba-kibana-c74b96f66-d9vqs                        1/1       Running            0          9h

onap-pomba-pomba-networkdiscovery-5f89c498fb-xttln             2/2       Running            0          9h

onap-pomba-pomba-networkdiscoveryctxbuilder-655b56cdb8-sjjc5   2/2       Running            0          9h

onap-pomba-pomba-sdcctxbuilder-64bd6c5d45-j4568                1/1       Running            0          9h

onap-pomba-pomba-search-data-787fb7bf5-wlsl2                   2/2       Running            0          9h

onap-pomba-pomba-servicedecomposition-7cf895c688-x5wtl         2/2       Running            0          9h

onap-pomba-pomba-validation-service-dd7d787ff-jfvtw            1/1       Running            0          9h

 

But we have on oof and ansible-server

 

 kubectl get pods -n onap |grep -v Running

NAME                                                           READY     STATUS             RESTARTS   AGE

onap-oof-oof-has-api-7597966cb9-48wrl                          0/1       Init:0/3           56         9h

onap-oof-oof-has-controller-755f689584-rlr8s                   0/1       CrashLoopBackOff   112        9h

onap-oof-oof-has-data-c7788fc4d-jmrld                          0/1       Init:2/4           55         9h

onap-oof-oof-has-healthcheck-tnssv                             0/1       Init:0/1           56         9h

onap-oof-oof-has-reservation-6cb9fd8b48-gk9p5                  0/1       Init:2/4           55         9h

onap-oof-oof-has-solver-54f46bbccc-dds5h                       0/1       Init:2/4           55         9h

onap-sdnc-sdnc-ansible-server-5886ff7f69-6msxc                 0/1       CrashLoopBackOff   111        10h

 

/Morgan

 

 

Le lundi 18 février 2019 à 01:32 +0000, Michael O'Brien a écrit :

Team,

   Verified that POMBA is OK on the latest Casablanca – the key is adhering to the orchestration sequence – DmaaP (specifically the mr pod) – needs to be up before everything else

https://wiki.onap.org/display/DW/Log+Streaming+Compliance+and+API#LogStreamingComplianceandAPI-DeploymentDependencyTree-Containerlevel

 

  All pods are up no problem – using the branch (essentially 3.0.1-ONAP) (Note: however on a long running 3.0.0-ONAP system for 60 days I do see crashloops on several pods across the ONAP deployment – but this is due to our s3p status in general)

Every 2.0s: kubectl get pods --all-namespaces                                                                                                                             Sun Feb 17 18:48:55 2019

 

NAMESPACE     NAME                                                           READY     STATUS    RESTARTS   AGE

kube-system   heapster-7b48b696fc-69hqm                                      1/1       Running   0          44m

kube-system   kube-dns-6655f78c68-blgzk                                      3/3       Running   0          44m

kube-system   kubernetes-dashboard-6f54f7c4b-69hd2                           1/1       Running   0          44m

kube-system   monitoring-grafana-7877679464-fmwws                            1/1       Running   0          44m

kube-system   monitoring-influxdb-64664c6cf5-kqswn                           1/1       Running   0          44m

kube-system   tiller-deploy-6f4745cbcf-p55ng                                 1/1       Running   0          44m

onap          onap-dmaap-dbc-pg-0                                            1/1       Running   0          15m

onap          onap-dmaap-dbc-pg-1                                            1/1       Running   0          15m

onap          onap-dmaap-dbc-pgpool-c5f8498-8fbfk                            1/1       Running   0          15m

onap          onap-dmaap-dbc-pgpool-c5f8498-q4jcm                            1/1       Running   0          15m

onap          onap-dmaap-dmaap-bus-controller-557dc8c59c-ps99v               1/1       Running   0          15m

onap          onap-dmaap-dmaap-dr-db-576f7968b8-dflf4                        1/1       Running   0          15m

onap          onap-dmaap-dmaap-dr-node-7647f9d6d8-rbwpd                      0/1       Running   7          15m

onap          onap-dmaap-dmaap-dr-prov-f4d84869f-87mj2                       1/1       Running   0          15m

onap          onap-dmaap-message-router-76f4799d-j6srw                       1/1       Running   0          15m

onap          onap-dmaap-message-router-kafka-5d96486cd6-77dkd               1/1       Running   0          15m

onap          onap-dmaap-message-router-zookeeper-677d5894d5-g5g9m           1/1       Running   0          15m

onap          onap-pomba-pomba-aaictxbuilder-8565f7d75c-dwvfr                2/2       Running   0          10m

onap          onap-pomba-pomba-contextaggregator-d9f888c4-zpx2k              1/1       Running   0          10m

onap          onap-pomba-pomba-data-router-66c5544446-d9crb                  1/1       Running   0          10m

onap          onap-pomba-pomba-elasticsearch-5c4f8c6b5b-85tvl                1/1       Running   0          10m

onap          onap-pomba-pomba-kibana-849cb74588-hfqps                       1/1       Running   0          10m

onap          onap-pomba-pomba-networkdiscovery-556bb9d7b8-9ghm4             2/2       Running   0          10m

onap          onap-pomba-pomba-networkdiscoveryctxbuilder-6ff7d49464-ngjql   2/2       Running   0          10m

onap          onap-pomba-pomba-sdcctxbuilder-7799ffccc9-jd2jx                1/1       Running   0          10m

onap          onap-pomba-pomba-search-data-7c649f8cbf-sfb5q                  2/2       Running   0          10m

onap          onap-pomba-pomba-servicedecomposition-5f8bb9d6f6-qdnqv         2/2       Running   0          10m

onap          onap-pomba-pomba-validation-service-79b8d5cb9f-x99r4           1/1       Running   0          10m

 

/michael

 

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Morgan Richomme
Sent: Friday, February 15, 2019 10:00 AM
To: xiao_xi.zhan@...; ZZZ Onap OPENLAB <onap.openlab@...>; mohamedlamine.traore@...; nthomas@...; Harshith.Bariki@...; barnali@...; sharangn@...; PM00501616@...; d035007@...; mark.harrison.uk69@...; James_Bryant@...; rajeev@...; Chao.Kan@...; GARCIA CESPEDES, Francisco javier OSP <franciscojavier.garcia@...>; PAWLAK Pawel O-PL <pawel.pawlak3@...>; MASTALERZ Wojciech O-PL <wojciech.mastalerz@...>; BRAUD Arnaud TGI/OLN <arnaud.braud@...>; srupanagunta@...; surveraj0612@...; jian.4.li@...; MINODIER David TGI/OLN <david.minodier@...>; Anuj.Singh@...; ROZIECKI Arnaud OLN/QOP <arnaud.roziecki@...>; Mandar.Ghogale@...; cprecup@...; alaslan@...; SKORUPA Marian O-PL <marian.skorupa@...>; KOWALCZYK Emil O-PL <emil.kowalczyk@...>; GEEREBAERT Matthieu TGI/OLS <matthieu.geerebaert@...>; HASPEKIAN Goar TGI/OLN <goar.haspekian@...>; Kyrylo_Iarosh@...; DEBEAU Eric TGI/OLN <eric.debeau@...>; adrian.osullivan@...; kevin.mcdonnell@...; Achilles.Devilla@...; Francesco.Cuzzoni@...; vijay.ramachandran@...; DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@...>; Karthikeyan_M39@...; ROBERT René TGI/OLN <rene.robert@...>; LY Amadou Houndaisse OLN/QOP <amadouhoundaisse.ly@...>; WECHSLER Philippe TGI/OLN <philippe.wechsler@...>; Syed_ah@...; EDEL Nicolas TGI/OLN <nicolas.edel@...>; SERKIES Bartek O-PL <bartek.serkies@...>; rajiva@...; pedro.benito@...; p.mentel@...; LABIDURIE Nathalie TGI/OLN <nathalie.labidurie@...>; BARS Remi TGI/OLN <remi.bars@...>; HOCHET Remi TGI/OLN <remi.hochet@...>; marco.ferrero@...; ROBERT Ludovic TGI/OLS <ludovic.robert@...>; NISHI_MATHUR@...; CANEVALI Alexis OLN/QOP <alexis.canevali@...>; CLAQUIN Marc TGI/OLN <marc.claquin@...>; Prakash.Ramchandran@...; Mielowski Rafał 2 - ORPL <rafal.mielowski2@...>; lukasz.urbanski@...; LABIDURIE Nathalie TGI/OLN <nathalie.labidurie@...>; GALIPOT Francis TGI/OLS <francis.galipot@...>; UllasKumar_Y@...; s.dehghanzadeh@...; SANCHEZ VILCHEZ Jose Manuel TGI/OLN <jose2.sanchez@...>; HAMID Mahmoud Ext OBS/CSO <maabdelhamid.ext@...>; JANASZKA Tomasz O-PL <tomasz.janaszka@...>; FRINDRICH Ondrej O-SK/ITN <ondrej1.frindrich@...>; SEVILLA Karine TGI/OLN <karine.sevilla@...>; sanchita@...; DESTRE Christian TGI/OLN <christian.destre@...>; donaldh@...; GOARZIN Lionel TGI/OLN <lionel.goarzin@...>; Ing-Wher_Chen@...; Ali.Fouladgar@...; Ning.So@...; BERRICHE Wassim TGI/OLN <wassim.berriche@...>; ROSSANT Olivier DTRS/DREAM <olivier.rossant@...>; BURSZTYNOWSKI Dariusz O-PL <dariusz.bursztynowski@...>; SEAUDI Abdelmuhaimen O-EG/HRCS <abdelmuhaimen.seaudi@...>; GAREL Romain TGI/OLN <romain.garel@...>; CROSSON David TGI/OLS <david.crosson@...>; PANEK Grzegorz O-PL <grzegorz.panek@...>; oguzhan.ceylan@...; fbrockne@...; nuno-t-simoes@...; Manojava_Bhagavathula@...; LAPLAUD Nicolas TGI/OLS <nicolas.laplaud@...>; SS820F@...; WALY Mohamed O-EG/HRCS <mohamed.waly@...>; luc.vermoesen@...; OSIŃSKI Tomasz O-PL <tomasz.osinski2@...>; Pawłowski Michał 1 - Hurt <michal.pawlowski1@...>; SIVAN Nicolas TGI/OLN <nicolas.sivan@...>; serkan.costu@...; Adnan.Saleem@...; alessandro.dalessandro@...; Luis.Suarez@...; taranjit_singh@...; SLAVKOVSKÝ Adrián O-SK/ITN <adrian.slavkovsky@...>; Kannan.Raman@...; RAJEWSKI Lukasz O-PL <lukasz.rajewski@...>; PERZO Thibault TGI/OLN <thibault.perzo@...>; Jerome.THIERY@...; HUET Vincent TGI/OLN <vincent.huet@...>; Muhammad.Siddiqui@...; antoine.bernard@...; KERRIEN Isabelle TGI/OLN <isabelle.kerrien@...>; MURAT.TURPCU@...; yog.vashishth@...; OUZZIF Meryem TGI/OLN <meryem.ouzzif@...>; tommy.guario@...; HARDY Thierry TGI/OLN <thierry.hardy@...>; DENISIEWICZ Andrzej O-PL <andrzej.denisiewicz@...>; chgump@...; BLAISONNEAU David TGI/OLN <david.blaisonneau@...>; chenxdu@...; sahin.renckes@...; OCENAS Martin O-SK/ITN <martin.ocenas@...>; AS00500801@...; GIMBERT Romain TGI/OLS <romain.gimbert@...>; romain.dutot@...; JEZEQUEL Mickael TGI/OLN <mickael.jezequel@...>; Kwiecień Krzysztof 1 - ORPL <krzysztof.kwiecien1@...>; MIELCZAREK Slawomir O-PL <slawomir.mielczarek@...>; Liming.Meng@...; eh552t@...
Cc: Loic.LEGAL@...; onap-openlab@...; onap-discuss@...
Subject: Re: [onap-discuss] [ONAP] Orange openlab upgrade casablanca to casablanca maintenance release

 

Hi

 

the Openlab has been reinstalled.

The keys have been pushed to the jumphost .

 

Basic tests have been performed .

It was possible to onboard and instantiate a basic VM successfuly.

 

However

 

please note that some pods are not in Running state (JIRAs are already open)

 

NAME                                                           READY     STATUS             RESTARTS   AGE

onap-aai-aai-sparky-be-7d778b7c6c-2glrc                        1/2       CrashLoopBackOff   55         3h

onap-appc-appc-ansible-server-54f489647d-lrznf                 0/1       CrashLoopBackOff   28         2h

onap-pomba-pomba-networkdiscoveryctxbuilder-6bf8dccf8f-96574   1/2       CrashLoopBackOff   47         2h

onap-pomba-pomba-sdcctxbuilder-77d67bcf7b-z525c                0/1       CrashLoopBackOff   47         2h

onap-sdnc-sdnc-ansible-server-7449c969bd-4blc8                 0/1       CrashLoopBackOff   37         3h

onap-uui-uui-server-64bf85dc6d-5tl29                           0/1       CrashLoopBackOff   33         2h

 

On the healthcheck are not all successfull

 

==============================================================================

Testsuites                                                                    

==============================================================================

Testsuites.Health-Check :: Testing ecomp components are available via calls.  

==============================================================================

Basic A&AI Health Check                                               | PASS |

------------------------------------------------------------------------------

Basic AAF Health Check                                                | PASS |

------------------------------------------------------------------------------

Basic AAF SMS Health Check                                            | PASS |

------------------------------------------------------------------------------

Basic APPC Health Check                                               | PASS |

------------------------------------------------------------------------------

Basic CLI Health Check                                                | PASS |

------------------------------------------------------------------------------

Basic CLAMP Health Check                                              | PASS |

------------------------------------------------------------------------------

Basic DCAE Health Check                                               | FAIL |

500 != 200

------------------------------------------------------------------------------

Basic DMAAP Data Router Health Check                                  | PASS |

------------------------------------------------------------------------------

Basic DMAAP Message Router Health Check                               | PASS |

------------------------------------------------------------------------------

Basic External API NBI Health Check                                   | PASS |

------------------------------------------------------------------------------

Basic Log Elasticsearch Health Check                                  | PASS |

------------------------------------------------------------------------------

Basic Log Kibana Health Check                                         | PASS |

------------------------------------------------------------------------------

Basic Log Logstash Health Check                                       | PASS |

------------------------------------------------------------------------------

Basic Microservice Bus Health Check                                   | PASS |

------------------------------------------------------------------------------

Basic Multicloud API Health Check                                     | PASS |

------------------------------------------------------------------------------

Basic Multicloud-ocata API Health Check                               | PASS |

------------------------------------------------------------------------------

Basic Multicloud-pike API Health Check                                | PASS |

------------------------------------------------------------------------------

Basic Multicloud-titanium_cloud API Health Check                      | PASS |

------------------------------------------------------------------------------

Basic Multicloud-vio API Health Check                                 | PASS |

------------------------------------------------------------------------------

Basic OOF-Homing Health Check                                         | PASS |

------------------------------------------------------------------------------

Basic OOF-SNIRO Health Check                                          | PASS |

------------------------------------------------------------------------------

Basic OOF-CMSO Health Check                                           | PASS |

------------------------------------------------------------------------------

Basic Policy Health Check                                             | PASS |

------------------------------------------------------------------------------

Basic Pomba AAI-context-builder Health Check                          | FAIL |

Test timeout 10 seconds exceeded.

------------------------------------------------------------------------------

Basic Pomba SDC-context-builder Health Check                          | PASS |

------------------------------------------------------------------------------

Basic Pomba Network-discovery-context-builder Health Check            | FAIL |

Test timeout 10 seconds exceeded.

------------------------------------------------------------------------------

Basic Portal Health Check                                             | PASS |

------------------------------------------------------------------------------

Basic SDC Health Check                                                (DMaaP:UP)| PASS |

------------------------------------------------------------------------------

Basic SDNC Health Check                                               | PASS |

------------------------------------------------------------------------------

Basic SO Health Check                                                 | PASS |

------------------------------------------------------------------------------

Basic UseCaseUI API Health Check                                      | PASS |

------------------------------------------------------------------------------

Basic VFC catalog API Health Check                                    | PASS |

------------------------------------------------------------------------------

Basic VFC emsdriver API Health Check                                  | PASS |

------------------------------------------------------------------------------

Basic VFC gvnfmdriver API Health Check                                | FAIL |

Test timeout 10 seconds exceeded.

------------------------------------------------------------------------------

Basic VFC huaweivnfmdriver API Health Check                           | PASS |

------------------------------------------------------------------------------

Basic VFC jujuvnfmdriver API Health Check                             | PASS |

------------------------------------------------------------------------------

Basic VFC multivimproxy API Health Check                              | PASS |

------------------------------------------------------------------------------

Basic VFC nokiavnfmdriver API Health Check                            | PASS |

------------------------------------------------------------------------------

Basic VFC nokiav2driver API Health Check                              | PASS |

------------------------------------------------------------------------------

Basic VFC nslcm API Health Check                                      | FAIL |

Test timeout 10 seconds exceeded.

------------------------------------------------------------------------------

Basic VFC resmgr API Health Check                                     | PASS |

------------------------------------------------------------------------------

Basic VFC vnflcm API Health Check                                     | FAIL |

Test timeout 10 seconds exceeded.

------------------------------------------------------------------------------

Basic VFC vnfmgr API Health Check                                     | PASS |

------------------------------------------------------------------------------

Basic VFC vnfres API Health Check                                     | PASS |

------------------------------------------------------------------------------

Basic VFC workflow API Health Check                                   | PASS |

------------------------------------------------------------------------------

Basic VFC ztesdncdriver API Health Check                              | PASS |

------------------------------------------------------------------------------

Basic VFC ztevnfmdriver API Health Check                              | FAIL |

Test timeout 10 seconds exceeded.

------------------------------------------------------------------------------

Basic VID Health Check                                                | PASS |

------------------------------------------------------------------------------

Basic VNFSDK Health Check                                             | PASS |

------------------------------------------------------------------------------

Basic Holmes Rule Management API Health Check                         | FAIL |

502 != 200

------------------------------------------------------------------------------

Basic Holmes Engine Management API Health Check                       | FAIL |

502 != 200

------------------------------------------------------------------------------

Testsuites.Health-Check :: Testing ecomp components are available ... | FAIL |

51 critical tests, 42 passed, 9 failed

51 tests total, 42 passed, 9 failed

==============================================================================

Testsuites                                                            | FAIL |

51 critical tests, 42 passed, 9 failed

51 tests total, 42 passed, 9 failed

==============================================================================

 

/Morgan

 

Le mardi 12 février 2019 à 15:57 +0100, Morgan Richomme a écrit :

Hi,

 

after 52 days of very relative stability of the Casablanca release, we finally lost our OpenLab this afternoon.

 

There are discrepencies in Kubernetes between the SO pods, replicaset and deployment.

The Deployment see everything all right, the pod does not exist anymore and the replicaset cannot be deleted or modified in order to force the respawn of the so-so pod.

Several pods were in a bad shape anyway

Rancher indicates unhealthy state of addon-starter and rancher-ingress-controller/

We started troubleshooting but as we planned to re-install the Casablanca maintenance release soon, we decided to anticipate this reinstallation to spare some time.

 

If you want to save anything on your jumphost, please proceed. Save you rc file (we do not reinstall the OpenStack part)

Everything will be cleaned. and your creds/keys repushed.

 

Sorry for the incovenience.

 

Morgan

 

_________________________________________________________________________________________________________________________

 

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 email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service

_________________________________________________________________________________________________________________________
 
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 email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service


aaf-service authz keyspace not found - Casablanca

kranthi guttikonda
 

Hi Team,

 

I am seeing an issue with onap Casablanca release with AAF-service container

 

I see aaf-cs started properly but aaf-service returns ‘authz’ keyspace not found error and all other pods are failing

 

I have created a question in Wiki with logs https://wiki.onap.org/questions/58229873/aaf-service-authz-keyspace-not-found---casablanca

 

Any help would be great.

 

Thanks,
Kranthi


Re: Onap OOM Casablanca DMaaP-Prov container - Issue

Michael O'Brien <frank.obrien@...>
 

My environment was minimal – a 50G VMware Workstation 12.5 VM on my laptop running only dmaap - SSD-NVMe drive, 12 vCores, 2.4Ghz

/michael

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Ronan Keogh
Sent: Monday, February 18, 2019 6:30 AM
To: kranthi guttikonda <kranthi.guttikonda@...>; onap-discuss@...
Subject: Re: [onap-discuss] Onap OOM Casablanca DMaaP-Prov container - Issue

 

Hi Kranthi,

Thanks for reporting this issue.

Can you send on the following logs from dmaap-dr-db pod please..

  • /var/lib/mysql/slow_query.log
  • /var/lib/mysql/audit.log
  • /var/log/mysql/mysql.log


Also, if you have details of your deployment so I can try to reproduce the issue that would be great, e.g. deploying across how many VMs and VM specs; full OOM deployment or a subset of components, etc?

Thanks,
Ronan

This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service


Re: [SO] vfModule model IDs - what are they all for?

Srini
 

Hi Gil and Ting,

 

Thank you so much for this response. We were trying to find the right documentation to understand these concepts for a while.  Thanks for the pointers to the detailed documents. Will try to understand more with internal team and get back if there are any questions.

 

One set of questions though J

I see VNF and VFM terminology. Are they both same in SDC?  In your email, you referred VNF and hence the question.

 

Also, there is one more term VSP (Vendor Software Package) in SDC. How does onboarding of VSP manifest as VNF or VFM?

 

Again, any simple explanation of these terms (VSP, VNF, VFM) and how they are related to each other is really appreciated.

 

Thanks

Srini

 

 

 

 

From: BULLARD, GIL [mailto:wb5674@...]
Sent: Wednesday, February 20, 2019 2:47 AM
To: onap-discuss@...; Multanen, Eric W <eric.w.multanen@...>
Cc: LU, TINGTING <tl2062@...>; FREEMAN, BRIAN D <bf1936@...>; SMOKOWSKI, STEVEN <ss835w@...>; SONSINO, OFIR <ofir.sonsino@...>; Addepalli, Srinivasa R <srinivasa.r.addepalli@...>
Subject: RE: [SO] vfModule model IDs - what are they all for?

 

Eric,

 

SDC’s data model is published at:

https://wiki.onap.org/display/DW/SDC+Data+model

If you download the Amsterdam data model file, the descriptions of these IDs are on page 50.

 

E.g., if a VNFx is used in 3 different SDC Service types, that VNFx will have:

  • A single unique model-invariant-id
  • A model-version-id per version of VNFx.
  • 3 model-customization-ids, one for each “use” of VNFx within a given SDC Service.

 

When the VNFx descriptor is onboarded from the vendor, it would indicate the allowed values for a given configuration parameter.  For example, in Version 1 of VNFx the allowed values could be {A, B, C}, whereas in Version 2 of VNFx the allowed values could be {A, B, C, D}.

 

When someone “drags” VNFx into various Services, they could “customize” this such as:

  • In the context of Service A, the Service designer may want to restrict parameter value “B”, thus allowing only values {A, C, D}
  • Similar with Service B and C, they would be allowed to specify their own “customization” within their respective service contexts.

 

FYI:

SDC has a comprehensive project site on ONAP, where you can find almost everything about current SDC implementation:

https://wiki.onap.org/display/DW/Service+Design+and+Creation+%28SDC%29+Portal

 

Gil Bullard & Ting Lu

 

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Multanen, Eric W
Sent: Friday, February 15, 2019 7:44 PM
To: onap-discuss@...
Subject: [onap-discuss] [SO] vfModule model IDs - what are they all for?

 

When I look at the SO vnf adapter code that creates vfModules – it is using the model-customization-id as a key parameter to identify the model of the vfmodule.

 

Is there a document or wiki that explains the differences and uses of the various vfmodule model identifiers?

 

I see that vfmodules have 3 IDs that correspond to IDs in the SDC catalog for the vfmodule:

 

What I see in AAI vfmodule:

     "model-invariant-id": "e4caddaa-ba67-4322-bd41-fd177719aaf1",

     "model-version-id": "3f8a329d-19e3-4d7e-bc64-549b7083b330",

     "model-customization-id": "1d2f2f51-bc64-444b-8f32-ba058105d1b0",

 

What I see in SDC (the VF_MODULES_METADATA artifact specifically)

    "vfModuleModelInvariantUUID": "e4caddaa-ba67-4322-bd41-fd177719aaf1",

   "vfModuleModelUUID": "3f8a329d-19e3-4d7e-bc64-549b7083b330",

    "vfModuleModelCustomizationUUID": "1d2f2f51-bc64-444b-8f32-ba058105d1b0"

 

I guess the invariant ID stays constant through different versions.

 

I’m not so clear on the difference between the version and customization and why one vs the other would be used in a given situation.

 

 

Thanks,

Eric


Re: [SO] vfModule model IDs - what are they all for?

Gil Bullard <wb5674@...>
 

Eric,

 

SDC’s data model is published at:

https://wiki.onap.org/display/DW/SDC+Data+model

If you download the Amsterdam data model file, the descriptions of these IDs are on page 50.

 

E.g., if a VNFx is used in 3 different SDC Service types, that VNFx will have:

  • A single unique model-invariant-id
  • A model-version-id per version of VNFx.
  • 3 model-customization-ids, one for each “use” of VNFx within a given SDC Service.

 

When the VNFx descriptor is onboarded from the vendor, it would indicate the allowed values for a given configuration parameter.  For example, in Version 1 of VNFx the allowed values could be {A, B, C}, whereas in Version 2 of VNFx the allowed values could be {A, B, C, D}.

 

When someone “drags” VNFx into various Services, they could “customize” this such as:

  • In the context of Service A, the Service designer may want to restrict parameter value “B”, thus allowing only values {A, C, D}
  • Similar with Service B and C, they would be allowed to specify their own “customization” within their respective service contexts.

 

FYI:

SDC has a comprehensive project site on ONAP, where you can find almost everything about current SDC implementation:

https://wiki.onap.org/display/DW/Service+Design+and+Creation+%28SDC%29+Portal

 

Gil Bullard & Ting Lu

 

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Multanen, Eric W
Sent: Friday, February 15, 2019 7:44 PM
To: onap-discuss@...
Subject: [onap-discuss] [SO] vfModule model IDs - what are they all for?

 

When I look at the SO vnf adapter code that creates vfModules – it is using the model-customization-id as a key parameter to identify the model of the vfmodule.

 

Is there a document or wiki that explains the differences and uses of the various vfmodule model identifiers?

 

I see that vfmodules have 3 IDs that correspond to IDs in the SDC catalog for the vfmodule:

 

What I see in AAI vfmodule:

     "model-invariant-id": "e4caddaa-ba67-4322-bd41-fd177719aaf1",

     "model-version-id": "3f8a329d-19e3-4d7e-bc64-549b7083b330",

     "model-customization-id": "1d2f2f51-bc64-444b-8f32-ba058105d1b0",

 

What I see in SDC (the VF_MODULES_METADATA artifact specifically)

    "vfModuleModelInvariantUUID": "e4caddaa-ba67-4322-bd41-fd177719aaf1",

   "vfModuleModelUUID": "3f8a329d-19e3-4d7e-bc64-549b7083b330",

    "vfModuleModelCustomizationUUID": "1d2f2f51-bc64-444b-8f32-ba058105d1b0"

 

I guess the invariant ID stays constant through different versions.

 

I’m not so clear on the difference between the version and customization and why one vs the other would be used in a given situation.

 

 

Thanks,

Eric


Re: dev-dmaap-dmaap-dr-node pod does not come up due to https call to dev-dmaap-dmaap-dr-prov pod #dmaap #casablanca

Conor Ward
 

Hi,


The issue with only dmaap-dr-node not coming up is not related to DMAAP-964. DMAAP-964 is an issue which occurs due to the mariadb not being instantiated correctly so dmaap-dr-prov and dmaap-dr-node do not come up.

The issue we are now seeing with only dmaap-dr-node not coming up is due to AAF certs expiring. We are tracking that issue here DMAAP-1048, we also reached out to the onap-seccom mailing list for any advice on extending or renewing the certs but haven't heard anything back yet. The link to that message is here - https://lists.onap.org/g/onap-seccom/topic/aaf_certificates_expired/29915899?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,29915899.


I'm guessing that this issue has occurred before so any help or feedback would be appreciated.


Regards,

Conor


From: onap-discuss@... <onap-discuss@...> on behalf of Michael O'Brien <frank.obrien@...>
Sent: Wednesday 20 February 2019 03:10:28
To: onap-discuss@...; kranthi.guttikonda@...; alessandro.dalessandro@...
Subject: Re: [onap-discuss] dev-dmaap-dmaap-dr-node pod does not come up due to https call to dev-dmaap-dmaap-dr-prov pod #dmaap #casablanca
 

Guys seeing this again both on casablanca 20190218 and master 20180218 - both running only dmaap (nothing else deployed or deployed with aaf)

LOG-898
master
onap onap-dmaap-dmaap-dr-node-57f77bd54d-q7v78 0/1 CrashLoopBackOff 9 26m 10.42.112.70 obriensystemsu0 <none>

casablanca (3.0.1 essentially)
onap onap-dmaap-dmaap-dr-node-57f77bd54d-kw8n7 0/1 Running 79 5h

 

I am also seeing an issue with SDNC ansible on both the latest Casablanca and master – sdnc required dmaap and sdc to come up - note

onap          onap-sdnc-sdnc-ansible-server-7d595dd8-fvm95       0/1       CrashLoopBackOff   41         3h

 

/michael

From: onap-discuss@... <onap-discuss@...> On Behalf Of kranthi guttikonda
Sent: Tuesday, February 19, 2019 2:07 PM
To: onap-discuss@...; alessandro.dalessandro@...
Subject: Re: [onap-discuss] dev-dmaap-dmaap-dr-node pod does not come up due to https call to dev-dmaap-dmaap-dr-prov pod #dmaap #casablanca

 

Please take a look into https://jira.onap.org/browse/DMAAP-964

 

From: <onap-discuss@...> on behalf of D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "alessandro.dalessandro@..." <alessandro.dalessandro@...>
Date: Tuesday, February 19, 2019 at 12:16 PM
To: "onap-discuss@..." <onap-discuss@...>
Subject: [onap-discuss] dev-dmaap-dmaap-dr-node pod does not come up due to https call to dev-dmaap-dmaap-dr-prov pod #dmaap #casablanca

 

Hi all,

I have deployed Casablanca and I have an issue with the highlighted pod

 

 

dev-dmaap-dbc-pg-0                                                                    1/1      Running            0          30m       10.42.29.89   k8s-13    <none>

dev-dmaap-dbc-pg-1                                                                    1/1       Running            0          27m       10.42.182.91 k8s-7     <none>

dev-dmaap-dbc-pgpool-7b748d5894-88wb9                     1/1       Running            0          30m       10.42.140.152   k8s-11    <none>

dev-dmaap-dbc-pgpool-7b748d5894-pj8zv                        1/1        Running            0          30m       10.42.183.217   k8s-6     <none>

dev-dmaap-dmaap-bus-controller-6757c4c86-rv9zh       1/1       Running            0          30m       10.42.156.206   k8s-10    <none>

dev-dmaap-dmaap-dr-db-bb4c67cfd-84c99                        1/1       Running            0          30m       10.42.138.166   k8s-10    <none>

dev-dmaap-dmaap-dr-node-5655ffbd55-gdfpx                 0/1       Running            6         30m       10.42.30.95     k8s-6     <none>

dev-dmaap-dmaap-dr-prov-66df46884f-sjd7x                  1/1       Running            0          30m       10.42.13.150    k8s-7     <none>

dev-dmaap-message-router-684b499dbc-8c6dm            1/1       Running            0         30m       10.42.191.38    k8s-11    <none>

dev-dmaap-message-router-kafka-8466bf6864-t7gtq    1/1       Running            0          30m      10.42.32.83     k8s-4     <none>

dev-dmaap-message-router-zookeeper-5bd997b466-dfmzl  1/1       Running            0          30m       10.42.25.154    k8s-2     <none>

 

Log from dev-dmaap-dmaap-dr-node-5655ffbd55-gdfpx is:

 

16:03:22.198 ERROR [Node Configuration Timer] org.onap.dmaap.datarouter.node.NodeConfigManager - EELF0004E  Configuration failed.

java.net.UnknownHostException: dmaap-dr-prov - try again later.

provurl:: https://dmaap-dr-prov:8443/internal/prov

16:03:22.200 ERROR [Node Configuration Timer] org.onap.dmaap.datarouter.node.NodeConfigManager - EELF0004E  Configuration failed.

java.net.UnknownHostException: dmaap-dr-prov - try again later.

provurl:: https://dmaap-dr-prov:8443/internal/prov

 

 

what I notice is that if the request comes from http it is satisfied while it is NOT if it comes from https

 

please look at the details here below from the robot container:   

 

curl -v http://dmaap-dr-prov:8080/internal/prov

 

{

"feeds": [

],

"groups": [

],

"subscriptions": [

],

"parameters": {

   "ACTIVE_POD": "dmaap-dr-prov",

   "DELIVERY_INIT_RETRY_INTERVAL": 10,

   "DELIVERY_MAX_AGE": 86400,

   "DELIVERY_MAX_RETRY_INTERVAL": 3600,

   "DELIVERY_RETRY_RATIO": 2,

   "LOGROLL_INTERVAL": 300,

   "NODES": ["dmaap-dr-node"],

   "PROV_ACTIVE_NAME": "dmaap-dr-prov",

   "PROV_AUTH_ADDRESSES":

["dmaap-dr-prov","dmaap-dr-node"],

   "PROV_AUTH_SUBJECTS": [""],

   "PROV_DOMAIN": "onap",

   "PROV_MAXFEED_COUNT": 10000,

   "PROV_MAXSUB_COUNT": 100000,

   "PROV_NAME": "dmaap-dr-prov",

   "PROV_REQUIRE_CERT": "false",

   "PROV_REQUIRE_SECURE": "false",

   "STANDBY_POD": "",

   "_INT_VALUES":

["LOGROLL_INTERVAL","PROV_MAXFEED_COUNT","PROV_MAXSUB_COUNT","DELIVERY_INIT_RETRY_INTERVAL","DELIVERY_MAX_RETRY_INTERVAL","DELIVERY_RETRY_RATIO","DELIVERY_MAX_AGE"]

},

"ingress": [

],

"egress": {

},

"routing": [

]

 

 

curl - https://dmaap-dr-prov:8080/internal/prov     THE SAME REQUEST OF DMAAP-DR-NODE

 

 *   Trying 10.43.74.144...

* TCP_NODELAY set

* Connected to dmaap-dr-prov (10.43.74.144) port 8080 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* successfully set certificate verify locations:

*   CAfile: /etc/ssl/certs/ca-certificates.crt

   CApath: /etc/ssl/certs

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* error:1408F10B:SSL routines:ssl3_get_record:wrong version number

* stopped the pause stream!

* Closing connection 0

curl: (35) error:1408F10B:SSL

routines:ssl3_get_record:wrong version number

 

 

I’m re-installing Casablanca after changing the file: root@rancher:~/oom/kubernetes/dmaap/charts/dmaap-bus-controller/resources/dmaap/onap.json  as below:

from "drProvUrl": "https://dmaap-dr-prov:8443"    to

"drProvUrl": "http://dmaap-dr-prov:8080"

 

I’m wondering if someone else has already experienced the same issue and tested this change to share with me if there will be side effects.

 

Thanks in advance

Best regards,

Alessandro

This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service


Re: dev-dmaap-dmaap-dr-node pod does not come up due to https call to dev-dmaap-dmaap-dr-prov pod #dmaap #casablanca

Michael O'Brien <frank.obrien@...>
 

Guys seeing this again both on casablanca 20190218 and master 20180218 - both running only dmaap (nothing else deployed or deployed with aaf)

LOG-898
master
onap onap-dmaap-dmaap-dr-node-57f77bd54d-q7v78 0/1 CrashLoopBackOff 9 26m 10.42.112.70 obriensystemsu0 <none>

casablanca (3.0.1 essentially)
onap onap-dmaap-dmaap-dr-node-57f77bd54d-kw8n7 0/1 Running 79 5h

 

I am also seeing an issue with SDNC ansible on both the latest Casablanca and master – sdnc required dmaap and sdc to come up - note

onap          onap-sdnc-sdnc-ansible-server-7d595dd8-fvm95       0/1       CrashLoopBackOff   41         3h

 

/michael

From: onap-discuss@... <onap-discuss@...> On Behalf Of kranthi guttikonda
Sent: Tuesday, February 19, 2019 2:07 PM
To: onap-discuss@...; alessandro.dalessandro@...
Subject: Re: [onap-discuss] dev-dmaap-dmaap-dr-node pod does not come up due to https call to dev-dmaap-dmaap-dr-prov pod #dmaap #casablanca

 

Please take a look into https://jira.onap.org/browse/DMAAP-964

 

From: <onap-discuss@...> on behalf of D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "alessandro.dalessandro@..." <alessandro.dalessandro@...>
Date: Tuesday, February 19, 2019 at 12:16 PM
To: "onap-discuss@..." <onap-discuss@...>
Subject: [onap-discuss] dev-dmaap-dmaap-dr-node pod does not come up due to https call to dev-dmaap-dmaap-dr-prov pod #dmaap #casablanca

 

Hi all,

I have deployed Casablanca and I have an issue with the highlighted pod

 

 

dev-dmaap-dbc-pg-0                                                                    1/1      Running            0          30m       10.42.29.89   k8s-13    <none>

dev-dmaap-dbc-pg-1                                                                    1/1       Running            0          27m       10.42.182.91 k8s-7     <none>

dev-dmaap-dbc-pgpool-7b748d5894-88wb9                     1/1       Running            0          30m       10.42.140.152   k8s-11    <none>

dev-dmaap-dbc-pgpool-7b748d5894-pj8zv                        1/1        Running            0          30m       10.42.183.217   k8s-6     <none>

dev-dmaap-dmaap-bus-controller-6757c4c86-rv9zh       1/1       Running            0          30m       10.42.156.206   k8s-10    <none>

dev-dmaap-dmaap-dr-db-bb4c67cfd-84c99                        1/1       Running            0          30m       10.42.138.166   k8s-10    <none>

dev-dmaap-dmaap-dr-node-5655ffbd55-gdfpx                 0/1       Running            6         30m       10.42.30.95     k8s-6     <none>

dev-dmaap-dmaap-dr-prov-66df46884f-sjd7x                  1/1       Running            0          30m       10.42.13.150    k8s-7     <none>

dev-dmaap-message-router-684b499dbc-8c6dm            1/1       Running            0         30m       10.42.191.38    k8s-11    <none>

dev-dmaap-message-router-kafka-8466bf6864-t7gtq    1/1       Running            0          30m      10.42.32.83     k8s-4     <none>

dev-dmaap-message-router-zookeeper-5bd997b466-dfmzl  1/1       Running            0          30m       10.42.25.154    k8s-2     <none>

 

Log from dev-dmaap-dmaap-dr-node-5655ffbd55-gdfpx is:

 

16:03:22.198 ERROR [Node Configuration Timer] org.onap.dmaap.datarouter.node.NodeConfigManager - EELF0004E  Configuration failed.

java.net.UnknownHostException: dmaap-dr-prov - try again later.

provurl:: https://dmaap-dr-prov:8443/internal/prov

16:03:22.200 ERROR [Node Configuration Timer] org.onap.dmaap.datarouter.node.NodeConfigManager - EELF0004E  Configuration failed.

java.net.UnknownHostException: dmaap-dr-prov - try again later.

provurl:: https://dmaap-dr-prov:8443/internal/prov

 

 

what I notice is that if the request comes from http it is satisfied while it is NOT if it comes from https

 

please look at the details here below from the robot container:   

 

curl -v http://dmaap-dr-prov:8080/internal/prov

 

{

"feeds": [

],

"groups": [

],

"subscriptions": [

],

"parameters": {

   "ACTIVE_POD": "dmaap-dr-prov",

   "DELIVERY_INIT_RETRY_INTERVAL": 10,

   "DELIVERY_MAX_AGE": 86400,

   "DELIVERY_MAX_RETRY_INTERVAL": 3600,

   "DELIVERY_RETRY_RATIO": 2,

   "LOGROLL_INTERVAL": 300,

   "NODES": ["dmaap-dr-node"],

   "PROV_ACTIVE_NAME": "dmaap-dr-prov",

   "PROV_AUTH_ADDRESSES":

["dmaap-dr-prov","dmaap-dr-node"],

   "PROV_AUTH_SUBJECTS": [""],

   "PROV_DOMAIN": "onap",

   "PROV_MAXFEED_COUNT": 10000,

   "PROV_MAXSUB_COUNT": 100000,

   "PROV_NAME": "dmaap-dr-prov",

   "PROV_REQUIRE_CERT": "false",

   "PROV_REQUIRE_SECURE": "false",

   "STANDBY_POD": "",

   "_INT_VALUES":

["LOGROLL_INTERVAL","PROV_MAXFEED_COUNT","PROV_MAXSUB_COUNT","DELIVERY_INIT_RETRY_INTERVAL","DELIVERY_MAX_RETRY_INTERVAL","DELIVERY_RETRY_RATIO","DELIVERY_MAX_AGE"]

},

"ingress": [

],

"egress": {

},

"routing": [

]

 

 

curl - https://dmaap-dr-prov:8080/internal/prov     THE SAME REQUEST OF DMAAP-DR-NODE

 

 *   Trying 10.43.74.144...

* TCP_NODELAY set

* Connected to dmaap-dr-prov (10.43.74.144) port 8080 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* successfully set certificate verify locations:

*   CAfile: /etc/ssl/certs/ca-certificates.crt

   CApath: /etc/ssl/certs

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* error:1408F10B:SSL routines:ssl3_get_record:wrong version number

* stopped the pause stream!

* Closing connection 0

curl: (35) error:1408F10B:SSL

routines:ssl3_get_record:wrong version number

 

 

I’m re-installing Casablanca after changing the file: root@rancher:~/oom/kubernetes/dmaap/charts/dmaap-bus-controller/resources/dmaap/onap.json  as below:

from "drProvUrl": "https://dmaap-dr-prov:8443"    to

"drProvUrl": "http://dmaap-dr-prov:8080"

 

I’m wondering if someone else has already experienced the same issue and tested this change to share with me if there will be side effects.

 

Thanks in advance

Best regards,

Alessandro

This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service


Re: ONAP: communication components.

Michael O'Brien <frank.obrien@...>
 

Just noticed that your attachment is a very old version of the diagram – use the one from below

https://wiki.onap.org/display/DW/Cloud+Native+Deployment#CloudNativeDeployment-DeploymentProfile

dated 20191208

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Michael O'Brien
Sent: Tuesday, February 19, 2019 9:58 PM
To: natacha.mach@...
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>; onap-discuss@...
Subject: Re: [onap-discuss] ONAP: communication components.

 

Natacha,

  We discussed this briefly during the PTL call this morning – you bring up a good point – we need to revisit the dependency tree (static, deployment, runtime, compile time) – to get a good view of the system – there are several pages in the wiki – we should meet over this – Friday is a more open day, lets discuss this in the TSC.

  The diagram is a screencap of the original lucidchart diagram – there is no more to it – I just ran a full 3.0.0-ONAP deployment, did the following 2 commands to get pods and nodeports – I don’t plan on doing this manual diagram again – it was about 12h over a couple days – since 3.x was stable – it was a good time for snapshot – and I needed a diagram in which to enumerate log compliance (libraries, format, sidecars, shipping etc…) – there are no REST level API dependencies or deploy time pod dependencies in that diagram – just extraction of the DB layer from the pods.

              Kubectl get pods –all-namespaces

              Kubectl get services –all-namespaces

  Hi, that diagram only shows links from the filebeat sidecars into the logstash port on the ELK stack pods – for log streaming.

  I’ll keep any changes on the main page in https://wiki.onap.org/display/DW/Cloud+Native+Deployment

  You would be more interested in the levels of coms and compile dependencies between the pods.

  I created that diagram in lucidchart (for speed of drawing – easier than in gliffy) – it was a 1-time for casablanca – I am working on automating a live version as part of a dashboard.

 

  For static compile dependencies you can mine the pom.xml files

  For static pod dependencies you can mine the deployment yamls in the oom dir – this is how I derived the partial chart of pod dependencies enforced on deployment startup.

https://wiki.onap.org/display/DW/Log+Streaming+Compliance+and+API#LogStreamingComplianceandAPI-DeploymentDependencyTree-Containerlevel

 

  Most interesting would be the dynamic REST calls between the components – this would require going through all the code – or pulling the logs/metrics from the k8s stack during operations (would require 100% code coverage though) - Another option would be to either instrument/weave the rest controllers or more likely mine the logs generated during these saturation calls – easier to just browse the code – writing a parsing tool would be better but would likely take as much time as doing a pass through the code – like I did for the OOM dependencies.

 

   Sorry for the late reply – I have to triage/queue the work I do as I am currently overallocated.

  /michael

 

 

From: natacha.mach@... <natacha.mach@...>
Sent: Monday, February 11, 2019 4:51 AM
To: Michael O'Brien <Frank.Obrien@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>
Subject: ONAP: communication components.
Importance: High

 

Hello Michael,

 

We have had a discussion with Pawel within SECCOM regarding the relevance to elaborate a communication matrix between ONAP components.

In attached is a file that you transmitted : if it is possible to reuse this document, would you have the original file, that we could rely on in order to start the study regarding the communication flows between ONAP components?

 

Many thanks and regards

Natacha

_________________________________________________________________________________________________________________________
 
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 email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service

This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service


Re: ONAP: communication components.

Michael O'Brien <frank.obrien@...>
 

Natacha,

  We discussed this briefly during the PTL call this morning – you bring up a good point – we need to revisit the dependency tree (static, deployment, runtime, compile time) – to get a good view of the system – there are several pages in the wiki – we should meet over this – Friday is a more open day, lets discuss this in the TSC.

  The diagram is a screencap of the original lucidchart diagram – there is no more to it – I just ran a full 3.0.0-ONAP deployment, did the following 2 commands to get pods and nodeports – I don’t plan on doing this manual diagram again – it was about 12h over a couple days – since 3.x was stable – it was a good time for snapshot – and I needed a diagram in which to enumerate log compliance (libraries, format, sidecars, shipping etc…) – there are no REST level API dependencies or deploy time pod dependencies in that diagram – just extraction of the DB layer from the pods.

              Kubectl get pods –all-namespaces

              Kubectl get services –all-namespaces

  Hi, that diagram only shows links from the filebeat sidecars into the logstash port on the ELK stack pods – for log streaming.

  I’ll keep any changes on the main page in https://wiki.onap.org/display/DW/Cloud+Native+Deployment

  You would be more interested in the levels of coms and compile dependencies between the pods.

  I created that diagram in lucidchart (for speed of drawing – easier than in gliffy) – it was a 1-time for casablanca – I am working on automating a live version as part of a dashboard.

 

  For static compile dependencies you can mine the pom.xml files

  For static pod dependencies you can mine the deployment yamls in the oom dir – this is how I derived the partial chart of pod dependencies enforced on deployment startup.

https://wiki.onap.org/display/DW/Log+Streaming+Compliance+and+API#LogStreamingComplianceandAPI-DeploymentDependencyTree-Containerlevel

 

  Most interesting would be the dynamic REST calls between the components – this would require going through all the code – or pulling the logs/metrics from the k8s stack during operations (would require 100% code coverage though) - Another option would be to either instrument/weave the rest controllers or more likely mine the logs generated during these saturation calls – easier to just browse the code – writing a parsing tool would be better but would likely take as much time as doing a pass through the code – like I did for the OOM dependencies.

 

   Sorry for the late reply – I have to triage/queue the work I do as I am currently overallocated.

  /michael

 

 

From: natacha.mach@... <natacha.mach@...>
Sent: Monday, February 11, 2019 4:51 AM
To: Michael O'Brien <Frank.Obrien@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>
Subject: ONAP: communication components.
Importance: High

 

Hello Michael,

 

We have had a discussion with Pawel within SECCOM regarding the relevance to elaborate a communication matrix between ONAP components.

In attached is a file that you transmitted : if it is possible to reuse this document, would you have the original file, that we could rely on in order to start the study regarding the communication flows between ONAP components?

 

Many thanks and regards

Natacha

_________________________________________________________________________________________________________________________
 
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 email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service


Re: [appc] questions about configuration storage

Taka Cho
 

Hi,

 

Marco almost covered everything 😊

 

‘configureModidy’ is not for incremental configuration. It’s just to change any existing parameter.

 

If “incremental” means modifying existing parameter, then you said yes it’s yes. APPC sends consolidated config to each existing VM/VNF instances.

 

APPC does not maintain various versions of configuration.

 

Hope that helps

 

Taka

 

From: PLATANIA, MARCO
Sent: Tuesday, February 19, 2019 12:43 PM
To: onap-discuss@...; srinivasa.r.addepalli@...; CHO, TAKAMUNE <tc012c@...>; akapadia@...
Subject: Re: [onap-discuss] [appc] questions about configuration storage

 

Srini,

 

I comment on the scale out part, leaving the rest to Taka.

 

For scale out, the workflow that runs in SO includes a VNF reconfiguration building block that is used to reconfigure the VNF after scaling. The reconfiguration action is executed against an anchor point, which keeps some sort of VNF-level state. In the vLB/vDNS use case, the vLB is the anchor point and contains a list of active vDNS instances (each instance element is an actual GRE tunnel towards a vDNS). When we add a new vDNS as part of a scaling operation, the vLB gets reconfigured. In this use case, reconfiguration means that the list of active vDNS instances is extended so as to include the one just created.

 

The reconfiguration action can be executed by APPC (fully supported in Casablanca) or SDNC (experimental). Focusing on reconfiguration via APPC, we need to setup the VNF with CDT at the very beginning, specifying:

  • Action: ConfigScaleOut (note, this in NOT ConfigModify)
  • Protocol: NETCONF
  • Device port number: typically depends on the protocol that you choose
  • Device interface: an XML file that describes the interface of the device that APPC is going to talk to (in our example the vLB interface).
  • Configuration parameters: a YAML file that contains the parameters that will be used by the device interface

 

The actual parameter values come from SO as payload, APPC extracts them and populate the XML file accordingly before running a NETCONF query against the device. In Casablanca, APPC supports NETCONF merge operation, which means that behind the scenes NETCONF is merging the new configuration coming from the XML file described above with the existing configuration already set in the device. In practical terms, the XML file contains information about the new vDNS, while the configuration in the device (vLB) contains a list of vDNS instances already spun up. The NETCONF merge operation just adds the vDNS endpoint described in the XML file to the existing list.

 

I think “incremental” means that the configuration of the device changes but still depends on the previous state (in the example above, a new vDNS element is added to an existing list – the state of the vLB), while ConfigModify just replaces the old configuration with the new one.

 

Taka can certainly add more on this.

 

Marco

 

From: <onap-discuss@...> on behalf of Srini <srinivasa.r.addepalli@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "srinivasa.r.addepalli@..." <srinivasa.r.addepalli@...>
Date: Tuesday, February 19, 2019 at 11:51 AM
To: "onap-discuss@..." <onap-discuss@...>, "CHO, TAKAMUNE" <tc012c@...>, "akapadia@..." <akapadia@...>
Subject: Re: [onap-discuss] [appc] questions about configuration storage

 

 

Thank you Amar and Taka on the email thread.

 

I have few further questions.

 

APPC has ‘Configure’ and ‘ConfigModify’ LCM commands.  Based on documentation I see,  if multiple ‘Configure’ commands are issued, last ‘Configure’ configuration-parameters are used as each command replaces the old configuration with the configuration of the command.  ‘ConfigModify” – Is this meant for incremental configuration? If so, does APPC maintain various versions of configuration?  During scale-out, when new VM is instantiated, does APPC configure the new VM instances with the consolidated configuration without any human intervention?

 

When incremental configuration is made (via ConfigModify), does APPC send incremental configuration to all existing VM instances? 

Also, does it send only incremental configuration or does it send consolidated configuration to each of existing VM instances?

 

Thanks

Srini

 

 

 

 

 

From: onap-discuss@... [mailto:onap-discuss@...] On Behalf Of Taka Cho
Sent: Friday, February 15, 2019 5:46 AM
To: onap-discuss@...; akapadia@...
Subject: Re: [onap-discuss] [appc] questions about configuration storage

 

Hi Amar,

 

I am not sure what VNF configuration data that you are referring to.  You will see APPC dependencies here: https://wiki.onap.org/display/DW/APPC+Dublin+M1+Release+Planning#APPCDublinM1ReleasePlanning-ONAPDependencies

 

And APPC stores artifact in APPC’s maria DB.

 

APPC sends LCM API payload using ansible/REST/Chef etc protocols to downstream for configuring VNF(C) /VM.

 

Taka

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Amar Kapadia
Sent: Wednesday, February 13, 2019 7:12 PM
To: onap-discuss@...
Subject: [onap-discuss] [appc] questions about configuration storage

 

Hi, 

 

A few quick questions on APP-C and VNF configuration data storage:

 

1. Does APP-C store VNF configuration data? 

2. If so where? Is it in A&AI or some private APP-C datastore?

3. Is the storage populated when APP-C writes the configuration to the VNF or does APP-C  poll the VNF to get configuration data? 

 

Regards,

Amar

__________________________________________________________________________________________

Sign up for our Feb ONAP Bootcamp II in Berlin or Apr ONAP Bootcamp pre-ONS at aarnanetworks.com/training

__________________________________________________________________________________________


Re: dev-dmaap-dmaap-dr-node pod does not come up due to https call to dev-dmaap-dmaap-dr-prov pod #dmaap #casablanca

kranthi guttikonda
 

Please take a look into https://jira.onap.org/browse/DMAAP-964

 

From: <onap-discuss@...> on behalf of D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "alessandro.dalessandro@..." <alessandro.dalessandro@...>
Date: Tuesday, February 19, 2019 at 12:16 PM
To: "onap-discuss@..." <onap-discuss@...>
Subject: [onap-discuss] dev-dmaap-dmaap-dr-node pod does not come up due to https call to dev-dmaap-dmaap-dr-prov pod #dmaap #casablanca

 

Hi all,

I have deployed Casablanca and I have an issue with the highlighted pod

 

 

dev-dmaap-dbc-pg-0                                                                    1/1      Running            0          30m       10.42.29.89   k8s-13    <none>

dev-dmaap-dbc-pg-1                                                                    1/1       Running            0          27m       10.42.182.91 k8s-7     <none>

dev-dmaap-dbc-pgpool-7b748d5894-88wb9                     1/1       Running            0          30m       10.42.140.152   k8s-11    <none>

dev-dmaap-dbc-pgpool-7b748d5894-pj8zv                        1/1        Running            0          30m       10.42.183.217   k8s-6     <none>

dev-dmaap-dmaap-bus-controller-6757c4c86-rv9zh       1/1       Running            0          30m       10.42.156.206   k8s-10    <none>

dev-dmaap-dmaap-dr-db-bb4c67cfd-84c99                        1/1       Running            0          30m       10.42.138.166   k8s-10    <none>

dev-dmaap-dmaap-dr-node-5655ffbd55-gdfpx                 0/1       Running            6         30m       10.42.30.95     k8s-6     <none>

dev-dmaap-dmaap-dr-prov-66df46884f-sjd7x                  1/1       Running            0          30m       10.42.13.150    k8s-7     <none>

dev-dmaap-message-router-684b499dbc-8c6dm            1/1       Running            0         30m       10.42.191.38    k8s-11    <none>

dev-dmaap-message-router-kafka-8466bf6864-t7gtq    1/1       Running            0          30m      10.42.32.83     k8s-4     <none>

dev-dmaap-message-router-zookeeper-5bd997b466-dfmzl  1/1       Running            0          30m       10.42.25.154    k8s-2     <none>

 

Log from dev-dmaap-dmaap-dr-node-5655ffbd55-gdfpx is:

 

16:03:22.198 ERROR [Node Configuration Timer] org.onap.dmaap.datarouter.node.NodeConfigManager - EELF0004E  Configuration failed.

java.net.UnknownHostException: dmaap-dr-prov - try again later.

provurl:: https://dmaap-dr-prov:8443/internal/prov

16:03:22.200 ERROR [Node Configuration Timer] org.onap.dmaap.datarouter.node.NodeConfigManager - EELF0004E  Configuration failed.

java.net.UnknownHostException: dmaap-dr-prov - try again later.

provurl:: https://dmaap-dr-prov:8443/internal/prov

 

 

what I notice is that if the request comes from http it is satisfied while it is NOT if it comes from https

 

please look at the details here below from the robot container:   

 

curl -v http://dmaap-dr-prov:8080/internal/prov

 

{

"feeds": [

],

"groups": [

],

"subscriptions": [

],

"parameters": {

   "ACTIVE_POD": "dmaap-dr-prov",

   "DELIVERY_INIT_RETRY_INTERVAL": 10,

   "DELIVERY_MAX_AGE": 86400,

   "DELIVERY_MAX_RETRY_INTERVAL": 3600,

   "DELIVERY_RETRY_RATIO": 2,

   "LOGROLL_INTERVAL": 300,

   "NODES": ["dmaap-dr-node"],

   "PROV_ACTIVE_NAME": "dmaap-dr-prov",

   "PROV_AUTH_ADDRESSES":

["dmaap-dr-prov","dmaap-dr-node"],

   "PROV_AUTH_SUBJECTS": [""],

   "PROV_DOMAIN": "onap",

   "PROV_MAXFEED_COUNT": 10000,

   "PROV_MAXSUB_COUNT": 100000,

   "PROV_NAME": "dmaap-dr-prov",

   "PROV_REQUIRE_CERT": "false",

   "PROV_REQUIRE_SECURE": "false",

   "STANDBY_POD": "",

   "_INT_VALUES":

["LOGROLL_INTERVAL","PROV_MAXFEED_COUNT","PROV_MAXSUB_COUNT","DELIVERY_INIT_RETRY_INTERVAL","DELIVERY_MAX_RETRY_INTERVAL","DELIVERY_RETRY_RATIO","DELIVERY_MAX_AGE"]

},

"ingress": [

],

"egress": {

},

"routing": [

]

 

 

curl - https://dmaap-dr-prov:8080/internal/prov     THE SAME REQUEST OF DMAAP-DR-NODE

 

 *   Trying 10.43.74.144...

* TCP_NODELAY set

* Connected to dmaap-dr-prov (10.43.74.144) port 8080 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* successfully set certificate verify locations:

*   CAfile: /etc/ssl/certs/ca-certificates.crt

   CApath: /etc/ssl/certs

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* error:1408F10B:SSL routines:ssl3_get_record:wrong version number

* stopped the pause stream!

* Closing connection 0

curl: (35) error:1408F10B:SSL

routines:ssl3_get_record:wrong version number

 

 

I’m re-installing Casablanca after changing the file: root@rancher:~/oom/kubernetes/dmaap/charts/dmaap-bus-controller/resources/dmaap/onap.json  as below:

from "drProvUrl": "https://dmaap-dr-prov:8443"    to

"drProvUrl": "http://dmaap-dr-prov:8080"

 

I’m wondering if someone else has already experienced the same issue and tested this change to share with me if there will be side effects.

 

Thanks in advance

Best regards,

Alessandro

7841 - 7860 of 23498