Re: [onap-discuss] [onap-tsc] CII Badging Attention PTL

[zhao.huabing]

Hi Tony, Steve,

Thanks for the explanation, it really helped. 

One more question, do you happend to know how could I submit all the repos 
together if I want to apply at project level? 

The below screenshot show that only one repo can be submitted per project. I 
tried to contact Core Infrastructure Initiative directly to get the answer, but 
I can't find their contact information.









Thanks,


Huabing











Original Mail



Sender:  ;
To: zhaohuabing10201488;
CC:  ; ; 
; ; 
;
Date: 2018/01/25 22:54
Subject: Re: [onap-discuss] [onap-tsc] CII Badging Attention PTL




As PTL, it’s your choice. You can do a single report for your entire project, 
or you can file a separate report for each repo. If your repos use different 
languages or different testing procedures, you probably would find it easier to 
do  it per-repo.


 


If you do file one report for the entire project, then you need to answer each 
Met/Not Met question based on the lowest-common denominator answer: if any of 
the repos don’t meet the requirement, you cannot select Met. (Use the text box  
to keep track of your reasons for picking any particular answer.)


 


Tony Hansen


 



From:  on behalf of 
"zhao.huab...@zte.com.cn" 
 Date: Thursday, January 25, 2018 at 2:16 AM
 To: "stephen.terr...@ericsson.com" 
 Cc: "onap-sec...@lists.onap.org" , 
"rajee...@amdocs.com" , "onap-discuss@lists.onap.org" 
, "onap-...@lists.onap.org" 

 Subject: Re: [onap-discuss] [onap-tsc] CII Badging Attention PTL



 

Hi Arul and Seve,

 

It's a common situation that an ONAP project has multiple repos. Is it possible 
to submit the rpos as a whole as one project when applying for CII  Badging? Or 
I have to submit one by one?

 



 

Thanks,

Huabing


Original Mail



Sender:  ;



To:  ;  ; 
; ;



CC:  ;



Date: 2018/01/25 00:27



Subject: Re: [onap-tsc] CII Badging Attention PTL




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


Hi,


 


Thanks to Arul and team for putting this together.


 


We had one clarification today in the security subcommittee due to that it is 
discussed whether to do the badging at the project level  of the program level.

In general it is fine (expected) to do this at the project level.

However, a project may decide for different reasons to perform the badging per 
repo or set of repos; if this made sense.

This would imply from a S3P tracking perspective

A project has passed if it and it its dependencies has passed.

Note: sub-projects are responsible for doing their own badging process.

For %complete the least complete value is the %complete of the project


BR,


 


Steve


 



From: Arul Nambi [mailto:arul.na...@amdocs.com] 
 Sent: 19 January 2018 20:23
 To: onap-discuss@lists.onap.org; onap-...@lists.onap.org; 
onap-sec...@lists.onap.org
 Cc: Stephen Terrill ; HANSEN, TONY L 
; Rajeev Mehta 
 Subject: CII Badging Attention PTL




 


Hi Everyone,


If you have seen an email with almost the same subject ignore that, I had some 
issues posting the first email so I am re-sending it  again. Both emails have 
the same content


For getting ONAP carrier ready one of the requirements is that 70% of its 
projects needs to undergo a process called CII badging.


CII badging is a simple process(and takes less than a week normally) of 
answering some questions about the project. And it is better if you start it 
sooner than later.


And the security subcommittee has come up with a wiki page with

More information about the CII

Sample tools

Sample answers to all the questions that you will need to answer to get your 
app badged.


The current ask is that 70% of the project should be in passing level, if you 
want to go higher than that you can find the sample answers  for the Silver and 
gold level as well, they are not complete yet but if you find  answers then add 
them to the page.


Link: https://wiki.onap.org/display/DW/CII+Badging+Program


Let us know if you have any more questions or suggestions.


Regards


Arul


 


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,


you may review at https://www.amdocs.com/about/email-disclaimer___
onap-discuss mailing list
onap-discuss@lists.onap.org

Re: [onap-discuss] [**EXTERNAL**] Service distribution error on latest ONAP/OOM

[Ramanarayanan, Karthick]

Hi Alexis,

 I am still getting the Policy Exception error POL5000 with dcae disabled, 
(dcaegen2 app not running as mentioned earlier).

 I am on the latest OOM for amsterdam (policy images are 1.1.3 as verified).

 Service distribution immediately fails.

 policy pod logs don't indicate anything.

They do resolve dmaap.onap-message-router fine and connected to dmaap on port 
3904.



Regards,

-Karthick


From: Ramanarayanan, Karthick
Sent: Thursday, January 25, 2018 10:33:44 AM
To: Alexis de Talhouët
Cc: onap-discuss@lists.onap.org; Bainbridge, David
Subject: Re: [**EXTERNAL**] [onap-discuss] Service distribution error on latest 
ONAP/OOM


Thanks Alexis.

Fix is looking good but I haven't moved up yet.

Will do later.

Regards,

-Karthick


From: Alexis de Talhouët 
Sent: Tuesday, January 23, 2018 8:55:06 AM
To: Ramanarayanan, Karthick
Cc: onap-discuss@lists.onap.org; Bainbridge, David
Subject: Re: [**EXTERNAL**] [onap-discuss] Service distribution error on latest 
ONAP/OOM

Karthick,

The fix is out: 
https://gerrit.onap.org/r/#/c/28591/
 and has been tested.
Expect this to be merge on a couple of hours.

Please re-test and confirm it does fix your issue when you have time.

Regards,
Alexis

On Jan 22, 2018, at 11:57 AM, Ramanarayanan, Karthick 
> wrote:

That's great Alexis.
Thanks.
(also don't be surprised if backend doesn't come up sometimes with no indicator 
in the log pods.
 Just restart cassandra, elastic search and kibana pod before restarting 
backend pod and it would load the user profiles in the sdc-be logs :)

Regards,
-Karthick

From: Alexis de Talhouët 
>
Sent: Monday, January 22, 2018 5:10:26 AM
To: Ramanarayanan, Karthick
Cc: onap-discuss@lists.onap.org; 
Bainbridge, David
Subject: Re: [**EXTERNAL**] [onap-discuss] Service distribution error on latest 
ONAP/OOM

Hi Karthick,

Yes, I’m aware of this since you mentioned it last week. I reproduced the issue.
Currently implementing a fix for it. Sorry for the regression introduced.

See 
https://jira.onap.org/browse/OOM-608
 for more details.

Thanks,
Alexis

On Jan 19, 2018, at 4:21 PM, Ramanarayanan, Karthick 
> wrote:

Hi Alexis,
 I reverted the oom commit from head to:


git checkout cb02aa241edd97acb6c5ca744de84313f53e8a5a

Author: yuryn >
Date:   Thu Dec 21 14:31:21 2017 +0200

Fix firefox tab crashes in VNC

Change-Id: Ie295257d98ddf32693309535e15c6ad9529f10fc
Issue-ID: OOM-531


Everything works with service creation, vnf and vf creates!
Please note that I am running with dcae disabled.
Something is broken with dcae disabled in the latest.
100% reproducible with service distribution step through operator taking a 
policy exception mailed earlier.
Have a nice weekend.

Regards,
-Karthick






From: Ramanarayanan, Karthick
Sent: Friday, January 19, 2018 8:48:23 AM
To: Alexis de Talhouët
Cc: onap-discuss@lists.onap.org
Subject: Re: [**EXTERNAL**] Re: [onap-discuss] Service distribution error on 
latest ONAP/OOM

Hi Alexis,
 I did check the policy pod logs before sending the mail.
 I didn't see anything suspicious.
 I initially suspected aai-service dns not getting resolved but you seem to 
have fixed it
 and it was accessible from policy pod.
 Nothing suspicious from any log anywhere.
 I did see that the health check on sdc pods returned all UP except: DE 
component whose health check was down.
 Not sure if its anyway related. Could be benign.


curl 
http://127.0.0.1:30206/sdc1/rest/healthCheck
{
 "sdcVersion": "1.1.0",
 "siteMode": "unknown",
 "componentsInfo": [
   {
 "healthCheckComponent": "BE",
 "healthCheckStatus": "UP",
 "version": "1.1.0",
 "description": "OK"
   },
   {
 "healthCheckComponent": "TITAN",
 "healthCheckStatus": "UP",
 "description": "OK"
   },
   {
 "healthCheckComponent": "DE",
 "healthCheckStatus": 

Re: [onap-discuss] [**EXTERNAL**] Re: Demo update-vfw policy script when running without closed loop

[Ramanarayanan, Karthick]

I am running 1.1.1 OOM.


With the update to /dockerdata-nfs push-policy script change suggested by Marco 
to pull from amsterdam, it didn't work with 1.1. ( ?h=amsterdam change)


I still see the GET error on update policy run after restarting the policy 
pods, confirming policy script was updated (BRCM dependency version matches 
1.1.1)


Logging into the pdp pod to check /var/log/onap/pdp rest logs, shows a bunch of 
errors which seem to indicate policy deployment issues mailed by Hernandez in 
the context of 1.1.2 though I am running 1.1.1.

Interesting.


I will just move to OOM 1.1.3 with a pull before retrying since the service 
distribution issue along with this issue pointed by Marco has been fixed.


Another thing I wanted to point out that restarting ONAP k8s pods with 
/dockerdata-nfs data present takes a long time with create-config.


I know its not required to re-create onap-config if shared data is already 
present but I think its better to change the brute force find approach in 
config-init scripts to avoid touching database files (huge files when 
/dockerdata-nfs already exists) that takes forever to run the config sed update.


Maybe something like this in config-init.sh for all the finds:


find /config-init/$NAMESPACE/ -type f -exec sed -i -e 
"s/\.onap-/\.$NAMESPACE-/g" {} \;


Could be changed to:


find /config-init/$NAMESPACE/ -path */conf/* -type f -exec sed -i -e 
"s/\.onap-/\.$NAMESPACE-/g" {} \;


so it targets only conf locations.


Anyway will update OOM to the latest amsterdam which I presume moves images to 
1.1.3 and retry this.



Regards,

-Karthick



From: Alexis de Talhouët 
Sent: Thursday, January 25, 2018 12:00:36 PM
To: HERNANDEZ-HERRERO, JORGE
Cc: Ramanarayanan, Karthick; onap-discuss@lists.onap.org
Subject: [**EXTERNAL**] Re: [onap-discuss] Demo update-vfw policy script when 
running without closed loop

Finish testing, it does fix the issue. Thanks,
Alexis

On Jan 25, 2018, at 2:28 PM, Alexis de Talhouët 
> wrote:

Just put up a fix for this: 
https://gerrit.onap.org/r/#/c/29209/
 Trying it now.

On Jan 25, 2018, at 2:13 PM, Alexis de Talhouët 
> wrote:

This is tracked by 
https://jira.onap.org/browse/OOM-611

Currently, OOM uses 1.1.1

Alexis

On Jan 25, 2018, at 2:07 PM, HERNANDEZ-HERRERO, JORGE 
> wrote:

Hi Karthick,
With regards to policy, cannot tell you in the context of kubernetes, but we 
had a bug introduced in v1.1.2 policy docker images that was resolved with 
v1.1.3. The error shown in the text below indicates that the automated 
deployment of operational policies wasn’t successful which was one of the 
symptoms of the problems with v1.1.2.   First thing to check is if you are 
using the latest 1.1.3 images and latest amsterdam policy/docker repo?
Jorge

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Ramanarayanan, 
Karthick
Sent: Thursday, January 25, 2018 12:33 PM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] Demo update-vfw policy script when running without 
closed loop

Hi,
 In my kubernetes setup minus dcae (just vFW without closed loop),
 I am trying to mount the appc packetgen interface but I am unable to see the 
mounts in appc mounts list.
 The policy that was pushed used the kubernetes update-vfw-op-policy.sh script 
which seems to be applicable for closed loop.

 Though the policy script runs and applies the policy and restarts the policy 
pods, the get on controlloop.Params fails at the end.

 curl -v --silent --user @1b3rt:31nst31n -X 
GEThttp://${K8S_HOST}:${POLICY_DROOLS_PORT}/policy/pdp/engine/controllers/amsterdam/drools/facts/closedloop-amsterdam/org.onap.policy.controlloop.Params
  | python -m json.tool

{
"error": "amsterdam:closedloop-amsterdam:org.onap.policy.controlloop.Params 
not found"
}


Moving ahead, I configure the packet gen interface with an appc put to network 
topology for the packetgen vnf/ip.
Put succeeds but appc mounts doesn't show up.
Wondering if the policy script needs 

[onap-discuss] OOM new reference versions: Kubectl client 1.9.2, Kubernetes (server 1.8.5) via Rancher 1.6.14, Helm 2.8.0 and Docker 17.03.2-ce

[Michael O'Brien]

Team,
The following configuration is verified and an increase for all Kubernetes 
client/server, Rancher, Helm client/server and Docker versions
https://jira.onap.org/browse/OOM-535
Kubectl 1.9.2 - up from 1.8.6 - our secret generation issue 
https://github.com/kubernetes/kubernetes/issues/57528 was fixed in 1.9.1  
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md#v191
Kubernetes 1.8.5 (via Rancher) - up from 1.7.7
Rancher 1.6.14 (installs Helm 2.6.2 - needs a helm init -upgrade after 
client install below) - up from 1.6.10
Helm 2.8.0 (client and server) - up from 2.3
Docker 17.03.2 - up from 1.12

https://wiki.onap.org/display/DW/ONAP+on+Kubernetes
thank you

Michael O'Brien
Amdocs Technology
16135955268
55268
[amdocs-a]

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Demo update-vfw policy script when running without closed loop

[Alexis de Talhouët]

Finish testing, it does fix the issue. Thanks,
Alexis

> On Jan 25, 2018, at 2:28 PM, Alexis de Talhouët  
> wrote:
> 
> Just put up a fix for this: https://gerrit.onap.org/r/#/c/29209/ 
>  Trying it now.
> 
>> On Jan 25, 2018, at 2:13 PM, Alexis de Talhouët > > wrote:
>> 
>> This is tracked by https://jira.onap.org/browse/OOM-611 
>> 
>> 
>> Currently, OOM uses 1.1.1
>> 
>> Alexis
>> 
>>> On Jan 25, 2018, at 2:07 PM, HERNANDEZ-HERRERO, JORGE >> > wrote:
>>> 
>>> Hi Karthick,
>>> With regards to policy, cannot tell you in the context of kubernetes, but 
>>> we had a bug introduced in v1.1.2 policy docker images that was resolved 
>>> with v1.1.3. The error shown in the text below indicates that the 
>>> automated deployment of operational policies wasn’t successful which was 
>>> one of the symptoms of the problems with v1.1.2.   First thing to check is 
>>> if you are using the latest 1.1.3 images and latest amsterdam policy/docker 
>>> repo?
>>> Jorge   
>>>  
>>> From: onap-discuss-boun...@lists.onap.org 
>>>  
>>> [mailto:onap-discuss-boun...@lists.onap.org 
>>> ] On Behalf Of Ramanarayanan, 
>>> Karthick
>>> Sent: Thursday, January 25, 2018 12:33 PM
>>> To: onap-discuss@lists.onap.org 
>>> Subject: [onap-discuss] Demo update-vfw policy script when running without 
>>> closed loop
>>>  
>>> Hi,
>>>  In my kubernetes setup minus dcae (just vFW without closed loop),
>>>  I am trying to mount the appc packetgen interface but I am unable to see 
>>> the mounts in appc mounts list.
>>>  The policy that was pushed used the kubernetes update-vfw-op-policy.sh 
>>> script which seems to be applicable for closed loop.
>>>  
>>>  Though the policy script runs and applies the policy and restarts the 
>>> policy pods, the get on controlloop.Params fails at the end.
>>>  
>>>  curl -v --silent --user @1b3rt:31nst31n -X GEThttp://$ 
>>> {K8S_HOST}:${POLICY_DROOLS_PORT}/policy/pdp/engine/controllers/amsterdam/drools/facts/closedloop-amsterdam/org.onap.policy.controlloop.Params
>>>   | python -m json.tool
>>>  
>>> {
>>> "error": 
>>> "amsterdam:closedloop-amsterdam:org.onap.policy.controlloop.Params not 
>>> found"
>>> }
>>>  
>>>  
>>> Moving ahead, I configure the packet gen interface with an appc put to 
>>> network topology for the packetgen vnf/ip.
>>> Put succeeds but appc mounts doesn't show up.
>>> Wondering if the policy script needs to be changed when executing without 
>>> closed loop?
>>> What am I missing?
>>>  
>>> Thanks,
>>> -Karthick
>>> ___
>>> onap-discuss mailing list
>>> onap-discuss@lists.onap.org 
>>> https://lists.onap.org/mailman/listinfo/onap-discuss 
>>> 
> 

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Demo update-vfw policy script when running without closed loop

[Alexis de Talhouët]

Just put up a fix for this: https://gerrit.onap.org/r/#/c/29209/ Trying it now.

> On Jan 25, 2018, at 2:13 PM, Alexis de Talhouët  
> wrote:
> 
> This is tracked by https://jira.onap.org/browse/OOM-611 
> 
> 
> Currently, OOM uses 1.1.1
> 
> Alexis
> 
>> On Jan 25, 2018, at 2:07 PM, HERNANDEZ-HERRERO, JORGE > > wrote:
>> 
>> Hi Karthick,
>> With regards to policy, cannot tell you in the context of kubernetes, but we 
>> had a bug introduced in v1.1.2 policy docker images that was resolved with 
>> v1.1.3. The error shown in the text below indicates that the automated 
>> deployment of operational policies wasn’t successful which was one of the 
>> symptoms of the problems with v1.1.2.   First thing to check is if you are 
>> using the latest 1.1.3 images and latest amsterdam policy/docker repo?
>> Jorge   
>>  
>> From: onap-discuss-boun...@lists.onap.org 
>>  
>> [mailto:onap-discuss-boun...@lists.onap.org 
>> ] On Behalf Of Ramanarayanan, 
>> Karthick
>> Sent: Thursday, January 25, 2018 12:33 PM
>> To: onap-discuss@lists.onap.org 
>> Subject: [onap-discuss] Demo update-vfw policy script when running without 
>> closed loop
>>  
>> Hi,
>>  In my kubernetes setup minus dcae (just vFW without closed loop),
>>  I am trying to mount the appc packetgen interface but I am unable to see 
>> the mounts in appc mounts list.
>>  The policy that was pushed used the kubernetes update-vfw-op-policy.sh 
>> script which seems to be applicable for closed loop.
>>  
>>  Though the policy script runs and applies the policy and restarts the 
>> policy pods, the get on controlloop.Params fails at the end.
>>  
>>  curl -v --silent --user @1b3rt:31nst31n -X GEThttp://$ 
>> {K8S_HOST}:${POLICY_DROOLS_PORT}/policy/pdp/engine/controllers/amsterdam/drools/facts/closedloop-amsterdam/org.onap.policy.controlloop.Params
>>   | python -m json.tool
>>  
>> {
>> "error": 
>> "amsterdam:closedloop-amsterdam:org.onap.policy.controlloop.Params not found"
>> }
>>  
>>  
>> Moving ahead, I configure the packet gen interface with an appc put to 
>> network topology for the packetgen vnf/ip.
>> Put succeeds but appc mounts doesn't show up.
>> Wondering if the policy script needs to be changed when executing without 
>> closed loop?
>> What am I missing?
>>  
>> Thanks,
>> -Karthick
>> ___
>> onap-discuss mailing list
>> onap-discuss@lists.onap.org 
>> https://lists.onap.org/mailman/listinfo/onap-discuss 
>> 

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Demo update-vfw policy script when running without closed loop

[Alexis de Talhouët]

This is tracked by https://jira.onap.org/browse/OOM-611

Currently, OOM uses 1.1.1

Alexis

> On Jan 25, 2018, at 2:07 PM, HERNANDEZ-HERRERO, JORGE  wrote:
> 
> Hi Karthick,
> With regards to policy, cannot tell you in the context of kubernetes, but we 
> had a bug introduced in v1.1.2 policy docker images that was resolved with 
> v1.1.3. The error shown in the text below indicates that the automated 
> deployment of operational policies wasn’t successful which was one of the 
> symptoms of the problems with v1.1.2.   First thing to check is if you are 
> using the latest 1.1.3 images and latest amsterdam policy/docker repo?
> Jorge   
>  
> From: onap-discuss-boun...@lists.onap.org 
>  
> [mailto:onap-discuss-boun...@lists.onap.org 
> ] On Behalf Of Ramanarayanan, 
> Karthick
> Sent: Thursday, January 25, 2018 12:33 PM
> To: onap-discuss@lists.onap.org 
> Subject: [onap-discuss] Demo update-vfw policy script when running without 
> closed loop
>  
> Hi,
>  In my kubernetes setup minus dcae (just vFW without closed loop),
>  I am trying to mount the appc packetgen interface but I am unable to see the 
> mounts in appc mounts list.
>  The policy that was pushed used the kubernetes update-vfw-op-policy.sh 
> script which seems to be applicable for closed loop.
>  
>  Though the policy script runs and applies the policy and restarts the policy 
> pods, the get on controlloop.Params fails at the end.
>  
>  curl -v --silent --user @1b3rt:31nst31n -X GEThttp://$ 
> {K8S_HOST}:${POLICY_DROOLS_PORT}/policy/pdp/engine/controllers/amsterdam/drools/facts/closedloop-amsterdam/org.onap.policy.controlloop.Params
>   | python -m json.tool
>  
> {
> "error": 
> "amsterdam:closedloop-amsterdam:org.onap.policy.controlloop.Params not found"
> }
>  
>  
> Moving ahead, I configure the packet gen interface with an appc put to 
> network topology for the packetgen vnf/ip.
> Put succeeds but appc mounts doesn't show up.
> Wondering if the policy script needs to be changed when executing without 
> closed loop?
> What am I missing?
>  
> Thanks,
> -Karthick
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org 
> https://lists.onap.org/mailman/listinfo/onap-discuss 
> 
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Demo update-vfw policy script when running without closed loop

[HERNANDEZ-HERRERO, JORGE]

Hi Karthick,
With regards to policy, cannot tell you in the context of kubernetes, but we 
had a bug introduced in v1.1.2 policy docker images that was resolved with 
v1.1.3. The error shown in the text below indicates that the automated 
deployment of operational policies wasn't successful which was one of the 
symptoms of the problems with v1.1.2.   First thing to check is if you are 
using the latest 1.1.3 images and latest amsterdam policy/docker repo?
Jorge

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Ramanarayanan, 
Karthick
Sent: Thursday, January 25, 2018 12:33 PM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] Demo update-vfw policy script when running without 
closed loop


Hi,

 In my kubernetes setup minus dcae (just vFW without closed loop),

 I am trying to mount the appc packetgen interface but I am unable to see the 
mounts in appc mounts list.

 The policy that was pushed used the kubernetes update-vfw-op-policy.sh script 
which seems to be applicable for closed loop.



 Though the policy script runs and applies the policy and restarts the policy 
pods, the get on controlloop.Params fails at the end.



 curl -v --silent --user @1b3rt:31nst31n -X GET 
http://${K8S_HOST}:${POLICY_DROOLS_PORT}/policy/pdp/engine/controllers/amsterdam/drools/facts/closedloop-amsterdam/org.onap.policy.controlloop.Params
  | python -m json.tool


{
"error": "amsterdam:closedloop-amsterdam:org.onap.policy.controlloop.Params 
not found"
}




Moving ahead, I configure the packet gen interface with an appc put to network 
topology for the packetgen vnf/ip.

Put succeeds but appc mounts doesn't show up.

Wondering if the policy script needs to be changed when executing without 
closed loop?

What am I missing?



Thanks,

-Karthick
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Demo update-vfw policy script when running without closed loop

[PLATANIA, MARCO (MARCO)]

Karthick,

Please look for BRMS_DEPENDENCY_VERSION at the end of 
${OOM_HOME}/kubernetes/config/docker/init/src/config/policy/opt/policy/config/pe/brmsgw.conf.

That parameter should be the same as the Policy container version number. For 
Amsterdam, it has to be either 1.1.1 or 1.1.3, depending on the Policy version 
that you are using (Amsterdam v1.1.1 or Amsterdam Maintenance v1.1.3).

Also, 
${OOM_HOME}/kubernetes/config/docker/init/src/config/policy/opt/policy/config/pe/push-policies.sh,
 line 11 should be:

wget -O cl-amsterdam-template.drl 
https://git.onap.org/policy/drools-applications/plain/controlloop/templates/archetype-cl-amsterdam/src/main/resources/archetype-resources/src/main/resources/__closedLoopControlName__.drl?h=amsterdam

instead of wget -O cl-amsterdam-template.drl 
https://git.onap.org/policy/drools-applications/plain/controlloop/templates/archetype-cl-amsterdam/src/main/resources/archetype-resources/src/main/resources/__closedLoopControlName__.drl

(note ?h=amsterdam at the end of the correct call).

You can make these changes in your OOM local repo, as described above, or 
directly in the ONAP configuration folder in your NFS share (or local disk if 
you have a single-host K8S cluster), in 
/dockerdata-nfs/onap/policy/opt/policy/config/pe/push-policies.sh (and the same 
path for brmsgw.conf). The former approach requires to rebuild ONAP, while the 
latter requires to rebuild only Policy.

Marco



From:  on behalf of "Ramanarayanan, 
Karthick" 
Date: Thursday, January 25, 2018 at 1:32 PM
To: "onap-discuss@lists.onap.org" 
Subject: [onap-discuss] Demo update-vfw policy script when running without 
closed loop


Hi,

 In my kubernetes setup minus dcae (just vFW without closed loop),

 I am trying to mount the appc packetgen interface but I am unable to see the 
mounts in appc mounts list.

 The policy that was pushed used the kubernetes update-vfw-op-policy.sh script 
which seems to be applicable for closed loop.



 Though the policy script runs and applies the policy and restarts the policy 
pods, the get on controlloop.Params fails at the end.



 curl -v --silent --user @1b3rt:31nst31n -X GET 
http://${K8S_HOST}:${POLICY_DROOLS_PORT}/policy/pdp/engine/controllers/amsterdam/drools/facts/closedloop-amsterdam/org.onap.policy.controlloop.Params
  | python -m json.tool


{
"error": "amsterdam:closedloop-amsterdam:org.onap.policy.controlloop.Params 
not found"
}




Moving ahead, I configure the packet gen interface with an appc put to network 
topology for the packetgen vnf/ip.

Put succeeds but appc mounts doesn't show up.

Wondering if the policy script needs to be changed when executing without 
closed loop?

What am I missing?



Thanks,

-Karthick
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [**EXTERNAL**] Service distribution error on latest ONAP/OOM

[Ramanarayanan, Karthick]

Thanks Alexis.

Fix is looking good but I haven't moved up yet.

Will do later.

Regards,

-Karthick


From: Alexis de Talhouët 
Sent: Tuesday, January 23, 2018 8:55:06 AM
To: Ramanarayanan, Karthick
Cc: onap-discuss@lists.onap.org; Bainbridge, David
Subject: Re: [**EXTERNAL**] [onap-discuss] Service distribution error on latest 
ONAP/OOM

Karthick,

The fix is out: 
https://gerrit.onap.org/r/#/c/28591/
 and has been tested.
Expect this to be merge on a couple of hours.

Please re-test and confirm it does fix your issue when you have time.

Regards,
Alexis

On Jan 22, 2018, at 11:57 AM, Ramanarayanan, Karthick 
> wrote:

That's great Alexis.
Thanks.
(also don't be surprised if backend doesn't come up sometimes with no indicator 
in the log pods.
 Just restart cassandra, elastic search and kibana pod before restarting 
backend pod and it would load the user profiles in the sdc-be logs :)

Regards,
-Karthick

From: Alexis de Talhouët 
>
Sent: Monday, January 22, 2018 5:10:26 AM
To: Ramanarayanan, Karthick
Cc: onap-discuss@lists.onap.org; 
Bainbridge, David
Subject: Re: [**EXTERNAL**] [onap-discuss] Service distribution error on latest 
ONAP/OOM

Hi Karthick,

Yes, I’m aware of this since you mentioned it last week. I reproduced the issue.
Currently implementing a fix for it. Sorry for the regression introduced.

See 
https://jira.onap.org/browse/OOM-608
 for more details.

Thanks,
Alexis

On Jan 19, 2018, at 4:21 PM, Ramanarayanan, Karthick 
> wrote:

Hi Alexis,
 I reverted the oom commit from head to:


git checkout cb02aa241edd97acb6c5ca744de84313f53e8a5a

Author: yuryn >
Date:   Thu Dec 21 14:31:21 2017 +0200

Fix firefox tab crashes in VNC

Change-Id: Ie295257d98ddf32693309535e15c6ad9529f10fc
Issue-ID: OOM-531


Everything works with service creation, vnf and vf creates!
Please note that I am running with dcae disabled.
Something is broken with dcae disabled in the latest.
100% reproducible with service distribution step through operator taking a 
policy exception mailed earlier.
Have a nice weekend.

Regards,
-Karthick






From: Ramanarayanan, Karthick
Sent: Friday, January 19, 2018 8:48:23 AM
To: Alexis de Talhouët
Cc: onap-discuss@lists.onap.org
Subject: Re: [**EXTERNAL**] Re: [onap-discuss] Service distribution error on 
latest ONAP/OOM

Hi Alexis,
 I did check the policy pod logs before sending the mail.
 I didn't see anything suspicious.
 I initially suspected aai-service dns not getting resolved but you seem to 
have fixed it
 and it was accessible from policy pod.
 Nothing suspicious from any log anywhere.
 I did see that the health check on sdc pods returned all UP except: DE 
component whose health check was down.
 Not sure if its anyway related. Could be benign.


curl 
http://127.0.0.1:30206/sdc1/rest/healthCheck
{
 "sdcVersion": "1.1.0",
 "siteMode": "unknown",
 "componentsInfo": [
   {
 "healthCheckComponent": "BE",
 "healthCheckStatus": "UP",
 "version": "1.1.0",
 "description": "OK"
   },
   {
 "healthCheckComponent": "TITAN",
 "healthCheckStatus": "UP",
 "description": "OK"
   },
   {
 "healthCheckComponent": "DE",
 "healthCheckStatus": "DOWN",
 "description": "U-EB cluster is not available"
   },
   {
 "healthCheckComponent": "CASSANDRA",
 "healthCheckStatus": "UP",
 "description": "OK"
   },
   {
 "healthCheckComponent": "ON_BOARDING",
 "healthCheckStatus": "UP",
 "version": "1.1.0",
 "description": "OK",
 "componentsInfo": [
   {
 "healthCheckComponent": "ZU",
 "healthCheckStatus": "UP",
 "version": "0.2.0",
 "description": "OK"
   },
   {
 "healthCheckComponent": "BE",
 "healthCheckStatus": "UP",
 "version": "1.1.0",
 "description": "OK"
   },
   {
 "healthCheckComponent": "CAS",

[onap-discuss] Demo update-vfw policy script when running without closed loop

[Ramanarayanan, Karthick]

Hi,

 In my kubernetes setup minus dcae (just vFW without closed loop),

 I am trying to mount the appc packetgen interface but I am unable to see the 
mounts in appc mounts list.

 The policy that was pushed used the kubernetes update-vfw-op-policy.sh script 
which seems to be applicable for closed loop.


 Though the policy script runs and applies the policy and restarts the policy 
pods, the get on controlloop.Params fails at the end.


 curl -v --silent --user @1b3rt:31nst31n -X GET 
http://${K8S_HOST}:${POLICY_DROOLS_PORT}/policy/pdp/engine/controllers/amsterdam/drools/facts/closedloop-amsterdam/org.onap.policy.controlloop.Params
  | python -m json.tool


{
"error": "amsterdam:closedloop-amsterdam:org.onap.policy.controlloop.Params 
not found"
}



Moving ahead, I configure the packet gen interface with an appc put to network 
topology for the packetgen vnf/ip.

Put succeeds but appc mounts doesn't show up.

Wondering if the policy script needs to be changed when executing without 
closed loop?

What am I missing?


Thanks,

-Karthick
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Invitation: 5G Use Case Team Meeting @ Weekly from 8am to 9am on Thursday from Thu Jan 4 to Thu Dec 13 (PST) (onap-discuss@lists.onap.org)

[BULLARD, GIL]

Thank you Ben, Sigmar, the presentation today was very informative!

Here are some notes I took on the impact to ONAP.  Hopefully

*   Both RAN and Core NFs are “tracking area aware”.  And a slice must be 
“consistently configured” throughout a tracking area.   It inadvisable (or 
impossible?) to configure a slice on just a subset of a tracking area.  Thus, 
the lowest level of granularity of “scope” that a slice can be mapped to is a 
tracking area.
*   So it sounds like we need to model an object type in A that 
represents a "Tracking Area", and need to allow (an easy) way for a service 
provider to maintain the association between a (RAN or Core) NF and the 
Tracking Areas that it supports.
*   Thus, when a (RAN or Core) NF is instantiated the service provider must 
enter the “list of” tracking areas that the NF is intended to supports.
*   When ONAP receives a request to create a slice instance, the request 
must include a list of Tracking Areas in which that slice should be configured. 
 ONAP would use A to map that request into a list of RAN and Core NFs that 
need to be configured.  Perhaps to make it less cumbersome on the GUI user, 
ONAP should also allow the service provider to define an arbitrarily deep 
hierarchy of container objects in A to that would at the “bottom” resolve to 
a list of tracking areas.
*   So, it sounds like ONAP has no need to track the association of 
tracking area to cell, and in fact ONAP has no need to even be aware of cells 
at all.  This implies that ONAP need not track the association between a cell 
and the frequencies it supports.
*   We confirmed that, as the wiki Slicing use case states, it is possible 
for an ONAP service designer to define a “slice type” that maps to a certain 
(set of) frequenc(ies), like the “Red” and “Blue” frequencies example.  
However, because ONAP doesn’t track cells, much less the frequencies of the 
cells, there is no way for ONAP to validate that the set of tracking areas 
included in a “slice instantiation request” is actually consistent with the 
frequency map for that slice type.  E.g., ONAP would not know if a user tries 
to instantiate a slice type that is restricted to “Red frequencies” in a 
tracking area that has no cells that use the “Red frequencies”.  We decided 
this is okay, presumably because whoever is providing the list of tracking 
areas to ONAP has “non-ONAP” ways of verifying the consistency between the 
frequency definition of a slice type and the characteristics of the tracking 
area in which they want that slice instantiated.
*   As mentioned above, it is inadvisable (or impossible?) to configure a 
slice on just a portion of a tracking area.  Thus, when configuring a slice in 
a tracking area it is important that ONAP apply/activate the configuration of 
that new slice on all CUs (for example) in that tracking area at exactly the 
same time.  We didn’t discuss the adverse effects of race conditions in this 
regard.
*   We need a way to allow a service provider to redefine the mapping 
between a (RAN or Core) NF to the tracking areas that it supports.  Such 
redefinition could trigger ONAP “mass update” activity.  E.g., if a tracking 
area is added/removed from a CU then ONAP will need to determine if that action 
resulted in a change in the set of slice instances that the CU should support, 
and if so reconfigure the CU accordingly to add/remove the appropriate slices.


-Original Appointment-
From: ONAP Meetings and Events 
[mailto:linuxfoundation.org_1rmtb5tpr3uc8f76fmflplo...@group.calendar.google.com]
Sent: Wednesday, January 03, 2018 7:44 PM
To: ONAP Meetings and Events; onap-discuss@lists.onap.org; BEGWANI, VIMAL
Subject: [onap-discuss] Invitation: 5G Use Case Team Meeting @ Weekly from 8am 
to 9am on Thursday from Thu Jan 4 to Thu Dec 13 (PST) 
(onap-discuss@lists.onap.org)
When: Thursday, January 25, 2018 11:00 AM-12:00 PM America/New_York.
Where: https://zoom.us/j/478423919


more details 
>

5G Use Case Team Meeting
When
Weekly from 8am to 9am on Thursday from Thu Jan 4 to Thu Dec 13 Pacific 
Time

Where

https://zoom.us/j/478423919
 

[onap-discuss] [dmaap] l2 resiliency side effects on clients?

[HERNANDEZ-HERRERO, JORGE]

Hello DMaaPers,

I understand that DMaaP will be L2 resilient in Beijing.

Are there any side effects known at this time, for REST clients using the 
polling consumer APIs?

Thank you.
Jorge
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Invitation: [onap-arc] Architecture Subcommittee @ Tue Jan 30, 2018 7am - 9am (PST) (onap-discuss@lists.onap.org)

[kpaul]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20180130T07
DTEND;TZID=America/Los_Angeles:20180130T09
DTSTAMP:20180125T173643Z
ORGANIZER;CN=ONAP Meetings and Events:mailto:linuxfoundation.org_1rmtb5tpr3
 uc8f76fmflplo...@group.calendar.google.com
UID:3h2blddpsn05vkj8cuoi9gm...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=christopher.don...@huawei.com;X-NUM-GUESTS=0:mailto:christopher.donley@
 huawei.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=onap-...@lists.onap.org;X-NUM-GUESTS=0:mailto:onap-...@lists.onap.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=onap-discuss@lists.onap.org;X-NUM-GUESTS=0:mailto:onap-discuss@list
 s.onap.org
RECURRENCE-ID;TZID=America/Los_Angeles:20180130T07
CREATED:20170807T175557Z
DESCRIPTION:Hi there\,\n\nChris Donley is inviting you to a scheduled Zoom 
 meeting.\n\nJoin from PC\, Mac\, Linux\, iOS or Android: https://zoom.us/j/
 413478743\n\nOr iPhone one-tap (US Toll):  +16465588656\,\,413478743# or +1
 4086380968\,\,413478743#\n\nOr Telephone:\nDial: +1 646 558 8656 (US To
 ll) or +1 408 638 0968 (US Toll)\nMeeting ID: 413 478 743\nInternat
 ional numbers available: https://zoom.us/zoomconference?m=f1HxFMhoSj5UzX-6q
 B3w2uPXcfjeWMjs\n\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the d
 escription.\n\nView your event at https://www.google.com/calendar/event?act
 ion=VIEW=M2gyYmxkZHBzbjA1dmtqOGN1b2k5Z21vcjZfMjAxODAxMzBUMTUwMDAwWiBvbm
 FwLWRpc2N1c3NAbGlzdHMub25hcC5vcmc=NzIjbGludXhmb3VuZGF0aW9uLm9yZ18xcm10Y
 jV0cHIzdWM4Zjc2Zm1mbHBsb2k4OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tM2NmMWMzMjY1
 OWI1NDg4YTRlNWVkMDMzYzllZmI4NzYwYWJjOWQ0Ng=America/Los_Angeles=en.\n
 -::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~::~:~::-
LAST-MODIFIED:20180125T173643Z
LOCATION:https://zoom.us/j/413478743
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:[onap-arc] Architecture Subcommittee
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [OpenLab] OOM deployment results

[Alexis de Talhouët]

Gary,

Here is the fix for the service-change-handler issue in DCAE: 
https://gerrit.onap.org/r/#/c/29193/
You can edit those directly in the /dockerdata-nfs/onap/dcagen2/nginx/config 
instead of re-deploying.

Once done, go in the dcaedokp00 
 VM 
and restart the service-change-handler container.

Thanks,
Alexis

> On Jan 25, 2018, at 7:49 AM, Alexis de Talhouët  
> wrote:
> 
> Thanks Gary, I have the same result in the OpenLab for the OOM tenant. I’ll 
> dig up the service-change-handler issue. Usually this is happening when it 
> cannot connect to DMAAP.
> 
> UUI is broken since a little bit in OOM, I’ve noticed this but haven’t looked 
> into it.
> 
> Alexis
> 
>> On Jan 24, 2018, at 9:06 PM, Gary Wu > > wrote:
>> 
>> OOM deployment results from today:
>>  
>> Besides a minor issue that I worked around for now 
>> (https://gerrit.onap.org/r/#/c/29071/ 
>> ), I was able to start up DCAE via OOM 
>> on both Wind River lab and my own OpenStack with Designate (no proxy).  On 
>> both environments, only DCAE and UUI failed health checks as follows:
>>  
>> --
>> Basic DCAE Health Check   | FAIL 
>> |
>> [  | cdap |  |  |  |  | 
>> 1c1c99c96bca47cfacd950932f89409b_cdap_app_cdap_app_tca | cdap_broker | 
>> config_binding_service | deployment_handler | inventory | 
>> platform_dockerhost |  | component_dockerhost | 
>> 7911cc59914340d5b4c549ac599c5408_dcae-analytics-holmes-engine-management | 
>> cb08cc6e229e4c49b2b73f170b62685c_dcaegen2-collectors-ves | 
>> dd04a13962834b18ada0575c0e62b81b_dcae-analytics-holmes-rule-management |  | 
>> cloudify_manager ] does not contain match for pattern 
>> 'service-change-handler'.
>> --
>> usecaseui-gui API Health Check| FAIL 
>> |
>> 502 != 200
>> --
>>  
>> DCAE health check failed even though all DCAE VMs started.  UUI consistently 
>> fails health checks when deployed by OOM, even though it usually succeeds 
>> when deployed by heat.  At this point I suspect both of these failures to be 
>> some sort of race conditions during startup, but we can get the project 
>> teams involved once we retry the deployments a few more times to observe the 
>> behavior.
>>  
>> The above was deployed using the OOM amsterdam branch as of today.
>> 
>> Thanks,
>> Gary
>>  
>> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
>> ] 
>> Sent: Wednesday, January 24, 2018 8:48 AM
>> To: onap-discuss > >; Gary Wu > >
>> Subject: Re: [OpenLab] DNS Designate zone for simpledemo.onap.org 
>> 
>>  
>> Gary, all,
>>  
>> Actually, digging and thinking about this, the solution that has been 
>> implemented in OOM to support DCAE will not work with a shared DNS Designate 
>> backend, e.g. if multiple ONAP instances are deployed, each one of them need 
>> its own DNS Designate. The reason for that is, to accommodate DCAE VM 
>> resolution of .simpledemo.onap.org  hosts (aai, 
>> msb, sdc, policy), OOM creates a simpledemo.onap.org 
>> . zone in which it will create the A record and 
>> a bunch of CNAME, as it was done in the DNS VM.
>> The thing is, that simpledemo.onap.org  zone 
>> will have records pointing to a given instance of ONAP, and you cannot have 
>> multiple zones sharing the same zone. Which means, we need 
>> https://gerrit.onap.org/r/#/c/28347/ 
>> for Amsterdam ASAP so OOM can be used 
>> in the OpenLab. That patch basically instantiate a small OpenStack in OOM 
>> with only the support for keystone and designate. This way, no need to rely 
>> on infrastructure dns designate support.
>>  
>> Alexis
>> 
>> 
>> On Jan 24, 2018, at 11:19 AM, Alexis de Talhouët > > wrote:
>>  
>> Greetings,
>>  
>> I’m trying to add a DNS zone in the DNS Designate of OpenLab, but I’m 
>> getting the following failure:
>>  
>> openstack zone create --email=o...@onap.org  
>> '--description=DNS zone bridging DCAE and OOM' --type=PRIMARY 
>> simpledemo.onap.org .
>> Unable to create zone because another tenant owns a subzone of the zone
>>  
>> Can I get assistance with this?
>>  
>> Thanks,
>> Alexis
> 

___
onap-discuss mailing list

[onap-discuss] (SOLVED) DCAE bootstrap - Connection timed out err in boot container installer script

[Josef Reisinger]

Well, hard to debug and find .. it was the security group for the first 
DCAE machine spawned by the bootstrap VM. Why do DCAE server use a 
different security group as the other VMs?

Mit freundlichen Grüßen / Kind regards
Josef Reisinger 

IBM Deutschland GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter 
Geschäftsführung: Martina Koederitz (Vorsitzende), Nicole Reimer, Norbert 
Janzen, Dr. Christian Keller, Ivo Koerner, Stefan Lutz 
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, 
HRB 14562 / WEEE-Reg.-Nr. DE 99369940 




From:   "Josef Reisinger" 
To: onap-discuss 
Date:   04.01.2018 15:12
Subject:[onap-discuss] DCAE bootstrap - Connection timed out err 
in boot container installer script
Sent by:onap-discuss-boun...@lists.onap.org



Folks,

I am trying to get this issue solved for a while, but I am stuck and do 
not understand why DCAE does not want to start up.

The boot container in dcae_bootstrap starts /opt/app/installer/installer 
which seems to successfully bring up the first DCAE VM (called 
'dcaeorcl00' for me).
The logs in the boot container contain a warning about about celery 
'2018-01-04 13:43:04 LOG  [mgmt_worker_aaf03.start] WARNING: 
celery status: worker not running, Retrying in 3 seconds...', 

but nothing else which I could identify as an issue. Everything seems to 
be ok to the lines
2018-01-04 13:43:13 CFY  [sanity_6a35e.start] Sending task 
'fabric_plugin.tasks.run_script'
2018-01-04 13:43:13 CFY  [sanity_6a35e.start] Task started 
'fabric_plugin.tasks.run_script'
2018-01-04 13:43:13 LOG  [sanity_6a35e.start] INFO: Preparing 
fabric environment...
2018-01-04 13:43:13 LOG  [sanity_6a35e.start] INFO: Environment 
prepared successfully
2018-01-04 13:43:14 LOG  [sanity_6a35e.start] INFO: Saving sanity 
input configuration to 
/opt/cloudify/sanity/node_properties/properties.json
2018-01-04 13:43:15 CFY  [sanity_6a35e.start] Task succeeded 
'fabric_plugin.tasks.run_script'
2018-01-04 13:43:16 CFY  'install' workflow execution succeeded
Bootstrap failed! (('Connection aborted.', error(110, 'Connection timed 
out')))
Executing teardown due to failed bootstrap...
2018-01-04 13:45:24 CFY  Starting 'uninstall' workflow execution


On dcaeorcl00 I can see a warning from celery: 
Jan 04 13:28:35 dcaeorcl00.novalocal celery[21174]: 
/opt/mgmtworker/env/lib/python2.7/site-packages/celery/platforms.py:766: 
RuntimeWarning: You are running the worker with superuser privileges, 
which is
Jan 04 13:28:35 dcaeorcl00.novalocal celery[21174]: absolutely not 
recommended!

and from consul
Jan 04 14:02:21 dcaeorcl00.novalocal consul[9064]: agent: failed to sync 
remote state: No known Consul servers
Jan 04 14:02:49 dcaeorcl00.novalocal consul[9064]: manager: No servers 
available

I would really like to understand what's going wrong... maybe even as 
simple as a configuration error, Any help is appreciated.

Mit freundlichen Grüßen / Kind regards
Josef Reisinger 
IBM Deutschland GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter 
Geschäftsführung: Martina Koederitz (Vorsitzende), Nicole Reimer, Norbert 
Janzen, Dr. Christian Keller, Ivo Koerner, Stefan Lutz 
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, 
HRB 14562 / WEEE-Reg.-Nr. DE 99369940 

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss




___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [onap-tsc] CII Badging Attention PTL

[HANSEN, TONY L]

As PTL, it’s your choice. You can do a single report for your entire project, 
or you can file a separate report for each repo. If your repos use different 
languages or different testing procedures, you probably would find it easier to 
do it per-repo.

If you do file one report for the entire project, then you need to answer each 
Met/Not Met question based on the lowest-common denominator answer: if any of 
the repos don’t meet the requirement, you cannot select Met. (Use the text box 
to keep track of your reasons for picking any particular answer.)

Tony Hansen

From:  on behalf of 
"zhao.huab...@zte.com.cn" 
Date: Thursday, January 25, 2018 at 2:16 AM
To: "stephen.terr...@ericsson.com" 
Cc: "onap-sec...@lists.onap.org" , 
"rajee...@amdocs.com" , "onap-discuss@lists.onap.org" 
, "onap-...@lists.onap.org" 

Subject: Re: [onap-discuss] [onap-tsc] CII Badging Attention PTL


Hi Arul and Seve,



It's a common situation that an ONAP project has multiple repos. Is it possible 
to submit the rpos as a whole as one project when applying for CII Badging? Or 
I have to submit one by one?



[cid:0011d7ec933f1ad2c5062]



Thanks,

Huabing
Original Mail
Sender:  ;
To:  ; ; 
; ;
CC:  ;
Date: 2018/01/25 00:27
Subject: Re: [onap-tsc] CII Badging Attention PTL
___
ONAP-TSC mailing list
onap-...@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc


Hi,

Thanks to Arul and team for putting this together.

We had one clarification today in the security subcommittee due to that it is 
discussed whether to do the badging at the project level of the program level.

  *   In general it is fine (expected) to do this at the project level.
  *   However, a project may decide for different reasons to perform the 
badging per repo or set of repos; if this made sense.
  *   This would imply from a S3P tracking perspective

 *   A project has passed if it and it its dependencies has passed.
 *   Note: sub-projects are responsible for doing their own badging process.
 *   For %complete the least complete value is the %complete of the project
BR,

Steve

From: Arul Nambi [mailto:arul.na...@amdocs.com]
Sent: 19 January 2018 20:23
To: onap-discuss@lists.onap.org; onap-...@lists.onap.org; 
onap-sec...@lists.onap.org
Cc: Stephen Terrill ; HANSEN, TONY L 
; Rajeev Mehta 
Subject: CII Badging Attention PTL

Hi Everyone,
If you have seen an email with almost the same subject ignore that, I had some 
issues posting the first email so I am re-sending it again. Both emails have 
the same content
For getting ONAP carrier ready one of the requirements is that 70% of its 
projects needs to undergo a process called CII badging.
CII badging is a simple process(and takes less than a week normally) of 
answering some questions about the project. And it is better if you start it 
sooner than later.
And the security subcommittee has come up with a wiki page with

  1.  More information about the CII
  2.  Sample tools
  3.  Sample answers to all the questions that you will need to answer to get 
your app badged.
The current ask is that 70% of the project should be in passing level, if you 
want to go higher than that you can find the sample answers for the Silver and 
gold level as well, they are not complete yet but if you find  answers then add 
them to the page.
Link: 
https://wiki.onap.org/display/DW/CII+Badging+Program
Let us know if you have any more questions or suggestions.
Regards
Arul

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at 
https://www.amdocs.com/about/email-disclaimer


___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [OpenLab] DNS Designate zone for simpledemo.onap.org

[Alexis de Talhouët]

Yes, and this is what I’ve done: https://gerrit.onap.org/r/#/c/29063/ :)

It’s working ok now, each deployment will create two zones

$ openstack zone list
+--+-+-++++
| id   | name   
 | type| serial | status | action |
+--+-+-++++
| 4e404684-c8c3-4b3c-b594-0575b7e8dd4b | 9rMR.simpledemo.onap.org.  
 | PRIMARY | 1516828782 | ACTIVE | NONE   |
| f891fe28-eec7-4c27-9ec8-b1993537477c | 
9rMR.dcaeg2.adetalhouet.oom.amsterdam.onap.org. | PRIMARY | 1516828945 | ACTIVE 
| NONE   |
+--+-+-++++

Alexis 

> On Jan 25, 2018, at 1:37 AM, Yang, Bin  wrote:
> 
> Hi Alexis, <>
>  
> You’d better prefix it with a random string similar to what DCAE does: 
> w6VA.dcaeg2.onap.org .
> Which avoid zone name conflicting from different tenants on the same 
> Designate backend.
>  
> Here are the scripts for your to manage the DNS zones. Please list all ZONEs 
> from all tenants to find the one named “simpledemo.onap.org 
> .”, and delete it . Otherwise you have to use 
> some other zone name which will not conflict with this one.
>  
>  
>  
> ### maintain designate zone
>  
> export KEYSTONE_EP=http://10.12.25.5:5000 
>  
> export TOKEN=$(curl -i -X POST $KEYSTONE_EP/v3/auth/tokens -H "Content-Type: 
> application/json" -H "Accept: application/json" -H "User-Agent: simpletool" 
> -d  '{"auth": {"identity": {"methods": ["password"],"password": {"user": 
> {"name": "","domain": {"name": "Default"}, "password": " password>"}}},"scope":{"project":{"domain":{"name":"Default"},"name": " tenant name>" } }}}'  2>&1 | grep X-Subject-Token | sed "s/^.*: //")
>  
> export DNS_EP=http://10.12.25.5:9001 
>  
> curl -v -s  -H "Content-Type: application/json" -H "X-Auth-Token: $TOKEN" -X 
> GET $DNS_EP/v2/zones |json_pp
>  
> {
>"zones" : [
>   {
>  "email" : "l...@research.att.com ",
>  "attributes" : {},
>  "created_at" : "2018-01-24T14:41:29.00",
>  "type" : "PRIMARY",
>  "transferred_at" : null,
>  "description" : null,
>  "links" : {
> "self" : 
> "http://127.0.0.1:9001/v2/zones/93f4c9db-49e0-4662-8d32-4f1e8f9e2688 
> "
>  },
>  "masters" : [],
>  "pool_id" : "794ccc2c-d751-44fe-b57f-8894c9f5c842",
>  "name" : "w6VA.dcaeg2.onap.org .",
>  "action" : "NONE",
>  "project_id" : "8b8ef50b050c47269fd4375aa2c7f7cd",
>  "updated_at" : "2018-01-24T16:46:04.00",
>  "id" : "93f4c9db-49e0-4662-8d32-4f1e8f9e2688",
>  "serial" : 1516812347,
>  "ttl" : 3600,
>  "status" : "ACTIVE",
>  "version" : 46
>   }
>],
>"metadata" : {
>   "total_count" : 1
>},
>"links" : {
>   "self" : "http://127.0.0.1:9001/v2/zones 
> "
>}
> }
>  
> curl -v -s  -H "Content-Type: application/json" -H "X-Auth-Token: $TOKEN" -X 
> GET $DNS_EP/v2/zones/93f4c9db-49e0-4662-8d32-4f1e8f9e2688
>  
> curl -v -s  -H "Content-Type: application/json" -H "X-Auth-Token: $TOKEN" -X 
> DELETE $DNS_EP/v2/zones/93f4c9db-49e0-4662-8d32-4f1e8f9e2688
>  
>  
>  
> Best Regards,
> Bin Yang,Solution Readiness Team,Wind River
> Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189
> Skype: yangbincs993
>  
> From: onap-discuss-boun...@lists.onap.org 
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët
> Sent: Thursday, January 25, 2018 12:19 AM
> To: onap-discuss
> Subject: [onap-discuss] [OpenLab] DNS Designate zone for simpledemo.onap.org
>  
> Greetings,
>  
> I’m trying to add a DNS zone in the DNS Designate of OpenLab, but I’m getting 
> the following failure:
>  
> openstack zone create --email=o...@onap.org  
> '--description=DNS zone bridging DCAE and OOM' --type=PRIMARY 
> simpledemo.onap.org .
> Unable to create zone because another tenant owns a subzone of the zone
>  
> Can I get assistance with this?
>  
> Thanks,
> Alexis

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [OpenLab] OOM deployment results

[Alexis de Talhouët]

Thanks Gary, I have the same result in the OpenLab for the OOM tenant. I’ll dig 
up the service-change-handler issue. Usually this is happening when it cannot 
connect to DMAAP.

UUI is broken since a little bit in OOM, I’ve noticed this but haven’t looked 
into it.

Alexis

> On Jan 24, 2018, at 9:06 PM, Gary Wu  wrote:
> 
> OOM deployment results from today:
>  
> Besides a minor issue that I worked around for now 
> (https://gerrit.onap.org/r/#/c/29071/ 
> ), I was able to start up DCAE via OOM 
> on both Wind River lab and my own OpenStack with Designate (no proxy).  On 
> both environments, only DCAE and UUI failed health checks as follows:
>  
> --
> Basic DCAE Health Check   | FAIL |
> [  | cdap |  |  |  |  | 
> 1c1c99c96bca47cfacd950932f89409b_cdap_app_cdap_app_tca | cdap_broker | 
> config_binding_service | deployment_handler | inventory | platform_dockerhost 
> |  | component_dockerhost | 
> 7911cc59914340d5b4c549ac599c5408_dcae-analytics-holmes-engine-management | 
> cb08cc6e229e4c49b2b73f170b62685c_dcaegen2-collectors-ves | 
> dd04a13962834b18ada0575c0e62b81b_dcae-analytics-holmes-rule-management |  | 
> cloudify_manager ] does not contain match for pattern 
> 'service-change-handler'.
> --
> usecaseui-gui API Health Check| FAIL |
> 502 != 200
> --
>  
> DCAE health check failed even though all DCAE VMs started.  UUI consistently 
> fails health checks when deployed by OOM, even though it usually succeeds 
> when deployed by heat.  At this point I suspect both of these failures to be 
> some sort of race conditions during startup, but we can get the project teams 
> involved once we retry the deployments a few more times to observe the 
> behavior.
>  
> The above was deployed using the OOM amsterdam branch as of today.
> 
> Thanks,
> Gary
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> ] 
> Sent: Wednesday, January 24, 2018 8:48 AM
> To: onap-discuss  >; Gary Wu  >
> Subject: Re: [OpenLab] DNS Designate zone for simpledemo.onap.org 
> 
>  
> Gary, all,
>  
> Actually, digging and thinking about this, the solution that has been 
> implemented in OOM to support DCAE will not work with a shared DNS Designate 
> backend, e.g. if multiple ONAP instances are deployed, each one of them need 
> its own DNS Designate. The reason for that is, to accommodate DCAE VM 
> resolution of .simpledemo.onap.org  hosts (aai, 
> msb, sdc, policy), OOM creates a simpledemo.onap.org 
> . zone in which it will create the A record and 
> a bunch of CNAME, as it was done in the DNS VM.
> The thing is, that simpledemo.onap.org  zone 
> will have records pointing to a given instance of ONAP, and you cannot have 
> multiple zones sharing the same zone. Which means, we need 
> https://gerrit.onap.org/r/#/c/28347/ 
> for Amsterdam ASAP so OOM can be used 
> in the OpenLab. That patch basically instantiate a small OpenStack in OOM 
> with only the support for keystone and designate. This way, no need to rely 
> on infrastructure dns designate support.
>  
> Alexis
> 
> 
> On Jan 24, 2018, at 11:19 AM, Alexis de Talhouët  > wrote:
>  
> Greetings,
>  
> I’m trying to add a DNS zone in the DNS Designate of OpenLab, but I’m getting 
> the following failure:
>  
> openstack zone create --email=o...@onap.org  
> '--description=DNS zone bridging DCAE and OOM' --type=PRIMARY 
> simpledemo.onap.org .
> Unable to create zone because another tenant owns a subzone of the zone
>  
> Can I get assistance with this?
>  
> Thanks,
> Alexis

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Did You Know?

[Keren Joseph]

[cid:image002.png@01D395D7.784680B0]

Did You Know?
OOM allows for rolling upgrades of component containers
OOM uses Helm K8S package manager to deploy ONAP components.
Each component is arranged in a packaging format called a chart - a collection 
of files that describe a set of k8s resources.
Helm allows for rolling upgrades of the ONAP component deployed.
To upgrade a component Helm release you will need an updated Helm chart. The 
chart might have modified, deleted or added values, deployment yamls, and more.

To get the release name use:
helm ls

To easily upgrade the release use:
helm upgrade [RELEASE] [CHART]

To roll back to a previous release version use:
helm rollback [flags] [RELEASE] [REVISION]


for example, to upgrade the onap-mso helm release to the latest MSO container 
release v1.1.2:

1)  Edit mso valus.yaml which is part of the chart
Change "mso: nexus3.onap.org:10001/openecomp/mso:v1.1.1" to
"mso: nexus3.onap.org:10001/openecomp/mso:v1.1.2"

2)  From the chart location run:

helm upgrade onap-mso ./
The previous mso pod will be terminated and a new mso pod with an updated mso 
container will be created.

[cid:image003.jpg@01D395D7.784680B0]
Helm history of the onap-mso release

If you'd like to learn more about Helm upgrade command, check out Helm 
docs. More about helm rollback 
here.
If you'd like to learn more about OOM, check out the OOM 
wiki or 
concepts to find out more about 
Kubernetes.




This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss