Re: [onap-discuss] [APP-C][CDT] - What is the expected payload for ANSIBLE?

2018-06-12 Thread Alexis de Talhouët
Sorry if this is going in many direction. I just confirm that the change I’ve 
made to the GENERATE_CONFIG_DG column is not required, this can remain NULL 
instead of Generic_AnsibleDG.

> On Jun 12, 2018, at 2:15 PM, Alexis de Talhouët  
> wrote:
> 
> Actually, I also tweaked to DB tables, to have GENERATE_CONFIG_DG be 
> Generic_AnsibleDG and DOWNLOAD_CONFIG_DG be ansible-adapter-1.0
> 
> In sdnctl.CONFIGURE_ACTION_DG
> 
> | CONFIGURE_ACTION_DG_ID | VNF_TYPE   | ACTION| GENERATE_CONFIG_DG | 
> DOWNLOAD_CONFIG_DG  |
> |   19 | vlns/vmx 0| 
> ConfigModify | Generic_AnsibleDG  | ansible-adapter-1.0   |
> 
> 
> And in sdnctl.DOWNLOAD_DG_REFERENCE
> 
> | DOWNLOAD_DG_REFERENCE_ID | PROTOCOL| DOWNLOAD_CONFIG_DG  |
> | 2 | ANSIBLE 
> | ansible-adapter-1.0 |
> 
> Is this necessary?
> 
>> On Jun 12, 2018, at 1:39 PM, Alexis de Talhouët > <mailto:adetalhoue...@gmail.com>> wrote:
>> 
>> Taka,
>> 
>> Thanks for the answer. I was able to call my ansible playbook after doing 
>> the following:
>> 
>> 1. Add the XYZ.ANSIBLE.ConfigModify.url = http://172.19.22.13:1234/Dispatch 
>> <http://172.19.22.13:1234/Dispatch> in 
>> /opt/appc/data/properties/appc_southbound.properties
>> 2. Define a template with the following payload: {"PlaybookName": 
>> "$playbook}”}
>> 3. Send the LCM RPC request using this payload:
>> 
>> "payload": 
>> "{\"configuration-parameters\":{\"operations_timeout\":\"3600\",\"playbook\":\"playbook1\"}}"
>> 
>> 
>> Question, is there a way to pass the agent url as argument of the LCM RPC 
>> input in some ways? Like we do for NETCONF configure action with 
>> vnf-host-ip-address?
>> 
>> 
>> Thanks,
>> Alexis
>> 
>>> On Jun 12, 2018, at 12:04 PM, CHO, TAKAMUNE >> <mailto:tc0...@att.com>> wrote:
>>> 
>>> Hi Alexis,
>>>  
>>> The payload for ConfigModify that you used is not correct.  AgentUrl has to 
>>> be present in Device Authentication Table rather than in the Payload. Below 
>>> is one sample:
>>>  
>>> "payload": 
>>> "{\"request-parameters\":{\"vnf-name\":\"xxx\",\"vnf-host-ip-address\":\"https://xx.xxx.xx.xx:5000/Dispatch\"},\"configuration-parameters\":{\"vnf_name\":\”XYZ\",\"operations_timeout\":\"3600\
>>>  
>>> <https://xx.xxx.xx.xx:5000/Dispatch/%22%7d,/%22configuration-parameters/%22:%7b/%22vnf_name/%22:/%E2%80%9DXYZ/%22,/%22operations_timeout/%22:/%223600/>"}}"
>>>  
>>> To Answer your next question for CDT’s PD. Here is the sample for PD:
>>>  
>>> kind: "Property Definition"
>>> version: V1
>>> vnf-parameter-list:
>>> - name: vnf_name
>>>   type: null
>>>   description: null
>>>   required: null
>>>   default: null
>>>   source: Manual
>>>   rule-type: null
>>>   request-keys: null
>>> response-keys: null
>>>  
>>> and one payload for Anisble:
>>>  
>>> {
>>>   "PlaybookName": "comx/latest/ansible/modify/site.yml",
>>>   "EnvParameters": {"vnf_instance": "${vnf_name}"},
>>>   "Timeout": 3600
>>> }
>>>  
>>> -Taka
>>>  
>>> From: onap-discuss-boun...@lists.onap.org 
>>> <mailto:onap-discuss-boun...@lists.onap.org> 
>>> [mailto:onap-discuss-boun...@lists.onap.org 
>>> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de 
>>> Talhouët
>>> Sent: Monday, June 11, 2018 4:56 PM
>>> To: onap-discuss >> <mailto:onap-discuss@lists.onap.org>>
>>> Subject: [onap-discuss] [APP-C][CDT] - What is the expected payload for 
>>> ANSIBLE?
>>>  
>>> Greetings team,
>>>  
>>> I’m trying to use the ConfigModify action using the ANSIBLE “device 
>>> protocol” within CDT.
>>> I’m trying to execute my REST API from Postman to APP-C. I’m using the 
>>> bellow payload.
>>> I cannot get around this error: 
>>> org.onap.ccsdk.sli.core.sli.SvcLogicException: Error constructing request 
>>> for execution of playbook due to missing mandatory parameters. Reason = 
>>>

Re: [onap-discuss] [APP-C][CDT] - What is the expected payload for ANSIBLE?

2018-06-12 Thread Alexis de Talhouët
I’d like to avoid having to hardcode the agent url in the appc config file. I 
see you pass it as param here, is it because I changed the GENERATE_CONFIG_DG 
to Generic_AnsibleDG that I have to provide it in the config?

"payload": 
"{\"request-parameters\":{\"vnf-name\":\"xxx\",\"vnf-host-ip-address\":\"https://xx.xxx.xx.xx:5000/Dispatch\"},\"configuration-parameters\":{\"vnf_name\":\”XYZ\",\"operations_timeout\":\"3600\
 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__xx.xxx.xx.xx-3A5000_Dispatch_-2522-257d-2C_-2522configuration-2Dparameters_-2522-3A-257b_-2522vnf-5Fname_-2522-3A_-25E2-2580-259DXYZ_-2522-2C_-2522operations-5Ftimeout_-2522-3A_-25223600_=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=i5VHNTZ3SDPgIii87sudZA=PeJr6sYd7P1VKXtXb-diVaPj2WHKOKPWM3Xb8dSDjCs=JjK8tBkpXKLoOjKojaBpo8Q6VqeY9-HwJEwh1CPdPaM=>"}}"


I’m going to try.
Thanks,
Alexis

> On Jun 12, 2018, at 2:07 PM, CHO, TAKAMUNE  wrote:
> 
> HI Alexis,
>  
> Just like to clarify you question:
>  
> You want to pass the agenturl as an argument in an ansible payload?
>  
> Taka
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Tuesday, June 12, 2018 1:40 PM
> To: CHO, TAKAMUNE 
> Cc: onap-discuss 
> Subject: Re: [onap-discuss] [APP-C][CDT] - What is the expected payload for 
> ANSIBLE?
>  
> Taka,
>  
> Thanks for the answer. I was able to call my ansible playbook after doing the 
> following:
>  
> 1. Add the XYZ.ANSIBLE.ConfigModify.url = http://172.19.22.13:1234/Dispatch 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__172.19.22.13-3A1234_Dispatch=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=i5VHNTZ3SDPgIii87sudZA=PeJr6sYd7P1VKXtXb-diVaPj2WHKOKPWM3Xb8dSDjCs=87yEcGpI_Hj3_lET1wTptoO-6g59YzlqSmgBgHh6uxI=>
>  in /opt/appc/data/properties/appc_southbound.properties
> 2. Define a template with the following payload: {"PlaybookName": 
> "$playbook}”}
> 3. Send the LCM RPC request using this payload:
>  
> "payload": 
> "{\"configuration-parameters\":{\"operations_timeout\":\"3600\",\"playbook\":\"playbook1\"}}"
>  
>  
> Question, is there a way to pass the agent url as argument of the LCM RPC 
> input in some ways? Like we do for NETCONF configure action with 
> vnf-host-ip-address?
>  
>  
> Thanks,
> Alexis
>  
> On Jun 12, 2018, at 12:04 PM, CHO, TAKAMUNE  <mailto:tc0...@att.com>> wrote:
>  
> Hi Alexis,
>  
> The payload for ConfigModify that you used is not correct.  AgentUrl has to 
> be present in Device Authentication Table rather than in the Payload. Below 
> is one sample:
>  
> "payload": 
> "{\"request-parameters\":{\"vnf-name\":\"xxx\",\"vnf-host-ip-address\":\"https://xx.xxx.xx.xx:5000/Dispatch\"},\"configuration-parameters\":{\"vnf_name\":\”XYZ\",\"operations_timeout\":\"3600\
>  
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__xx.xxx.xx.xx-3A5000_Dispatch_-2522-257d-2C_-2522configuration-2Dparameters_-2522-3A-257b_-2522vnf-5Fname_-2522-3A_-25E2-2580-259DXYZ_-2522-2C_-2522operations-5Ftimeout_-2522-3A_-25223600_=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=i5VHNTZ3SDPgIii87sudZA=PeJr6sYd7P1VKXtXb-diVaPj2WHKOKPWM3Xb8dSDjCs=JjK8tBkpXKLoOjKojaBpo8Q6VqeY9-HwJEwh1CPdPaM=>"}}"
>  
> To Answer your next question for CDT’s PD. Here is the sample for PD:
>  
> kind: "Property Definition"
> version: V1
> vnf-parameter-list:
> - name: vnf_name
>   type: null
>   description: null
>   required: null
>   default: null
>   source: Manual
>   rule-type: null
>   request-keys: null
> response-keys: null
>  
> and one payload for Anisble:
>  
> {
>   "PlaybookName": "comx/latest/ansible/modify/site.yml",
>   "EnvParameters": {"vnf_instance": "${vnf_name}"},
>   "Timeout": 3600
> }
>  
> -Taka
>  
> From: onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org> 
> [mailto:onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de Talhouët
> Sent: Monday, June 11, 2018 4:56 PM
> To: onap-discuss  <mailto:onap-discuss@lists.onap.org>>
> Subject: [onap-discuss] [APP-C][CDT] - What is the expected payload for 
> ANSIBLE?
>  
> Greetings team,
>  
> I’m trying to use the ConfigModify action using the ANSIBLE “device protocol” 
> within CDT.
> I’m trying to execute my REST API from Postman to APP-C. I’m using the bellow 
> payl

Re: [onap-discuss] [APP-C][CDT] - What is the expected payload for ANSIBLE?

2018-06-12 Thread Alexis de Talhouët
Actually, I also tweaked to DB tables, to have GENERATE_CONFIG_DG be 
Generic_AnsibleDG and DOWNLOAD_CONFIG_DG be ansible-adapter-1.0

In sdnctl.CONFIGURE_ACTION_DG

| CONFIGURE_ACTION_DG_ID | VNF_TYPE   | ACTION| GENERATE_CONFIG_DG | 
DOWNLOAD_CONFIG_DG  |
|   19 | vlns/vmx 0| 
ConfigModify | Generic_AnsibleDG  | ansible-adapter-1.0   |


And in sdnctl.DOWNLOAD_DG_REFERENCE

| DOWNLOAD_DG_REFERENCE_ID | PROTOCOL| DOWNLOAD_CONFIG_DG  |
| 2 | ANSIBLE | 
ansible-adapter-1.0 |

Is this necessary?

> On Jun 12, 2018, at 1:39 PM, Alexis de Talhouët  
> wrote:
> 
> Taka,
> 
> Thanks for the answer. I was able to call my ansible playbook after doing the 
> following:
> 
> 1. Add the XYZ.ANSIBLE.ConfigModify.url = http://172.19.22.13:1234/Dispatch 
> <http://172.19.22.13:1234/Dispatch> in 
> /opt/appc/data/properties/appc_southbound.properties
> 2. Define a template with the following payload: {"PlaybookName": 
> "$playbook}”}
> 3. Send the LCM RPC request using this payload:
> 
> "payload": 
> "{\"configuration-parameters\":{\"operations_timeout\":\"3600\",\"playbook\":\"playbook1\"}}"
> 
> 
> Question, is there a way to pass the agent url as argument of the LCM RPC 
> input in some ways? Like we do for NETCONF configure action with 
> vnf-host-ip-address?
> 
> 
> Thanks,
> Alexis
> 
>> On Jun 12, 2018, at 12:04 PM, CHO, TAKAMUNE > <mailto:tc0...@att.com>> wrote:
>> 
>> Hi Alexis,
>>  
>> The payload for ConfigModify that you used is not correct.  AgentUrl has to 
>> be present in Device Authentication Table rather than in the Payload. Below 
>> is one sample:
>>  
>> "payload": 
>> "{\"request-parameters\":{\"vnf-name\":\"xxx\",\"vnf-host-ip-address\":\"https://xx.xxx.xx.xx:5000/Dispatch\"},\"configuration-parameters\":{\"vnf_name\":\”XYZ\",\"operations_timeout\":\"3600\
>>  
>> <https://xx.xxx.xx.xx:5000/Dispatch/%22%7d,/%22configuration-parameters/%22:%7b/%22vnf_name/%22:/%E2%80%9DXYZ/%22,/%22operations_timeout/%22:/%223600/>"}}"
>>  
>> To Answer your next question for CDT’s PD. Here is the sample for PD:
>>  
>> kind: "Property Definition"
>> version: V1
>> vnf-parameter-list:
>> - name: vnf_name
>>   type: null
>>   description: null
>>   required: null
>>   default: null
>>   source: Manual
>>   rule-type: null
>>   request-keys: null
>> response-keys: null
>>  
>> and one payload for Anisble:
>>  
>> {
>>   "PlaybookName": "comx/latest/ansible/modify/site.yml",
>>   "EnvParameters": {"vnf_instance": "${vnf_name}"},
>>   "Timeout": 3600
>> }
>>  
>> -Taka
>>  
>> From: onap-discuss-boun...@lists.onap.org 
>> <mailto:onap-discuss-boun...@lists.onap.org> 
>> [mailto:onap-discuss-boun...@lists.onap.org 
>> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de Talhouët
>> Sent: Monday, June 11, 2018 4:56 PM
>> To: onap-discuss > <mailto:onap-discuss@lists.onap.org>>
>> Subject: [onap-discuss] [APP-C][CDT] - What is the expected payload for 
>> ANSIBLE?
>>  
>> Greetings team,
>>  
>> I’m trying to use the ConfigModify action using the ANSIBLE “device 
>> protocol” within CDT.
>> I’m trying to execute my REST API from Postman to APP-C. I’m using the 
>> bellow payload.
>> I cannot get around this error: 
>> org.onap.ccsdk.sli.core.sli.SvcLogicException: Error constructing request 
>> for execution of playbook due to missing mandatory parameters. Reason = 
>> Ansible: Mandatory AnsibleAdapter key AgentUrl not found in parameters 
>> provided by calling agent !
>>  
>> I do see AnsibleMessageParser#reqMessage is enforcing few parameters, final 
>> String[] mandatoryTestParams = {AGENT_URL_KEY,PLAYBOOK_NAME_KEY, USER_KEY, 
>> PASS_KEY};
>> but I don’t know how to input them...
>>  
>> Can you help me understand what’s the expected payload for this REST API? 
>>  
>> On another note, what is the expected template and parameter definition when 
>> using Ansible within CDT?
>>  
>> Thanks,
>> Alexis
>>  
>> {
>> "input": {
>> "common-header": {
>> 

Re: [onap-discuss] [APP-C][CDT] - What is the expected payload for ANSIBLE?

2018-06-12 Thread Alexis de Talhouët
Taka,

Thanks for the answer. I was able to call my ansible playbook after doing the 
following:

1. Add the XYZ.ANSIBLE.ConfigModify.url = http://172.19.22.13:1234/Dispatch 
<http://172.19.22.13:1234/Dispatch> in 
/opt/appc/data/properties/appc_southbound.properties
2. Define a template with the following payload: {"PlaybookName": "$playbook}”}
3. Send the LCM RPC request using this payload:

"payload": 
"{\"configuration-parameters\":{\"operations_timeout\":\"3600\",\"playbook\":\"playbook1\"}}"


Question, is there a way to pass the agent url as argument of the LCM RPC input 
in some ways? Like we do for NETCONF configure action with vnf-host-ip-address?


Thanks,
Alexis

> On Jun 12, 2018, at 12:04 PM, CHO, TAKAMUNE  wrote:
> 
> Hi Alexis,
>  
> The payload for ConfigModify that you used is not correct.  AgentUrl has to 
> be present in Device Authentication Table rather than in the Payload. Below 
> is one sample:
>  
> "payload": 
> "{\"request-parameters\":{\"vnf-name\":\"xxx\",\"vnf-host-ip-address\":\"https://xx.xxx.xx.xx:5000/Dispatch\"},\"configuration-parameters\":{\"vnf_name\":\”XYZ\",\"operations_timeout\":\"3600\
>  
> <https://xx.xxx.xx.xx:5000/Dispatch/%22%7d,/%22configuration-parameters/%22:%7b/%22vnf_name/%22:/%E2%80%9DXYZ/%22,/%22operations_timeout/%22:/%223600/>"}}"
>  
> To Answer your next question for CDT’s PD. Here is the sample for PD:
>  
> kind: "Property Definition"
> version: V1
> vnf-parameter-list:
> - name: vnf_name
>   type: null
>   description: null
>   required: null
>   default: null
>   source: Manual
>   rule-type: null
>   request-keys: null
> response-keys: null
>  
> and one payload for Anisble:
>  
> {
>   "PlaybookName": "comx/latest/ansible/modify/site.yml",
>   "EnvParameters": {"vnf_instance": "${vnf_name}"},
>   "Timeout": 3600
> }
>  
> -Taka
>  
> From: onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org> 
> [mailto:onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de Talhouët
> Sent: Monday, June 11, 2018 4:56 PM
> To: onap-discuss  <mailto:onap-discuss@lists.onap.org>>
> Subject: [onap-discuss] [APP-C][CDT] - What is the expected payload for 
> ANSIBLE?
>  
> Greetings team,
>  
> I’m trying to use the ConfigModify action using the ANSIBLE “device protocol” 
> within CDT.
> I’m trying to execute my REST API from Postman to APP-C. I’m using the bellow 
> payload.
> I cannot get around this error: 
> org.onap.ccsdk.sli.core.sli.SvcLogicException: Error constructing request for 
> execution of playbook due to missing mandatory parameters. Reason = Ansible: 
> Mandatory AnsibleAdapter key AgentUrl not found in parameters provided by 
> calling agent !
>  
> I do see AnsibleMessageParser#reqMessage is enforcing few parameters, final 
> String[] mandatoryTestParams = {AGENT_URL_KEY,PLAYBOOK_NAME_KEY, USER_KEY, 
> PASS_KEY};
> but I don’t know how to input them...
>  
> Can you help me understand what’s the expected payload for this REST API? 
>  
> On another note, what is the expected template and parameter definition when 
> using Ansible within CDT?
>  
> Thanks,
> Alexis
>  
> {
> "input": {
> "common-header": {
> "timestamp": "2018-06-11T17:42:14.227Z",
> "api-ver": "2.00",
> "originator-id": "ALEX",
> "request-id": "TEST-6",
> "sub-request-id": "TEST-2",
> "flags": {
> "force": "TRUE",
> "ttl": 12000
> }
> },
> "action": "ConfigModify",
> "action-identifiers": {
> "vnf-id": "8ef725b6-f94a-4596-89b1-d6810ca9d6f0"
> },
> "payload": 
> "{\"AgentUrl\":\"10m\",\"request-parameters\":{\"AgentUrl\":\"10m\",\"vf-module-id\":
>  
> \"fc8c4122-42a7-4657-9561-5adb2aa34f57\",\"vnf-host-ip-address\":\"10.195.198.22\",\"controller-template-id\":
>  \"vlns\"},\"configuration-parameters\":{\"AgentUrl\":\"10m\"}}"
> }
> }

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


[onap-discuss] [APP-C][CDT] - What is the expected payload for ANSIBLE?

2018-06-11 Thread Alexis de Talhouët
Greetings team,

I’m trying to use the ConfigModify action using the ANSIBLE “device protocol” 
within CDT.
I’m trying to execute my REST API from Postman to APP-C. I’m using the bellow 
payload.
I cannot get around this error: 
org.onap.ccsdk.sli.core.sli.SvcLogicException: Error constructing request for 
execution of playbook due to missing mandatory parameters. Reason = Ansible: 
Mandatory AnsibleAdapter key AgentUrl not found in parameters provided by 
calling agent !

I do see AnsibleMessageParser#reqMessage is enforcing few parameters, final 
String[] mandatoryTestParams = {AGENT_URL_KEY, PLAYBOOK_NAME_KEY, USER_KEY, 
PASS_KEY};
but I don’t know how to input them...

Can you help me understand what’s the expected payload for this REST API? 

On another note, what is the expected template and parameter definition when 
using Ansible within CDT?

Thanks,
Alexis

{
"input": {
"common-header": {
"timestamp": "2018-06-11T17:42:14.227Z",
"api-ver": "2.00",
"originator-id": "ALEX",
"request-id": "TEST-6",
"sub-request-id": "TEST-2",
"flags": {
"force": "TRUE",
"ttl": 12000
}
},
"action": "ConfigModify",
"action-identifiers": {
"vnf-id": "8ef725b6-f94a-4596-89b1-d6810ca9d6f0"
},
"payload": 
"{\"AgentUrl\":\"10m\",\"request-parameters\":{\"AgentUrl\":\"10m\",\"vf-module-id\":
 
\"fc8c4122-42a7-4657-9561-5adb2aa34f57\",\"vnf-host-ip-address\":\"10.195.198.22\",\"controller-template-id\":
 \"vlns\"},\"configuration-parameters\":{\"AgentUrl\":\"10m\"}}"
}
}___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] [AAI]: Cert has expired?

2018-06-04 Thread Alexis de Talhouët
It looks like this patch,https://gerrit.onap.org/r/#/c/44763/ 
<https://gerrit.onap.org/r/#/c/44763/>, from 6 weeks ago, is putting a new 
keystore within APP-C. When I look in there, I see the certificate expiring 
today, which seems to confirm my assumptions.

$ keytool -list -storetype pkcs12 -keystore ONAPall.p12 -storepass changeit | 
grep aai
oldaaiinter, 4-Jun-2018, trustedCertEntry,
oldaairoot, 4-Jun-2018, trustedCertEntry,

$ keytool -list -storetype pkcs12 -keystore ONAPall.p12 -storepass changeit | 
grep onap
onaptestca, 4-Jun-2018, trustedCertEntry,

Patrick, as contributor of this patch, could you chime in?

Thanks,
Alexis

> On Jun 4, 2018, at 3:06 PM, FREEMAN, BRIAN D  wrote:
> 
> Hmm the onap cert is good till 2038 let me check the aai server cert
>  
> Brian
>  
>  
>  
> root@njcdtl01bf1936:/home2/bf1936/ONAP/oom/kubernetes/so/resources/config/mso#
>  keytool -printcert -file onap-ca-new.crt
> Owner: C=US, O=ONAP, OU=OSAAF
> Issuer: C=US, O=ONAP, OU=OSAAF
> Serial number: 9eaeedc0a7ceb59d
> Valid from: Thu Apr 05 09:15:28 EST 2018 until: Wed Mar 31 09:15:28 EST 2038
> Certificate fingerprints:
>MD5:  77:EB:5E:94:2E:B7:A3:45:97:6C:87:FE:A7:F7:64:0F
>SHA1: 
> 90:25:D1:D3:8B:3C:BE:2C:73:E9:6C:1A:48:5B:06:A8:39:0D:54:3B
>SHA256: 
> 1F:C2:BB:F6:7E:11:6F:F0:4C:C3:D9:6C:73:E5:99:B7:CA:7D:4D:EF:AA:6C:69:46:0D:2C:7B:A9:E4:23:5F:EA
>Signature algorithm name: SHA256withRSA
>Version: 3
>  
> Extensions: 
>  
> #1: ObjectId: 2.5.29.35 Criticality=false
> AuthorityKeyIdentifier [
> KeyIdentifier [
> : 53 55 33 F2 4B EB D0 51   B1 C1 78 9A C1 28 31 7B  SU3.K..Q..x..(1.
> 0010: EF EA ED 49...I
> ]
> ]
>  
> #2: ObjectId: 2.5.29.19 Criticality=true
> BasicConstraints:[
>   CA:true
>   PathLen:2147483647
> ]
>  
> #3: ObjectId: 2.5.29.15 Criticality=true
> KeyUsage [
>   DigitalSignature
>   Key_CertSign
>   Crl_Sign
> ]
>  
> #4: ObjectId: 2.5.29.14 Criticality=false
> SubjectKeyIdentifier [
> KeyIdentifier [
> : 53 55 33 F2 4B EB D0 51   B1 C1 78 9A C1 28 31 7B  SU3.K..Q..x..(1.
> 0010: EF EA ED 49...I
> ]
> ]
>  
> root@njcdtl01bf1936:/home2/bf1936/ONAP/oom/kubernetes/so/resources/config/mso#
>  keytool -printcert -file onap-ca-new.crt
> Owner: C=US, O=ONAP, OU=OSAAF
> Issuer: C=US, O=ONAP, OU=OSAAF
> Serial number: 9eaeedc0a7ceb59d
> Valid from: Thu Apr 05 09:15:28 EST 2018 until: Wed Mar 31 09:15:28 EST 2038
> Certificate fingerprints:
>MD5:  77:EB:5E:94:2E:B7:A3:45:97:6C:87:FE:A7:F7:64:0F
>SHA1: 
> 90:25:D1:D3:8B:3C:BE:2C:73:E9:6C:1A:48:5B:06:A8:39:0D:54:3B
>SHA256: 
> 1F:C2:BB:F6:7E:11:6F:F0:4C:C3:D9:6C:73:E5:99:B7:CA:7D:4D:EF:AA:6C:69:46:0D:2C:7B:A9:E4:23:5F:EA
>Signature algorithm name: SHA256withRSA
>Version: 3
>  
> Extensions: 
>  
> #1: ObjectId: 2.5.29.35 Criticality=false
> AuthorityKeyIdentifier [
> KeyIdentifier [
> : 53 55 33 F2 4B EB D0 51   B1 C1 78 9A C1 28 31 7B  SU3.K..Q..x..(1.
> 0010: EF EA ED 49...I
> ]
> ]
>  
> #2: ObjectId: 2.5.29.19 Criticality=true
> BasicConstraints:[
>   CA:true
>   PathLen:2147483647
> ]
>  
> #3: ObjectId: 2.5.29.15 Criticality=true
> KeyUsage [
>   DigitalSignature
>   Key_CertSign
>   Crl_Sign
> ]
>  
> #4: ObjectId: 2.5.29.14 Criticality=false
> SubjectKeyIdentifier [
> KeyIdentifier [
> : 53 55 33 F2 4B EB D0 51   B1 C1 78 9A C1 28 31 7B  SU3.K..Q..x..(1.
> 0010: EF EA ED 49...I
> ]
> ]
>  
> From: onap-discuss-boun...@lists.onap.org 
>  On Behalf Of Alexis de Talhouët
> Sent: Monday, June 04, 2018 3:01 PM
> To: onap-discuss 
> Subject: Re: [onap-discuss] [AAI]: Cert has expired?
>  
> To clarify, VID is failing to communicate with AAI as well. Same symptom: 
>  
> 2018-06-04T19:00:52.907Z   [http-apr-8080-exec-7]   INFO  
> com.att.eelf.error   
> InstanceUUID=292b461a-2954-4b63-a3f9-f916c7ad3bc0
> RequestId=5db9eb4c-688c-461f-958e-52d050752a1c   LoginId=demo
> AlertSeverity=INFORMATIONAL   PROTOCOL=HTTP 
> PartnerName=Default_FE ServerFQDN=onap-vid-6fb489db7c-f9z9j   
>   ClientIPAddress=10.42.153.167   
> Full-URL=http://vid.api.simpledemo.onap.org:30200/vid/aai_get_services 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__vid.api.simpledemo.onap.org-3A30200_vid_aai-5Fget-5Fservices=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDm

Re: [onap-discuss] [app-c] Ansible Server details in appc.properties file

2018-06-04 Thread Alexis de Talhouët
Hi, same issue here: 
https://lists.onap.org/pipermail/onap-discuss/2018-June/010067.html

This relate to this topic: re [AAI]: Cert has expired?

I think that’s your root cause.

Thanks,
Alexis

> On Jun 4, 2018, at 3:12 PM, Anumaneni, Venkataramana (Nokia - US/Irving) 
>  wrote:
> 
> Hello Taka,
>  
> I am still facing same issue even after doing lot of configuration changes. 
> Below are the issues.
>  
> APPC Ansible Adapter is not taking configuration parameter from 
> appc.properties file.
>  
> My appc.properties contains below parameters. I have restarted APPC with 
> TRUST_all parameters also.
>  
> org.onap.appc.adapter.ansible.clientType=TRUST_CERT
> org.onap.appc.adapter.ansible.trustStore=/opt/openecomp/appc/data/stores/truststore.openecomp.taco.jks
> org.onap.appc.adapter.ansible.trustStore.trustPasswd=adminadmin
>  
> 2018-06-04 18:53:21,305 | INFO  | Event Dispatcher | AnsibleAdapterImpl   
> | 402 - appc-ansible-adapter - 1.2.0 | Creating http client with 
> default behaviour
>  
> I have followed steps mentioned at below link to create trust store.
>  
> https://docs.oracle.com/cd/E19509-01/820-3503/6nf1il6er/index.html
>  
> I am still facing same issue when I send request.
>  
> 2018-06-04 18:08:34,091 | ERROR | ppc-dispatcher-1 | ExecuteNodeExecutor  
> | 295 - org.onap.ccsdk.sli.core.sli-provider - 0.1.2 | Could not 
> execute plugin. SvcLogic status will be set to failure.
> org.onap.ccsdk.sli.core.sli.SvcLogicException: Ansible Adapter Error = Error 
> posting request. Reason = sun.security.validator.ValidatorException: PKIX 
> path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
> at 
> org.openecomp.appc.adapter.ansible.impl.AnsibleAdapterImpl.doFailure(AnsibleAdapterImpl.java:207)
> at 
> org.openecomp.appc.adapter.ansible.impl.AnsibleAdapterImpl.reqExec(AnsibleAdapterImpl.java:325)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)[:1.8.0_151]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_151]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_151]
> at 
> org.onap.ccsdk.sli.core.sli.provider.ExecuteNodeExecutor.execute(ExecuteNodeExecutor.java:96)
> at 
> org.onap.ccsdk.sli.core.sli.provider.SvcLogicServiceImpl.executeNode(SvcLogicServiceImpl.java:182)
> at 
> org.onap.ccsdk.sli.core.sli.provider.SvcLogicServiceImpl.execute(SvcLogicServiceImpl.java:159)
> at 
> org.onap.ccsdk.sli.core.sli.provider.CallNodeExecutor.execute(CallNodeExecutor.java:127)
> at 
> org.onap.ccsdk.sli.core.sli.provider.SvcLogicServiceImpl.executeNode(SvcLogicServiceImpl.java:182)
> at 
> org.onap.ccsdk.sli.core.sli.provider.BlockNodeExecutor.execute(BlockNodeExecutor.java:62)
> at 
> org.onap.ccsdk.sli.core.sli.provider.SvcLogicServiceImpl.executeNode(SvcLogicServiceImpl.java:182)
> at 
> org.onap.ccsdk.sli.core.sli.provider.SvcLogicServiceImpl.execute(SvcLogicServiceImpl.java:159)
> at 
> org.onap.ccsdk.sli.core.sli.provider.CallNodeExecutor.execute(CallNodeExecutor.java:127)
> at 
> org.onap.ccsdk.sli.core.sli.provider.SvcLogicServiceImpl.executeNode(SvcLogicServiceImpl.java:182)
> at 
> org.onap.ccsdk.sli.core.sli.provider.BlockNodeExecutor.execute(BlockNodeExecutor.java:62)
> at 
> org.onap.ccsdk.sli.core.sli.provider.SvcLogicServiceImpl.executeNode(SvcLogicServiceImpl.java:182)
> at 
> org.onap.ccsdk.sli.core.sli.provider.SvcLogicServiceImpl.execute(SvcLogicServiceImpl.java:159)
> at 
> org.onap.ccsdk.sli.core.sli.provider.SvcLogicServiceImpl.execute(SvcLogicServiceImpl.java:248)
> at 
> org.onap.ccsdk.sli.core.sli.provider.SvcLogicServiceImpl.execute(SvcLogicServiceImpl.java:221)
>  
> If I use http it works but APPC doesn’t send authentication parameters in 
> request whereas Ansible Server expects authentication parameters.
>  
> Please help me to solve this issue.
>  
> Regards
> Venkat
>  
>  
> From: CHO, TAKAMUNE [mailto:tc0...@att.com] 
> Sent: Thursday, May 31, 2018 3:06 PM
> To: Anumaneni, Venkataramana (Nokia - US/Irving) ; 
> onap-discuss@lists.onap.org
> Cc: Talari Nehemiah Vara, Vara (Nokia - US/Irving) 
> ; Akula, Ramanjaneyul Reddy (Nokia - 
> US/Irving) 
> Subject: RE: [onap-discuss] [app-c] Ansible Server details in appc.properties 
> file
>  
> Hi Venkat,
>  
> TRUST_ALL value should be fine.
>  
> From the error you got (I excerpted)
>  
> Error posting request. Reason = sun.security.validator.ValidatorException: 
> PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>  
> It sounds like your trusted keysore js file is 

Re: [onap-discuss] [AAI]: Cert has expired?

2018-06-04 Thread Alexis de Talhouët
To clarify, VID is failing to communicate with AAI as well. Same symptom: 

2018-06-04T19:00:52.907Z[http-apr-8080-exec-7]  INFO
com.att.eelf.error  InstanceUUID=292b461a-2954-4b63-a3f9-f916c7ad3bc0   
RequestId=5db9eb4c-688c-461f-958e-52d050752a1c  LoginId=demo
AlertSeverity=INFORMATIONAL PROTOCOL=HTTP   PartnerName=Default_FE  
ServerFQDN=onap-vid-6fb489db7c-f9z9jClientIPAddress=10.42.153.167   
Full-URL=http://vid.api.simpledemo.onap.org:30200/vid/aai_get_services  
ServiceInstanceId=  ServerIPAddress=10.42.252.68
ServiceName=/aai_get_services   ClassName=org.onap.vid.aai.AaiClient
19:00:52:0907<== .doAaiGetjavax.ws.rs.ProcessingException: 
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: 
PKIX path validation failed: java.security.cert.CertPathValidatorException: 
validity check failed


> On Jun 4, 2018, at 2:57 PM, Alexis de Talhouët  
> wrote:
> 
> Hello team,
> 
> I had Beijing deployment working fine until a few hours, and now I’m seeing 
> the bellow log in APP-C that seems to indicated the AAI cert has expired.
> Is this accurate? If so, is someone looking into this?
> 
> Also, VID is failing, etc… 
> 
> Thanks,
> Alexis
> 
>  timestamp="1528138436602" level="WARN" thread="qtp611540313-772">
> 
> 

[onap-discuss] [AAI]: Cert has expired?

2018-06-04 Thread Alexis de Talhouët
Hello team,

I had Beijing deployment working fine until a few hours, and now I’m seeing the 
bellow log in APP-C that seems to indicated the AAI cert has expired.
Is this accurate? If so, is someone looking into this?

Also, VID is failing, etc… 

Thanks,
Alexis




Re: [onap-discuss] SDC distribution POL5000 error in K8S, "U-EB cluster is not available"

2018-03-19 Thread Alexis de Talhouët
Reason why it’s using the external IP is so DCAE can communicate with DMaaP. As 
DCAE query SDC to get the UEB IPs (DMaaP), if those IPs are internal to K8S, 
DCAE VMs won’t be able to communicate with DMaaP, hence close-loop won’t work.

Alexis

> On Mar 18, 2018, at 4:55 PM, abdelmuhaimen.sea...@orange.com wrote:
> 
> Here's the output showing now DE is UP after correcting IP Address.
> 
> root@olc-k8s:/dockerdata-nfs/onap/sdc/environments# curl -X GET   
> http://localhost:30205/sdc/v1/distributionUebCluster 
>    -H 'Accept: 
> application/json'   -H 'Content-Type: application/json'   -H 
> 'X-ECOMP-InstanceID: mso'   -H 'authorization: Basic 
> dmlkOktwOGJKNFNYc3pNMFdYbGhhazNlSGxjc2UyZ0F3ODR2YW9HR21KdlV5MlU='
> {"uebServerList":["10.43.205.37","10.43.205.37"]}
> 
> root@olc-k8s:/dockerdata-nfs/onap/sdc/environments# curl -X GET   
> http://localhost:30205/sdc2/rest/healthCheck 
> 
> > ^C
> root@olc-k8s:/dockerdata-nfs/onap/sdc/environments# curl -X GET   
> http://localhost:30205/sdc2/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": "UP",
>   "description": "OK"
> },
> {
>   "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",
>   "healthCheckStatus": "UP",
>   "version": "2.1.17",
>   "description": "OK"
> }
>   ]
> }
>   ]
> }
> From: SEAUDI Abdelmuhaimen OBS/CSO
> Sent: Sunday, March 18, 2018 10:34 PM
> To: Ahmad, Munir; onap-discuss@lists.onap.org 
> 
> Subject: RE: [onap-discuss] SDC distribution POL5000 error in K8S, "U-EB 
> cluster is not available"
> 
> Hi Munir,
> 
> Thanks for your reply.
> 
> I found out that the reason SDC is using the external IP of DMAAP, instead of 
> the internal IP, is the configuration file 
> /dockerdata-nfs/onap/sdc/environments/AUTO.json, which mentions :
> "ueb_url_list": "84.39.48.90,84.39.48.90"
> 
> Shouldn't SDC be configured with the K8S internal IP address of the DMAAP, 
> for example in my case it should be the IP Address 10.43.205.37 as per the 
> output from kubectl get services below ?
> 
> How can this be corrected ?
> 
> kubectl get services --all-namespaces
> NAMESPACE NAME   CLUSTER-IP  EXTERNAL-IP   
> PORT(S)  
> AGE
> onap-message-router   dmaap  10.43.205.37   
> 3904:30227/TCP,3905:30226/TCP
> 24m
> root@olc-k8s:~# 
> From: Ahmad, Munir [munir.ah...@bell.ca ]
> Sent: Sunday, March 18, 2018 4:21 AM
> To: SEAUDI Abdelmuhaimen OBS/CSO; onap-discuss@lists.onap.org 
> 
> Subject: Re: [onap-discuss] SDC distribution POL5000 error in K8S, "U-EB 
> cluster is not available"
> 
> Hi,
>  
> It may have to do with the order your sdc containers started. Try deleting 
> your pods in the following order
>  
> sdc-es
> sdc-cs
> sdc-kb
> sdc-be
> sdc-fe
>  
>  
> Thanks
> Munir
> From:  > on behalf of 
> "abdelmuhaimen.sea...@orange.com " 
> >
> Date: Saturday, March 17, 2018 at 5:31 AM
> To: "onap-discuss@lists.onap.org " 
> >
> Subject: [onap-discuss] SDC distribution POL5000 error in K8S, "U-EB cluster 
> is not available"
>  
> Hi,
>  
> I have a minimal ONAP Depoloyment on K8S running.
>  
> If I try to distribute a new service in SDC, I get Error code POL5000, status 
> code: 500, Internal Server Error. Please try again later.
>  
> Regarding the output below, what does UEB Cluster not 

Re: [onap-discuss] [onap-discussion]: Multi VIM deployment

2018-03-06 Thread Alexis de Talhouët
Ramu,

This can be done as part of the same Service. As part of the Service design, 
you will define the VNF required. And as part of the VNF definition, you will 
define the VFC required.
In the case of VoLTE, there are two VNFs: vIMS, vEPC. Each of those VNF is 
composed of multiple VFCs. See 
https://wiki.onap.org/display/DW/Integration+Testing+Schedule%2C+10-4-2017?preview=%2F15999783%2F15999774%2FVoLTE+Use+Case+for+Dev+Event+Presented.pdf
 


At the time of creating the VFC (or vf-module), you will have to select the VIM 
where to deploy.

Look at https://wiki.onap.org/pages/viewpage.action?pageId=25431491 
 to learn how to 
register a VIM.

Alexis

> On Mar 5, 2018, at 4:24 PM, Akula, Ramanjaneyul Reddy (Nokia - US/Irving) 
>  wrote:
> 
> Hi,
> I’m looking at a case where my service has multiple VNFs each need to be 
> deployed on different VIM 
> (ex: 5G slicing that involved Radio + Core, radio on one VIM and Core on a 
> different VIM).
> Is  there a possibility to achieve this or do we need to split it into 2 
> different services and deploy them separately?
>  
>  
>  
> best regards,
> Ramu
>  
>  
>  
>  
> ___
> 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] Amsterdam Kubernetes OOM SDC UI is not accessible

2018-03-05 Thread Alexis de Talhouët
Hi,

This is AAI model-loader that failed to initialized correctly. Please bounce 
model-loader pod. After that, you should be fine.
See https://jira.onap.org/browse/OOM-766 

Alexis

> On Mar 5, 2018, at 6:03 AM, Vivekanandan Muthukrishnan 
>  wrote:
> 
> Hi Borislav,
> 
> Thanks for the support. 
> 
> Yes, we did the same and we are able to create a new service, but it fails at 
> the deployment time.
> 
> Here is the UI logs, i guess this is something to do with the service type? I 
> can only see the only vLB, vFWCL, vCPE, vIMS and the there is not vFW in the 
> drop down box.
> 
> 
> Deploy instance failed
> 
> "requestId": "1e8a37c9-4028-45c7-acd3-282b5600b1ba",
> "requestType": "createInstance",
> "timestamp": undefined,
> "requestState": "FAILED",
> "requestStatus": "SVC3001Resource not found for %1 using id %2 (msg=%3) 
> (ec=%4)PUTbusiness/customers/customer/Demonstration/service-subscriptions/service-subscription/vFWCL/service-instances/service-instance/c52f17cf-fbd6-42c0-8019-aa8eeb3cadbcNode
>  Not Found:object located at 
> service-design-and-creation/models/model/827361dd-931e-4468-a8ac-d77785039938/model-vers/model-ver/6e064bcd-b574-49cf-9846-48f9c52e7ce8#model-version
>  not foundERR.5.4.6114",
> "precentProgress": "100"
> 
> 03/05/18 10:52:56 HTTP Status: Accepted (202)
> {
>   "requestReferences": {
> "instanceId": "c52f17cf-fbd6-42c0-8019-aa8eeb3cadbc",
> "requestId": "1e8a37c9-4028-45c7-acd3-282b5600b1ba"
>   }
> }
> 
> VID Screen shot
> 
> 
> 
> 
> 
> On Mon, Mar 5, 2018 at 4:20 PM, Borislav Glozman  > wrote:
> Please try to redeploy sdc: 
> deleteAll.sh -n yournamespace -a sdc
> createAll.sh -n yournamespace -a sdc
> Wait that all pods are running and retry the workaround I wrote in the 
> previous email.
> 
> 
> Thanks,
> Borislav Glozman
> O. +972-9-7669188
> M. +972-52-2835726
> 
> 
> -Original Message- 
> From: Vivekanandan Muthukrishnan [vmuthukrish...@aarnanetworks.com 
> ]
> Received: Monday, 05 Mar 2018, 9:59
> To: Borislav Glozman [borislav.gloz...@amdocs.com 
> ]
> CC: onap-discuss@lists.onap.org  
> [onap-discuss@lists.onap.org ]
> Subject: Re: [onap-discuss] Amsterdam Kubernetes OOM SDC UI is not accessible
> 
> Hi Borislav,
> 
> Now the SDC UI is not loading and the below are the UI console image and logs.
> 
> I did the steps that you have suggested. Am i missing something here?
> 
> I would really appreciate your help to over come this issue.
>  
> Regards
> Vivek
> 
> 
> 
> SDC-BE Log snippet (/var/log/onap/sdc/sdc-be/error.log)
> 
> 2018-03-05T07:53:30.316Z [BE-Health-Check-Task]
> INFO c.d.d.c.p.DCAwareRoundRobinPolicy
> Using data-center name 'SDC-CS-AUTO' for DCAwareRoundRobinPolicy (if this is 
> incorrect, please provide the correct datacenter name with 
> DCAwareRoundRobinPolicy constructor)
> 2018-03-05T07:53:30.316Z [BE-Health-Check-Task]
> INFO com.datastax.driver.core.Cluster
> New Cassandra host sdc-cs.onap-sdc/10.42.139.62:9042 
>  added
> 2018-03-05T07:53:30.452Z [BE-Health-Check-Task]
> INFO o.o.s.b.c.impl.CassandraHealthCheck
> The number of cassandra nodes is:1
> 2018-03-05T07:53:30.452Z [BE-Health-Check-Task]
> INFO o.o.s.b.c.impl.CassandraHealthCheck
> The cassandra down nodes number is 0
> 2018-03-05T07:53:31.418Z [qtp561247961-19]
> INFO o.o.sdc.be.filters.BeServletFilter
> serviceInstanceID=null userId=null
> localAddr=10.42.94.114 uuid=5bdb4381-f45f-477a-a665-003f8a314702
> remoteAddr=10.42.123.31 No requestID  provided -> Generated UUID 
> 5bdb4381-f45f-477a-a665-003f8a314702
> 2018-03-05T07:53:33.126Z [BE-Health-Check-Task]
> INFO o.o.s.b.c.impl.CassandraHealthCheck
> creating cluster for Cassandra for monitoring.
> 2018-03-05T07:53:33.126Z [BE-Health-Check-Task]
> INFO o.o.s.b.d.c.schema.SdcSchemaUtils
> connecting to node:[sdc-cs.onap-sdc].
> 2018-03-05T07:53:33.168Z [ES-Health-Check-Thread]
> ERROR o.o.sdc.be.dao.impl.ESCatalogDAO
> Error while trying to connect to elasticsearch. host: [sdc-es.onap-sdc:9300] 
> | port: 9200 | error: None of the configured nodes are available: 
> [{#transport#-1}{10.42.103.200}{sdc-es.onap-sdc/10.42.103.200:9300 
> }]
> org.elasticsearch.client.transport.NoNodeAvailableException: None of the 
> configured nodes are available: 
> [{#transport#-1}{10.42.103.200}{sdc-es.onap-sdc/10.42.103.200:9300 
> }]
> at 
> org.elasticsearch.client.transport.TransportClientNodesService.ensureNodesAreAvailable(TransportClientNodesService.java:290)
>  ~[elasticsearch-2.1.0.jar:2.1.0]
> at 
> org.elasticsearch.client.transport.TransportClientNodesService.execute(TransportClientNodesService.java:207)
>  ~[elasticsearch-2.1.0.jar:2.1.0]
> at 
> 

Re: [onap-discuss] UUI health-check amsterdam

2018-03-05 Thread Alexis de Talhouët
Please review https://gerrit.onap.org/r/#/c/34055/

I adjust the MSB endpoint definition to match the one in the demo script. I 
have not validated this fixes the issue.

Alexis

> On Mar 2, 2018, at 7:54 AM, Ptacek Michal <michal.pta...@tieto.com> wrote:
> 
> Hi,
>  
> well, the easier part would be if /iui/usecase-ui/ is the correct one,
> so we can just modify robot healthcheck test and it will pass
>  
> please advise,
> Michal
>  
> From: onap-discuss-boun...@lists.onap.org 
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of shentao
> Sent: Friday, March 2, 2018 11:41 AM
> To: 'Alexis de Talhouët' <adetalhoue...@gmail.com>; 'onap-discuss' 
> <onap-discuss@lists.onap.org>
> Subject: [onap-discuss] 答复: UUI health-check amsterdam
>  
> Hi, Alexis
>  
> Sorry for my late reply. I’ve just returned from my holiday.
> The right URI is “/iui/usecaseui/” because UUI has been registered in MSB by 
> this path.
>  
> Best regards,
> Tao
>  
> 发件人: onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org> 
> [mailto:onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>] 代表Alexis de Talhou?t
> 发送时间: 2018年3月1日 21:36
> 收件人: onap-discuss
> 主题: Re: [onap-discuss] UUI health-check amsterdam
>  
> Hello,
>  
> Any news on the same? This is giving bad publicity to UUI that health-check 
> is failing in OOM. Please help us address this.
>  
> Alexis
>  
> 
> On Feb 20, 2018, at 12:47 PM, Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>> wrote:
>  
> Hi UUI experts,
>  
> UUI health-check has been failing on amsterdam for a few weeks now, I could 
> find that patch has changed the uri to use 
> https://gerrit.onap.org/r/#/c/28431/ <https://gerrit.onap.org/r/#/c/28431/>
> Amsterdam is giving 200 OK for /iui/usecase-ui/ and 502 for /iui/usecaseui/ 
> so since this patch came in, it’s failing.
> What should be the URI to use for amsterdam for this health-check ?
>  
> Alexis

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


Re: [onap-discuss] UUI health-check amsterdam

2018-03-01 Thread Alexis de Talhouët
Hello,

Any news on the same? This is giving bad publicity to UUI that health-check is 
failing in OOM. Please help us address this.

Alexis

> On Feb 20, 2018, at 12:47 PM, Alexis de Talhouët <adetalhoue...@gmail.com> 
> wrote:
> 
> Hi UUI experts,
> 
> UUI health-check has been failing on amsterdam for a few weeks now, I could 
> find that patch has changed the uri to use 
> https://gerrit.onap.org/r/#/c/28431/ <https://gerrit.onap.org/r/#/c/28431/>
> Amsterdam is giving 200 OK for /iui/usecase-ui/ and 502 for /iui/usecaseui/ 
> so since this patch came in, it’s failing.
> 
> What should be the URI to use for amsterdam for this health-check ?
> 
> Alexis

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


Re: [onap-discuss] [onap-tsc] Release management process is broken

2018-03-01 Thread Alexis de Talhouët
I don’t have enough knowledge on this to answer your question, Gary. But my 
hope is we can get this fix so Beijing delivers tagged code as well.

Thanks,
Alexis

> On Feb 28, 2018, at 3:32 PM, Gary Wu <gary.i...@huawei.com> wrote:
> 
> Usually the maven release plugin is used for this, which would:
>  
> · Checkout SNAPSHOT version poms, e.g. “1.1-SNAPSHOT”
> · Update poms to release version, e.g. “1.1”
> · Build and run all tests
> · Commit release version poms into git repo
> · Tag this “release version” commit in git
> · Update poms to next SNAPSHOT version, e.g. “1.2-SNAPSHOT”
> · Commit new SNAPSHOT version poms into git repo
>  
> However, this conflicts with our use of staging/RC builds since we obviously 
> don’t want to commit pom changes for every RC build. 
>  
> To work with staging/RC builds, the ODL method of saving git bundles for 
> later tagging seems like it would work fine.  Are there any downsides to this 
> approach?
>  
> Thanks,
> Gary
>  
> From: onap-tsc-boun...@lists.onap.org 
> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët
> Sent: Wednesday, February 28, 2018 11:07 AM
> To: t...@lists.onap.org; onap-discuss <onap-discuss@lists.onap.org>
> Subject: Re: [onap-tsc] Release management process is broken
>  
> Does anyone has any input on the same?
>  
> I think it is *critical* that we can deliver tagged artifacts (whether maven, 
> docker *and code*) for each of our release. Most importantly, for Beijing 
> coming in a few weeks.
>  
> We had a discussion last week on the #lf-releng channel, and it seems the 
> issue is identified. See raw discussion snippet bellow
>  
> tykeal hmm I think I may know what the problem here is. The 
> ONAP releases are done using the maven version plugin. The release jobs take 
> the current version that gets checked out and then for the release job the 
> version plugin is run to drop the SNAPSHOT name and then produce the artifacts
> zxiiro adetalhouet_: looks like you got all the points to me.
> tykeal as such gerrit doesn't have any of the released versions 
> actually stored but the target tag points to the version that was checked out 
> to produce the release artifacts
> zxiiro tykeal: maven version plugin should take care of removing 
> the snapshot AND git tagging though if I recall.
> tykeal zxiiro: it's not being used to do the tagging
> zxiiro :/
> zxiiro looks like they are missing the step we do in ODL where we 
> produce git.bundles and store it in the log server for tagging at a later 
> date.
> tykeal ONAP release process at present is basically the following:
> tykeal daily jobs produce RC builds
> tykeal a request is made to release the builds staging repo 
> produced by job XYZ
> tykeal RE looks up the staging repo from the job output
> tykeal signs the artifacts and releases them
> tykeal looks up the git sha that was checked out by the job and 
> tags it
> zxiiro ya that's not right. they need to get the git.bundle and 
> Jenkins should be producing it by creating a commit on the pom.xmls that it 
> modified before the build.
> tykeal zxiiro: yes, they're missing that step because ONAP isn't 
> using the release jobs that ODL created because global-jjb didn't exist when 
> they implemented and they didn't want to copy the work that ODL had already 
> done
> zxiiro even if we drop the SNAPSHOTS and tag from the same base 
> commit, that produces a new sha so while it looks the same it is not 
> identical. Which is why it's so important to save the git.bundles.
> * AlexAvadanii has quit (Ping timeout: 256 seconds)
> * CristinaPauna has quit (Ping timeout: 248 seconds)
> tykeal @zxiiro: I'm not saying that they're producing an updated 
> commit, they're are literally tagging the commit that Jenkins checked out, 
> not one with a modified pom
>  
>  
> Alexis
>  
> On Feb 23, 2018, at 10:58 AM, Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>> wrote:
>  
> Hello TSC, Release management team,
> 
> I just found out our release process is somewhat broken. We should never be 
> tagging snapshot commits as releases, and tags in projects relates to 
> SNAPSHOT.
> Even more, they are multiple tags pointing to the same SNAPSHOT.
> I can see they are released artifacts in Nexus, but there is no corresponding 
> code for it, although I would have expect the tag to have the code at the 
> very specific com

Re: [onap-discuss] Release management process is broken

2018-02-28 Thread Alexis de Talhouët
Does anyone has any input on the same?

I think it is *critical* that we can deliver tagged artifacts (whether maven, 
docker *and code*) for each of our release. Most importantly, for Beijing 
coming in a few weeks.

We had a discussion last week on the #lf-releng channel, and it seems the issue 
is identified. See raw discussion snippet bellow

tykeal  hmm I think I may know what the problem here is. The ONAP 
releases are done using the maven version plugin. The release jobs take the 
current version that gets checked out and then for the release job the version 
plugin is run to drop the SNAPSHOT name and then produce the artifacts
zxiiro  adetalhouet_: looks like you got all the points to me.
tykeal  as such gerrit doesn't have any of the released versions 
actually stored but the target tag points to the version that was checked out 
to produce the release artifacts
zxiiro  tykeal: maven version plugin should take care of removing the 
snapshot AND git tagging though if I recall.
tykeal  zxiiro: it's not being used to do the tagging
zxiiro  :/
zxiiro  looks like they are missing the step we do in ODL where we 
produce git.bundles and store it in the log server for tagging at a later date.
tykeal  ONAP release process at present is basically the following:
tykeal  daily jobs produce RC builds
tykeal  a request is made to release the builds staging repo produced 
by job XYZ
tykeal  RE looks up the staging repo from the job output
tykeal  signs the artifacts and releases them
tykeal  looks up the git sha that was checked out by the job and tags it
zxiiro  ya that's not right. they need to get the git.bundle and 
Jenkins should be producing it by creating a commit on the pom.xmls that it 
modified before the build.
tykeal  zxiiro: yes, they're missing that step because ONAP isn't using 
the release jobs that ODL created because global-jjb didn't exist when they 
implemented and they didn't want to copy the work that ODL had already done
zxiiro  even if we drop the SNAPSHOTS and tag from the same base 
commit, that produces a new sha so while it looks the same it is not identical. 
Which is why it's so important to save the git.bundles.
*   AlexAvadanii has quit (Ping timeout: 256 seconds)
*   CristinaPauna has quit (Ping timeout: 248 seconds)
tykeal  @zxiiro: I'm not saying that they're producing an updated 
commit, they're are literally tagging the commit that Jenkins checked out, not 
one with a modified pom


Alexis

> On Feb 23, 2018, at 10:58 AM, Alexis de Talhouët <adetalhoue...@gmail.com> 
> wrote:
> 
> Hello TSC, Release management team,
> 
> I just found out our release process is somewhat broken. We should never be 
> tagging snapshot commits as releases, and tags in projects relates to 
> SNAPSHOT.
> Even more, they are multiple tags pointing to the same SNAPSHOT.
> I can see they are released artifacts in Nexus, but there is no corresponding 
> code for it, although I would have expect the tag to have the code at the 
> very specific commit used for the release.
> 
> This is a major concern, as this means it’s impossible for downstream users 
> to consume and develop their own stuff on released ONAP code (as it doesn’t 
> exist). It’s also impossible to debug issues as we don’t have the exact 
> version of the code we’re running.
> 
> Can this topic be added at the TSC next week?
> 
> Alexis

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


Re: [onap-discuss] [OOM] nameserver issue

2018-02-26 Thread Alexis de Talhouët
Harry,

I’m not sure to fully understand the issue wrt dns. Is it when deploying DCAE 
with OOM? If so, here are the requirement:

Have support for DNS Designate, and configure DNS Designate backend to forward 
request to an external DNS to resolve internet facing domain name.

All the VMs will be configured to point to DNS Designate backend IP address, 
which means all the VMs will be able to resolve internal domain (the one for 
dcae vms, and the one for simpledemo.onap.org  
that will be created in DNS Designate during the provisioning of DCAE), and the 
external domains, as DNS Designate will recurse the request if not able to 
resolve.

HTH,
Alexis 

> On Feb 25, 2018, at 9:10 PM, huangxiangyu  wrote:
> 
> Joe
>  
> Not sure if an onap_dns server steps in at this time. It seems that in ONAP 
> on kubernetes procedure, containers comes first then a heat bootstrap pod 
> will then launch dcae VMs in openstack using heat. I think that’s when a dns 
> server is needed. Anyway, 10.43.0.10 does look like a local dns server,  
> thing is I can’t find this 10.43.0.10  then somehow manipulate it to make 
> containers to connect to internet. Besides, I think I never configure this 
> address to be a local dns server but this address shows up every time when I 
> deploy the OOM.
>  
> Regards
> Harry
>  
> 发件人: Joe Kidder [mailto:joe.kid...@5thlayer.com] 
> 发送时间: 2018年2月25日 9:06
> 收件人: huangxiangyu 
> 抄送: Michael O'Brien ; onap-discuss@lists.onap.org
> 主题: Re: [onap-discuss] [OOM] nameserver issue
>  
> Harry,
>   Do you have an onap_dns server in your setup?  In the heat-based ONAP, it 
> looks like there’s an onap_dns server that provides name resolution for the 
> various components, and then it may use some openstack DNS service called 
> designate to get out to the real world (e.g. 8.8.8.8).  
>   Two things that might come out of that - if you just jump out to 8.8.8.8, 
> you may not get local name resolution.  Secondly, perhaps the 10.43.0.10 is 
> supposed to be the local onap_dns server?  That doesn’t sound like the 
> address defaulted in the heat template for ONAP on O.S., however.
>  
> Joe
>  
> On Feb 24, 2018, at 1:43 AM, huangxiangyu  > wrote:
>  
> Hi Michael
>  
> I’m using OOM Amsterdam branch and found that the nameserver in each 
> container is configured to 10.43.0.10. This address is unreachable and 
> therefore cause package installation failure in pod like heat-bootstrap- 
> under onap-dcaegen2. I can manually change nameserver to 8.8.8.8 to install 
> package but is there a way to configure nameserver to 8.8.8.8 ?
>  
> Thanks
> Harry
> ___
> 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

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


[onap-discuss] Release management process is broken

2018-02-23 Thread Alexis de Talhouët
Hello TSC, Release management team,

I just found out our release process is somewhat broken. We should never be 
tagging snapshot commits as releases, and tags in projects relates to SNAPSHOT.
Even more, they are multiple tags pointing to the same SNAPSHOT.
I can see they are released artifacts in Nexus, but there is no corresponding 
code for it, although I would have expect the tag to have the code at the very 
specific commit used for the release.

This is a major concern, as this means it’s impossible for downstream users to 
consume and develop their own stuff on released ONAP code (as it doesn’t 
exist). It’s also impossible to debug issues as we don’t have the exact version 
of the code we’re running.

Can this topic be added at the TSC next week?

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


Re: [onap-discuss] Domain names and toy certificates for Beijing demo

2018-02-21 Thread Alexis de Talhouët


> On Feb 19, 2018, at 10:21 AM, FORSYTH, JAMES  wrote:
> 
> Does OOM manage this now? 


Hi,

OOM does not manage this as of now. We accommodate ourself for DCAE by 
specifying the domain names, but we can very easily update if new domain name 
is used.
DNS entry are created in DNS Designate; this is handled by this script: 
https://github.com/onap/oom/blob/amsterdam/kubernetes/config/docker/init/src/config/dcaegen2/heat/entrypoint.sh#L4
 


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


[onap-discuss] UUI health-check amsterdam

2018-02-20 Thread Alexis de Talhouët
Hi UUI experts,

UUI health-check has been failing on amsterdam for a few weeks now, I could 
find that patch has changed the uri to use https://gerrit.onap.org/r/#/c/28431/ 

Amsterdam is giving 200 OK for /iui/usecase-ui/ and 502 for /iui/usecaseui/ so 
since this patch came in, it’s failing.

What should be the URI to use for amsterdam for this health-check ?

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


Re: [onap-discuss] [E] Service Distribution and Service Deployment Issue on OOM Amsterdam release

2018-02-20 Thread Alexis de Talhouët
Hi, this issue is due to AAI model-loader component not working well at the 
time of the distribution. There is a window where model-loader tries to connect 
to sdc but fails because sdc is not yet up, hence model-loader is giving up. To 
fix this, bounce model-loader pod, re-deploy the service. Then all should be 
fine.

Alexis

> On Feb 20, 2018, at 10:49 AM, Thiruveedula, Bharath 
>  wrote:
> 
> Hi Vijayalakshmi,
> 
> Generally " Model-Version not found . " error is because of something wrong 
> in "model loader" in AAI. Check if model-loader container is up.
> 
> Are you running the OOM behind the proxy?
> 
> Best Regards
> Bharath T
> 
> 
> 
> On Sun, Feb 18, 2018 at 12:48 PM, Vijayalakshmi Hadimani 
> > wrote:
> Thanks Michael and Alexis for very detailed wiki and comprehensive demos .  
> 
>  
> 
> Continuing to Run Demo Vnf and DCAE Deployment on OOM Amsterdam release , I 
> am facing 2 Issues at Hand . I have tried rebuilding the pod and things 
> around it . but some how It is not helping .
> 
>  
> 
> Pls find the Onap-parameter.yaml attached .
> 
> The issue faced are Two .
> 
>  
> 
> a-   At the Time of deploying  the services below error is seen 
> .Indicating Model-Version not found .
> 
>  
> 
>  
> 
> 
> 
>  
> 
>  
> 
> b-  W.r.t to Service Distribution ,
> 
>   The artifcats are distributed to SO only  .It looks Like 
> there is no artifcats distribution happening between A . Any Pointer why 
> this could be happening and recommendation will be helpful .
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> ::DISCLAIMER::
> --
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects.
> --
> 
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=UTP8N06L2trD3jawJkElFfA6CQYtkCWzTnn4GsHkmJw=O8fh9U8Fckd80BGFY5-_E1_3KnDPBdCVU17zX9uMrrQ=vQExGgI1FCnR5KLIwkrapYEJ3OEC12IIqWeqjKxbKTg=
>  
> 
> 
> 

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


Re: [onap-discuss] [SO][Multicloud] How to get SO deploy VNF using Multicloud on any type of VIM?

2018-02-19 Thread Alexis de Talhouët
Suraj,

As far as I know, the SO code is supporting HEAT *only* to create a VNF, hence 
does support only VIM supporting HEAT. Using MultiCloud to authenticate to the 
VIM is fine, but SO doesn’t offload the creation of the VNF to MultCloud. Hence 
for a VIM not supporting HEAT, and not OpenStack based, this doesn’t work.

I’m wondering if there is any design document about having SO completely 
relying on MultiCloud instead of relying on its own HEAT support.

Alexis

> On Feb 19, 2018, at 1:06 PM, Bisht, Suraj (Nokia - US/Irving) 
> <suraj.bi...@nokia.com> wrote:
> 
> Hi Alexis,
>  
> Attached mail earlier has all steps for SO integration as well
>  
> For other cloud SO config should be
> Case 2: SO instantiate a VF modules via MultiCloud
> 
>In this case, VIM registration information refers to 
> MultiCloud endpoints which is a proxy to underlying VIMs, so the identity_url 
> looks like:
> 
> "identity_url": " 
> http://10.0.14.1:80/api/multicloud-titanium_cloud/v0/pod25_RegionOne/identity/v2.0
>  
> <http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_RegionOne/identity/v2.0>",
> 
> Above should invoke multi-VIM API supporting various VIM types, supported VIM 
> types are available in following link  “Release Components Name“
>  
> https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-MultiVIM/Cloud
>  
> <https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-MultiVIM/Cloud>
>  
> Thanks,
> Suraj
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Monday, February 19, 2018 11:41 AM
> To: Bisht, Suraj (Nokia - US/Irving) <suraj.bi...@nokia.com 
> <mailto:suraj.bi...@nokia.com>>
> Cc: Avdhut Kholkar <avdhut.khol...@amdocs.com 
> <mailto:avdhut.khol...@amdocs.com>>; onap-discuss 
> <onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>>; Talari 
> Nehemiah Vara, Vara (Nokia - US/Irving) <vara.talari_nehemiah_v...@nokia.com 
> <mailto:vara.talari_nehemiah_v...@nokia.com>>
> Subject: Re: [onap-discuss] [SO][Multicloud] How to get SO deploy VNF using 
> Multicloud on any type of VIM?
>  
> Avdhut,
>  
> Thanks for the answer, good to know there is a possibility through VFC, but 
> I’d really want to integrate in SO as I need BPMN support. Or does VFC 
> provides hooks to trigger BPMN flow in SO?
> 
> Suraj,
>  
> What you linked is to provision a new cloud in ONAP.
>  
> What I’m looking for is how SO can leverage this new type of cloud seamlessly 
> to deploy VNF in there.
> As of now, SO let you instantiate only on OpenStack/Rackspace, based on the 
> code itself.
> I’m looking for what is required to get SO use multivim instead. More 
> precisely, I’m looking for design document, workflow to understand what the 
> supposed interaction should be.
>  
> Thanks,
> Alexis
> 
> 
> On Feb 19, 2018, at 11:56 AM, Bisht, Suraj (Nokia - US/Irving) 
> <suraj.bi...@nokia.com <mailto:suraj.bi...@nokia.com>> wrote:
>  
> Hi,
>  
> Kindly follow attached procedure to configure Multi-VIM. It has steps for AAI 
> as well as MSO
>  
> Thanks,
> Suraj
>  
> From: onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org> 
> [mailto:onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Avdhut Kholkar
> Sent: Sunday, February 18, 2018 9:59 PM
> To: Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>>; onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [SO][Multicloud] How to get SO deploy VNF using 
> Multicloud on any type of VIM?
>  
> As far as I am aware, SO does not integrate with Multicloud. There is no 
> adaptor in SO that interfaces with Multicloud.
> The VoLTE use case had SO integrated with VFC/NFVO which in turn interfaces 
> with Multicloud. I was also looking for something similar and was hoping that 
> the VoLTE use case had integrated SO and multivim but that was not the case. 
> The other Amsterdam use cases do not use multivim.
> I maybe wrong and the multicloud experts can clarify.
>  
> Regards,
> Avdhut Kholkar
>  
> From: onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org> 
> [mailto:onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de Talhouët
> Sent: Sunday, February 18, 2018 10:04 PM
> To: onap-discuss <onap-discuss@lists.onap.org 
> <

Re: [onap-discuss] [SO][Multicloud] How to get SO deploy VNF using Multicloud on any type of VIM?

2018-02-19 Thread Alexis de Talhouët
Avdhut,

Thanks for the answer, good to know there is a possibility through VFC, but I’d 
really want to integrate in SO as I need BPMN support. Or does VFC provides 
hooks to trigger BPMN flow in SO?

Suraj,

What you linked is to provision a new cloud in ONAP.

What I’m looking for is how SO can leverage this new type of cloud seamlessly 
to deploy VNF in there.
As of now, SO let you instantiate only on OpenStack/Rackspace, based on the 
code itself.
I’m looking for what is required to get SO use multivim instead. More 
precisely, I’m looking for design document, workflow to understand what the 
supposed interaction should be.

Thanks,
Alexis

> On Feb 19, 2018, at 11:56 AM, Bisht, Suraj (Nokia - US/Irving) 
> <suraj.bi...@nokia.com> wrote:
> 
> Hi,
>  
> Kindly follow attached procedure to configure Multi-VIM. It has steps for AAI 
> as well as MSO
>  
> Thanks,
> Suraj
>  
> From: onap-discuss-boun...@lists.onap.org 
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Avdhut Kholkar
> Sent: Sunday, February 18, 2018 9:59 PM
> To: Alexis de Talhouët <adetalhoue...@gmail.com>; onap-discuss 
> <onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] [SO][Multicloud] How to get SO deploy VNF using 
> Multicloud on any type of VIM?
>  
> As far as I am aware, SO does not integrate with Multicloud. There is no 
> adaptor in SO that interfaces with Multicloud.
> The VoLTE use case had SO integrated with VFC/NFVO which in turn interfaces 
> with Multicloud. I was also looking for something similar and was hoping that 
> the VoLTE use case had integrated SO and multivim but that was not the case. 
> The other Amsterdam use cases do not use multivim.
> I maybe wrong and the multicloud experts can clarify.
>  
> Regards,
> Avdhut Kholkar
>  
> From: onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org> 
> [mailto:onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de Talhouët
> Sent: Sunday, February 18, 2018 10:04 PM
> To: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: [onap-discuss] [SO][Multicloud] How to get SO deploy VNF using 
> Multicloud on any type of VIM?
>  
> Hi SO and Multicloud experts,
>  
> Can SO seamlessly hand off request to multicloud in Amsterdam? or master?
>  
> How such process is / would be working? I tried to look for 
> design/integration doc but couldn’t find any. I landed here: 
> https://jira.onap.org/browse/MULTICLOUD-21 
> <https://jira.onap.org/browse/MULTICLOUD-21> but not much is explained in the 
> ticket.
>  
> Looking at the code, I could find only one implementation of MsoVnfAdapter 
> here: 
> https://github.com/onap/so/tree/master/adapters/mso-vnf-adapter/src/main/java/org/openecomp/mso/adapters/vnf
>  
> <https://github.com/onap/so/tree/master/adapters/mso-vnf-adapter/src/main/java/org/openecomp/mso/adapters/vnf>
>  
> I need to deploy VNFs on a specific type of VIM, not OpenStack, nor 
> Rackspace, my impression was I need to create the multicloud driver for this 
> VIM, and then, auto-magically, SO would be able to get to this driver. How? 
> Can SO fetch VIM info from AAI in the case of use using multicloud ?
>  
> Please help me understand what is there and how it should be done, so I can 
> understand the missing pieces and help toward that goal.
>  
> Alexis
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement, you may review 
> athttps://www.amdocs.com/about/email-disclaimer 
> <https://www.amdocs.com/about/email-disclaimer>
> Amdocs Development Centre India Private Limited having CIN: 
> U72200PN2004PTC0188320 converted into Amdocs Development Centre India LLP (A 
> limited liability partner­ship with LLP Identification Number: AAI-6901 
> effective 28th Feb 2017)
> 

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


Re: [onap-discuss] [OOM] static routes from SDNC to vGMUX

2018-02-15 Thread Alexis de Talhouët
For us, when we need ODL to reach other machine, we add the route in the host 
having the container, not in the container itself.

> On Feb 15, 2018, at 10:42 AM, Alexis de Talhouët <adetalhoue...@gmail.com> 
> wrote:
> 
> Sorry I misread your mail. To do this, either you need to enter your docker 
> container with privileged access: 
> 
> - docker exec -it -u 0  bash
> 
> Either you configure the host running the SDNC container with the proper 
> route. because K8S rely on the host routing table.
> 
> Alexis
> 
> 
>> On Feb 9, 2018, at 5:35 PM, FREEMAN, BRIAN D <bf1...@att.com 
>> <mailto:bf1...@att.com>> wrote:
>> 
>>  
>> For the vCPE Use Case we add a static route from the SDNC controller to the 
>> vBNG  so that we can to the vBRG to create the tunnels to the vGMUX.
>>  
>> The command we use on regular docker seems to fail on the K8 based image.
>>  ip route add 10.3.0.0/24 via 10.0.101.10 dev eth0
>> RTNETLINK answers: Operation not permitted
>>  
>> Other ip config data below.
>>  
>> Do we need to add this static route from the K8 side ?
>>  
>> Brian
>>  
>> root@sdnc-1507781456-qpp77:/# ifconfig
>> eth0  Link encap:Ethernet  HWaddr 02:f2:9c:4e:8e:03
>>   inet addr:10.42.105.196  Bcast:0.0.0.0  Mask:255.255.0.0
>>   inet6 addr: fe80::c461:2eff:fe28:5ab8/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1402  Metric:1
>>   RX packets:452850 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:374275 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:0
>>   RX bytes:72235413 (72.2 MB)  TX bytes:53479210 (53.4 MB)
>>  
>> loLink encap:Local Loopback
>>   inet addr:127.0.0.1  Mask:255.0.0.0
>>   inet6 addr: ::1/128 Scope:Host
>>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>>   RX packets:10453 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:10453 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:1155768 (1.1 MB)  TX bytes:1155768 (1.1 MB)
>>  
>>  
>>  
>>  
>> root@sdnc-1507781456-qpp77:/# ip route
>> default via 10.42.0.1 dev eth0
>> 10.42.0.0/16 dev eth0  proto kernel  scope link  src 10.42.105.196
>> 169.254.169.250 via 10.42.0.1 dev eth0
>> ___
>> onap-discuss mailing list
>> onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
>> https://lists.onap.org/mailman/listinfo/onap-discuss 
>> <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] [OOM] static routes from SDNC to vGMUX

2018-02-15 Thread Alexis de Talhouët
Sorry I misread your mail. To do this, either you need to enter your docker 
container with privileged access: 

- docker exec -it -u 0  bash

Either you configure the host running the SDNC container with the proper route. 
because K8S rely on the host routing table.

Alexis


> On Feb 9, 2018, at 5:35 PM, FREEMAN, BRIAN D  wrote:
> 
>  
> For the vCPE Use Case we add a static route from the SDNC controller to the 
> vBNG  so that we can to the vBRG to create the tunnels to the vGMUX.
>  
> The command we use on regular docker seems to fail on the K8 based image.
>  ip route add 10.3.0.0/24 via 10.0.101.10 dev eth0
> RTNETLINK answers: Operation not permitted
>  
> Other ip config data below.
>  
> Do we need to add this static route from the K8 side ?
>  
> Brian
>  
> root@sdnc-1507781456-qpp77:/# ifconfig
> eth0  Link encap:Ethernet  HWaddr 02:f2:9c:4e:8e:03
>   inet addr:10.42.105.196  Bcast:0.0.0.0  Mask:255.255.0.0
>   inet6 addr: fe80::c461:2eff:fe28:5ab8/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1402  Metric:1
>   RX packets:452850 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:374275 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:72235413 (72.2 MB)  TX bytes:53479210 (53.4 MB)
>  
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>   RX packets:10453 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:10453 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:1155768 (1.1 MB)  TX bytes:1155768 (1.1 MB)
>  
>  
>  
>  
> root@sdnc-1507781456-qpp77:/# ip route
> default via 10.42.0.1 dev eth0
> 10.42.0.0/16 dev eth0  proto kernel  scope link  src 10.42.105.196
> 169.254.169.250 via 10.42.0.1 dev eth0
> ___
> 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] [OOM] static routes from SDNC to vGMUX

2018-02-15 Thread Alexis de Talhouët
Brian

SDNC controller is using a script to boostrap, as shown here: 
https://github.com/onap/oom/blob/amsterdam/kubernetes/sdnc/templates/sdnc-deployment.yaml#L45
 


What I suggest is to customize this script to deploy the route if an 
environment parameter is set.
Could be something like: 

- name:vCPE_use_case_enable
value: true

If you don’t want to modify this script, then I suggest you create a new 
script, that will call the /opt/onap/sdnc/bin/startODL.sh script and add your 
route. If you do this, you will have to load your script in a config-map 
(similarly as done here: https://gerrit.onap.org/r/#/c/30603/ 
)  in the SDNC namespace, you will have 
to add this config-map as volume in the SDNC deployment, and you will have to 
change the start command to run your added script.

Alexis


> On Feb 9, 2018, at 5:35 PM, FREEMAN, BRIAN D  wrote:
> 
>  
> For the vCPE Use Case we add a static route from the SDNC controller to the 
> vBNG  so that we can to the vBRG to create the tunnels to the vGMUX.
>  
> The command we use on regular docker seems to fail on the K8 based image.
>  ip route add 10.3.0.0/24 via 10.0.101.10 dev eth0
> RTNETLINK answers: Operation not permitted
>  
> Other ip config data below.
>  
> Do we need to add this static route from the K8 side ?
>  
> Brian
>  
> root@sdnc-1507781456-qpp77:/# ifconfig
> eth0  Link encap:Ethernet  HWaddr 02:f2:9c:4e:8e:03
>   inet addr:10.42.105.196  Bcast:0.0.0.0  Mask:255.255.0.0
>   inet6 addr: fe80::c461:2eff:fe28:5ab8/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1402  Metric:1
>   RX packets:452850 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:374275 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:72235413 (72.2 MB)  TX bytes:53479210 (53.4 MB)
>  
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>   RX packets:10453 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:10453 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:1155768 (1.1 MB)  TX bytes:1155768 (1.1 MB)
>  
>  
>  
>  
> root@sdnc-1507781456-qpp77:/# ip route
> default via 10.42.0.1 dev eth0
> 10.42.0.0/16 dev eth0  proto kernel  scope link  src 10.42.105.196
> 169.254.169.250 via 10.42.0.1 dev eth0
> ___
> 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] [OOM] UEB IP and Port on OOM Install

2018-02-15 Thread Alexis de Talhouët
Brian,

As part of the fix, it is now required for user of a k8s cluster to put the 
external ip of their nodes in the dcaegen2/values.yaml 
(https://github.com/onap/oom/blob/amsterdam/kubernetes/dcaegen2/values.yaml#L11-L19
 
)
 file, as explained here: 
https://github.com/onap/oom/blob/amsterdam/kubernetes/config/onap-parameters-sample.yaml#L4-L8
 


The reason for that is we need to expose the reverse proxy service on all the 
nodes, so the UEB port is open everywhere. kube-proxy will manage to route the 
traffic to the node having the nginx service.

Hope it helps. I know this change is not convenient, but it was the only 
good/easy was for Amsterdam. This fix will be revisit in Beijing.

Thanks,
Alexis

> On Feb 12, 2018, at 5:25 PM, FREEMAN, BRIAN D  wrote:
> 
>  
> Trying to bring up OOM in Azure with the latest rancher/heml recommended and 
> SDC and others cant seem to get to UEB.
>  
> https://jira.onap.org/browse/OOM-654  
> mentions that the external IP has to be open on UEB port but I don’t see that 
> in my kube portal.
> Only the 10.42 address is open on  port 3904.
>  
> Is there something I need to check or change in the rancher GUI ?
>  
> Brian
>  
>  
>  
> ___
> 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] [DCAE][AAI][APPC][DMAAP] Help with UEB-source-APPC-LCM-WRITE missing topic and heatbridge debugging

2018-02-09 Thread Alexis de Talhouët
David,

You could try to re-deploy the vFWCL instances. You shouldn’t have to edit 
hearbridge; when it say it was incorrect, what do you mean by that? note, if 
heatbridge failed, that will not work. It must pass as its added stack 
information in AAI, so policy can correlate a vnf-id to a stack name, and other 
OpenStack resources, through the service instance.

Policy/DCAE experts might chime in to provide more insight on what’s happening.

Alexis

> On Feb 8, 2018, at 7:39 PM, Elie Dit Cosaque, David (Nokia - US/Irving) 
> <david.elie_dit_cosa...@nokia.com> wrote:
> 
> Hi Alexis, 
>  
> Thanks for the pointers. I was able to further a little bit my investigation 
> by looking at the drools logs.
> I see the following error in drools:
>  
> --
> [2018-02-07 20:56:15,407|INFO|AAIManager|Session 
> org.onap.policy-engine.drools.amsterdam:policy-amsterdam-rules:0.8.0:closedloop-amsterdam]
>  
> https://aai.api.simpledemo.openecomp.org:8443/aai/v11/network/generic-vnfs/generic-vnf?vnf-name=zdfw1fwl01fwl01
>  
> <https://aai.api.simpledemo.openecomp.org:8443/aai/v11/network/generic-vnfs/generic-vnf?vnf-name=zdfw1fwl01fwl01>
> [2018-02-07 20:56:15,407|INFO|AAIManager|Session 
> org.onap.policy-engine.drools.amsterdam:policy-amsterdam-rules:0.8.0:closedloop-amsterdam]
>  404
> [2018-02-07 20:56:15,407|INFO|AAIManager|Session 
> org.onap.policy-engine.drools.amsterdam:policy-amsterdam-rules:0.8.0:closedloop-amsterdam]
>  {"requestError":{"serviceException":{"messageId":"SVC3001","text":"Resource 
> not found for %1 using id %2 (msg=%3) 
> (ec=%4)","variables":["GET","network/generic-vnfs/generic-vnf","Node Not 
> Found:No Node of type generic-vnf found at: 
> network/generic-vnfs/generic-vnf","ERR.5.4.6114"]}}}
> -
>  
> Drools is trying to find a VNF name but is using the vserver name to do so 
> (as received from VES).
> At the same time I saw an error in CDAP complaining about not finding 
> Enrichment entries for my vserver, which pointed to a heatbridge issue 
> (https://wiki.onap.org/display/DW/VES+event+enrichment+for+DCAE+mS 
> <https://wiki.onap.org/display/DW/VES+event+enrichment+for+DCAE+mS>). I 
> checked the heatbridge configuration and it was incorrect. A query with even 
> the correct  VNF name was failing. I fixed the “heatbridge” vserver entries 
> in AAI but still no luck. There was not new update in the Enrichment log on 
> CDAP.
> I then redeployed CDAP to try to go back to a state where the enrichment 
> query is performed again. Now I cannot see this log anymore and not 
> heatbridge/enrichment query is coming to AAI.
>  
> Hence my question: when is the entry responsible for the  enrichment query 
> created in CDAP? How can I re-create it?
> Thanks,
> David.
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Wednesday, February 7, 2018 6:45 AM
> To: Elie Dit Cosaque, David (Nokia - US/Irving) 
> <david.elie_dit_cosa...@nokia.com>
> Cc: onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] [DCAE][AAI][APPC][DMAAP] Help with 
> UEB-source-APPC-LCM-WRITE missing topic and heatbridge debugging
>  
> Have you mount the packet generator in APPC?
> Have you update the operational policy with the vnf-id?
>  
> Checkout the logs in drools to see what is happening.
>  
> Thanks,
> Alexis
> 
> 
> On Feb 6, 2018, at 10:01 AM, Elie Dit Cosaque, David (Nokia - US/Irving) 
> <david.elie_dit_cosa...@nokia.com <mailto:david.elie_dit_cosa...@nokia.com>> 
> wrote:
>  
> Hi Alexis, 
>  
> Thanks for the response. The robot script for heatbridge seems to have 
> completed successfully. I also looked at the robot output webpage for 
> heatbridge and it is all green (thanks for the ./demo.sh init_robot tip, I 
> used to do this manually). The problem is that The closed loop demo does not 
> seem to provide any feedback to the packet generator. The number of streams 
> stays always at 10.
> The debugging steps in the tutorial seems to be fine, I can see the events 
> from VES to TCA and from TCA. I was trying to trace the DCAE workflow to 
> understand the missing step in our deployment but I could not find more 
> information. Heatbridge seems to be a required step in the process so I 
> wanted to verify that it is working properly.
> Do you know what could be wrong? Do you have some debugging tips for closed 
> loop?
>  
> Thanks,
> David.
>  
>  
>  
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Tuesday, February 6, 2018 7:08 AM
> To: Elie Dit Cosaque, David (N

Re: [onap-discuss] Regarding the ONAP installation on rancher on kubernetes in openstack

2018-02-09 Thread Alexis de Talhouët
Hi Pranjal,

Please send mail to the mailing list rather than to me directly, so ppl can 
benefit the answers as well. Looping it in.

You can have rancher on one host, and kubernetes in another host, the is 
recommended.
When trying to add a K8S host through Rancher, you can either use an API call 
to do so, as explain in the wiki page 
https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+OpenStack#ONAPonKubernetesonRancherinOpenStack-KubernetesonRancher
 

 or you can create the host manually, then provision it with docker, and 
finally run the docker command the  that Rancher will provide you when clicking 
on “Add host” under the infrastructure tab / hosts.
See  "Copy, paste, and run the command below to register the host with 
Rancher:” (example: 
https://www.google.ca/search?q=Copy,+paste,+and+run+the+command+below+to+register+the+host+with+Rancher:=firefox-b-ab=0=lnms=isch=X=0ahUKEwjhzrGs9ZjZAhVr_IMKHUV7B5sQ_AUIDCgD=1417=921#imgrc=gTc1VIl6VGdofM:
 
)

Thanks,
Alexis

> On Feb 9, 2018, at 4:52 AM, Pranjal Dadhich  wrote:
> 
> Hi Alex,
> 
> I need your help regarding the installation steps of onap on rancher on 
> kubernetes in openstack:
> 
> - for installation right now, shall we use amsterdam release or latest 
> release.
> - i have 2 compute host machine, supposedly 192.168.30.14 and 192.168.30.17
> in that 30.14, i have create a VM (30.12) and installed openstack in that 
> 
> for rancher and kubernetes installation,  i want to install rancher in 30.14 
> host and kubernetes host in 30.17 due to some memory issue in 30.14.
> 
> is that possible for me, or else i have create rancher/kubernetes in the same 
> machine.
> 
> - I have a problem creating the kubernetes host showing the exit 1 error.
> 
> Do you have any idea on this.
> 
> 
> 
> Thanks and Regards,
> Pranjal Dadhich

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


Re: [onap-discuss] [OOM] restart an entire POD ?

2018-02-08 Thread Alexis de Talhouët
Re: Deterministic order

Guys, if we want deterministic order we should rely on Helm hook, in addition 
to readiness-probe / liveness probe.

I’ll let you have a look: 
https://github.com/kubernetes/helm/blob/master/docs/charts_hooks.md 
<https://github.com/kubernetes/helm/blob/master/docs/charts_hooks.md>

If you want an example, I have a patch using it: 
https://gerrit.onap.org/r/#/c/28347/ <https://gerrit.onap.org/r/#/c/28347/>

Alexis

> On Feb 8, 2018, at 2:26 AM, Borislav Glozman <borislav.gloz...@amdocs.com> 
> wrote:
> 
> Thanks.
> What is the correct order? We will take care of enforcing it.
>  
> Thanks,
> Borislav Glozman
> O:+972.9.776.1988
> M:+972.52.2835726
> 
> Amdocs a Platinum member of ONAP 
> <https://www.amdocs.com/open-network/nfv-powered-by-onap>
>  
> From: FREEMAN, BRIAN D [mailto:bf1...@att.com] 
> Sent: Wednesday, February 7, 2018 7:33 PM
> To: Borislav Glozman <borislav.gloz...@amdocs.com>; Mandeep Khinda 
> <mandeep.khi...@amdocs.com>; Alexis de Talhouët <adetalhoue...@gmail.com>
> Cc: onap-discuss@lists.onap.org
> Subject: RE: [onap-discuss] [OOM] restart an entire POD ?
>  
> AAI
>  
> Brian
>  
>  
> k8s_aai-service_aai-service-749944520-qqs7m_onap-aai_4e885d69-0c18-11e8-acd3-02f29cda8767_0
> k8s_aai-traversal_aai-traversal-140815912-xpmkn_onap-aai_4ebfdced-0c18-11e8-acd3-02f29cda8767_0
> k8s_aai-resources_aai-resources-4188957633-28fns_onap-aai_4e7ee05b-0c18-11e8-acd3-02f29cda8767_0
> k8s_data-router_data-router-3700447603-n4q2x_onap-aai_4ee40c1c-0c18-11e8-acd3-02f29cda8767_0
> k8s_model-loader-service_model-loader-service-911950978-2k6vz_onap-aai_4e945d5f-0c18-11e8-acd3-02f29cda8767_0
> k8s_elasticsearch_elasticsearch-622738319-5f71z_onap-aai_4f1ec5be-0c18-11e8-acd3-02f29cda8767_0
> k8s_search-data-service_search-data-service-2471976899-z2zxf_onap-aai_4ea070c4-0c18-11e8-acd3-02f29cda8767_0
> k8s_sparky-be_sparky-be-1779663793-z9qj5_onap-aai_4ea7cb7f-0c18-11e8-acd3-02f29cda8767_0
> k8s_hbase_hbase-3471984843-hg3pw_onap-aai_4e919e66-0c18-11e8-acd3-02f29cda8767_0
> k8s_esr-esrserver_esr-esrserver-1044617554-0hk2k_onap-esr_c12b3c4d-0ac6-11e8-acd3-02f29cda8767_0
> k8s_esr-esrgui_esr-esrgui-1816310556-lw69v_onap-esr_c1297dd7-0ac6-11e8-acd3-02f29cda8767_0
>  
>  
>  
>  
> -Original Message-
> From: Borislav Glozman [mailto:borislav.gloz...@amdocs.com 
> <mailto:borislav.gloz...@amdocs.com>] 
> Sent: Wednesday, February 07, 2018 10:46 AM
> To: FREEMAN, BRIAN D <bf1...@att.com <mailto:bf1...@att.com>>; Mandeep Khinda 
> <mandeep.khi...@amdocs.com <mailto:mandeep.khi...@amdocs.com>>; Alexis de 
> Talhouët <adetalhoue...@gmail.com <mailto:adetalhoue...@gmail.com>>
> Cc: onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> Subject: RE: [onap-discuss] [OOM] restart an entire POD ?
>  
> It is possible to define an order by using readinessCheck init container. It 
> is done in many places like sdc (although there are other problems there that 
> should be solved soon by SDC project)
>  
> Which component is 8 containers?
>  
>  
>  
> Thanks,
>  
> Borislav Glozman
>  
> O:+972.9.776.1988
>  
> M:+972.52.2835726
>  
>  
>  
> Amdocs a Platinum member of ONAP
>  
>  
>  
>  
>  
> -Original Message-----
>  
> From: FREEMAN, BRIAN D [mailto:bf1...@att.com <mailto:bf1...@att.com>]
>  
> Sent: Wednesday, February 7, 2018 5:43 PM
>  
> To: Borislav Glozman <borislav.gloz...@amdocs.com 
> <mailto:borislav.gloz...@amdocs.com>>; Mandeep Khinda 
> <mandeep.khi...@amdocs.com <mailto:mandeep.khi...@amdocs.com>>; Alexis de 
> Talhouët <adetalhoue...@gmail.com <mailto:adetalhoue...@gmail.com>>
>  
> Cc: onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
>  
> Subject: RE: [onap-discuss] [OOM] restart an entire POD ?
>  
>  
>  
> Agree and for simple components I do that. When there are 8 pods in a 
> component getting the order correct is important/a pain.
>  
>  
>  
> Brian
>  
>  
>  
>  
>  
> -Original Message-
>  
> From: Borislav Glozman [mailto:borislav.gloz...@amdocs.com 
> <mailto:borislav.gloz...@amdocs.com>]
>  
> Sent: Wednesday, February 07, 2018 10:41 AM
>  
> To: Mandeep Khinda <mandeep.khi...@amdocs.com 
> <mailto:mandeep.khi...@amdocs.com>>; FREEMAN, BRIAN D <bf1...@att.com 
> <mailto:bf1...@att.com>>; Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>>
>  
> Cc: onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
>  
> Subject: RE: [onap-discuss] [OOM] resta

Re: [onap-discuss] Help with DCAE Designate url authentication during dcae-controller DNS record creation - my creds/url combo is rejected

2018-02-07 Thread Alexis de Talhouët
Michael,

Regarding the arguments you had to change, those are specific per deployment, 
e.g. mine might not work for yours…

> Unable to create zone because another tenant owns a subzone of the zone

Are you using latest Amsterdam? Because that particular issue was fixed here: 
https://jira.onap.org/browse/OOM-615 <https://jira.onap.org/browse/OOM-615>

> ++ openstack zone create --email=o...@onap.org '--description=DNS zone 
> bridging DCAE and OOM' --type=PRIMARY simpledemo.onap.org. -f=yaml -c id

This let me think you’re not using latest.
 Please double check and migrate to use latest.

Thanks,
Alexis

> On Feb 7, 2018, at 10:36 AM, Michael O'Brien <frank.obr...@amdocs.com> wrote:
> 
> Alexis,
>   Getting a lot further - thanks
>   Retrofitted my environment with additional edits - we are aligned exactly 
> except for the 2 dcae keys, my domain and my user/pass
>   OPENSTACK_IMAGE to 16 NOT 14, DCAE_IP_ADDR 10.99.0.3 NOT 2
> 
>   As you mention I think we need a DNS collision strategy/workarounds for 
> multiple DCAE installs in the same tenant
> 
>   Q) how can I get Designate configured with the Logging project the way it 
> is for OOM - so I have that second Designate tenant id and we can coexist
>For now before you delete yours - I will experiment with creating a 
> different target simpledemo.obrien.onap.org - just to verify I can get the 
> VMs up for now.
>If you don't need your DCAE vms then you could also delete them to test 
> this.
> 
>   When I rerun I get the following DNS collision on your DCAE setup - I am 
> wondering if more than one DCAE setup can be configured - because our 
> recordset entries will both point to the same simpledemo.onap.org - make 
> sense we collide.
> 
> "Unable to create zone because another tenant owns a subzone of the zone"
> 
> 
> logs
> + EXISTING_ZONES='9rMR.simpledemo.onap.org.
> 9rMR.dcaeg2.adetalhouet.oom.amsterdam.onap.org.
> 4Xpi.simpledemo.onap.org.
> KfD9.simpledemo.onap.org.
> KfD9.dcaeg2.adetalhouet.oom.amsterdam.onap.org.
> Idp8.simpledemo.onap.org.
> Idp8.dcaeg2.adetalhouet.oom.amsterdam.onap.org.
> Phx4.simpledemo.onap.org.
> Phx4.dcaeg2.adetalhouet.oom.amsterdam.onap.org.'
> + [[ 9rMR.simpledemo.onap.org.
> 9rMR.dcaeg2.adetalhouet.oom.amsterdam.onap.org.
> 4Xpi.simpledemo.onap.org.
> KfD9.simpledemo.onap.org.
> KfD9.dcaeg2.adetalhouet.oom.amsterdam.onap.org.
> Idp8.simpledemo.onap.org.
> Idp8.dcaeg2.adetalhouet.oom.amsterdam.onap.org.
> Phx4.simpledemo.onap.org.
> Phx4.dcaeg2.adetalhouet.oom.amsterdam.onap.org. =~ 
> (^|[[:space:]])simpledemo.onap.org.($|[[:space:]]) ]]
> + echo 'Zone simpledemo.onap.org. doens'\''t exist, creating ...'
> Zone simpledemo.onap.org. doens't exist, creating ...
> ++ awk '{ print $2} '
> ++ openstack zone create --email=o...@onap.org '--description=DNS zone 
> bridging DCAE and OOM' --type=PRIMARY simpledemo.onap.org. -f=yaml -c id
> Unable to create zone because another tenant owns a subzone of the zone
> Create recordSet for simpledemo.onap.org.
> + SIMPLEDEMO_ONAP_ORG_ZONE_ID=
> + echo 'Create recordSet for simpledemo.onap.org.'
> + openstack recordset create --type=A --ttl=10 --records=10.12.6.150 vm1.aai
> usage: openstack recordset create [-h] [-f {json,shell,table,value,yaml}]
>  [-c COLUMN] [--max-width ]
>  [--fit-width] [--print-empty] [--noindent]
>  [--prefix PREFIX] --record RECORD --type
>  TYPE [--ttl TTL] [--description DESCRIPTION]
>  [--all-projects] [--edit-managed]
>      [--sudo-project-id SUDO_PROJECT_ID]
>  zone_id name
> openstack recordset create: error: too few arguments
> 
> 
> 
> 
> -Original Message-
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Wednesday, February 7, 2018 09:50
> To: Michael O'Brien <frank.obr...@amdocs.com>
> Cc: onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] Help with DCAE Designate url authentication 
> during dcae-controller DNS record creation - my creds/url combo is rejected
> 
> Michael,
> 
> Let me know if that works for you.
> Also, I can clear my deployment, or feel free to do so, if you want. I no 
> longer need it. That would free up some space.
> 
> Alexis
> 
>> On Feb 7, 2018, at 9:28 AM, Michael O'Brien <frank.obr...@amdocs.com> wrote:
>> 
>> Alexis,
>>  Sounds good, thanks for clearing this up with the tenant-designate required 
>> link.
>>  I was triaging different auth/url combinations directly in the container in 
>> both RC files and then retrof

Re: [onap-discuss] [OOM] restart an entire POD ?

2018-02-07 Thread Alexis de Talhouët
Hi Brian,

Those issues are tracked in JIRA already. Adding Mike that is looking at it (I 
think).

About your question, you cannot do this through K8S UI; at least, not that I’m 
aware of.
But using our scripts, you can delete and create a specific app.

For instance:
./oom/kubernetes/oneclick/deleteAll.sh -n onap -a aai <— will delete the whole 
AAI namespace (deployment and services)
./oom/kubernetes/oneclick/createAll.sh -n onap -a aai <— will create the whole 
AAI namespace (deployment and services)

I’m not sure this is what you’re after, but that’s how I do it when I need to 
bounce a whole application (e.g. all the containers of an app).

Alexis

> On Feb 7, 2018, at 9:34 AM, FREEMAN, BRIAN D  wrote:
> 
> Michael, Alexi,
> 
> I'm having race conditions when I use OOM in Azure where the health check 
> passes but distribution fails (MSO and AAI never get notified).
> 
> I restarted the SO front end POD and SO successfully picked up a model 
> distribution.
> 
> I tried to restart just the AAI Model loader but that didnt seem to work so I 
> need to restart all of AAI
> 
> I suspect that SO and AAI came up before DMaaP was up but cant confirm that.
> 
> Is there an easy / safe way to do restart an entire domain through the K8 
> portal ?
> 
> Feel free to point me at the right documentation on the wiki if I am just 
> missing that guidance.
> 
> Brian
> 
> ___
> 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] Help with DCAE Designate url authentication during dcae-controller DNS record creation - my creds/url combo is rejected

2018-02-07 Thread Alexis de Talhouët
Michael,

Let me know if that works for you.
Also, I can clear my deployment, or feel free to do so, if you want. I no 
longer need it. That would free up some space.

Alexis

> On Feb 7, 2018, at 9:28 AM, Michael O'Brien <frank.obr...@amdocs.com> wrote:
> 
> Alexis,
>   Sounds good, thanks for clearing this up with the tenant-designate required 
> link.
>   I was triaging different auth/url combinations directly in the container in 
> both RC files and then retrofitting them back out to onap-parameters.yaml in 
> a delete/create pod cycle to verify each.
>   Good to know it is config that can be fixed.
> 
>   I have a VM both in the OOM and Logging tenants - there is still enough 
> space for one more DCAE setup (96G) in the OOM tenant.
>   I will try to get my Logging tenant enabled for Designate as then I can 
> free up space on OOM.
> 
>   Retrying on my OOM VM now
> 
>   Differences
>   DNSAAS_API_VERSION is v3 not v2.0 anymore
>   DCAE_PROXIED_KEYSTONE_URL was supposed to my my OOM vm!
>   DCAE_OS_OAM_NETWORK_CIDR should have been 28 not 27
>   DCAE_DOMAIN was not specific enough added my LF id in the domain name
> 
>   And
>   DNSAAS_TENANT_ID is not the OOM or Logging tenant id - it is different - I 
> will need to get one of these to align with the Logging tenant as well right?
> 
> 
>   Thank you
> 
>   /michael
> 
> -Original Message-
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Wednesday, February 7, 2018 07:41
> To: Michael O'Brien <frank.obr...@amdocs.com>
> Cc: onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] Help with DCAE Designate url authentication 
> during dcae-controller DNS record creation - my creds/url combo is rejected
> 
> Michael,
> 
> The reason you’re not able to get authorization to the OpenStack providing 
> the DNS Designate is probably because of the tenantID you used. The lab has 
> two OpenStack, .2, where you create the workload and so on, and .5 providing 
> DNS Designate support. When configuring the DNAAS_* parameters, you need to 
> reference the information of .5; the tenant OOM is the same, but its ID is 
> different.
> 
> I don’t think you want someone’s DNS-openrc-v2.sh file, if it doesn’t work, 
> it means initial config is wrong (as highlighted above). This is 
> implementation details that user shouldn’t care about.
> 
> I’ll send you my onap-parameters.yaml for the OpenLab, for the OOM tenant, 
> privately.
> 
> Thanks,
> Alexis
> 
>> On Feb 7, 2018, at 12:43 AM, Michael O'Brien <frank.obr...@amdocs.com> wrote:
>> 
>> Team,
>>   Hi, I need your assistance for anyone bringing up DCAE in the intel lab.  
>> I am bringing up DCAEGEN2 via OOM using Alexis’ dcae-controller – I am 
>> having issues authenticating with designate in openlab.  There is no issue 
>> with the code, there are 2 installs of DCAE from the heat teamplate 
>> generated on the Kubernetes side – already in the lab.  My issue is the env 
>> parameters inside the amsterdam version of onap-parameters.yaml.
>> 
>>   My issue is with DNS record creation, I don’t think the DCAE creation will 
>> have an issue – because opensource commands work in side the container on 
>> this RC – but it is blocked by my designate config.
>> 
>>   So this goes out to anyone that is doing a manual or automated 
>> installation of OOM.
>>   The OOM Teams’ automated CD system is not yet configured to test 
>> DCAEGEN2 – hence the health numbers are always below 28/30 
>> http://jenkins.onap.info/job/oom-cd/
>> 
>> – I would like to fix this as well as get logs from the DCAE side.
>> 
>>   I am posting details of reproducing the dcae install in Alexis’ 
>> page 
>> https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+Open
>> Stack
>> 
>>   Issue:
>> 1)  When I source the DCAE rc – I am able to run openstack commands via 
>> the kubernetes dcae controller – as usual
>> 2)  But when I source the DNS rc – I get an authentication failure using 
>> the demo/onapdemo credentials
>> 
>> 
>> ubuntu@onap-oom-obrien:/dockerdata-nfs/onap/dcaegen2/heat$ sudo vi 
>> DNS-openrc-v2.sh
>> 
>> Eexport OS_AUTH_URL=http://10.12.25.5:5000/v2.0
>> export OS_AUTH_URL=http://10.12.25.2:5000/v2.0
>> export OS_TENANT_ID=a85a0...802c9fc50a7
>> export OS_TENANT_NAME=Logging
>> export OS_USERNAME=demo
>> export OS_PASSWORD=onapdemo
>> export OS_REGION_NAME=RegionOne
>> 
>> 
>> root@heat-bootstrap:/opt/heat# source DNS-openrc-v2.sh 
>> root@heat-bootstrap:/opt/heat# openstack recordset list The request 

Re: [onap-discuss] [DCAE][AAI][APPC][DMAAP] Help with UEB-source-APPC-LCM-WRITE missing topic and heatbridge debugging

2018-02-07 Thread Alexis de Talhouët
Have you mount the packet generator in APPC?
Have you update the operational policy with the vnf-id?

Checkout the logs in drools to see what is happening.

Thanks,
Alexis

> On Feb 6, 2018, at 10:01 AM, Elie Dit Cosaque, David (Nokia - US/Irving) 
> <david.elie_dit_cosa...@nokia.com> wrote:
> 
> Hi Alexis, 
>  
> Thanks for the response. The robot script for heatbridge seems to have 
> completed successfully. I also looked at the robot output webpage for 
> heatbridge and it is all green (thanks for the ./demo.sh init_robot tip, I 
> used to do this manually). The problem is that The closed loop demo does not 
> seem to provide any feedback to the packet generator. The number of streams 
> stays always at 10.
> The debugging steps in the tutorial seems to be fine, I can see the events 
> from VES to TCA and from TCA. I was trying to trace the DCAE workflow to 
> understand the missing step in our deployment but I could not find more 
> information. Heatbridge seems to be a required step in the process so I 
> wanted to verify that it is working properly.
> Do you know what could be wrong? Do you have some debugging tips for closed 
> loop?
>  
> Thanks,
> David.
>  
>  
>  
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Tuesday, February 6, 2018 7:08 AM
> To: Elie Dit Cosaque, David (Nokia - US/Irving) 
> <david.elie_dit_cosa...@nokia.com>
> Cc: onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] [DCAE][AAI][APPC][DMAAP] Help with 
> UEB-source-APPC-LCM-WRITE missing topic and heatbridge debugging
>  
> Hi, 
>  
> To debug heatbridge, or more generally, to debug any robot run, see point 8/9 
> here 
> https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+OpenStack 
> <https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+OpenStack>
>  
> Basically, use the goal ./demo.sh init_robot, this will let you configure the 
> access to a webpage that will provide all the logs of every robot run.
>  
> Regarding the error, it simply means no message was ever sent on the 
> APPC_LCM_WRITE topic, hence it hasn’t been created. I don’t see this as an 
> issue, but expert my have different opinion.
>  
> Regards,
> Alexis
> 
> 
> On Feb 5, 2018, at 7:39 PM, Elie Dit Cosaque, David (Nokia - US/Irving) 
> <david.elie_dit_cosa...@nokia.com <mailto:david.elie_dit_cosa...@nokia.com>> 
> wrote:
>  
> Hello All,
>  
> While trying to run the vFWCL demo, I encountered the error below. Has anyone 
> see this issue before? I followed the instructions at : 
> https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging
>  
> <https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging>
>  
>  
> ERROR in the policy VM, drool container in the file: 
> /opt/app/policy/logs/error.log:
> ---
> [2018-02-06 00:18:57,511|WARN|CambriaConsumerImpl|UEB-source-APPC-LCM-WRITE] 
> Topic not found: 
> /events/APPC-LCM-WRITE/e59c2ad7-da80-4362-aa04-3c7da7fb1eea/0?timeout=15000=100
> 
> I am also unsure how to debug issues with heatbridge. Is there a diagram 
> explaining how it fits in ONAP?
> Which containers are making queries to it? Is there a way to see/debug these 
> queries?
>  
> From the tutorial, I could verify successfully the following:
> Check the events sent by VES to TCA app
> Check the events sent by TCA on unauthenticated.DCAE_CL_OUTPUT (picked up by 
> APPC, amoung others)
>  
> Thanks,
> David.
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> https://lists.onap.org/mailman/listinfo/onap-discuss 
> <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] Help with DCAE Designate url authentication during dcae-controller DNS record creation - my creds/url combo is rejected

2018-02-07 Thread Alexis de Talhouët
Michael,

The reason you’re not able to get authorization to the OpenStack providing the 
DNS Designate is probably because of the tenantID you used. The lab has two 
OpenStack, .2, where you create the workload and so on, and .5 providing DNS 
Designate support. When configuring the DNAAS_* parameters, you need to 
reference the information of .5; the tenant OOM is the same, but its ID is 
different.

I don’t think you want someone’s DNS-openrc-v2.sh file, if it doesn’t work, it 
means initial config is wrong (as highlighted above). This is implementation 
details that user shouldn’t care about.

I’ll send you my onap-parameters.yaml for the OpenLab, for the OOM tenant, 
privately.

Thanks,
Alexis

> On Feb 7, 2018, at 12:43 AM, Michael O'Brien  wrote:
> 
> Team,
>Hi, I need your assistance for anyone bringing up DCAE in the intel lab.  
> I am bringing up DCAEGEN2 via OOM using Alexis’ dcae-controller – I am having 
> issues authenticating with designate in openlab.  There is no issue with the 
> code, there are 2 installs of DCAE from the heat teamplate generated on the 
> Kubernetes side – already in the lab.  My issue is the env parameters inside 
> the amsterdam version of onap-parameters.yaml.
>  
>My issue is with DNS record creation, I don’t think the DCAE creation will 
> have an issue – because opensource commands work in side the container on 
> this RC – but it is blocked by my designate config.
>   
>So this goes out to anyone that is doing a manual or automated 
> installation of OOM.
>The OOM Teams’ automated CD system is not yet configured to test DCAEGEN2 
> – hence the health numbers are always below 28/30
> http://jenkins.onap.info/job/oom-cd/
>  
> – I would like to fix this as well as get logs from the DCAE side.
>  
>I am posting details of reproducing the dcae install in Alexis’ page
> https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+OpenStack
>  
>Issue:
> 1)  When I source the DCAE rc – I am able to run openstack commands via 
> the kubernetes dcae controller – as usual
> 2)  But when I source the DNS rc – I get an authentication failure using 
> the demo/onapdemo credentials
>  
>  
> ubuntu@onap-oom-obrien:/dockerdata-nfs/onap/dcaegen2/heat$ sudo vi 
> DNS-openrc-v2.sh
>  
> Eexport OS_AUTH_URL=http://10.12.25.5:5000/v2.0
> export OS_AUTH_URL=http://10.12.25.2:5000/v2.0
> export OS_TENANT_ID=a85a0...802c9fc50a7
> export OS_TENANT_NAME=Logging
> export OS_USERNAME=demo
> export OS_PASSWORD=onapdemo
> export OS_REGION_NAME=RegionOne
>  
>  
> root@heat-bootstrap:/opt/heat# source DNS-openrc-v2.sh
> root@heat-bootstrap:/opt/heat# openstack recordset list
> The request you have made requires authentication. (HTTP 401) (Request-ID: 
> req-8d3619cb-d3e4-46d2-b923-6c0cd3df6598)
> ubuntu@onap-oom-obrien:~$ kubectl -n onap-dcaegen2 exec -it 
> heat-bootstrap-4010086101-8cdwz bash
> root@heat-bootstrap:/# cd /opt/heat   
>   
> 
> root@heat-bootstrap:/opt/heat# source DCAE-openrc-v2.sh
> root@heat-bootstrap:/opt/heat# openstack server list
> | 87569b68-cd4c-4a1f-9c6c-96ea7ce3d9b9 | onap-oom-obrien | ACTIVE | 
> oam_onap_w37L=10.0.16.1, 10.12.6.124   | ubuntu-16-04-cloud-amd64 
> | m1.xxlarge |
> | d80f35ac-1257-47fc-828e-dddc3604d3c1 | oom-jenkins | ACTIVE | 
> appc-multicloud-integration=10.10.5.14, 10.12.6.49 |  
> | v1.xlarge  |
>  
> 
> root@heat-bootstrap:/opt/heat# source DNS-openrc-v2.sh
> root@heat-bootstrap:/opt/heat# openstack server list  
> The request you have made requires authentication. (HTTP 401) (Request-ID: 
> req-82cfa5be-e351-49d0-bf87-18834c8affa0)
>  
>  
> The password/username for the pod25 Designate DNS as a Service - should be 
> demo/onapdemo
> ubuntu@onap-oom-obrien:/dockerdata-nfs/onap/dcaegen2/heat$ cat 
> DNS-openrc-v2.sh
> export OS_USERNAME="demo"
> export OS_PASSWORD="onapdemo"
>  
> I am not using multicloud proxying so the following url would not resolve 
> anyway for me (no instance) - I am using the regular keystone url - which 
> likely won't recognize the demo/onapdemo credentials
> http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_RegionOne/identity/v2.0
>  
>  
> If I set the user/pass to my tenant - then the DNS rc works for openstack 
> commands - testing to see if this will pass the dns record creation commands 
> now
> Q: could anyone pass me their DNS-openrc-v2.sh file from their 
> /dockerdata-nfs dir from their working Intel openlab environment so I can 
> compare them - I specifically would like to see the DNS keystone url
> thank you
>  
> DNSaaS references
> http://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/installation_heat.html#heat-template-parameters
> Alexis, original fix to parameterize the hardcoded user/pass to designate
> 

[onap-discuss] [Multicloud] Add VIM adapter

2018-02-06 Thread Alexis de Talhouët
Greetings multicloud experts,

I’d like to implement a new adapter to be able to create VNF and a new type of 
VIM. 
I was wondering if there is a document explaining how to do this? Are they some 
common APIs to implement? etc...

Please provide pointers, if possible, on how to proceed.

Also, if possible, can you quickly remind me how the multicloud adapter is 
hooked in SO so at instantiation time it uses a particular adapter.

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


Re: [onap-discuss] [DCAE][AAI][APPC][DMAAP] Help with UEB-source-APPC-LCM-WRITE missing topic and heatbridge debugging

2018-02-06 Thread Alexis de Talhouët
Hi, 

To debug heatbridge, or more generally, to debug any robot run, see point 8/9 
here 
https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+OpenStack 


Basically, use the goal ./demo.sh init_robot, this will let you configure the 
access to a webpage that will provide all the logs of every robot run.

Regarding the error, it simply means no message was ever sent on the 
APPC_LCM_WRITE topic, hence it hasn’t been created. I don’t see this as an 
issue, but expert my have different opinion.

Regards,
Alexis

> On Feb 5, 2018, at 7:39 PM, Elie Dit Cosaque, David (Nokia - US/Irving) 
>  wrote:
> 
> Hello All,
>  
> While trying to run the vFWCL demo, I encountered the error below. Has anyone 
> see this issue before? I followed the instructions at : 
> https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging
>  
> 
>  
>  
> ERROR in the policy VM, drool container in the file: 
> /opt/app/policy/logs/error.log:
> ---
> [2018-02-06 00:18:57,511|WARN|CambriaConsumerImpl|UEB-source-APPC-LCM-WRITE] 
> Topic not found: 
> /events/APPC-LCM-WRITE/e59c2ad7-da80-4362-aa04-3c7da7fb1eea/0?timeout=15000=100
> 
> I am also unsure how to debug issues with heatbridge. Is there a diagram 
> explaining how it fits in ONAP?
> Which containers are making queries to it? Is there a way to see/debug these 
> queries?
>  
> From the tutorial, I could verify successfully the following:
> Check the events sent by VES to TCA app
> Check the events sent by TCA on unauthenticated.DCAE_CL_OUTPUT (picked up by 
> APPC, amoung others)
>  
> Thanks,
> David.
> ___
> 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] [dmaap] Where to Get DMaaP Dockers?

2018-02-05 Thread Alexis de Talhouët
Hi,

It lives here: https://hub.docker.com/r/attos/dmaap/ 


Alexis

> On Feb 5, 2018, at 1:42 AM, fu.guangr...@zte.com.cn wrote:
> 
> Dear DMaaP Team,
> 
> 
> 
> We tried to locate DMaaP docker images in the ONAP release repo 
> (https://nexus3.onap.org/#browse/browse/components:docker.release 
> ) but 
> failed. Is the DMaaP docker still only available on GitHub?
> 
> 
> 
> Best Regards,
> 
> Guangrong
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Help: HEAT DCAE controller dcae2_vm_init.sh blueprint tasks failing - need a working DCAE config to compare to

2018-02-05 Thread Alexis de Talhouët
Michael,

Hard to follow everything you’re doing here, but I suggest we meet to discuss, 
if you want.

Alexis

> On Feb 4, 2018, at 6:15 PM, Michael O'Brien  wrote:
> 
> Update:
>Running Alexis’s expanded onap-parameters.yaml for amsterdam with all the 
> DCAE and heat settings for the Kubernetes side DCAE controller
>
> https://lists.onap.org/pipermail/onap-discuss/2018-February/007884.html 
> 
> https://jira.onap.org/browse/OOM-508  
> https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+OpenStack#ONAPonKubernetesonRancherinOpenStack-Deployingthedcaegen2pod
>  
> 
> Writing up specific config expansion to
> https://wiki.onap.org/display/DW/ONAP+on+Kubernetes#ONAPonKubernetes-AmsterdamOOM+DCAEHeatinstallation
>  
> 
>  
> triaging if there is a NodePort conflict – 
> https://jira.onap.org/browse/OOM-656 
> OOM-657 
> Verifying yaml
> Error: release onap-dcaegen2 failed: Service "dcaegen2" is invalid: 
> spec.ports[2]: Duplicate value: api.ServicePort{Name:"", Protocol:"TCP", 
> Port:8443, TargetPort:intstr.IntOrString{Type:0, IntVal:0, StrVal:""}, 
> NodePort:0}
>  
> /michael
>  
> From: Michael O'Brien 
> Sent: Sunday, February 4, 2018 00:00
> To: onap-discuss@lists.onap.org
> Subject: Help: HEAT DCAE controller dcae2_vm_init.sh blueprint tasks failing 
> - need a working DCAE config to compare to
>  
> Team,
>Goal: to get DCAEGEN2 running in HEAT on openlab – so I can get closed 
> loop logs/DMaaP traffic via the hybrid DCAE/HEAT + Kubernetes deployment and 
> prep for when we add a Filebeat container for the ELK stack to DCAE 
> containers.
>Issue: cannot get past dcae-bootstrap/opt/dcae2_vm_init.sh at the centos 
> blueprint tasks just before bringing up the consul VMs
>  
>Need your help.  There are a couple working DCAE orchestrations in HEAT 
> right now and several working closed loop installs on this group -  so if I 
> could get a copy of the values for the following that would be of great 
> assistance.  It looks like everything should be good as long as I am patient 
> (aai starts after 40 min) – holding up DCAE and make sure my env file is 
> exact.
>  
> I am following RTD and several wikis/jiras.  alexis.de_talho...@bell.ca 
>  has been providing a bridge between DCAE 
> and Kubernetes that I now need to dive more into since last being involved 
> with openstack late Nov. – starting on the heat side first.
> http://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/installation_heat.html#heat-template-parameters
>  
> 
> These are good instructions but they have some ambiguities – I will try to 
> add a troubleshooting section once I get an exact set of variables.
> 
> Right now I am just trying to get the HEAT stack up for Beijing and get 
> past cdap/consul orchestration.
> Got past the AAI_vm1 container creation/dependency issues by rebooting 
> the VM and then in sequence the DCAE controller VM.
> Initially had the double v2/v2.0 issue but a vi of the config in 
> /opt/config and /opt/config/app fixed this after an rm of the boot container 
> and a reboot of the DCAE vm.
> Got past the authentication 404 – but I have an issue with the keypair – 
> but the dcae private/public keys are set ok in /opt/config.
> This looks to be related to the generated key in 
> /opt/app/config/inputs.yaml:keypair
> I am going to go through the boot code in demo repo more
>  
> The 4 tasks are created, sent but fail
> I used to get a 404 on network creation until I removed the extra v2.0 from 
> keystone_url.
>  
> >docker tail –f boot
> Initiated ./blueprints/centos_vm.yaml
> If you make changes to the blueprint, run `cfy local init -p 
> ./blueprints/centos_vm.yaml` again to apply them
> + cfy local execute -w install --task-retries=10
> 2018-02-04 04:22:20 CFY  Starting 'install' workflow execution
> 2018-02-04 04:22:20 CFY  [private_net_9a5e7] Creating node
> 2018-02-04 04:22:20 CFY  [security_group_1cbe1] Creating node
> 2018-02-04 04:22:20 CFY  [key_pair_0dbec] Creating node
> 2018-02-04 04:22:20 CFY  [floatingip_vm00_18e89] Creating node
> 2018-02-04 04:22:20 CFY  [key_pair_0dbec.create] Sending task 
> 'nova_plugin.keypair.create'
> 2018-02-04 04:22:20 CFY  [security_group_1cbe1.create] Sending task 
> 'neutron_plugin.security_group.create'
> 2018-02-04 04:22:20 CFY  [floatingip_vm00_18e89.create] Sending task 
> 

Re: [onap-discuss] [E] Re: [oom] ONAP R1 | Unable to distribute models to AAI in OOM deployment

2018-01-31 Thread Alexis de Talhouët
Bharath,
Thanks, I think this is good for expert to help you, unfortunately, this is not 
something I can help with.
Seems to be something off with the files being ingested by SDC that AAI tries 
to import.
Alexis


> On Jan 31, 2018, at 9:56 AM, Thiruveedula, Bharath 
> <bharath.thiruveed...@verizon.com> wrote:
> 
> Hi Alexis,
> 
> I have attached the logs of AAI-ML. while distributing I can see one error 
> highlighted below:
> "
> ERROR   org.onap.aai.modelloader.entity.model.ModelArtifact
> RequestId=c8e05f3d-f43f-4c75-920a-d24ccaefa191 ServiceName=ModelLoader
> ServiceInstanceId= StartTime=2018-01-31T14:43:12.710Z ClientAddress= 
> PartnerName=Event-Bus  ServerFQDN=model-loader-service-1965047489-7dkw0   
> MDLSVC2002E|MDLSVC2002E Distribution event error: Ingestion failed for MODEL 
> 1c8299f2-de1b-4217-a77c-0be9522acc0d|4d199989-3de7-430c-9e07-16da50935ab7. 
> Rolling back distribution.|
> 
> Best Regards
> Bharath T
> 
> On Wed, Jan 31, 2018 at 6:40 PM, Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>> wrote:
> Hi,
> 
> Can you look at the logs of the model-loader component of AAI?
> 
> Thanks,
> Alexis
> 
>> On Jan 31, 2018, at 3:03 AM, Kumar Skand Priya, Viswanath V via onap-discuss 
>> <onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>> wrote:
>> 
>> Dear OOM Team,
>> 
>> We are powering ONAP R1 using OOM. While the installation is successful, we 
>> are facing issues while distributing a network service from SDC to AAI. 
>> 
>> PS : 
>> There are no issues with R1 standalone ONAP deployment ( via HOT files ).
>> Restarting AAI and/or redeploying PODs doesn't help.
>> 
>> Details about Error :
>> 
>> In OOM setup, after distributing the SDC model, we are getting  "deploy 
>> error" in AAI, which blocks the deployment of network service. Below are the 
>> screenshots:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Log from AAI-datarouter
>> 
>> 2018-01-30T07:44:53.722Z||main|DataRouter||org.onap.aai.datarouter.policy.EntityEventPolicy||ERROR|EEP012E|EEP012E
>>  Failed to create Search index topography-search-index due to: Error during 
>> GET operation to AAI with message = java.net.UnknownHostException: 
>> aai.searchservice.simpledemo.openecomp.org 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__aai.searchservice.simpledemo.openecomp.org_=DwMFAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=UTP8N06L2trD3jawJkElFfA6CQYtkCWzTnn4GsHkmJw=pE8QwbDjaNkuup9BTf6IyD_m28XAuk08wglK3quWHSc=DR3AWFS2Unxp3tOT8vgcoeOVr5-fP1W7qQAyEl33nM8=>
>>|
>> 2018-01-30T07:44:53.722Z||main|DataRouter||org.onap.aai.datarouter.policy.EntityEventPolicy||INFO|EEP0007I|EEP0007I
>>  Entity Event Policy component started.|
>> 2018-01-30T07:44:53.865Z||main|DataRouter||org.apache.camel.impl.converter.DefaultTypeConverter||WARN|Overriding
>>  type converter from: StaticMethodTypeConverter: public static 
>> java.io.InputStream 
>> org.apache.camel.component.http.HttpConverter.toInputStream(javax.servlet.http.HttpServletRequest,org.apache.camel.Exchange)
>>  throws java.io.IOException to: StaticMethodTypeConverter: public static 
>> java.io.InputStream 
>> org.apache.camel.component.http4.HttpConverter.toInputStream(javax.servlet.http.HttpServletRequest,org.apache.camel.Exchange)
>>  throws java.io.IOException
>> 2018-01-30T07:44:53.865Z||main|DataRouter||org.apache.camel.impl.converter.DefaultTypeConverter||WARN|Overriding
>>  type converter from: StaticMethodTypeConverter: public static 
>> javax.servlet.http.HttpServletResponse 
>> org.apache.camel.component.http.HttpConverter.toServletResponse(org.apache.camel.Message)
>>  to: StaticMethodTypeConverter: public static 
>> javax.servlet.http.HttpServletResponse 
>> org.apache.camel.component.http4.HttpConverter.toServletResponse(org.apache.camel.Message)
>> 2018-01-30T07:44:53.865Z||main|DataRouter||org.apache.camel.impl.converter.DefaultTypeConverter||WARN|Overriding
>>  type converter from: StaticMethodTypeConverter: public static 
>> javax.servlet.http.HttpServletRequest 
>> org.apache.camel.component.http.HttpConverter.toServletRequest(org.apache.camel.Message)
>>  to: StaticMethodTypeConverter: public static 
>> javax.servlet.http.HttpServletRequest 
>> org.apache.camel.component.http4.HttpConverter.toServletRequest(org.apache.camel.Message)
>> 2018-01-30T07:44:55.047Z||main|DataRouter||ajsc.ComputeService||ERROR|NMBS-COMPUTESVC-0042:
>>  addRoute for data-router:entity-event:v1 failed  - EXCEPTION: null
>> CAUSED BY: org.xml.sax.SA

Re: [onap-discuss] [E] [DCAGEN2] Proxied DNS Designate only with Multicloud Titanium

2018-01-31 Thread Alexis de Talhouët
; [31/Jan/2018 11:32:32] "GET 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/compute/v2.1/os-keypairs 
> HTTP/1.1" 200 5152
> [31/Jan/2018 11:32:32] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> [31/Jan/2018 11:32:33] "GET 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/network/v2.0/networks.json?name=provider-core-cmn-v4
>  HTTP/1.1" 200 654
> [31/Jan/2018 11:32:33] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/network/v2.0/floatingips.json
>  HTTP/1.1" 201 434
> [31/Jan/2018 11:32:34] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> [31/Jan/2018 11:32:34] "GET 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/network/v2.0/security-groups.json?name=onap_sg_MYGL
>  HTTP/1.1" 200 2628
> [31/Jan/2018 11:32:36] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> [31/Jan/2018 11:32:37] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/network/v2.0/ports.json 
> HTTP/1.1" 201 760
> [31/Jan/2018 11:32:38] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> [31/Jan/2018 11:32:38] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> [31/Jan/2018 11:35:55] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> [31/Jan/2018 11:35:55] "GET 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/network/v2.0/networks.json?name=oam_onap_MYGL
>  HTTP/1.1" 200 631
> [31/Jan/2018 11:35:56] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> [31/Jan/2018 11:35:56] "GET 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/network/v2.0/security-groups.json?name=onap_sg_MYGL
>  HTTP/1.1" 200 2628
> [31/Jan/2018 11:35:57] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> [31/Jan/2018 11:35:57] "GET 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/network/v2.0/networks.json?name=provider-core-cmn-v4
>  HTTP/1.1" 200 654
> [31/Jan/2018 11:35:58] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/network/v2.0/floatingips.json
>  HTTP/1.1" 201 434
> [31/Jan/2018 11:35:58] "GET 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0 HTTP/1.1" 200 
> 185
> [31/Jan/2018 11:35:58] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> [31/Jan/2018 11:35:59] "GET 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/compute/v2.1/os-keypairs 
> HTTP/1.1" 200 5152
> [31/Jan/2018 11:36:01] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> [31/Jan/2018 11:36:02] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/network/v2.0/ports.json 
> HTTP/1.1" 201 759
> [31/Jan/2018 11:36:02] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> [31/Jan/2018 11:36:03] "POST 
> /api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0/tokens 
> HTTP/1.1" 200 4481
> 
> 
> 
> from dcae2_vm_init.sh, it can access designate where as in boot container it 
> didn't send any request to designate.
> 
> Am I missing something here?
> 
> 
> 
> 
> On Wed, Jan 31, 2018 at 2:25 AM, Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>> wrote:
> Have you tried dcae_keystone_url = 
> http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0
>  
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.14.1_api_multicloud-2Dtitanium-5Fcloud_v0_pod25-5FregionOne_identity_v2.0=DwMFaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=UTP8N06L2trD3jawJkElFfA6CQYtkCWzTnn4GsHkmJw=yVUttGTl-Q6McKAsdtJZ3a2xYL5eCDrCAx36YI_USDA=0nYDovBOw68SXyeIgWKuj70Mi0tfqJHZdlp18cvw9SM=>
>   ?
> 
> 
>> On Jan 30, 2018, at 3:20 PM, Akula, Ramanjaneyul Reddy (Nokia - US/Irving) 
>> <ramanjaneyul_reddy.ak...@nokia.com 
>> <mailto:ramanjaneyul_reddy.ak...@nokia.com>> wrote:
>> 
>> Alex,
>> Thanks a lot for quick response.
>>  
>> Apologies. There is a typo due to copy paste error.
>>  
>> I meant the dcae_keystone is pointing to the openstack keystone endpoint url
>>   dcae_keystone_url: http://> <https://urld

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

2018-01-31 Thread Alexis de Talhouët
Marco,

Yes, that’s because you need to update manually the /etc/hosts of the 
vnc-portal to point to the new clusterIP of the SDC services.
This has been made dynamic in master, but not in amsterdam.

Thanks,
Alexis

> On Jan 31, 2018, at 9:09 AM, PLATANIA, MARCO (MARCO) 
> <plata...@research.att.com> wrote:
> 
> Alexis,
>  
> Another issue that I see after rebuilding SDC is that Portal cannot access 
> it. I received connection timeout when it tries to resolve 
> sdc.api.simpledemo.org <http://sdc.api.simpledemo.org/>. This SDC is healthy 
> and using dmaap.onap-message-router as UEB endpoint.
>  
> Marco
>  
> From: <onap-discuss-boun...@lists.onap.org> on behalf of Alexis de Talhouët 
> <adetalhoue...@gmail.com>
> Date: Wednesday, January 31, 2018 at 8:18 AM
> To: "Ramanarayanan, Karthick" <krama...@ciena.com>
> Cc: "onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] [**EXTERNAL**] Service distribution error on 
> latest ONAP/OOM
>  
> Hello Karthick, Brian 
>  
> I think, thanks to Marco, we have identified one piece of the problem.
> I guess you guys are running a K8S cluster. The way UEB is configured in SDC 
> is using the K8S hosts IPs, so DCAE service (when deployed), can reach it 
> when retrieving the config using the following request (replace K8S_HOST 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__k8s-5Fhost-3A30205_sdc_v1_distributionUebCluster=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=KgFIQiUJzSC0gUhJaQxg8eC3w16GC3sKgWIcs4iIee0=0obmGOdMa0pDqApFfYn5zOSu4_310axvnfuzekAGlDk=aNJLVdGEkzqCTJXXS94ZtGZsFmJKj-2iqUqKtw-kXsk=>
>  with one of your host ip):
>  
> curl -X GET \
>   http://K8S_HOST:30205/sdc/v1/distributionUebCluster 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__k8s-5Fhost-3A30205_sdc_v1_distributionUebCluster=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=KgFIQiUJzSC0gUhJaQxg8eC3w16GC3sKgWIcs4iIee0=0obmGOdMa0pDqApFfYn5zOSu4_310axvnfuzekAGlDk=aNJLVdGEkzqCTJXXS94ZtGZsFmJKj-2iqUqKtw-kXsk=>
>  \
>   -H 'Accept: application/json' \
>   -H 'Content-Type: application/json' \
>   -H 'X-ECOMP-InstanceID: mso' \
>   -H 'authorization: Basic 
> dmlkOktwOGJKNFNYc3pNMFdYbGhhazNlSGxjc2UyZ0F3ODR2YW9HR21KdlV5MlU=‘
>  
> I guess, if you try this request on the setup where it was failing before, 
> you’ll get the list where the first elements look ok, but the second one is 
> wrong, See https://jira.onap.org/browse/OOM-638 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_OOM-2D638=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=KgFIQiUJzSC0gUhJaQxg8eC3w16GC3sKgWIcs4iIee0=0obmGOdMa0pDqApFfYn5zOSu4_310axvnfuzekAGlDk=8cYV3C2xyccWXp5tlX3_h-rMbtVxWGa16tJirzl92zk=>
>  for more details.
> This has now been fix.
>  
> That said, it seems this is not it, and there is still something breaking SDC 
> UEB registration. 
>  
> Can you confirm you’re running in a K8S cluster?  I’m looking into this.
>  
> Alexis
> 
> 
>> On Jan 26, 2018, at 1:22 PM, Ramanarayanan, Karthick <krama...@ciena.com 
>> <mailto:krama...@ciena.com>> wrote:
>>  
>> The sdc-backend was always a suspect in my setup (56 core) and I invariably 
>> used to restart the backend pods to get the backend health checks to succeed:
>> curl http://127.0.0.1:30205/sdc2/rest/healthCheck 
>> <http://127.0.0.1:30205/sdc2/rest/healthCheck>
>>  
>> This returns "Service unavailable" when backend doesn't come up. If you 
>> restart the cassandra/es/kibana pods and then restart the backend, it would 
>> come up.
>>  
>> In my single node k8s host (k8s directly on the host as in my earlier runs),
>> I see health check component DE for backend failing. (distribution engine)
>>  
>> Everything else is up.
>>  
>> curl http://127.0.0.1:30205/sdc2/rest/healthCheck 
>> <http://127.0.0.1:30205/sdc2/rest/healthCheck>
>>  
>>  {
>>   "healthCheckComponent": "DE",
>>   "healthCheckStatus": "DOWN",
>>   "description": "U-EB cluster is not available"
>> },
>>  
>> This probably implies that in my setup, the UebServers list fetched in the 
>> backend catalog code before running the DistributionHealthCheck servers 
>> fetched from the distributionEngine configuration is not proper. (when 
>> running without dcae vm or dcae disabled)
>>  
>> This is probably the reason why distribution for service fails with policy 
>> exception.
>> Its not able to find the ueb server list perhaps when dcae is disabled.
>> Alexis would know best.
>>  
>> Regards,
>> -Karthick
>> From

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

2018-01-31 Thread Alexis de Talhouët
Ok, single instance should work fine now. It has been tested and is constantly 
being tested in the OpenLab.
Alexis

> On Jan 31, 2018, at 8:54 AM, FREEMAN, BRIAN D <bf1...@att.com> wrote:
> 
> Alexis,
> I am out of town but when I was trying the install on Friday last week it was 
> failing on a non-clustered instance. A single 64 GB VM. It was working before 
> Friday but cant say if it broke on thur or wed.
>  
> Brian
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Wednesday, January 31, 2018 8:19 AM
> To: Ramanarayanan, Karthick <krama...@ciena.com>
> Cc: FREEMAN, BRIAN D <bf1...@att.com>; onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] [**EXTERNAL**] Service distribution error on 
> latest ONAP/OOM
>  
> Hello Karthick, Brian
>  
> I think, thanks to Marco, we have identified one piece of the problem.
> I guess you guys are running a K8S cluster. The way UEB is configured in SDC 
> is using the K8S hosts IPs, so DCAE service (when deployed), can reach it 
> when retrieving the config using the following request (replace K8S_HOST 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__k8s-5Fhost-3A30205_sdc_v1_distributionUebCluster=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=t7ust0WtLxmmSq5SogWbBSttAmjVahwu4R1dDHM5HME=VhUBCSv2LdUaRcFDL9iM8CFSIyeluz78I4XP8eCpTCI=>
>  with one of your host ip):
>  
> curl -X GET \
>   http://K8S_HOST:30205/sdc/v1/distributionUebCluster 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__k8s-5Fhost-3A30205_sdc_v1_distributionUebCluster=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=t7ust0WtLxmmSq5SogWbBSttAmjVahwu4R1dDHM5HME=VhUBCSv2LdUaRcFDL9iM8CFSIyeluz78I4XP8eCpTCI=>
>  \
>   -H 'Accept: application/json' \
>   -H 'Content-Type: application/json' \
>   -H 'X-ECOMP-InstanceID: mso' \
>   -H 'authorization: Basic 
> dmlkOktwOGJKNFNYc3pNMFdYbGhhazNlSGxjc2UyZ0F3ODR2YW9HR21KdlV5MlU=‘
>  
> I guess, if you try this request on the setup where it was failing before, 
> you’ll get the list where the first elements look ok, but the second one is 
> wrong, See https://jira.onap.org/browse/OOM-638 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_OOM-2D638=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=t7ust0WtLxmmSq5SogWbBSttAmjVahwu4R1dDHM5HME=EVe5pnnzkMgWl1LNlpyeDyfSj0g9zXT-RqnSixqIBco=>
>  for more details.
> This has now been fix.
>  
> That said, it seems this is not it, and there is still something breaking SDC 
> UEB registration. 
>  
> Can you confirm you’re running in a K8S cluster?  I’m looking into this.
>  
> Alexis
> 
> 
> On Jan 26, 2018, at 1:22 PM, Ramanarayanan, Karthick <krama...@ciena.com 
> <mailto:krama...@ciena.com>> wrote:
>  
> The sdc-backend was always a suspect in my setup (56 core) and I invariably 
> used to restart the backend pods to get the backend health checks to succeed:
> curl http://127.0.0.1:30205/sdc2/rest/healthCheck 
> <http://127.0.0.1:30205/sdc2/rest/healthCheck>
>  
> This returns "Service unavailable" when backend doesn't come up. If you 
> restart the cassandra/es/kibana pods and then restart the backend, it would 
> come up.
>  
> In my single node k8s host (k8s directly on the host as in my earlier runs),
> I see health check component DE for backend failing. (distribution engine)
>  
> Everything else is up.
>  
> curl http://127.0.0.1:30205/sdc2/rest/healthCheck 
> <http://127.0.0.1:30205/sdc2/rest/healthCheck>
>  
>  {
>   "healthCheckComponent": "DE",
>   "healthCheckStatus": "DOWN",
>   "description": "U-EB cluster is not available"
> },
>  
> This probably implies that in my setup, the UebServers list fetched in the 
> backend catalog code before running the DistributionHealthCheck servers 
> fetched from the distributionEngine configuration is not proper. (when 
> running without dcae vm or dcae disabled)
>  
> This is probably the reason why distribution for service fails with policy 
> exception.
> Its not able to find the ueb server list perhaps when dcae is disabled.
> Alexis would know best.
>  
> Regards,
> -Karthick
> From: FREEMAN, BRIAN D <bf1...@att.com <mailto:bf1...@att.com>>
> Sent: Friday, January 26, 2018 9:52:24 AM
> To: Alexis de Talhouët; Ramanarayanan, Karthick
> Cc: onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> Subject: RE: [onap-discuss] [**EXTERNAL**] Service distribution error on 
> latest ONAP/OOM
>  
> Alexi,
> 
> 
> 
> I cant get OOM install to work today (it was working yesterday) - seems to 
> fail on sdc - doesnt

Re: [onap-discuss] [oom] Question on DCAE deployment using OOM

2018-01-31 Thread Alexis de Talhouët
Hi,

Let’s clarify one thing, OOM is the medium to deploy ONAP. DCAE doesn’t provide 
a way to be deployed in Kubernetes for now, hence OOM is not able to do this.

What OOM does is create the HEAT stack in OpenStack, HEAT stack that will 
create a VM running the dcae-boostrap container, which will then deploy the 
whole DCAE. OOM has created a wrapper on top of this so one can seamlessly 
deploy ONAP using OOM, as it’s done with HEAT. Please see the attachment here: 
https://jira.onap.org/browse/OOM-508  
explaining the implementation.

DCAE team and OOM team are working together to see how we can migrate DCAE 
components into Kubernetes deployment/services.  That work is still in 
progress, and I don’t have a clear view of the timeline for completion. Until 
this is done, ONAP will still requires a VIM to deploy DCAE.

Thanks,
Alexis


> On Jan 31, 2018, at 2:17 AM, Kumar Skand Priya, Viswanath V via onap-discuss 
>  wrote:
> 
> Dear OOM Team,
> 
> We found that, even-though OOM deploys DCAE bootstrap container inside a POD, 
> the bootstrap container in-turn deploys other DCAE components as VMs in 
> underlying VIM ( openstack ).
> 
> Would like to know, why doesn't entire DCAE run under kubern8s mode? and also 
> what's the story of DCAE's LCM with OOM, since some parts of DCAE are still 
> in VM mode ?
> 
> BR,
> Viswa
> 
>  
> 
> Viswanath Kumar Skand Priya
> Architect
> Verizon India ( VDSI )
> 
>  <>___
> 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] [oom] ONAP R1 | Unable to distribute models to AAI in OOM deployment

2018-01-31 Thread Alexis de Talhouët
Hi,

Can you look at the logs of the model-loader component of AAI?

Thanks,
Alexis

> On Jan 31, 2018, at 3:03 AM, Kumar Skand Priya, Viswanath V via onap-discuss 
>  wrote:
> 
> Dear OOM Team,
> 
> We are powering ONAP R1 using OOM. While the installation is successful, we 
> are facing issues while distributing a network service from SDC to AAI. 
> 
> PS : 
> There are no issues with R1 standalone ONAP deployment ( via HOT files ).
> Restarting AAI and/or redeploying PODs doesn't help.
> 
> Details about Error :
> 
> In OOM setup, after distributing the SDC model, we are getting  "deploy 
> error" in AAI, which blocks the deployment of network service. Below are the 
> screenshots:
> 
> 
> 
> 
> 
> 
> 
> Log from AAI-datarouter
> 
> 2018-01-30T07:44:53.722Z||main|DataRouter||org.onap.aai.datarouter.policy.EntityEventPolicy||ERROR|EEP012E|EEP012E
>  Failed to create Search index topography-search-index due to: Error during 
> GET operation to AAI with message = java.net.UnknownHostException: 
> aai.searchservice.simpledemo.openecomp.org 
>    |
> 2018-01-30T07:44:53.722Z||main|DataRouter||org.onap.aai.datarouter.policy.EntityEventPolicy||INFO|EEP0007I|EEP0007I
>  Entity Event Policy component started.|
> 2018-01-30T07:44:53.865Z||main|DataRouter||org.apache.camel.impl.converter.DefaultTypeConverter||WARN|Overriding
>  type converter from: StaticMethodTypeConverter: public static 
> java.io.InputStream 
> org.apache.camel.component.http.HttpConverter.toInputStream(javax.servlet.http.HttpServletRequest,org.apache.camel.Exchange)
>  throws java.io.IOException to: StaticMethodTypeConverter: public static 
> java.io.InputStream 
> org.apache.camel.component.http4.HttpConverter.toInputStream(javax.servlet.http.HttpServletRequest,org.apache.camel.Exchange)
>  throws java.io.IOException
> 2018-01-30T07:44:53.865Z||main|DataRouter||org.apache.camel.impl.converter.DefaultTypeConverter||WARN|Overriding
>  type converter from: StaticMethodTypeConverter: public static 
> javax.servlet.http.HttpServletResponse 
> org.apache.camel.component.http.HttpConverter.toServletResponse(org.apache.camel.Message)
>  to: StaticMethodTypeConverter: public static 
> javax.servlet.http.HttpServletResponse 
> org.apache.camel.component.http4.HttpConverter.toServletResponse(org.apache.camel.Message)
> 2018-01-30T07:44:53.865Z||main|DataRouter||org.apache.camel.impl.converter.DefaultTypeConverter||WARN|Overriding
>  type converter from: StaticMethodTypeConverter: public static 
> javax.servlet.http.HttpServletRequest 
> org.apache.camel.component.http.HttpConverter.toServletRequest(org.apache.camel.Message)
>  to: StaticMethodTypeConverter: public static 
> javax.servlet.http.HttpServletRequest 
> org.apache.camel.component.http4.HttpConverter.toServletRequest(org.apache.camel.Message)
> 2018-01-30T07:44:55.047Z||main|DataRouter||ajsc.ComputeService||ERROR|NMBS-COMPUTESVC-0042:
>  addRoute for data-router:entity-event:v1 failed  - EXCEPTION: null
> CAUSED BY: org.xml.sax.SAXParseException; lineNumber: 2; columnNumber: 109; 
> Element type "from" must be followed by either attribute specifications, ">" 
> or "/>".
> STACKTRACE: at 
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl(createUnmarshalException:578)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl(unmarshal0:264)
> at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl(unmarshal:229)
> at ajsc.ComputeService(getRouteDefinition:793)
> at ajsc.ComputeService$getRouteDefinition$3(callCurrent:-1)
> at ajsc.ComputeService(addRoute:820)
> at ajsc.ComputeService$_init_closure15(doCall:970)
> at ajsc.ComputeService(init:970)
> at ajsc.ComputeService$init(call:-1)
> at ajsc.RouteMgmtService(init:148)
> at ajsc.RouteMgmtService$init$0(call:-1)
> at ajsc.ContextMgr(onApplicationEvent:19)
> at 
> org.springframework.context.event.SimpleApplicationEventMulticaster(invokeListener:163)
> at 
> org.springframework.context.event.SimpleApplicationEventMulticaster(multicastEvent:136)
> at 
> org.springframework.context.support.AbstractApplicationContext(publishEvent:381)
> at 
> org.springframework.context.support.AbstractApplicationContext(publishEvent:335)
> at 
> org.springframework.context.support.AbstractApplicationContext(finishRefresh:855)
> at org.springframework.context.support.AbstractApplicationContext(refresh:541)
> at 
> org.springframework.web.context.ContextLoader(configureAndRefreshWebApplicationContext:444)
> at org.eclipse.jetty.server.handler.ContextHandler(startContext:791)
> at org.eclipse.jetty.servlet.ServletContextHandler(startContext:294)
> at org.eclipse.jetty.webapp.WebAppContext(startWebapp:1349)
> at org.eclipse.jetty.webapp.WebAppContext(startContext:1342)
> at org.eclipse.jetty.server.handler.ContextHandler(doStart:741)
> at org.eclipse.jetty.webapp.WebAppContext(doStart:505)
> at org.eclipse.jetty.util.component.AbstractLifeCycle(start:68)
> at 

Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with Multicloud Titanium

2018-01-30 Thread Alexis de Talhouët
Have you tried dcae_keystone_url = 
http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0 
<http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0>
  ?

> On Jan 30, 2018, at 3:20 PM, Akula, Ramanjaneyul Reddy (Nokia - US/Irving) 
> <ramanjaneyul_reddy.ak...@nokia.com> wrote:
> 
> Alex,
> Thanks a lot for quick response.
>  
> Apologies. There is a typo due to copy paste error.
>  
> I meant the dcae_keystone is pointing to the openstack keystone endpoint url
>   dcae_keystone_url: http:// public keystone 
> ip>:5000 
>  
> Here is the content from bootstrat config files
>  
> 
> root@dcae-dcae-bootstrap:/opt# cat /opt/config/dnsaas_keystone_url.txt
> http:///identity
> root@dcae-dcae-bootstrap:/opt#
>  
> 
>  
> dcae2_vm_init.sh:DNSAAS_SERVICE_URL="$(cat 
> /opt/config/dnsaas_keystone_url.txt)"
> 
>  
> 
> cat keystone_url.txt
> http:// endpoint IP>:5000/v2.0
> 
> 
>  
> root@dcae-dcae-bootstrap:/opt/config# cat openstack_keystone_url.txt
> http:// endpoint IP>:5000
> 
>  
> From your statement è
> When creating a VM using a proxied DNS Designate, the dcae_keystone_url 
> _must_ leverage the multicloud-titanium cloud driver, e.g. in your case 
> dcae_keystone_url = 
> http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0
>  
> <http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0>.
>  
>  
> I believe you meant to do this registration in AAI so that it will leverage 
> the titanium drivier.
> And the init script already has the logic to register the multicloud pod with 
> aai using above said url.
>  
> =
> CLOUD_IDENTITY_URL="http://${MCIP}/api/multicloud-titanium_cloud/v0/${CLOUD_OWNER}_${CLOUD_REGION}/identity/v2.0
>  
> <http://${mcip}/api/multicloud-titanium_cloud/v0/$%7BCLOUD_OWNER%7D_$%7BCLOUD_REGION%7D/identity/v2.0>"
> =
>  
> Or am I interpreting you wrongly?
>  
> best regards,
> Ramu
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Tuesday, January 30, 2018 1:23 PM
> To: Akula, Ramanjaneyul Reddy (Nokia - US/Irving) 
> <ramanjaneyul_reddy.ak...@nokia.com>
> Cc: Yang, Bin <bin.y...@windriver.com>; onap-discuss 
> <onap-discuss@lists.onap.org>; Bisht, Suraj (Nokia - US/Irving) 
> <suraj.bi...@nokia.com>; Talari Nehemiah Vara, Vara (Nokia - US/Irving) 
> <vara.talari_nehemiah_v...@nokia.com>
> Subject: Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with 
> Multicloud Titanium
>  
> Ramu,
>  
> You’re confusing things.
> 
> dcae_keystone_url is the keystone of the openstack where you will deploy DCAE
> dnsaas_keystone_url is the keystone of the openstack providing DNS Designate 
> support
> 
> When creating a VM using a proxied DNS Designate, the dcae_keystone_url 
> _must_ leverage the multicloud-titanium cloud driver, e.g. in your case 
> dcae_keystone_url = 
> http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0
>  
> <http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0>.
>  
> This is because cloudify will create the resources for the VM to be created 
> using the dcae_keystone_url. Among other things, this will create the record 
> in the DNS zone. This is possible because the multicloud-titanium leverage 
> AAI ESR information to know that for a particular cloud-site (identified by 
> the dcae_keystone_url) it should be using another site that provides 
> Designate support (dns-delegate)
>  
> See cloud-extra-info, e.g.
> {
>   "epa-caps": {
> "huge_page": "true",
> "cpu_pinning": "true",
> "cpu_thread_policy": "true",
> "numa_aware": "true",
> "sriov": "true",
> "dpdk_vswitch": "true",
> "rdt": "false",
> "numa_locality_pci": "true"
>   },
>   "dns-delegate": {
> "cloud-owner": "pod25dns",
> "cloud-region-id": "RegionOne"
>   }
> }
>  
>  
> Alexis
> 
> 
> On Jan 30, 2018, at 2:07 PM, Akula, Ramanjaneyul Reddy (Nokia - US/Irving) 
> <ramanjaneyul_reddy.ak...@nokia.com 
> <mailto:ramanjaneyul_reddy.ak...@nokia.com>> wrote:
> 
> Hi Alexis,
> Thanks for the response.
>  
> I’m using below params in my env f

Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with Multicloud Titanium

2018-01-30 Thread Alexis de Talhouët
Ramu,

You’re confusing things.

dcae_keystone_url is the keystone of the openstack where you will deploy DCAE
dnsaas_keystone_url is the keystone of the openstack providing DNS Designate 
support

When creating a VM using a proxied DNS Designate, the dcae_keystone_url _must_ 
leverage the multicloud-titanium cloud driver, e.g. in your case 
dcae_keystone_url = 
http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0 
<http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0>.
 
This is because cloudify will create the resources for the VM to be created 
using the dcae_keystone_url. Among other things, this will create the record in 
the DNS zone. This is possible because the multicloud-titanium leverage AAI ESR 
information to know that for a particular cloud-site (identified by the 
dcae_keystone_url) it should be using another site that provides Designate 
support (dns-delegate)

See cloud-extra-info, e.g.
{
  "epa-caps": {
"huge_page": "true",
"cpu_pinning": "true",
"cpu_thread_policy": "true",
"numa_aware": "true",
"sriov": "true",
"dpdk_vswitch": "true",
"rdt": "false",
"numa_locality_pci": "true"
  },
  "dns-delegate": {
"cloud-owner": "pod25dns",
"cloud-region-id": "RegionOne"
  }
}


Alexis

> On Jan 30, 2018, at 2:07 PM, Akula, Ramanjaneyul Reddy (Nokia - US/Irving) 
> <ramanjaneyul_reddy.ak...@nokia.com> wrote:
> 
> Hi Alexis,
> Thanks for the response.
>  
> I’m using below params in my env file while creating the heat stack.
>  
> ===
> dnsaas_config_enabled: true
>   dnsaas_region: regionOne
>   dnsaas_keystone_url: http:///identity
>   dnsaas_tenant_name: admin
>   dnsaas_username: admin
>   dnsaas_password: password
>   dcae_keystone_url: http://:5000 
> ===
>  
> To try it out, I changed the dnsaas_keystone_url.txt file on bootstrap and 
> tried to kick start the vm init script.
>  
> Changed file content 
>  
> root@dcae-dcae-bootstrap:~#  cat /opt/config/dnsaas_keystone_url.txt
> http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0
> root@dcae-dcae-bootstrap:~#
> 
>  
> I’m getting the same error as earlier.
>  
> By the way with/without this change, on the designate instance I see the dns 
> zone getting created + recordset is being added. It means I believe it’s able 
> to talk to Designate successfully.
>  
> ubuntu@designate:~/devstack$ openstack recordset list 
> 122ffabf-0268-41b1-a3d7-fed5ca4e2366
> +--+-+--++++
> | id   | name| type | records 
>| status | 
> action |
> +--+-+--++++
> | 14b0c34e-c88e-4ead-81b0-fe7f1c8d6679 | wJOo.dcae.onap.org. | NS   | 
> ns1.devstack.org.  | 
> ACTIVE | NONE   |
> | f95281a1-f97c-4beb-a7cc-777d860c | wJOo.dcae.onap.org. | SOA  | 
> ns1.devstack.org. lji.research.att.com. 1517329561 3565 600 86400 3600 | 
> ACTIVE | NONE   |
> +--+-+--++++
>  
>  
> best regards,
> Ramu
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Tuesday, January 30, 2018 10:47 AM
> To: Akula, Ramanjaneyul Reddy (Nokia - US/Irving) 
> <ramanjaneyul_reddy.ak...@nokia.com>
> Cc: Yang, Bin <bin.y...@windriver.com>; onap-discuss 
> <onap-discuss@lists.onap.org>; Bisht, Suraj (Nokia - US/Irving) 
> <suraj.bi...@nokia.com>; Talari Nehemiah Vara, Vara (Nokia - US/Irving) 
> <vara.talari_nehemiah_v...@nokia.com>
> Subject: Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with 
> Multicloud Titanium
>  
> Ramu,
>  
> What did you use for DCAE_PROXIED_KEYSTONE_URL parameter? It must be the 
> proxied url. See 
> https://github.com/onap/oom/blob/amsterdam/kubernetes/config/onap-parameters-sample.yaml#L143-L144
>  
> Hope this helps,
> Alexis
> 
> 
> On Jan 30, 2018, at 11:27 AM, Akula, Ramanjaneyul Reddy (Nokia - US/Irving) 
> <ramanjaneyul_reddy.ak...@nokia.com> wrote:
>  
> Hi Alex/Bin,

Re: [onap-discuss] Help with gerrit messages to rerun JobBuilder for example - on demand

2018-01-30 Thread Alexis de Talhouët
Michael,

Default JJB templates provide keyword, such as:
- patch submited: recheck
- patch merged: remerge

etc….

This is define in the trigger macro, here: 
https://github.com/onap/ci-management/blob/master/jjb/global-macros.yaml#L343 
 
or here 
https://github.com/onap/ci-management/blob/master/jjb/global-macros.yaml#L362 


I think every job is using those macros, hence you can use recheck/remerge on 
any patch in gerrit.

HTH,
Alexis

> On Jan 30, 2018, at 12:11 PM, Michael O'Brien  wrote:
> 
> Team,
>Need your help, I saw a message about a week ago on keywords you can put 
> into a gerrit review to do things like rerun the Jobbuilder without waiting 
> for an actual commit trigger to do it – on demand.
>  
> A rerun without a trigger for
> https://jenkins.onap.org/view/logging-analytics/job/logging-analytics-master-verify-java/3/
>  
> 
> to align with
> https://jenkins.onap.org/view/logging-analytics/job/logging-analytics-master-verify-java/5/
>  
> 
>  
>Where putting something like “rebuild” in the gerrit comment – would rerun 
> the Jenkins JobBuilder for that particular review
>For example we have committer that put in a change just before the 
> JobBuilder framework was finished – it failed but now passes In another 
> merged review – In another commit I would just push some changes with a
>  
> Git commit –amend
> Git review –R
> https://wiki.onap.org/display/DW/Development+Procedures+and+Policies#DevelopmentProceduresandPolicies-CommittingCode
>  
> 
>  
>But I would like to kick off a build for another developer on his review 
> without doing an amend
>Thank you
>/michael
>  
>  
>  
> Michael O’Brien
> Amdocs Technology
> 16135955268
> 55268
> 
>  
> 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 
> 
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with Multicloud Titanium

2018-01-30 Thread Alexis de Talhouët
Ramu,

What did you use for DCAE_PROXIED_KEYSTONE_URL parameter? It must be the 
proxied url. See 
https://github.com/onap/oom/blob/amsterdam/kubernetes/config/onap-parameters-sample.yaml#L143-L144
 
<https://github.com/onap/oom/blob/amsterdam/kubernetes/config/onap-parameters-sample.yaml#L143-L144>

Hope this helps,
Alexis

> On Jan 30, 2018, at 11:27 AM, Akula, Ramanjaneyul Reddy (Nokia - US/Irving) 
> <ramanjaneyul_reddy.ak...@nokia.com> wrote:
> 
> Hi Alex/Bin,
> I’m also witnessing the same problem in my cloud.
> My cloud is built using RedHat OSP10 (Newton).
>  
> Bottstrap log has below info.
>  
> 2018-01-30 16:00:51 CFY  [security_group_38d63] Configuring node
> 2018-01-30 16:00:51 CFY  [private_net_85fe3] Configuring node
> 2018-01-30 16:00:51 CFY  [key_pair_31e7f] Configuring node
> 2018-01-30 16:00:51 CFY  [floatingip_vm00_474ed] Configuring node
> 2018-01-30 16:00:51 CFY  [key_pair_31e7f] Starting node
> 2018-01-30 16:00:51 CFY  [private_net_85fe3] Starting node
> 2018-01-30 16:00:51 CFY  [security_group_38d63] Starting node
> 2018-01-30 16:00:51 CFY  [floatingip_vm00_474ed] Starting node
> 2018-01-30 16:00:52 CFY  [fixedip_vm00_b112a] Creating node
> 2018-01-30 16:00:52 CFY  [dns_cm_3211b] Creating node
> 2018-01-30 16:00:52 CFY  [dns_vm00_3cba2] Creating node
> 2018-01-30 16:00:52 CFY  [dns_cm_3211b.create] Sending task 
> 'dnsdesig.dns_plugin.aneeded'
> 2018-01-30 16:00:52 CFY  [dns_vm00_3cba2.create] Sending task 
> 'dnsdesig.dns_plugin.aneeded'
> 2018-01-30 16:00:52 CFY  [fixedip_vm00_b112a.create] Sending task 
> 'neutron_plugin.port.create'
> 2018-01-30 16:00:52 CFY  [dns_cm_3211b.create] Task started 
> 'dnsdesig.dns_plugin.aneeded'
> 2018-01-30 16:00:52 CFY  [dns_vm00_3cba2.create] Task started 
> 'dnsdesig.dns_plugin.aneeded'
> 2018-01-30 16:00:52 CFY  [dns_cm_3211b.create] Task failed 
> 'dnsdesig.dns_plugin.aneeded' -> 'dns'
> 2018-01-30 16:00:52 CFY  'install' workflow execution failed: Workflow 
> failed: Task failed 'dnsdesig.dns_plugin.aneeded' -> 'dns'
>  
> My AAI is already populated with both the pods info as shown below
>  
> ===
> {
> "cloud-region": [
> {
> "cloud-owner": "pod25",
> "cloud-region-id": "regionOne",
> "cloud-type": "openstack",
> "owner-defined-type": "owner-defined-type",
> "cloud-region-version": "titanium_cloud",
> "identity-url": 
> "http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0
>  
> <http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0>",
> "cloud-zone": "cloud zone",
> "complex-name": "complex name",
> "resource-version": "1517257340971"
> },
> {
> "cloud-owner": "pod25dns",
> "cloud-region-id": "regionOne",
> "cloud-type": "openstack",
> "owner-defined-type": "owner-defined-type",
> "cloud-region-version": "titanium_cloud",
> "identity-url": 
> "http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25dns_regionOne/identity/v2.0
>  
> <http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25dns_regionOne/identity/v2.0>",
> "cloud-zone": "cloud zone",
> "complex-name": "complex name2",
> "resource-version": "1517257341850"
> }
> ]
> }
> ===
>  
>  
> And on designate I see the new zone getting created.
>  
> Appreciate any hints/clues on how to overcome this problem.
>  
>  
>  
> best regards,
> Ramu
>  
>  
> From: onap-discuss-boun...@lists.onap.org 
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët
> Sent: Friday, January 19, 2018 1:08 PM
> To: Yang, Bin <bin.y...@windriver.com>
> Cc: onap-discuss <onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with 
> Multicloud Titanium
>  
> Ah, I missed the fact that when it’s proxied, dcae_keystone_url needs to be 
> the one from multivim. All good now.
>  
> Alexis
>  
> 
> 
> On Jan 19, 2018, at 11:05 AM, Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>> wrote:
>  
> Hum, actually, the DNS zone registration works. But now, the boot 

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

2018-01-26 Thread Alexis de Talhouët
Karthick,

I’ve just re-tested on latest Amsterdam, and distribute does work fine.

I don’t know if you have redeploy the whole ONAP or not, but understand that 
the issue you had with distribution not working was an issue
impacting so aai and sdc. 
The reason is, sdc is configured with the ueb cluster ip address (dmaap, the 
message bus basically), and the way ueb is configured in sdc is using
external access to dmaap, using the k8s node ip instead of the internal 
networking of k8s (e.g. dmaap.onap-message-router).
This change was done recently to accommodate DCAEGEN2 service-change-handler 
micro-service that has to connect to dmaap.
sdc has an api so one can retrieve the ueb cluster ips, 
/sdc/v1/distributionUebCluster, and all the consumer of sdc distribute are 
using the sdc-distribution-client application,
provided by sdc, that retrieves the ueb cluster ips using the api mentioned 
before. Hence when the DCAE micro service was retrieving the ips of the ueb 
cluster, and that one
was configured using k8s networking (dmaap.onap-message-router), the micro 
service was unable to resolve this; that’s why I changed it to the k8s node ip, 
that has to be resolvable
by the DCAE’s VMs.

Hope that clarifies a little bit what happen, and explain why I recommand you 
to re-deploy the whole onap by doing the following:

- In oom/kubernetes/oneclick: ./deleteAll.sh -n onap
- In the k8s nodes, rm -rf /dockerdata-nfs
- In oom/kubernetes/config: ./createConfig.sh -n onap
- In oom/kubernetes/oneclick: ./createAll.sh -n onap

This should take no longer than 15mn as you already have the docker images in 
your k8s hosts.

Alexis

> On Jan 25, 2018, at 8:17 PM, Ramanarayanan, Karthick <krama...@ciena.com> 
> wrote:
> 
> 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 <adetalhoue...@gmail.com>
> 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 <krama...@ciena.com> 
>> 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 <adetalhoue...@gmail.com>
>> 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 <krama...@ciena.com> 
>>> wrote:
>>> 
>>> Hi Alexis,
>>>  I reverted the oom commit from head to:
>>> 
>>> git checkout cb02aa241edd97acb6c5ca744de84313f53e8a5a
>>> 
>>> Author: yuryn <yury.novit...@amdocs.com>
>>> Date:   Thu Dec 21 14:31:21 2017 +0200
>>> 
>>> Fix firefox tab crashes in VNC
>>> 
>>> Change-Id: Ie295257d98ddf32693309535e15c6ad9529f10fc
>>> Issue-ID: OOM-531
>>> 
>>> 
>>> Every

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

2018-01-25 Thread 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 <adetalhoue...@gmail.com> 
> wrote:
> 
> Just put up a fix for this: https://gerrit.onap.org/r/#/c/29209/ 
> <https://gerrit.onap.org/r/#/c/29209/> Trying it now.
> 
>> On Jan 25, 2018, at 2:13 PM, Alexis de Talhouët <adetalhoue...@gmail.com 
>> <mailto:adetalhoue...@gmail.com>> wrote:
>> 
>> This is tracked by https://jira.onap.org/browse/OOM-611 
>> <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 <jh1...@att.com 
>>> <mailto:jh1...@att.com>> 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> 
>>> [mailto: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 <mailto: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://$ 
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__-24=DwQFAw=LFYZ-o9_HUMeMTSQicvjIg=AOclne09odx6cmeimzFUhQ=Bd5eoa3uty8tqL8D1Fb0okmmu11-xtxLkLjCshykLdc=WCU7ohmqRfVOzWP7sz-1iJpYWrm20PbhK4fXhDV_v-Y=>{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 <mailto:onap-discuss@lists.onap.org>
>>> https://lists.onap.org/mailman/listinfo/onap-discuss 
>>> <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

2018-01-25 Thread 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 <adetalhoue...@gmail.com> 
> wrote:
> 
> This is tracked by https://jira.onap.org/browse/OOM-611 
> <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 <jh1...@att.com 
>> <mailto:jh1...@att.com>> 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> 
>> [mailto: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 <mailto: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://$ 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__-24=DwQFAw=LFYZ-o9_HUMeMTSQicvjIg=AOclne09odx6cmeimzFUhQ=Bd5eoa3uty8tqL8D1Fb0okmmu11-xtxLkLjCshykLdc=WCU7ohmqRfVOzWP7sz-1iJpYWrm20PbhK4fXhDV_v-Y=>{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 <mailto:onap-discuss@lists.onap.org>
>> https://lists.onap.org/mailman/listinfo/onap-discuss 
>> <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

2018-01-25 Thread 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] [OpenLab] OOM deployment results

2018-01-25 Thread 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 
<http://10.12.25.2/project/instances/c8a2a6cb--4ae1-a23d-7f9827fa5481/> VM 
and restart the service-change-handler container.

Thanks,
Alexis

> On Jan 25, 2018, at 7:49 AM, Alexis de Talhouët <adetalhoue...@gmail.com> 
> 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 <gary.i...@huawei.com 
>> <mailto:gary.i...@huawei.com>> wrote:
>> 
>> OOM deployment results from today:
>>  
>> Besides a minor issue that I worked around for now 
>> (https://gerrit.onap.org/r/#/c/29071/ 
>> <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 
>> <mailto:adetalhoue...@gmail.com>] 
>> Sent: Wednesday, January 24, 2018 8:48 AM
>> To: onap-discuss <onap-discuss@lists.onap.org 
>> <mailto:onap-discuss@lists.onap.org>>; Gary Wu <gary.i...@huawei.com 
>> <mailto:gary.i...@huawei.com>>
>> Subject: Re: [OpenLab] DNS Designate zone for simpledemo.onap.org 
>> <http://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 <http://simpledemo.onap.org/> hosts (aai, 
>> msb, sdc, policy), OOM creates a simpledemo.onap.org 
>> <http://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 <http://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/ 
>> <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 <adetalhoue...@gmail.com 
>> <mailto:adetalhoue...@gmail.co

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

2018-01-25 Thread 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 <bin.y...@windriver.com> wrote:
> 
> Hi Alexis, <>
>  
> You’d better prefix it with a random string similar to what DCAE does: 
> w6VA.dcaeg2.onap.org <http://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 
> <http://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 <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 <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 <mailto: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 
> <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 <http://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 
> <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 <mailto:email=o...@onap.org> 
> '--description=DNS zone bridging DCAE and OOM' --type=PRIMARY 
> simpledemo.onap.org <http://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

2018-01-25 Thread 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 <gary.i...@huawei.com> wrote:
> 
> OOM deployment results from today:
>  
> Besides a minor issue that I worked around for now 
> (https://gerrit.onap.org/r/#/c/29071/ 
> <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 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Wednesday, January 24, 2018 8:48 AM
> To: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>; Gary Wu <gary.i...@huawei.com 
> <mailto:gary.i...@huawei.com>>
> Subject: Re: [OpenLab] DNS Designate zone for simpledemo.onap.org 
> <http://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 <http://simpledemo.onap.org/> hosts (aai, 
> msb, sdc, policy), OOM creates a simpledemo.onap.org 
> <http://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 <http://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/ 
> <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 <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>> 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 <mailto:email=o...@onap.org> 
> '--description=DNS zone bridging DCAE and OOM' --type=PRIMARY 
> simpledemo.onap.org <http://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] [OOM] inter-module instantiate dependencies

2018-01-24 Thread Alexis de Talhouët
Ticket for the robot issue: https://jira.onap.org/browse/OOM-618

But I think it should be a Robot ticket.

> On Jan 24, 2018, at 2:20 PM, FREEMAN, BRIAN D <bf1...@att.com> wrote:
> 
> On the chrome driver.
>  
> I think I worked around it by installing an alternate chrome version in the 
> container.
> Using part of a fix that Gary has in integration – basically using the 2.32 
> version instead of the version in the container.
>  
> Brian
>  
>  
> # install chrome driver
> if [ ! -x ${ROBOT_VENV}/bin/chromedriver ]; then
> pushd ${ROBOT_VENV}/bin
> wget -N 
> http://chromedriver.storage.googleapis.com/2.32/chromedriver_linux64.zip 
> <http://chromedriver.storage.googleapis.com/2.32/chromedriver_linux64.zip>
> unzip chromedriver_linux64.zip
> chmod +x chromedriver
> popd
> fi
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Wednesday, January 24, 2018 2:10 PM
> To: FREEMAN, BRIAN D <bf1...@att.com>
> Cc: onap-discuss <onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] [OOM] inter-module instantiate dependencies
>  
> Thank Brian for trying OOM and helping improving it! I guess this is on 
> Amsterdam?
> I opened bugs to track this, see inline. for questions.
>  
> Thanks
> Alexis
> 
> 
> On Jan 24, 2018, at 1:50 PM, FREEMAN, BRIAN D <bf1...@att.com 
> <mailto:bf1...@att.com>> wrote:
>  
> Started to confirm functionality with OOM Amsterdam.
>  
> I think these are already being tracked but wanted to confirm with OOM team.
>  
> Model distribution from SDC fails to SO and SDNC on a fresh install.
> SO’s ASDC Adapter tries to communicate with SDC-BE before its up.
>i.  Delete 
> of the SO pod and K8 automated restart clears the problem – redistribute 
> works so it seems like a timing problem that SO should not be started till 
> SDC-BEis up.
>  
> AdT: https://jira.onap.org/browse/OOM-616 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_OOM-2D616=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=0q6hZVTaqZ7d33E8pEaugboYHfjCjI_0rYPNo91TCCU=ltLOv2wp22VQOG-weLJjQaTkLwj7PIWg9r1vpdXkuTc=>
> 
> 
> SDNC ueb-listener tries to communicate with SDC-BE before its up.
>i.  Delete 
> of the ueb-listener pod and K8 automated restart clears the problem – 
> redistribute works so it seems like a timing problem that ueb-listener/SDNC 
> should not be started till SDC is up.
>  
> AdT: https://jira.onap.org/browse/OOM-617 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_OOM-2D617=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=0q6hZVTaqZ7d33E8pEaugboYHfjCjI_0rYPNo91TCCU=oAqDwtrHbRogu8ZA7K1KcOSZkmdzDX9Y-4fs0x0OdX0=>
> 
> 
> Agree there should be automated retry in listeners on boot but in Amsterdam 
> that does not seem to be there.
>  
> AdT: It’s ok, we can have deterministic startup with K8S. We can check for a 
> given port to be open.
> 
> 
>  
> AAF does not come up and delays the install by 10+ minutes
> I assume we can take AAF out of the config and not try to start it.
> I would think for Amsterdam that might need to be the default
>  
> AdT: As far as I know, AAF never worked for OOM on Amsterdam. Always failed 
> with `Error: Could not find or load main class 
> org.onap.aaf.authz.service.AuthAPI`
>  
> Robot had a problem with the chrome driver when trying to instantiate (and 
> probably other flows) – is there a fix ?
> WebDriverException: Message: unknown error: an X display is required for 
> keycode conversions, consider using Xvfb (Session info: headless 
> chrome=63.0.3239.132) (Driver info: chromedriver=2.29.461571
>  
>  
> AdT: Is this specific to OOM? 
> 
> 
>  
>  
> Brian
>  
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> https://lists.onap.org/mailman/listinfo/onap-discuss 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=0q6hZVTaqZ7d33E8pEaugboYHfjCjI_0rYPNo91TCCU=rHqg85CQ5FyJN75nqHsgWBLC6vcn_orisGfehj8iHJs=>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] [OOM] inter-module instantiate dependencies

2018-01-24 Thread Alexis de Talhouët
Thank Brian for trying OOM and helping improving it! I guess this is on 
Amsterdam?
I opened bugs to track this, see inline. for questions.

Thanks
Alexis

> On Jan 24, 2018, at 1:50 PM, FREEMAN, BRIAN D  wrote:
> 
> Started to confirm functionality with OOM Amsterdam.
>  
> I think these are already being tracked but wanted to confirm with OOM team.
>  
> Model distribution from SDC fails to SO and SDNC on a fresh install.
> SO’s ASDC Adapter tries to communicate with SDC-BE before its up.
>i.  Delete 
> of the SO pod and K8 automated restart clears the problem – redistribute 
> works so it seems like a timing problem that SO should not be started till 
> SDC-BEis up.

AdT: https://jira.onap.org/browse/OOM-616

> SDNC ueb-listener tries to communicate with SDC-BE before its up.
>i.  Delete 
> of the ueb-listener pod and K8 automated restart clears the problem – 
> redistribute works so it seems like a timing problem that ueb-listener/SDNC 
> should not be started till SDC is up.

AdT: https://jira.onap.org/browse/OOM-617

> Agree there should be automated retry in listeners on boot but in Amsterdam 
> that does not seem to be there.

AdT: It’s ok, we can have deterministic startup with K8S. We can check for a 
given port to be open.

> AAF does not come up and delays the install by 10+ minutes
> I assume we can take AAF out of the config and not try to start it.
> I would think for Amsterdam that might need to be the default

AdT: As far as I know, AAF never worked for OOM on Amsterdam. Always failed 
with `Error: Could not find or load main class 
org.onap.aaf.authz.service.AuthAPI`

> Robot had a problem with the chrome driver when trying to instantiate (and 
> probably other flows) – is there a fix ?
> WebDriverException: Message: unknown error: an X display is required for 
> keycode conversions, consider using Xvfb (Session info: headless 
> chrome=63.0.3239.132) (Driver info: chromedriver=2.29.461571
>  

AdT: Is this specific to OOM? 

>  
>  
> Brian
>  
> ___
> 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] [OOM][MSB] issues on services auto-discovery

2018-01-24 Thread Alexis de Talhouët
Hi,

Some answers/question inline.

Alexis

> On Jan 24, 2018, at 11:40 AM, HU, JUN NICOLAS  wrote:
> 
> Hi,
>  
> We deployed an OOM amsterdam 
> 
>  release. We installed all the containers a K8s cluster with 6 nodes hosts.
>  
> [centos@server-k8s6nodes-kubernetes-master-host-7qcfy4 ~]$ kubectl get nodes
> NAME STATUSAGE   VERSION
> server-k8s6nodes-kubernetes-master-host-7qcfy4   Ready 1dv1.7.4
> server-k8s6nodes-kubernetes-node-host-2sy3xz Ready 1dv1.7.4
> server-k8s6nodes-kubernetes-node-host-7rptcz Ready 1dv1.7.4
> server-k8s6nodes-kubernetes-node-host-8aaw03 Ready 1dv1.7.4
> server-k8s6nodes-kubernetes-node-host-b39rfm Ready 1dv1.7.4
> server-k8s6nodes-kubernetes-node-host-kvx3b8 Ready 1dv1.7.4
> server-k8s6nodes-kubernetes-node-host-w52ffi Ready 1dv1.7.4
>  
> Here is the running pods
>  
> [centos@server-k8s6nodes-kubernetes-master-host-7qcfy4 ~]$ kubectl get pod 
> --all-namespaces
> NAMESPACE NAME
>  READY STATUSRESTARTS   AGE
> kube-system   etcd-server-k8s6nodes-kubernetes-master-host-7qcfy4 
>  1/1   Running   2  1d
> kube-system   
> kube-apiserver-server-k8s6nodes-kubernetes-master-host-7qcfy41/1  
>  Running   0  1d
> kube-system   
> kube-controller-manager-server-k8s6nodes-kubernetes-master-host-7qcfy4   1/1  
>  Running   2  1d
> kube-system   kube-dns-2425271678-5724j   
>  3/3   Running   0  1d
> kube-system   kube-proxy-6lwp7
>  1/1   Running   0  1d
> kube-system   kube-proxy-bgvd6
>  1/1   Running   0  1d
> kube-system   kube-proxy-dtmfz
>  1/1   Running   0  1d
> kube-system   kube-proxy-dtql9
>  1/1   Running   0  1d
> kube-system   kube-proxy-t1pjw
>  1/1   Running   0  1d
> kube-system   kube-proxy-thjnr
>  1/1   Running   0  1d
> kube-system   kube-proxy-w8rjb
>  1/1   Running   0  1d
> kube-system   
> kube-scheduler-server-k8s6nodes-kubernetes-master-host-7qcfy41/1  
>  Running   3  1d
> kube-system   tiller-deploy-3206783038-5ldb1  
>  1/1   Running   0  1d
> kube-system   weave-net-178n1 
>  2/2   Running   6  1d
> kube-system   weave-net-31nf1 
>  2/2   Running   6  1d
> kube-system   weave-net-dl2qk 
>  2/2   Running   6  1d
> kube-system   weave-net-f88nv 
>  2/2   Running   6  1d
> kube-system   weave-net-fzs8t 
>  2/2   Running   6  1d
> kube-system   weave-net-lc965 
>  2/2   Running   7  1d
> kube-system   weave-net-vhj9x 
>  2/2   Running   7  1d
> onap-aaf  aaf-1993711932-m4d07
>  0/1   Running   0  1d
> onap-aaf  aaf-cs-1310404376-ptm73 
>  1/1   Running   0  1d
> onap-aai  aai-resources-2269342809-bd2gm  
>  2/2   Running   0  1d
> onap-aai  aai-service-749944520-1rt0l 
>  1/1   Running   0  1d
> onap-aai  aai-traversal-8423740-31htm 
>  2/2   Running   0  1d
> onap-aai  data-router-3434587794-pm2z0
>  1/1   Running   0  1d
> onap-aai  elasticsearch-622738319-k590c   
>  1/1   Running   0  1d
> onap-aai  hbase-1949550546-8f612   

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

2018-01-24 Thread Alexis de Talhouët
Ah, actually, I might be able to re-use the random-str that was used by DCAE 
for their DNS zone. Looking into this now.

> On Jan 24, 2018, at 11:48 AM, Alexis de Talhouët <adetalhoue...@gmail.com> 
> wrote:
> 
> 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 <http://simpledemo.onap.org/> hosts (aai, 
> msb, sdc, policy), OOM creates a simpledemo.onap.org 
> <http://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 <http://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/ <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 <adetalhoue...@gmail.com 
>> <mailto:adetalhoue...@gmail.com>> 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 <mailto:email=o...@onap.org> 
>> '--description=DNS zone bridging DCAE and OOM' --type=PRIMARY 
>> simpledemo.onap.org <http://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] DNS Designate zone for simpledemo.onap.org

2018-01-24 Thread Alexis de Talhouët
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 <adetalhoue...@gmail.com> 
> 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 <mailto:email=o...@onap.org> 
> '--description=DNS zone bridging DCAE and OOM' --type=PRIMARY 
> simpledemo.onap.org <http://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] [OpenLab] DNS Designate zone for simpledemo.onap.org

2018-01-24 Thread Alexis de Talhouët
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] [OOM] DCAE config in windriver

2018-01-24 Thread Alexis de Talhouët
Gary,

Have you properly configured those parameters in the onap-parameters.yaml file:

DNSAAS_API_VERSION: ""
DNSAAS_REGION: ""
DNSAAS_KEYSTONE_URL: ""
DNSAAS_TENANT_ID: ""
DNSAAS_TENANT_NAME: ""
DNSAAS_USERNAME: ""
DNSAAS_PASSWORD: “"

Those need to reflect the OpenStack instance providing DNS Designate. The 
OpenLab is configured so the tenant names are replicated, but the tenant ID is 
not the same. Please double check this. OpenLab has two instances. 
http://10.12.25.2 on which you deploy ONAP, and http://10.12.25.5 providing DNS 
Designate support. To get your tenant id for a given tenant name, log in the 
http://10.12.25.5 instance.

Based on those variables, we will setup the DNS-openrc-v2.sh 
<https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/docker/init/src/config/dcaegen2/heat/DNS-openrc-v2.sh;h=9c9e3f06346b32e6a6cdc7e8e53ddcc90b3e5399;hb=refs/heads/amsterdam>
 and DNS-openrc-v3.sh 
<https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/docker/init/src/config/dcaegen2/heat/DNS-openrc-v3.sh;h=eebf8357e1fa6e55b2ff83c60bc775a69b9b16ad;hb=refs/heads/amsterdam>
 files to be used to authenticate to the OpenStack (see line 156 
<https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/docker/init/src/config/dcaegen2/heat/entrypoint.sh;h=bbf47a9bac6b98e6bd52ae3e8af309816097464a;hb=refs/heads/amsterdam>),
 enabling the pod to use the openstack cli instead of multicloud. I understand 
this is by-passing the multicloud apis, but it was easier for me to set this 
up. Any contribution to change this is welcome :) But my hope is, this will go 
away when OOM will provide DNS Designate itself (see OOM-588 
<https://jira.onap.org/browse/OOM-588>) so ppl won’t have to provide it in 
their infra.

I have tested this in OpenLab, under the OOM tenant, it can authenticate fine. 
The issue is, I’m facing this issue now:

++ openstack zone create --email=o...@onap.org '--description=DNS zone bridging 
DCAE and OOM' --type=PRIMARY simpledemo.onap.org. -f=yaml -c id
Zone simpledemo.onap.org. doens't exist, creating ...
++ awk '{ print $2} '
Unable to create zone because another tenant owns a subzone of the zone

Regarding the `sed: can’t read /opt/robot/vm_properties.py: No such file or 
directory`, thanks for reporting this, it’s an oversight, sorry about that. 
Working on too many things at the same time. Fix here: 
https://gerrit.onap.org/r/#/c/29039/

Regarding the robot log, you can use the init_robot tag that let you then 
browse the robot logs through the browser at http://:30209/logs/ I 
didn’t know ppl where going in the persisted data. But probably I should revert 
this change to persist the logs again.

Thanks,
Alexis

> On Jan 24, 2018, at 10:42 AM, Gary Wu <gary.i...@huawei.com> wrote:
> 
> Sorry, one more thing:  since yesterday I can no longer retrieve the robot 
> test logs from /dockerdata-nfs/onap/robot/eteshare/logs/.  Not sure if this 
> is related either.
>  
> Thanks,
> Gary
>  
> From: Gary Wu 
> Sent: Tuesday, January 23, 2018 6:13 PM
> To: 'Alexis de Talhouët' <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>>
> Cc: 'BRIAN D FREEMAN' <bf1...@att.com <mailto:bf1...@att.com>>; 'PLATANIA, 
> MARCO (MARCO)' <plata...@research.att.com 
> <mailto:plata...@research.att.com>>; 'onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>' <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: RE: [onap-discuss] [OOM] DCAE config in windriver
>  
> Incidentally I’m also getting this error from entrypoint.sh; not sure if it’s 
> related to this set of changes:
>  
> sed: can’t read /opt/robot/vm_properties.py: No such file or directory
>  
> Thanks,
> Gary
>  
> From: Gary Wu 
> Sent: Tuesday, January 23, 2018 4:41 PM
> To: 'Alexis de Talhouët' <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>>
> Cc: BRIAN D FREEMAN <bf1...@att.com <mailto:bf1...@att.com>>; PLATANIA, MARCO 
> (MARCO) <plata...@research.att.com <mailto:plata...@research.att.com>>; 
> onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> Subject: RE: [onap-discuss] [OOM] DCAE config in windriver
>  
> Hi Alexis,
>  
> Despite having DNS_PROXY_ENABLE turned on, I’m observing the following:
>  
> dcaegen2/heat/entrypoint.sh repeatedly tries to configure Designate directly 
> via “openstack recordset” commands and failing with authentication errors.  
> Is this supposed to be happening?  The multicloud proxy endpoint seems to be 
> properly configured in onap_dcae.env, but this endpoint doesn’t seem to be 
> used by entrypoint.sh so I’m not sure how the DNS record requests are 
> supposed to get 

Re: [onap-discuss] [AAI][SO] How to add another LCP Region

2018-01-24 Thread Alexis de Talhouët
Ah, that would be because of this patch: https://gerrit.onap.org/r/#/c/28591/

As cd.sh is not checked-in OOM, it is difficult for me to maintain it when an 
modification is occurring.

@Michael, should we submit this to OOM?

Alexis

> On Jan 23, 2018, at 5:05 PM, FREEMAN, BRIAN D <bf1...@att.com> wrote:
> 
> I think this issue was the format of onap_parameters.yaml changed.
>  
>  
> I re-edited the onap_parameters_sample.yaml and used that and it at least got 
> past the k8 init phase.
>  
>  
> Brian
>  
>  
> From: FREEMAN, BRIAN D 
> Sent: Tuesday, January 23, 2018 3:56 PM
> To: Alexis de Talhouët <adetalhoue...@gmail.com>
> Cc: onap-discuss <onap-discuss@lists.onap.org>
> Subject: RE: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
> That’s Michael’s continuouse deployment script.
>  
> It was working fine now I seem to have broken it.
>  
> Brian
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Tuesday, January 23, 2018 3:54 PM
> To: FREEMAN, BRIAN D <bf1...@att.com <mailto:bf1...@att.com>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
> Brian,
>  
> I’m not familiar with the cd.sh script.
>  
> Alexis
>  
> 
> On Jan 23, 2018, at 12:53 PM, FREEMAN, BRIAN D <bf1...@att.com 
> <mailto:bf1...@att.com>> wrote:
>  
> OK – I’ll try later. For some reason cd.sh got stuck “waiting for config pod 
> to complete” ?
>  
> Do I need to update my version of cd.sh ?
>  
> Brian
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Tuesday, January 23, 2018 11:48 AM
> To: FREEMAN, BRIAN D <bf1...@att.com <mailto:bf1...@att.com>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
> Brian, no it’s not merged yet.
>  
> It has been Code-Review +2 and Verified +1, but not submitted yet. It’s 
> dependent on some other patch I was testing. I just found my missing piece. 
> Expect this to be merge by 1pm.
>  
> Thanks for testing, though :)
>  
> Thanks, 
> Alexis
> 
> 
> 
> On Jan 23, 2018, at 11:37 AM, FREEMAN, BRIAN D <bf1...@att.com 
> <mailto:bf1...@att.com>> wrote:
>  
> I think it was merged today (in parallel with your email I suspect).
>  
> Trying an cd.sh install now on -b amsterdam to see.
>  
> Brian
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Tuesday, January 23, 2018 11:28 AM
> To: FREEMAN, BRIAN D <bf1...@att.com <mailto:bf1...@att.com>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
>  
> 
> 
> 
> 
> On Jan 10, 2018, at 5:56 PM, FREEMAN, BRIAN D <bf1...@att.com 
> <mailto:bf1...@att.com>> wrote:
>  
> Robot did not work – trying to patch/work around to use it and it partially 
> succeed – could be amsterdam vs master issue
> Tried to run robot distribute and the heat templates were missing
> Used the following:
>i.  Cd 
> /dockerdata-nfs/onap/
>  ii.  Git 
> clone http://gerrit.onap.org/r/demo 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__gerrit.onap.org_r_demo=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=o3Vg65e8bgfkPRtjuz5eDNYufb41yNfuAyjRaK4bftI=D-8_FXY0_QYgowq65_4Z9CWQaQZopUGFiCjMcYjKxOg=>
>iii.  Cd demo
>iv.  cp -rf 
> heat ../robot/eteshare
>  v.  this put 
> the heat/vFW etc into the heat directory.
> After this distribute seems to work partially
>i.  ROBOT 
> fails after partially distributing looking for 6 thing and getting 5 – not 
> sure what that error is but the models do seem to be distributed to AAI and 
> SO from the SDC GUI perspective
>  
>  
> Brian, the fix for this is now out: https://gerrit.onap.org/r/#/c/28935/ 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_-23_c_28935_=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=o3Vg65e8bgfkPRtjuz5eDNYufb41yNfuAyjRaK4bftI=ZzJnP1iNcTOUodaNsGPvcXKQzWzY5trbqBadkE6Mdrw=>
>  
> Expect it to be merged in the next few days.
>  
> Thanks,
> Alexis

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


Re: [onap-discuss] [AAI][SO] How to add another LCP Region

2018-01-23 Thread Alexis de Talhouët
Brian,

I’m not familiar with the cd.sh script.

Alexis

> On Jan 23, 2018, at 12:53 PM, FREEMAN, BRIAN D <bf1...@att.com> wrote:
> 
> OK – I’ll try later. For some reason cd.sh got stuck “waiting for config pod 
> to complete” ?
>  
> Do I need to update my version of cd.sh ?
>  
> Brian
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Tuesday, January 23, 2018 11:48 AM
> To: FREEMAN, BRIAN D <bf1...@att.com>
> Cc: onap-discuss <onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
> Brian, no it’s not merged yet.
>  
> It has been Code-Review +2 and Verified +1, but not submitted yet. It’s 
> dependent on some other patch I was testing. I just found my missing piece. 
> Expect this to be merge by 1pm.
>  
> Thanks for testing, though :)
>  
> Thanks, 
> Alexis
> 
> 
> On Jan 23, 2018, at 11:37 AM, FREEMAN, BRIAN D <bf1...@att.com 
> <mailto:bf1...@att.com>> wrote:
>  
> I think it was merged today (in parallel with your email I suspect).
>  
> Trying an cd.sh install now on -b amsterdam to see.
>  
> Brian
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Tuesday, January 23, 2018 11:28 AM
> To: FREEMAN, BRIAN D <bf1...@att.com <mailto:bf1...@att.com>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
>  
> 
> 
> 
> On Jan 10, 2018, at 5:56 PM, FREEMAN, BRIAN D <bf1...@att.com 
> <mailto:bf1...@att.com>> wrote:
>  
> Robot did not work – trying to patch/work around to use it and it partially 
> succeed – could be amsterdam vs master issue
> Tried to run robot distribute and the heat templates were missing
> Used the following:
>i.  Cd 
> /dockerdata-nfs/onap/
>  ii.  Git 
> clone http://gerrit.onap.org/r/demo 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__gerrit.onap.org_r_demo=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=o3Vg65e8bgfkPRtjuz5eDNYufb41yNfuAyjRaK4bftI=D-8_FXY0_QYgowq65_4Z9CWQaQZopUGFiCjMcYjKxOg=>
>iii.  Cd demo
>iv.  cp -rf 
> heat ../robot/eteshare
>  v.  this put 
> the heat/vFW etc into the heat directory.
> After this distribute seems to work partially
>i.  ROBOT 
> fails after partially distributing looking for 6 thing and getting 5 – not 
> sure what that error is but the models do seem to be distributed to AAI and 
> SO from the SDC GUI perspective
>  
>  
> Brian, the fix for this is now out: https://gerrit.onap.org/r/#/c/28935/ 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_-23_c_28935_=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=o3Vg65e8bgfkPRtjuz5eDNYufb41yNfuAyjRaK4bftI=ZzJnP1iNcTOUodaNsGPvcXKQzWzY5trbqBadkE6Mdrw=>
>  
> Expect it to be merged in the next few days.
>  
> Thanks,
> Alexis

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


Re: [onap-discuss] ONAP continuous tagging and deployment discussion - full CI/CD

2018-01-23 Thread Alexis de Talhouët
Some thoughts:

- Continuous System Integration Test (CSIT) per project, current level is low: 
https://jenkins.onap.org/view/CSIT/ We should encourage project as part as 
their milestones to have a certain level of coverage through CSIT. Maybe create 
a reward, like the project that has the best test coverage (we’ve done this for 
a few releases in ODL)
- REST API layer
- E2E functionality within the project itself (using simulators, …)

- CSIT for overall ONAP, e.g run close-loop use cases

- A better way to customize ONAP deployment in OOM. Currently everything is 
coming from an onap-parameters.yaml file, which was done initially but isn’t a 
good solution. Team is currently working on moving the configuration under each 
helm chart (per project), so configuration can be derived from the helm chart 
itself. Once done, we can create a common helm chart that will centralize the 
ONAP parameters to be passed to any projects helm chart, it will basically sit 
on top of the other, as illustrated bellow:
——— 
 common chart
——— 
 projects chart
——— 
That way, projects chart can be configured to retrieved the value from the 
common chart, or to use their own values (using Go Templating, e.g. {{ 
Values.common.appcversion | default v1.1.1 }} ). So basically we keep the 
ability to deploy one chart at the time.
Finally, Helm provides the ability to overwrite the values.yaml properties when 
deploying a chart, hence the common values.yaml file can be overwritten to 
provide specific environment details.

- Create a CI process for OOM in ONAP’s Jenkins. As OOM is using helm chart for 
each application, OOM should produce helm chart, and at release time, should 
release helm chart, so consumer (GOCD, Cloudify, …) can consume them. This 
currently doesn’t exist in ONAP, moreover, we need ONAP to be able to host helm 
chart. Nexus doesn’t offer this capability yet. I know Bintray does, and it’s 
on the way for Artifcatory. But we need support from the LF on this to find the 
appropriate solution. Note, it could also be a simple HTTP server on which we 
can have two folders, snapshot and release, and manipulate helm chart from 
there.

- Create a CD process for OOM in ONAP’s Jenkins: Today we have Michael’s script 
that does the job. But we should have something that provides more auditing, 
better logging, better traceability, etc Internally we’ve been using GOCD 
for that, and we’re currently looking at how to properly upstream what we’ve 
done. GOCD allows to create pipeline, similar to Jenkins pipeline, but geared 
mainly for CD and not CI. This will give the ability to deploy ONAP on 
multiple/different environments. Also, this could be triggered by an upstream 
Jenkins Job, like a merge job, or a keyword comment on a gerrit patch. An 
alternative to GOCD, being currently developed in OOM, is Cloudify. So both 
options will sit on top of OOM, consuming helm chart build by OOM.

- Ability to upgrade a component. Today, OOM only offers the ability to create 
or delete component, which is underusing the advantage of Kubernetes that 
support upgrade for any deployment.
With the upgradability feature provided by OOM, we will be able to re-deploy 
only components that have changed, based on docker image version. So no need to 
re-deploy the whole ONAP. And the best part is, it will rollback is the upgrade 
has failed. So we can keep and “stable” like kind of environment where to 
periodically run the CSIT covering the close-loop use cases.

Regarding how the process should work in Gerrit:
- I tend to think we shouldn’t have to wait for an hour or so to have a 
Verified +1 from Jenkins, this is too long, and this will impact development 
cycles badly. Ideally, the Jenkins verified job shouldn’t take more than 30 mn 
if we want to be efficient. 
The addition of a Gerrit trigger keyword to run it the full CSIT close-loops 
suites will allow committer/developers to run more in-depth verification on 
patches that they feel requires it.


Alexis

> On Jan 23, 2018, at 2:37 PM, Michael O'Brien  wrote:
> 
> Team,
> Hi, the Integration(Ran, Marco, Gary, Helen, Brian), OOM(Alexis, Mike O, 
> Mike E, Yuri), the Linux Foundation(Jessica) and members of the TSC (Gildas) 
> have been discussing build tagging and continuous deployment as a way of 
> validating the runtime integrity of each component merge – a fully jenkins 
> triggered automated CI/CD system that does more than healthcheck.
> At the last Integration meet and a couple before that we discussed moving 
> away from blind tagging and more towards continuous build validation – this 
> meeting is in response.
> One of the major goals of this meeting is getting a clean set of tasks we 
> will present to the Linux Foundation and the PTLs on any 
> addition/modification of the current Jenkins/nexus3 build structure.
>  
> We will be holding weekly meetings so 

Re: [onap-discuss] [OOM] DCAE config in windriver

2018-01-23 Thread Alexis de Talhouët
Right, as I said, expect this to be merged in a couple of hours.

Thanks,
Alexis

> On Jan 23, 2018, at 12:29 PM, Gary Wu <gary.i...@huawei.com> wrote:
> 
> The first patch depends on the second, but the second has not yet been merged 
> yet?  I guess I should wait for the second one to merged first?
>  
> Thanks,
> Gary
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Tuesday, January 23, 2018 8:53 AM
> To: Gary Wu <gary.i...@huawei.com>
> Cc: BRIAN D FREEMAN <bf1...@att.com>; PLATANIA, MARCO (MARCO) 
> <plata...@research.att.com>; onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] [OOM] DCAE config in windriver
>  
> Gary,
>  
> This patch fixes the OOM to enable proxy DNS designate setup: 
> https://gerrit.onap.org/r/#/c/28933/ <https://gerrit.onap.org/r/#/c/28933/>
>  
> I’ve tested in my environment, it’s working.
>  
> Please try again when you have some time. Note, the onap-parameters.yaml have 
> changed a little bit to enable this. See https://gerrit.onap.org/r/#/c/28591/ 
> <https://gerrit.onap.org/r/#/c/28591/>
>  
> Expect this to be merge in a couple of hours.
>  
> Thanks,
> Alexis
> 
> 
> On Jan 22, 2018, at 3:57 PM, Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>> wrote:
>  
> Gary,
>  
> OOM doesn’t yet support the proxied solution. This is being worked on; until 
> this is not fix, you cannot use Wind-River lab to deploy OOM with DCAENGEN2.
> Expect the fix to be submit in the next couple of days.
>  
> Thanks,
> Alexis
> 
> 
> On Jan 22, 2018, at 3:17 PM, Gary Wu <gary.i...@huawei.com 
> <mailto:gary.i...@huawei.com>> wrote:
>  
> Hi Alexis,
>  
> Yes, I’m able to deploy DCAEGEN2 on a (non-Wind River) system with Designate 
> installed.  My question is specifically on the Wind River lab.  Can we use 
> Designate there?  So far what I see is “public endpoint for dns service in 
> RegionOne region not found”, so it seems like we cannot.  Or is there a 
> special Designate endpoint/config available?
>  
> Has anyone successfully deployed OOM with DCAEGEN2 in the Wind River lab, 
> with or without the proxy solution?
>  
> Thanks,
> Gary
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Monday, January 22, 2018 11:58 AM
> To: Gary Wu <gary.i...@huawei.com <mailto:gary.i...@huawei.com>>
> Cc: BRIAN D FREEMAN <bf1...@att.com <mailto:bf1...@att.com>>; PLATANIA, MARCO 
> (MARCO) <plata...@research.att.com <mailto:plata...@research.att.com>>; 
> onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] [OOM] DCAE config in windriver
>  
> Hi Gary,
>  
> I noticed the proxy solution that DCAEGEN2 offers is not fully working yet 
> with OOM. What is working is having DCAE on the same OpenStack as DNS 
> Designate. I’m currently in the process of addressing this.
>  
> Regarding your question about how "vm1.aai.simpledemo.onap.org 
> <http://vm1.aai.simpledemo.onap.org/> gets resolves, we create a zone in 
> Designate for simpledemo.onap.org <http://simpledemo.onap.org/>, see 
> https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/docker/init/src/config/dcaegen2/heat/entrypoint.sh;h=85c5ee2b131458f7f25cab3c8efc4071b22775f5;hb=refs/heads/amsterdam
>  
> <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/docker/init/src/config/dcaegen2/heat/entrypoint.sh;h=85c5ee2b131458f7f25cab3c8efc4071b22775f5;hb=refs/heads/amsterdam>
> And we added a reverse proxy so the lookup returns the IP of the K8S host 
> running the reverse-proxy, and the service port are opened.
>  
> See bellow design implemented:
>  
> 
>  
>  
> Thanks,
> Alexis
> 
> 
> 
> On Jan 22, 2018, at 2:00 PM, Gary Wu <gary.i...@huawei.com 
> <mailto:gary.i...@huawei.com>> wrote:
>  
> Hi Alexis and Brian,
> 
> How should we currently spin up DCAEGEN2 using OOM in Wind River lab?
> 
> I assume we're supposed to set DNSAAS_PROXY_ENABLE to "true".  However, when 
> this is done, my dcae-dcae-boostrap VM gets stuck on wait_for_aai_ready() 
> since it's unable to resolve the hostname "vm1.aai.simpledemo.onap.org 
> <http://vm1.aai.simpledemo.onap.org/>", and none of the DNSAAS-related code 
> in dcae_vm_init.sh gets triggered since they only occur after 
> wait_for_aai_ready().
> 
> Is there additional config/init that we're supposed to do to get 
> vm1.aai.simpledemo.onap.org <http://vm1.aai.simpledemo.onap.org/> to resolve 
> in this VM?
&

Re: [onap-discuss] [**EXTERNAL**] oom openstack config in the pod lab

2018-01-23 Thread Alexis de Talhouët
# #
# OpenStack Config on which DCAE will be deployed #
# #

# --- 
# Either v2.0 or v3
DCAE_OS_API_VERSION: "v2.0"
DCAE_OS_KEYSTONE_URL: "http://10.1.1.5:5000;
DCAE_OS_USERNAME: "nso"
DCAE_OS_PASSWORD: "Password"
DCAE_OS_TENANT_NAME: "nso-rancher"
DCAE_OS_TENANT_ID: "21ca0f4c2239475fb1b4b499399163e"
DCAE_OS_REGION: "RegionOne"
# — 

That section let you provide the information for the OpenStack on which to 
deploy DCAE. If that OpenStack instance has Designate, then 
# Proxy DNS Designate. This means DCAE will run in an instance not support 
Designate, and Designate will be provided by another instance.
# Set to true if you wish to use it
DNSAAS_PROXY_ENABLE: “true"

Will be set to false, and that OpenStack will be used for DNS Designate support.

Hope this clarifies things,
Alexis

> On Jan 23, 2018, at 12:00 PM, Kranthi Guttikonda 
> <kranthi.guttiko...@b-yond.com> wrote:
> 
> Hi Alexis,
>  
> I have couple of questions. Pardon me.
>  
> # Whether or not to deploy DCAE
> # If set to false, all the parameters bellow can be left empty or removed
> # If set to false, update ../dcaegen2/values.yaml disableDcae value to true, 
> //Is it possible to elaborate this???
> # this is to avoid deploying the DCAE deployments and services.
> DEPLOY_DCAE: "true"
>  
> # In the HEAT setup, it's meant to be a DNS list, as the HEAT setup deploys a 
> DNS Server VM in addition to DNS Designate
> # and this DNS Server is setup to forward request to the DNS Designate 
> backend when it cannot resolve, hence the
> # DNS_FORWARDER config here. The DCAE Boostrap requires both inputs, even 
> though they are now similar, we have to pass
> # them.
> # -
> # ATTENTION: Assumption is made the DNS Designate backend is configure to 
> forward request to a public DNS (e.g. 8.8.8.8)
> # -
> # Put the IP of the DNS Designate backend (e.g. the OpenStack IP supporting 
> DNS Designate)
> DNS_LIST : "10.1.1.16"
> DNS_FORWARDER: "10.1.1.16"
>  
> If DNS designate is available (not using proxy) then can’t we directly give 
> the DNS designate URL to DCAE instead querying that from keystone/openstack 
> services? I mean we can pass the direct API url to DCAE scripts. Just 
> wondering.
>  
> Thanks,
> Kranthi
>  
> From: <onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>> on behalf of Alexis de Talhouët 
> <adetalhoue...@gmail.com <mailto:adetalhoue...@gmail.com>>
> Date: Tuesday, January 23, 2018 at 11:09 AM
> To: Gary Wu <gary.i...@huawei.com <mailto:gary.i...@huawei.com>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [**EXTERNAL**] oom openstack config in the pod lab
>  
> Hello guys,  <>
>  
> Could you provide feedback on this updated version of onap-parameters.yaml? 
> https://gerrit.onap.org/r/#/c/28591/5/kubernetes/config/onap-parameters-sample.yaml
>  
> <https://gerrit.onap.org/r/#/c/28591/5/kubernetes/config/onap-parameters-sample.yaml>
>  
> It’s under review, and I’d love a little but a feedback. I added a lot of 
> comments explaining what are the param to give. Please let me know if it 
> helps and does answer your questions.
>  
> Thanks,
> Alexis
> 
> 
> On Jan 18, 2018, at 12:59 PM, Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>> wrote:
>  
> Gary, 
>  
> For now Amsterdam branch has been highly tested. I’m starting the work on the 
> master branch.
> So please use Amsterdam branch for now.
>  
> Regarding the issue you faced with the init container, this should be fix 
> now.You could try to re-pull the config-init:2.0.0-SNAPSHOT image (for master)
>  
> The config container does provision directory, and it does also a bunch of 
> sed command to inject parameters, Those sed commands is what is taking most 
> of the time, because we loop blindly over all the directories, instead of 
> targeting the sed more precisely. I’m currently working on improving this for 
> Amsterdam, and will cherry-pick on master once ready.
>  
> Thanks,
> Alexis
> 
> 
> On Jan 18, 2018, at 12:49 PM, Gary Wu <gary.i...@huawei.com 
> <mailto:gary.i...@huawei.com>> wrote:
>  
> Are we mainly testing against OOM amsterdam branch, or master?
>  
> In the master branch, the config container complains about other parameters 
> missing like NEXUS_REPO or something.  Is the OOM master branch stable enough 
> for us to try now?  If so, can you share your sample para

[onap-discuss] [OOM][Amsterdam] It's getting stable - HEAT feature parity

2018-01-23 Thread Alexis de Talhouët
Hi OOM team,

I think we have all the outstanding bugs for Amsterdam being addressed here: 
https://gerrit.onap.org/r/#/q/status:open+project:oom+branch:amsterdam

We support both DCAEGEN2 deployment solution: the standalone one, and the 
proxied one.

There is still one to be done, OOM-604, that is update the docker version to 
latest Amsterdam Maintenance Release.

Once done, I’ll make sure to back-port all those fixes in master.

Bye,
Alexis
___
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

2018-01-23 Thread Alexis de Talhouët
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 <krama...@ciena.com> 
> 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 <adetalhoue...@gmail.com>
> 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 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_OOM-2D608=DwMFaQ=06gGS5mmTNpWnXkc0ACHoA=3Q306Mu4iPxbTMD0vasm2o7f6Fs_R4Dsdq4HWP9yOq8=f9rBnbJzOXBaXfGkT0Vpe42EeDuUacO5Bd5YM2KscZ8=Kfo_4eq50-zh0ubMpedUQQh4e6Uvr-2X4dpWAQcYYbw=>
>  for more details.
> 
> Thanks,
> Alexis
> 
>> On Jan 19, 2018, at 4:21 PM, Ramanarayanan, Karthick <krama...@ciena.com 
>> <mailto:krama...@ciena.com>> wrote:
>> 
>> Hi Alexis,
>>  I reverted the oom commit from head to:
>> 
>> git checkout cb02aa241edd97acb6c5ca744de84313f53e8a5a
>> 
>> Author: yuryn <yury.novit...@amdocs.com <mailto:yury.novit...@amdocs.com>>
>> 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 <mailto: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 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__127.0.0.1-3A30206_sdc1_rest_healthCheck=DwMFaQ=06gGS5mmTNpWnXkc0ACHoA=3Q306Mu4iPxbTMD0vasm2o7f6Fs_R4Dsdq4HWP9yOq8=f9rBnbJzOXBaXfGkT0Vpe42EeDuUacO5Bd5YM2KscZ8=kw5keI716zhaX2yeaToDMAmWzlSoL2jdAfJg075jS6A=>
>> {
>>  "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",
>> 

Re: [onap-discuss] [OOM] DCAE config in windriver

2018-01-23 Thread Alexis de Talhouët
Gary,

This patch fixes the OOM to enable proxy DNS designate setup: 
https://gerrit.onap.org/r/#/c/28933/

I’ve tested in my environment, it’s working.

Please try again when you have some time. Note, the onap-parameters.yaml have 
changed a little bit to enable this. See https://gerrit.onap.org/r/#/c/28591/

Expect this to be merge in a couple of hours.

Thanks,
Alexis

> On Jan 22, 2018, at 3:57 PM, Alexis de Talhouët <adetalhoue...@gmail.com> 
> wrote:
> 
> Gary,
> 
> OOM doesn’t yet support the proxied solution. This is being worked on; until 
> this is not fix, you cannot use Wind-River lab to deploy OOM with DCAENGEN2.
> Expect the fix to be submit in the next couple of days.
> 
> Thanks,
> Alexis
> 
>> On Jan 22, 2018, at 3:17 PM, Gary Wu <gary.i...@huawei.com 
>> <mailto:gary.i...@huawei.com>> wrote:
>> 
>> Hi Alexis,
>>  
>> Yes, I’m able to deploy DCAEGEN2 on a (non-Wind River) system with Designate 
>> installed.  My question is specifically on the Wind River lab.  Can we use 
>> Designate there?  So far what I see is “public endpoint for dns service in 
>> RegionOne region not found”, so it seems like we cannot.  Or is there a 
>> special Designate endpoint/config available?
>>  
>> Has anyone successfully deployed OOM with DCAEGEN2 in the Wind River lab, 
>> with or without the proxy solution?
>>  
>> Thanks,
>> Gary
>>  
>>  
>> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
>> <mailto:adetalhoue...@gmail.com>] 
>> Sent: Monday, January 22, 2018 11:58 AM
>> To: Gary Wu <gary.i...@huawei.com <mailto:gary.i...@huawei.com>>
>> Cc: BRIAN D FREEMAN <bf1...@att.com <mailto:bf1...@att.com>>; PLATANIA, 
>> MARCO (MARCO) <plata...@research.att.com 
>> <mailto:plata...@research.att.com>>; onap-discuss@lists.onap.org 
>> <mailto:onap-discuss@lists.onap.org>
>> Subject: Re: [onap-discuss] [OOM] DCAE config in windriver
>>  
>> Hi Gary,
>>  
>> I noticed the proxy solution that DCAEGEN2 offers is not fully working yet 
>> with OOM. What is working is having DCAE on the same OpenStack as DNS 
>> Designate. I’m currently in the process of addressing this.
>>  
>> Regarding your question about how "vm1.aai.simpledemo.onap.org 
>> <http://vm1.aai.simpledemo.onap.org/> gets resolves, we create a zone in 
>> Designate for simpledemo.onap.org <http://simpledemo.onap.org/>, see 
>> https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/docker/init/src/config/dcaegen2/heat/entrypoint.sh;h=85c5ee2b131458f7f25cab3c8efc4071b22775f5;hb=refs/heads/amsterdam
>>  
>> <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/docker/init/src/config/dcaegen2/heat/entrypoint.sh;h=85c5ee2b131458f7f25cab3c8efc4071b22775f5;hb=refs/heads/amsterdam>
>> And we added a reverse proxy so the lookup returns the IP of the K8S host 
>> running the reverse-proxy, and the service port are opened.
>>  
>> See bellow design implemented:
>>  
>> 
>>  
>>  
>> Thanks,
>> Alexis
>> 
>> 
>> On Jan 22, 2018, at 2:00 PM, Gary Wu <gary.i...@huawei.com 
>> <mailto:gary.i...@huawei.com>> wrote:
>>  
>> Hi Alexis and Brian,
>> 
>> How should we currently spin up DCAEGEN2 using OOM in Wind River lab?
>> 
>> I assume we're supposed to set DNSAAS_PROXY_ENABLE to "true".  However, when 
>> this is done, my dcae-dcae-boostrap VM gets stuck on wait_for_aai_ready() 
>> since it's unable to resolve the hostname "vm1.aai.simpledemo.onap.org 
>> <http://vm1.aai.simpledemo.onap.org/>", and none of the DNSAAS-related code 
>> in dcae_vm_init.sh gets triggered since they only occur after 
>> wait_for_aai_ready().
>> 
>> Is there additional config/init that we're supposed to do to get 
>> vm1.aai.simpledemo.onap.org <http://vm1.aai.simpledemo.onap.org/> to resolve 
>> in this VM?
>> 
>> Thanks,
>> Gary
>> 
>> -Original Message-
>> From: onap-discuss-boun...@lists.onap.org 
>> <mailto:onap-discuss-boun...@lists.onap.org> 
>> [mailto:onap-discuss-boun...@lists.onap.org 
>> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de Talhouët
>> Sent: Monday, January 22, 2018 6:48 AM
>> To: BRIAN D FREEMAN <bf1...@att.com <mailto:bf1...@att.com>>
>> Cc: onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
>> Subject: Re: [onap-discuss] [OOM] DCAE status in non-openstack clouds ?
>> 
>> Brian,
>> 
>> DCAE deployment in Amsterdam is coupled to OpenStack cloud, and we’re not in 
>> the process of supporting other cloud for now.
>> This could be an enhancement for Beijing, if DCAE still runs in VMs. And if 
>> we do such implementation, we should leverage Multicloud interfaces to do so.
>> 
>> Prior to this, we should flush out the requirement of DCAE deployment on 
>> different type of cloud, what are the implications and so on.
>> 
>> Alexis
>> 
>>  
> 

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


Re: [onap-discuss] [AAI][SO] How to add another LCP Region

2018-01-23 Thread Alexis de Talhouët
Brian, no it’s not merged yet.

It has been Code-Review +2 and Verified +1, but not submitted yet. It’s 
dependent on some other patch I was testing. I just found my missing piece. 
Expect this to be merge by 1pm.

Thanks for testing, though :)

Thanks,
Alexis

> On Jan 23, 2018, at 11:37 AM, FREEMAN, BRIAN D <bf1...@att.com> wrote:
> 
> I think it was merged today (in parallel with your email I suspect).
>  
> Trying an cd.sh install now on -b amsterdam to see.
>  
> Brian
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Tuesday, January 23, 2018 11:28 AM
> To: FREEMAN, BRIAN D <bf1...@att.com>
> Cc: onap-discuss <onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
>  
> 
> 
> On Jan 10, 2018, at 5:56 PM, FREEMAN, BRIAN D <bf1...@att.com 
> <mailto:bf1...@att.com>> wrote:
>  
> Robot did not work – trying to patch/work around to use it and it partially 
> succeed – could be amsterdam vs master issue
> Tried to run robot distribute and the heat templates were missing
> Used the following:
>i.  Cd 
> /dockerdata-nfs/onap/
>  ii.  Git 
> clone http://gerrit.onap.org/r/demo 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__gerrit.onap.org_r_demo=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=o3Vg65e8bgfkPRtjuz5eDNYufb41yNfuAyjRaK4bftI=D-8_FXY0_QYgowq65_4Z9CWQaQZopUGFiCjMcYjKxOg=>
>iii.  Cd demo
>iv.  cp -rf 
> heat ../robot/eteshare
>  v.  this put 
> the heat/vFW etc into the heat directory.
> After this distribute seems to work partially
>i.  ROBOT 
> fails after partially distributing looking for 6 thing and getting 5 – not 
> sure what that error is but the models do seem to be distributed to AAI and 
> SO from the SDC GUI perspective
>  
>  
> Brian, the fix for this is now out: https://gerrit.onap.org/r/#/c/28935/ 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_-23_c_28935_=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=o3Vg65e8bgfkPRtjuz5eDNYufb41yNfuAyjRaK4bftI=ZzJnP1iNcTOUodaNsGPvcXKQzWzY5trbqBadkE6Mdrw=>
>  
> Expect it to be merged in the next few days.
>  
> Thanks,
> Alexis

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


Re: [onap-discuss] [AAI][SO] How to add another LCP Region

2018-01-23 Thread Alexis de Talhouët


> On Jan 10, 2018, at 5:56 PM, FREEMAN, BRIAN D  wrote:
> 
> Robot did not work – trying to patch/work around to use it and it partially 
> succeed – could be amsterdam vs master issue
> Tried to run robot distribute and the heat templates were missing
> Used the following:
>i.  Cd 
> /dockerdata-nfs/onap/
>  ii.  Git 
> clone http://gerrit.onap.org/r/demo 
>iii.  Cd demo
>iv.  cp -rf 
> heat ../robot/eteshare
>  v.  this put 
> the heat/vFW etc into the heat directory.
> After this distribute seems to work partially
>i.  ROBOT 
> fails after partially distributing looking for 6 thing and getting 5 – not 
> sure what that error is but the models do seem to be distributed to AAI and 
> SO from the SDC GUI perspective


Brian, the fix for this is now out: https://gerrit.onap.org/r/#/c/28935/

Expect it to be merged in the next few days.

Thanks,
Alexis___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] [**EXTERNAL**] oom openstack config in the pod lab

2018-01-23 Thread Alexis de Talhouët
Hello guys,

Could you provide feedback on this updated version of onap-parameters.yaml? 
https://gerrit.onap.org/r/#/c/28591/5/kubernetes/config/onap-parameters-sample.yaml

It’s under review, and I’d love a little but a feedback. I added a lot of 
comments explaining what are the param to give. Please let me know if it helps 
and does answer your questions.

Thanks,
Alexis

> On Jan 18, 2018, at 12:59 PM, Alexis de Talhouët <adetalhoue...@gmail.com> 
> wrote:
> 
> Gary,
> 
> For now Amsterdam branch has been highly tested. I’m starting the work on the 
> master branch.
> So please use Amsterdam branch for now.
> 
> Regarding the issue you faced with the init container, this should be fix 
> now.You could try to re-pull the config-init:2.0.0-SNAPSHOT image (for master)
> 
> The config container does provision directory, and it does also a bunch of 
> sed command to inject parameters, Those sed commands is what is taking most 
> of the time, because we loop blindly over all the directories, instead of 
> targeting the sed more precisely. I’m currently working on improving this for 
> Amsterdam, and will cherry-pick on master once ready.
> 
> Thanks,
> Alexis
> 
>> On Jan 18, 2018, at 12:49 PM, Gary Wu <gary.i...@huawei.com 
>> <mailto:gary.i...@huawei.com>> wrote:
>> 
>> Are we mainly testing against OOM amsterdam branch, or master?
>>  
>> In the master branch, the config container complains about other parameters 
>> missing like NEXUS_REPO or something.  Is the OOM master branch stable 
>> enough for us to try now?  If so, can you share your sample parameters file 
>> for the master branch?
>>  
>> As an aside, does anyone know why the config container takes 2 to 3 minutes 
>> to complete?  Seems to be a long time for creating shared config 
>> directories, or maybe my environment is not set up right somehow.
>> 
>> Thanks,
>> Gary
>>  
>> From: onap-discuss-boun...@lists.onap.org 
>> <mailto:onap-discuss-boun...@lists.onap.org> 
>> [mailto:onap-discuss-boun...@lists.onap.org 
>> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de Talhouët
>> Sent: Thursday, January 18, 2018 9:14 AM
>> To: PLATANIA, MARCO (MARCO) <plata...@research.att.com 
>> <mailto:plata...@research.att.com>>
>> Cc: onap-discuss <onap-discuss@lists.onap.org 
>> <mailto:onap-discuss@lists.onap.org>>
>> Subject: Re: [onap-discuss] [**EXTERNAL**] oom openstack config in the pod 
>> lab
>>  
>> Marco,
>>  
>> Well that’s the thing I’m currently looking at. I know Robot needs them for 
>> whatever reason.
>>  
>> I’m currently about to test a deployment without those parameters, because 
>> as you pointed out, they don’t necessarily make sense for OOM.
>>  
>> I have to validate this, but I’m validating other thing at the same time. 
>> Because with the introduction of DCAE, we potentially can configure tree 
>> different OpenStack:
>>  
>> - 1 where to deploy VNF
>> - 1 where to deploy DCAE
>> - 1 where DNS Designate is supported
>>  
>> So I’m re-doing the onap-parameters.yaml to take this in consideration. 
>> Note, it could also be the same OpenStack instance for all of them, but as 
>> the flexibility is giving to us
>> by DCAE, let’s leverage this.
>>  
>> Moreover, this separation is useful when going in prod.
>>  
>> Alexis
>> 
>> 
>> On Jan 18, 2018, at 12:06 PM, PLATANIA, MARCO (MARCO) 
>> <plata...@research.att.com <mailto:plata...@research.att.com>> wrote:
>>  
>> Alexis,
>>  
>> What are these parameters used for in OOM?
>>  
>> OPENSTACK_UBUNTU_14_IMAGE: "ubuntu-14-04-cloud-amd64"
>> OPENSTACK_PUBLIC_NET_ID: "971040b2-7059-49dc-b220-4fab50cb2ad4"
>> OPENSTACK_OAM_NETWORK_ID: "31b5d82c-bfd3-44bf-a830-4bc0b628013f"
>> OPENSTACK_OAM_SUBNET_ID: "658d0e1b-8e2c-45c3-94e3-e7a1df1ed475"
>> OPENSTACK_OAM_NETWORK_CIDR: "10.10.2.0/24"
>>  
>> We had them for Heat, to tell the Orchestrator what image and network to use 
>> when creating ONAP VMs. For vFW/vLB use cases, those parameters are passed 
>> as SDNC preload.
>>  
>> Marco
>>  
>> From: <onap-discuss-boun...@lists.onap.org 
>> <mailto:onap-discuss-boun...@lists.onap.org>> on behalf of Alexis de 
>> Talhouët <adetalhoue...@gmail.com <mailto:adetalhoue...@gmail.com>>
>> Date: Thursday, January 18, 2018 at 11:47 AM
>> To: Pavel Paroulek <parou...@objectify.sk <mailto:parou...@objectify.sk>

Re: [onap-discuss] [OOM] DCAE config in windriver

2018-01-22 Thread Alexis de Talhouët
Gary,

OOM doesn’t yet support the proxied solution. This is being worked on; until 
this is not fix, you cannot use Wind-River lab to deploy OOM with DCAENGEN2.
Expect the fix to be submit in the next couple of days.

Thanks,
Alexis

> On Jan 22, 2018, at 3:17 PM, Gary Wu <gary.i...@huawei.com> wrote:
> 
> Hi Alexis,
>  
> Yes, I’m able to deploy DCAEGEN2 on a (non-Wind River) system with Designate 
> installed.  My question is specifically on the Wind River lab.  Can we use 
> Designate there?  So far what I see is “public endpoint for dns service in 
> RegionOne region not found”, so it seems like we cannot.  Or is there a 
> special Designate endpoint/config available?
>  
> Has anyone successfully deployed OOM with DCAEGEN2 in the Wind River lab, 
> with or without the proxy solution?
>  
> Thanks,
> Gary
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Monday, January 22, 2018 11:58 AM
> To: Gary Wu <gary.i...@huawei.com <mailto:gary.i...@huawei.com>>
> Cc: BRIAN D FREEMAN <bf1...@att.com <mailto:bf1...@att.com>>; PLATANIA, MARCO 
> (MARCO) <plata...@research.att.com <mailto:plata...@research.att.com>>; 
> onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] [OOM] DCAE config in windriver
>  
> Hi Gary,
>  
> I noticed the proxy solution that DCAEGEN2 offers is not fully working yet 
> with OOM. What is working is having DCAE on the same OpenStack as DNS 
> Designate. I’m currently in the process of addressing this.
>  
> Regarding your question about how "vm1.aai.simpledemo.onap.org 
> <http://vm1.aai.simpledemo.onap.org/> gets resolves, we create a zone in 
> Designate for simpledemo.onap.org <http://simpledemo.onap.org/>, see 
> https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/docker/init/src/config/dcaegen2/heat/entrypoint.sh;h=85c5ee2b131458f7f25cab3c8efc4071b22775f5;hb=refs/heads/amsterdam
>  
> <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/docker/init/src/config/dcaegen2/heat/entrypoint.sh;h=85c5ee2b131458f7f25cab3c8efc4071b22775f5;hb=refs/heads/amsterdam>
> And we added a reverse proxy so the lookup returns the IP of the K8S host 
> running the reverse-proxy, and the service port are opened.
>  
> See bellow design implemented:
>  
> 
>  
>  
> Thanks,
> Alexis
> 
> 
> On Jan 22, 2018, at 2:00 PM, Gary Wu <gary.i...@huawei.com 
> <mailto:gary.i...@huawei.com>> wrote:
>  
> Hi Alexis and Brian,
> 
> How should we currently spin up DCAEGEN2 using OOM in Wind River lab?
> 
> I assume we're supposed to set DNSAAS_PROXY_ENABLE to "true".  However, when 
> this is done, my dcae-dcae-boostrap VM gets stuck on wait_for_aai_ready() 
> since it's unable to resolve the hostname "vm1.aai.simpledemo.onap.org 
> <http://vm1.aai.simpledemo.onap.org/>", and none of the DNSAAS-related code 
> in dcae_vm_init.sh gets triggered since they only occur after 
> wait_for_aai_ready().
> 
> Is there additional config/init that we're supposed to do to get 
> vm1.aai.simpledemo.onap.org <http://vm1.aai.simpledemo.onap.org/> to resolve 
> in this VM?
> 
> Thanks,
> Gary
> 
> -Original Message-
> From: onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org> 
> [mailto:onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de Talhouët
> Sent: Monday, January 22, 2018 6:48 AM
> To: BRIAN D FREEMAN <bf1...@att.com <mailto:bf1...@att.com>>
> Cc: onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] [OOM] DCAE status in non-openstack clouds ?
> 
> Brian,
> 
> DCAE deployment in Amsterdam is coupled to OpenStack cloud, and we’re not in 
> the process of supporting other cloud for now.
> This could be an enhancement for Beijing, if DCAE still runs in VMs. And if 
> we do such implementation, we should leverage Multicloud interfaces to do so.
> 
> Prior to this, we should flush out the requirement of DCAE deployment on 
> different type of cloud, what are the implications and so on.
> 
> Alexis
> 
>  

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


Re: [onap-discuss] [OOM] DCAE status in non-openstack clouds ?

2018-01-22 Thread Alexis de Talhouët
Brian,

DCAE deployment in Amsterdam is coupled to OpenStack cloud, and we’re not in 
the process of supporting other cloud for now.
This could be an enhancement for Beijing, if DCAE still runs in VMs. And if we 
do such implementation, we should leverage Multicloud interfaces to do so.

Prior to this, we should flush out the requirement of DCAE deployment on 
different type of cloud, what are the implications and so on.

Alexis

> On Jan 22, 2018, at 9:34 AM, FREEMAN, BRIAN D  wrote:
> 
> Michale, Alexis,
> 
> What is the current status of bring DCAE up on non-openstack clouds via OOM ? 
> I have gotten all components but DCAE to pass healthcheck but not sure 
> dcaegen2 pod is even starting in my Azure test environment.
> 
> Brian
> 
> -Original Message-
> From: onap-discuss-boun...@lists.onap.org 
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Michael O'Brien via 
> RT
> Sent: Friday, January 05, 2018 2:46 PM
> Cc: onap-discuss@lists.onap.org; onap-...@lists.onap.org
> Subject: Re: [onap-discuss] [ONAP Helpdesk #50702] Unable to create new JIRA 
> on mandatory "Affects Version" introduced today
> 
> Jessica,
>   Fixed - thank you
>   Verified task and bug creation
> https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_INT-2D376=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=X0h7lcMZUU83N2cuK_RLHtm5rKHLh_QVh7IVqQwuWl8=tKrU0djaLFNMunPe64UL71aFWuRZOtZNphgsL0_tZww=
>   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_INT-2D377=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=X0h7lcMZUU83N2cuK_RLHtm5rKHLh_QVh7IVqQwuWl8=lmgLUdA1wy4X-hgZh5sG7g92G3dUW8ZBiQIzON1dVIg=
>  
> 
>   /michael
> 
> -Original Message-
> From: Jessica Wagantall via RT [mailto:onap-helpd...@rt.linuxfoundation.org] 
> Sent: Friday, January 5, 2018 13:38
> To: Michael O'Brien 
> Cc: onap-discuss@lists.onap.org; onap-...@lists.onap.org
> Subject: [ONAP Helpdesk #50702] Unable to create new JIRA on mandatory 
> "Affects Version" introduced today
> 
> Dear Michael , 
> 
> Can you please try again. This mandatory field has now been isolated to only 
> Bug type issues on its own. Epic and Story can now be created without the 
> need of an Affected Version. 
> 
> Please try and let me know. 
> 
> Thanks and sorry for the trouble
> Jess
> 
> On Fri Jan 05 13:33:22 2018, jwagantall wrote:
>> Working on this now.. 
>> 
>> thanks!
>> Jess
>> 
>> On Fri Jan 05 08:17:31 2018, frank.obr...@amdocs.com wrote:
>>> Jessica,
>>>   Hi, JIRA currently is broken on the new validation field - we are 
>>> not able to add any new issues - could we get this addressed ASAP, 
>>> either temporarily reverse the change and retest it before 
>>> reintroducing it or temporarily auto-populating it
>>> 
>>> Thank you
>>> /michael
>>> 
>>> -Original Message-
>>> From: ONAP Helpdesk via RT [mailto:onap- 
>>> helpd...@rt.linuxfoundation.org]
>>> Sent: Friday, January 5, 2018 00:44
>>> To: Michael O'Brien 
>>> Subject: [ONAP Helpdesk #50702] AutoReply: Unable to create new JIRA 
>>> on mandatory "Affects Version" introduced today
>>> 
>>> Greetings,
>>> 
>>> Your support ticket regarding:
>>>"Unable to create new JIRA on mandatory "Affects Version"
>>> introduced today", has been entered in our ticket tracker.  A 
>>> summary of your ticket appears below.
>>> 
>>> If you have any follow-up related to this issue, please reply to 
>>> this email.
>>> 
>>> You may also follow up on your open tickets by visiting 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__rt.linuxfoundation.org_=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=X0h7lcMZUU83N2cuK_RLHtm5rKHLh_QVh7IVqQwuWl8=FXckY0PVLNJI-0IyLaAM6k6lmgsRtC5iXouWEJ8SEcU=
>>>   -- if you have not logged into RT 
>>> before, you will need to follow the "Forgot your password" link to 
>>> set an RT password.
>>> 
>>> --
>>> The Linux Foundation Support Team
>>> 
>>> 
>>> 
>>> -
>>> LF,
>>>  Hi, I totally agree with the new mandatory field "affects version"
>>> - however I have tried adjusting the "configure fields" section and 
>>> an unable to raise any Epic or Story anymore because of the blocking 
>>> error on this field - which does not show on the create issue screen.
>>>   Setting the "Fix Version/s" field does not help.
>>>   Can you adjust the "Create Issue" screen so we can fill in this 
>>> mandatory field
>>> 
>>> 
>>> [cid:image002.jpg@01D385BE.48F088C0]
>>>thank you
>>>   /Michael
>>> 
>>> This message and the information contained herein is proprietary and 
>>> confidential and subject to the Amdocs policy statement,
>>> 
>>> you may review at 
>>> 

Re: [onap-discuss] conflicted Interpretation of Cloud Region ID in AAI, RE: [AAI][SO] How to add another LCP Region

2018-01-22 Thread Alexis de Talhouët
Bin, 

I think every component should rely on AAI to get the VIM information. SO and 
Robot should then be fixed to rely on AAI, instead of there baked configs.

Alexis

> On Jan 22, 2018, at 9:32 AM, Yang, Bin <bin.y...@windriver.com> wrote:
> 
> Hi Brian, <>
>  
>Two OpenStack instance cannot have the same Region ID will be 
> a fundamental (and confusing) assumption which impacts many ONAP components.  
> MultiCloud is one of them which has been interpreting this Region ID in 
> different way: MultiCloud assumes that this Cloud Region ID in AAI was to 
> store the OpenStack’s Region ID , it is confined in scope of a Cloud Owner. 
> So MultiCloud assumes that Region ID itself does not have to be unique , but 
> Cloud Owner + Cloud Region ID should be unique.  This interpretation was 
> based on the communication with AAI team (Ethan in cc list could share more 
> context around that communication).
>  
> With the AAI documentation (aai_swagger_v11.html), the cloud-region is 
> uniquely identified by {cloud-owner}/{cloud-region-id}, not the 
> {cloud-region-id} alone. That implies that it is possible that different 
> {cloud-owner} have the same {cloud-region-id}.
>  
> GET 
> /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}
> Tags: CloudInfrastructure 
> 
> returns cloud-region
> cloud-owner
> Identifies the vendor and cloud name, e.g., att-aic. First part of composite 
> key should be formatted as vendor-cloudname
> path
> string
> cloud-region-id
> Identifier used by the vendor for the region. Second part of composite key
> path
> string
>  
>  
> On the other hands, SO, Robot VM, they all use ‘cloud-region-id’ as parameter 
> to invoke OpenStack API, which means, this ‘cloud-region-id’ is the exactly 
> the Region ID used in context of OpenStack API. Inevitably, there will be 
> different OpenStack provisioned with “RegionOne” by default. 
>  
> So there is discrepancy between different ONAP components with regarding to 
> how to interpret this ‘cloud-region-id’ in AAI. This discrepancy should be 
> resolved in Beijing Release, otherwise it will be a blocking issue when there 
> is use case to deploy VNFs to multiple VIM/Cloud instances.
>  
> Thanks.
>  
> 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> 
> [mailto:onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of FREEMAN, BRIAN D
> Sent: Thursday, January 11, 2018 2:55 AM
> To: Alexis de Talhouët
> Cc: onap-discuss
> Subject: Re: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
> “So is it fair to say X distinct OpenStack instances must have unique 
> Region(s) to be used in ONAP? e.g. two instance cannot have the same Region.” 
> – Yes
>  
> Brian
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Wednesday, January 10, 2018 1:48 PM
> To: FREEMAN, BRIAN D <bf1...@att.com <mailto:bf1...@att.com>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
> Ok, creating another Region in OpenStack , alongs with its service endpoints 
> is working.
>  
> So is it fair to say X distinct OpenStack instances must have unique 
> Region(s) to be used in ONAP? e.g. two instance cannot have the same Region.
>  
> Thanks for the help,
> Alexis
>  
> 
> On Jan 10, 2018, at 9:57 AM, FREEMAN, BRIAN D <bf1...@att.com 
> <mailto:bf1...@att.com>> wrote:
>  
> I would name the second openstack something other than RegionOne in that 
> Openstack :)  I suspect the design assumes the cloud regions have unique 
> names but I didnt think robot needed the cloud region in their vanilla 
> openstack keystone queries (but its been a while since I looked at a trace). 
> I know Rackspace does have unique region names (IAD, DFW, etc) and we do in 
> our installations but not sure if vanilla would require that.
>  
> Brian
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Wednesday, January 10, 2018 9:53 AM
> To: FREEMAN, BRIAN D <bf1...@att.com <mailto:bf1...@att.com>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
> Ok, h

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

2018-01-22 Thread Alexis de Talhouët
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 <krama...@ciena.com> 
> wrote:
> 
> Hi Alexis,
>  I reverted the oom commit from head to:
> 
> git checkout cb02aa241edd97acb6c5ca744de84313f53e8a5a
> 
> Author: yuryn <yury.novit...@amdocs.com <mailto:yury.novit...@amdocs.com>>
> 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",
>  "healthCheckStatus": "UP",
>  "version": "2.1.17",
>  "description": "OK"
>},
>{
>  "healthCheckComponent": "FE",
>  "healthCheckStatus": "UP",
>  "version": "1.1.0",
>  "description": "OK"
>}
>  ]
>},
>{
>  "healthCheckComponent": "FE",
>  "healthCheckStatus": "UP",
>  "version": "1.1.0",
>  "description": "OK"
>}
>  ]
> 
> 
> On some occasions backend doesn't come up even though pods are running. 
> (seen on other nodes running onap and was there even without your changes. 
> Logs indicated nothing.
> But if I restart the sdc pods for cassandra, elastic search and kibana before 
> backend restart, backend starts responding and ends up creating the user 
> profile entries for the various user roles for onap as seen in logs. But this 
> is unrel

Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with Multicloud Titanium

2018-01-19 Thread Alexis de Talhouët
Ah, I missed the fact that when it’s proxied, dcae_keystone_url needs to be the 
one from multivim. All good now.

Alexis


> On Jan 19, 2018, at 11:05 AM, Alexis de Talhouët <adetalhoue...@gmail.com> 
> wrote:
> 
> Hum, actually, the DNS zone registration works. But now, the boot container 
> is failing with the following:
> 
> 2018-01-19 15:52:53 CFY  [dns_cm_4834b.create] Sending task 
> 'dnsdesig.dns_plugin.aneeded'
> 2018-01-19 15:52:53 CFY  [dns_vm00_73f5a.create] Sending task 
> 'dnsdesig.dns_plugin.aneeded'
> 2018-01-19 15:52:53 CFY  [fixedip_vm00_91a2f] Creating node
> 2018-01-19 15:52:53 CFY  [dns_cm_4834b.create] Task started 
> 'dnsdesig.dns_plugin.aneeded'
> 2018-01-19 15:52:53 CFY  [dns_vm00_73f5a.create] Task started 
> 'dnsdesig.dns_plugin.aneeded'
> 2018-01-19 15:52:53 CFY  [dns_cm_4834b.create] Task failed 
> 'dnsdesig.dns_plugin.aneeded' -> 'dns'
> 2018-01-19 15:52:53 CFY  'install' workflow execution failed: Workflow 
> failed: Task failed 'dnsdesig.dns_plugin.aneeded' -> 'dns'
> Workflow failed: Task failed 'dnsdesig.dns_plugin.aneeded' -> ‘dns'
> 
> Of course, the OpenStack on which I deploy DCAE doesn’t support DNS 
> Designate, I’m wondering what I could have missed?
> 
> Alexis
> 
>> On Jan 19, 2018, at 10:46 AM, Alexis de Talhouët <adetalhoue...@gmail.com 
>> <mailto:adetalhoue...@gmail.com>> wrote:
>> 
>> Bin,
>> 
>> Awesome, I got it to work with my OpenStack Pike instance. 
>> 
>> One issue though, the register_multicloud_pod25dns_with_aai() is using 
>> hardcoded username/password 
>> https://gerrit.onap.org/r/gitweb?p=demo.git;a=blob;f=boot/dcae2_vm_init.sh;h=b071dffd53f0a431bbdff1c1228edce8ecddef2d;hb=refs/heads/amsterdam
>>  
>> <https://gerrit.onap.org/r/gitweb?p=demo.git;a=blob;f=boot/dcae2_vm_init.sh;h=b071dffd53f0a431bbdff1c1228edce8ecddef2d;hb=refs/heads/amsterdam>
>> 
>> I opened DCAEGEN2-270 <https://jira.onap.org/browse/DCAEGEN2-270> and 
>> submitted the fix https://gerrit.onap.org/r/#/c/28673/ 
>> <https://gerrit.onap.org/r/#/c/28673/>
>> 
>> Current workaround is to push the data in AAI prior to having the script 
>> running. So the put request will fail, but the validation will pass.
>> 
>> Alexis
>> 
>>> On Jan 19, 2018, at 12:10 AM, Yang, Bin <bin.y...@windriver.com 
>>> <mailto:bin.y...@windriver.com>> wrote:
>>> 
>>> Hi Alexis,
>>> 
>>> Please refer to answers embedded below
>>> 
>>> Best Regards,
>>> Bin Yang,Solution Readiness Team,Wind River
>>> Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189
>>> Skype: yangbincs993
>>> 
>>> -Original Message-
>>> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
>>> <mailto:adetalhoue...@gmail.com>] 
>>> Sent: Friday, January 19, 2018 10:30 AM
>>> To: Yang, Bin
>>> Cc: onap-discuss
>>> Subject: Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with 
>>> Multicloud Titanium
>>> 
>>> Hi Bin,
>>> 
>>> So if I understand correctly, I should register the VIM in multi cloud (do 
>>> you have an example or a link on how to ) and DCAE will be able to use it 
>>> to proxy DNS request (DNSaaS) to this instance. I was under the impression 
>>> it was hard coded to pod25 in the DCAE boostrap script, I’ll look again.
>>> 
>>> 
>>> [Bin] Yes, pod25 was hard coded in DCAE bootstrap script, but it is just 
>>> the cloud owner name, most related information that DCAE bootstrap uses to 
>>> register a VIM instance are passed by HEAT template ( I believe OOM could 
>>> support that parameter injection , correct?)
>>> 
>>> I’m glad this is already there then, I guess I got confused while reading 
>>> the script. I’ll try this tomorrow.
>>> [Bin] I think it is the hardcoded 'titanium_cloud' in that script to 
>>> confuse you. This could be changed to be a parameter passing by HEAT/OOM. 
>>> But right now MultiCloud plugin for titanium_cloud support vanilla 
>>> OpenStack version like ocata, mitaka, newton as well. I didn't try the 
>>> pike, but there is big chance that pike can be supported without any 
>>> modification.  
>>> 
>>> So you confirm I can already use the proxy setup provided by DCAE to use a 
>>> proxy for DNS Desginate other than the OpenLab one?
>>> 
>>> I have OpenStack Pike, would that work?
>>> [Bin] I didn't test with pike yet,  you can give it a try  .
>>>

Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with Multicloud Titanium

2018-01-19 Thread Alexis de Talhouët
Hum, actually, the DNS zone registration works. But now, the boot container is 
failing with the following:

2018-01-19 15:52:53 CFY  [dns_cm_4834b.create] Sending task 
'dnsdesig.dns_plugin.aneeded'
2018-01-19 15:52:53 CFY  [dns_vm00_73f5a.create] Sending task 
'dnsdesig.dns_plugin.aneeded'
2018-01-19 15:52:53 CFY  [fixedip_vm00_91a2f] Creating node
2018-01-19 15:52:53 CFY  [dns_cm_4834b.create] Task started 
'dnsdesig.dns_plugin.aneeded'
2018-01-19 15:52:53 CFY  [dns_vm00_73f5a.create] Task started 
'dnsdesig.dns_plugin.aneeded'
2018-01-19 15:52:53 CFY  [dns_cm_4834b.create] Task failed 
'dnsdesig.dns_plugin.aneeded' -> 'dns'
2018-01-19 15:52:53 CFY  'install' workflow execution failed: Workflow 
failed: Task failed 'dnsdesig.dns_plugin.aneeded' -> 'dns'
Workflow failed: Task failed 'dnsdesig.dns_plugin.aneeded' -> ‘dns'

Of course, the OpenStack on which I deploy DCAE doesn’t support DNS Designate, 
I’m wondering what I could have missed?

Alexis

> On Jan 19, 2018, at 10:46 AM, Alexis de Talhouët <adetalhoue...@gmail.com> 
> wrote:
> 
> Bin,
> 
> Awesome, I got it to work with my OpenStack Pike instance. 
> 
> One issue though, the register_multicloud_pod25dns_with_aai() is using 
> hardcoded username/password 
> https://gerrit.onap.org/r/gitweb?p=demo.git;a=blob;f=boot/dcae2_vm_init.sh;h=b071dffd53f0a431bbdff1c1228edce8ecddef2d;hb=refs/heads/amsterdam
>  
> <https://gerrit.onap.org/r/gitweb?p=demo.git;a=blob;f=boot/dcae2_vm_init.sh;h=b071dffd53f0a431bbdff1c1228edce8ecddef2d;hb=refs/heads/amsterdam>
> 
> I opened DCAEGEN2-270 <https://jira.onap.org/browse/DCAEGEN2-270> and 
> submitted the fix https://gerrit.onap.org/r/#/c/28673/ 
> <https://gerrit.onap.org/r/#/c/28673/>
> 
> Current workaround is to push the data in AAI prior to having the script 
> running. So the put request will fail, but the validation will pass.
> 
> Alexis
> 
>> On Jan 19, 2018, at 12:10 AM, Yang, Bin <bin.y...@windriver.com 
>> <mailto:bin.y...@windriver.com>> wrote:
>> 
>> Hi Alexis,
>> 
>> Please refer to answers embedded below
>> 
>> Best Regards,
>> Bin Yang,Solution Readiness Team,    Wind River
>> Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189
>> Skype: yangbincs993
>> 
>> -Original Message-
>> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
>> <mailto:adetalhoue...@gmail.com>] 
>> Sent: Friday, January 19, 2018 10:30 AM
>> To: Yang, Bin
>> Cc: onap-discuss
>> Subject: Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with 
>> Multicloud Titanium
>> 
>> Hi Bin,
>> 
>> So if I understand correctly, I should register the VIM in multi cloud (do 
>> you have an example or a link on how to ) and DCAE will be able to use it to 
>> proxy DNS request (DNSaaS) to this instance. I was under the impression it 
>> was hard coded to pod25 in the DCAE boostrap script, I’ll look again.
>> 
>> 
>> [Bin] Yes, pod25 was hard coded in DCAE bootstrap script, but it is just the 
>> cloud owner name, most related information that DCAE bootstrap uses to 
>> register a VIM instance are passed by HEAT template ( I believe OOM could 
>> support that parameter injection , correct?)
>> 
>> I’m glad this is already there then, I guess I got confused while reading 
>> the script. I’ll try this tomorrow.
>> [Bin] I think it is the hardcoded 'titanium_cloud' in that script to confuse 
>> you. This could be changed to be a parameter passing by HEAT/OOM. But right 
>> now MultiCloud plugin for titanium_cloud support vanilla OpenStack version 
>> like ocata, mitaka, newton as well. I didn't try the pike, but there is big 
>> chance that pike can be supported without any modification.  
>> 
>> So you confirm I can already use the proxy setup provided by DCAE to use a 
>> proxy for DNS Desginate other than the OpenLab one?
>> 
>> I have OpenStack Pike, would that work?
>> [Bin] I didn't test with pike yet,  you can give it a try  .
>> 
>> 
>> OOM does already provide the support for this in Amsterdam. I guess what I 
>> was looking for is a proxy setup using plain OpenStack APIs.  and not using 
>> Multicloud. But I’m all in for using Multicloud if available and working 
>> already.
>> 
>> [Bin]: I do think it will be valuable that OOM provide such kind of support 
>> and I can share what I learned and hope you get more comprehensive 
>> understanding of the requirement/solutions.
>> 
>> Thanks,
>> Alexis
>> 
>>> On Jan 18, 2018, at 8:58 PM, Yang, Bin <bin.y...@windriver.com 
>>> <mailto:b

Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with Multicloud Titanium

2018-01-19 Thread Alexis de Talhouët
Bin,

Awesome, I got it to work with my OpenStack Pike instance. 

One issue though, the register_multicloud_pod25dns_with_aai() is using 
hardcoded username/password 
https://gerrit.onap.org/r/gitweb?p=demo.git;a=blob;f=boot/dcae2_vm_init.sh;h=b071dffd53f0a431bbdff1c1228edce8ecddef2d;hb=refs/heads/amsterdam
 
<https://gerrit.onap.org/r/gitweb?p=demo.git;a=blob;f=boot/dcae2_vm_init.sh;h=b071dffd53f0a431bbdff1c1228edce8ecddef2d;hb=refs/heads/amsterdam>

I opened DCAEGEN2-270 <https://jira.onap.org/browse/DCAEGEN2-270> and submitted 
the fix https://gerrit.onap.org/r/#/c/28673/ 
<https://gerrit.onap.org/r/#/c/28673/>

Current workaround is to push the data in AAI prior to having the script 
running. So the put request will fail, but the validation will pass.

Alexis

> On Jan 19, 2018, at 12:10 AM, Yang, Bin <bin.y...@windriver.com> wrote:
> 
> Hi Alexis,
> 
> Please refer to answers embedded below
> 
> Best Regards,
> Bin Yang,Solution Readiness Team,Wind River
> Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189
> Skype: yangbincs993
> 
> -Original Message-
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Friday, January 19, 2018 10:30 AM
> To: Yang, Bin
> Cc: onap-discuss
> Subject: Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with 
> Multicloud Titanium
> 
> Hi Bin,
> 
> So if I understand correctly, I should register the VIM in multi cloud (do 
> you have an example or a link on how to ) and DCAE will be able to use it to 
> proxy DNS request (DNSaaS) to this instance. I was under the impression it 
> was hard coded to pod25 in the DCAE boostrap script, I’ll look again.
> 
> 
> [Bin] Yes, pod25 was hard coded in DCAE bootstrap script, but it is just the 
> cloud owner name, most related information that DCAE bootstrap uses to 
> register a VIM instance are passed by HEAT template ( I believe OOM could 
> support that parameter injection , correct?)
> 
> I’m glad this is already there then, I guess I got confused while reading the 
> script. I’ll try this tomorrow.
> [Bin] I think it is the hardcoded 'titanium_cloud' in that script to confuse 
> you. This could be changed to be a parameter passing by HEAT/OOM. But right 
> now MultiCloud plugin for titanium_cloud support vanilla OpenStack version 
> like ocata, mitaka, newton as well. I didn't try the pike, but there is big 
> chance that pike can be supported without any modification.  
> 
> So you confirm I can already use the proxy setup provided by DCAE to use a 
> proxy for DNS Desginate other than the OpenLab one?
> 
> I have OpenStack Pike, would that work?
> [Bin] I didn't test with pike yet,  you can give it a try  .
> 
> 
> OOM does already provide the support for this in Amsterdam. I guess what I 
> was looking for is a proxy setup using plain OpenStack APIs.  and not using 
> Multicloud. But I’m all in for using Multicloud if available and working 
> already.
> 
> [Bin]: I do think it will be valuable that OOM provide such kind of support 
> and I can share what I learned and hope you get more comprehensive 
> understanding of the requirement/solutions.
> 
> Thanks,
> Alexis
> 
>> On Jan 18, 2018, at 8:58 PM, Yang, Bin <bin.y...@windriver.com> wrote:
>> 
>> Hi Alexis,
>> 
>>   I think it would be better to clarify that: proxy the DNS Designate 
>> requests is the enhanced feature by MultiCloud to federate services from 
>> different underlying VIM instances. In ONAP Amsterdam release it has been 
>> implemented to support both vanilla OpenStack Ocata (and Newton as well, not 
>> tested yet) and Titanium Cloud, and more to come in future releases. I had 
>> tested with vanilla OpenStack Ocata and it works well.
>> 
>>   To utilize it , the consumer presuppose that the MultiCloud services are 
>> ready and the VIM instances are registered. So for DCAEgen2 which has been 
>> the actually consumer in ONAP Amsterdam release, the bootstrap VM did this 
>> part , the VIM instance information (both underlying OpenStack and the 
>> proxied one which exposes Designate services) are passed in by HEAT 
>> template/environment file. I believe  OOM can support this in similar way.
>> 
>>   This federation can be designed/implemented in various way but why it was 
>> designed/implemented  is that MultiCloud do the federation and the consumers 
>> will be transparent with regards who provides DNSaaS services. 
>> 
>> BTW,I do think it will be valuable that OOM can offer the similar proxy 
>> to DNS designate, I would like to share our experiences.
>> 
>> Best Regards,
>> Bin Yang,Solution Readiness Team,Wind River

Re: [onap-discuss] [ONAP Helpdesk #51126] [integration] nexus.onap.org is down

2018-01-19 Thread Alexis de Talhouët via RT
Hi,

nexus.onap.org  and nexu3.onap.org 
 seems to be down again.

Alexis

> On Jan 15, 2018, at 2:08 PM, Jessica Wagantall via RT 
>  wrote:
> 
> Should be back now
> 
> Thanks!
> 
> On Mon Jan 15 14:08:01 2018, jwagantall wrote:
>> Our team is looking into it now.
>> 
>> thanks a ton and sorry for the inconvenience
>> Jess
>> 
>> On Mon Jan 15 13:14:35 2018, gary.i...@huawei.com wrote:
>>> Hi helpdesk,
>>> 
>>> Nexus.onap.org is currently returning 502 Bad Gateway.  Can you take
>>> a look?
>>> 
>>> Thanks,
>>> Gary
>>> 
>>> 
> 
> 
> 
> ___
> 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 Helpdesk #51126] [integration] nexus.onap.org is down

2018-01-19 Thread Alexis de Talhouët
Hi,

nexus.onap.org  and nexu3.onap.org 
 seems to be down again.

Alexis

> On Jan 15, 2018, at 2:08 PM, Jessica Wagantall via RT 
>  wrote:
> 
> Should be back now
> 
> Thanks!
> 
> On Mon Jan 15 14:08:01 2018, jwagantall wrote:
>> Our team is looking into it now.
>> 
>> thanks a ton and sorry for the inconvenience
>> Jess
>> 
>> On Mon Jan 15 13:14:35 2018, gary.i...@huawei.com wrote:
>>> Hi helpdesk,
>>> 
>>> Nexus.onap.org is currently returning 502 Bad Gateway.  Can you take
>>> a look?
>>> 
>>> Thanks,
>>> Gary
>>> 
>>> 
> 
> 
> 
> ___
> 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] Service distribution error on latest ONAP/OOM

2018-01-19 Thread Alexis de Talhouët
Hi,

Could you look at the log of Policy for errors, for that you need to go in the 
pod themselves, under /var/log/onap.
You could do the same for SDC container (backend).
The thing that could have affect Policy is the fact we removed the persisted 
data of mariadb, because it was bogus (https://gerrit.onap.org/r/#/c/27521/ 
). But I doubt it does explain your issue.
Beside that, nothing having a potential disruptive effect happen to policy.
The DCAE work was well tested before it got merged. I’ll re-test sometime today 
or early next week to make sure nothing has slept through the crack.

Thanks,
Alexis

> On Jan 18, 2018, at 11:44 PM, Ramanarayanan, Karthick  
> wrote:
> 
> Hi,
>  Trying to distribute a demo firewall service instance on a kubernetes host 
> running ONAP, I am seeing a new policy exception error on the latest oom on 
> amsterdam.
> (dcae deploy is false and disableDcae is true)
> 
> Error code: POL5000
> Status code: 500
> Internal Server Error. Please try again later.
> 
> All pods are up. Health check seems to be fine on all pods.
> k8s pod logs don't seem to reveal anything and this happens consistently 
> whenever I try to distribute the service as an operator.
> 
> It was working fine last week. 
> Even yesterday I didn't get this error though I got a different one related 
> createVnfInfra notify exception on SO vnf create workflow step but that was a 
> different failure than this.
> 
> After the dcae config changes got merged, this service distribution error 
> seems to have popped up. (dcae is disabled for my setup)
> 
> 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] [DCAGEN2] Proxied DNS Designate only with Multicloud Titanium

2018-01-18 Thread Alexis de Talhouët
Hi Bin,

So if I understand correctly, I should register the VIM in multi cloud (do you 
have an example or a link on how to ) and DCAE will be able to use it to proxy 
DNS request (DNSaaS) to this instance. I was under the impression it was hard 
coded to pod25 in the DCAE boostrap script, I’ll look again.

I’m glad this is already there then, I guess I got confused while reading the 
script. I’ll try this tomorrow.

So you confirm I can already use the proxy setup provided by DCAE to use a 
proxy for DNS Desginate other than the OpenLab one?

I have OpenStack Pike, would that work?

OOM does already provide the support for this in Amsterdam. I guess what I was 
looking for is a proxy setup using plain OpenStack APIs.  and not using 
Multicloud. But I’m all in for using Multicloud if available and working 
already.

Thanks,
Alexis

> On Jan 18, 2018, at 8:58 PM, Yang, Bin <bin.y...@windriver.com> wrote:
> 
> Hi Alexis,
> 
>I think it would be better to clarify that: proxy the DNS Designate 
> requests is the enhanced feature by MultiCloud to federate services from 
> different underlying VIM instances. In ONAP Amsterdam release it has been 
> implemented to support both vanilla OpenStack Ocata (and Newton as well, not 
> tested yet) and Titanium Cloud, and more to come in future releases. I had 
> tested with vanilla OpenStack Ocata and it works well.
> 
>To utilize it , the consumer presuppose that the MultiCloud services are 
> ready and the VIM instances are registered. So for DCAEgen2 which has been 
> the actually consumer in ONAP Amsterdam release, the bootstrap VM did this 
> part , the VIM instance information (both underlying OpenStack and the 
> proxied one which exposes Designate services) are passed in by HEAT 
> template/environment file. I believe  OOM can support this in similar way.
> 
>This federation can be designed/implemented in various way but why it was 
> designed/implemented  is that MultiCloud do the federation and the consumers 
> will be transparent with regards who provides DNSaaS services. 
> 
> BTW,I do think it will be valuable that OOM can offer the similar proxy 
> to DNS designate, I would like to share our experiences.
> 
> Best Regards,
> Bin Yang,Solution Readiness Team,Wind River
> Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189
> Skype: yangbincs993
> 
> -Original Message-
> From: onap-discuss-boun...@lists.onap.org 
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët
> Sent: Friday, January 19, 2018 6:34 AM
> To: onap-discuss
> Subject: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with Multicloud 
> Titanium
> 
> Hi experts,
> 
> In the dcae_vm_init.sh script, we have the possibility to proxy the DNS 
> Designate requests to an OpenStack other than the one on which we spawn DCAE.
> But this feature only allow to proxy to Multicloud Titanium cloud, it doesn’t 
> allow to proxy to an other plain OpenStack instance.
> I was wondering whether a contribution to address this is Amsterdam would be 
> accepted, if yes, I can do it.
> 
> Basically, I’d like to leverage the dnaas_* config bits to establish a 
> connection to an OpenStack directly, instead of using Multi-cloud.
> I would have a add a param to let the user choose whether the use Multicloud 
> Titanium or plain OpenStack.
> 
> Please, let me know what you think of this?
> 
> FYI, I tend to think we should be able to have DNS Designate running where 
> ever we want in the infra, as long as it’s provided. Moreover, we’re working 
> on providing it in OOM, so it’s not required in ppl infra.
> 
> Thanks,
> Alexis
> 
> 
> ___
> 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


[onap-discuss] [DCAGEN2] Proxied DNS Designate only with Multicloud Titanium

2018-01-18 Thread Alexis de Talhouët
Hi experts,

In the dcae_vm_init.sh script, we have the possibility to proxy the DNS 
Designate requests to an OpenStack other than the one on which we spawn DCAE.
But this feature only allow to proxy to Multicloud Titanium cloud, it doesn’t 
allow to proxy to an other plain OpenStack instance.
I was wondering whether a contribution to address this is Amsterdam would be 
accepted, if yes, I can do it.

Basically, I’d like to leverage the dnaas_* config bits to establish a 
connection to an OpenStack directly, instead of using Multi-cloud.
I would have a add a param to let the user choose whether the use Multicloud 
Titanium or plain OpenStack.

Please, let me know what you think of this?

FYI, I tend to think we should be able to have DNS Designate running where ever 
we want in the infra, as long as it’s provided. Moreover, we’re working on 
providing it in OOM, so it’s not required in ppl infra.

Thanks,
Alexis


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


Re: [onap-discuss] [**EXTERNAL**] oom openstack config in the pod lab

2018-01-18 Thread Alexis de Talhouët
Gary,

For now Amsterdam branch has been highly tested. I’m starting the work on the 
master branch.
So please use Amsterdam branch for now.

Regarding the issue you faced with the init container, this should be fix 
now.You could try to re-pull the config-init:2.0.0-SNAPSHOT image (for master)

The config container does provision directory, and it does also a bunch of sed 
command to inject parameters, Those sed commands is what is taking most of the 
time, because we loop blindly over all the directories, instead of targeting 
the sed more precisely. I’m currently working on improving this for Amsterdam, 
and will cherry-pick on master once ready.

Thanks,
Alexis

> On Jan 18, 2018, at 12:49 PM, Gary Wu <gary.i...@huawei.com> wrote:
> 
> Are we mainly testing against OOM amsterdam branch, or master?
>  
> In the master branch, the config container complains about other parameters 
> missing like NEXUS_REPO or something.  Is the OOM master branch stable enough 
> for us to try now?  If so, can you share your sample parameters file for the 
> master branch?
>  
> As an aside, does anyone know why the config container takes 2 to 3 minutes 
> to complete?  Seems to be a long time for creating shared config directories, 
> or maybe my environment is not set up right somehow.
> 
> Thanks,
> Gary
>  
> From: onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org> 
> [mailto:onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of Alexis de Talhouët
> Sent: Thursday, January 18, 2018 9:14 AM
> To: PLATANIA, MARCO (MARCO) <plata...@research.att.com 
> <mailto:plata...@research.att.com>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [**EXTERNAL**] oom openstack config in the pod lab
>  
> Marco,
>  
> Well that’s the thing I’m currently looking at. I know Robot needs them for 
> whatever reason.
>  
> I’m currently about to test a deployment without those parameters, because as 
> you pointed out, they don’t necessarily make sense for OOM.
>  
> I have to validate this, but I’m validating other thing at the same time. 
> Because with the introduction of DCAE, we potentially can configure tree 
> different OpenStack:
>  
> - 1 where to deploy VNF
> - 1 where to deploy DCAE
> - 1 where DNS Designate is supported
>  
> So I’m re-doing the onap-parameters.yaml to take this in consideration. Note, 
> it could also be the same OpenStack instance for all of them, but as the 
> flexibility is giving to us
> by DCAE, let’s leverage this.
>  
> Moreover, this separation is useful when going in prod.
>  
> Alexis
> 
> 
> On Jan 18, 2018, at 12:06 PM, PLATANIA, MARCO (MARCO) 
> <plata...@research.att.com <mailto:plata...@research.att.com>> wrote:
>  
> Alexis,
>  
> What are these parameters used for in OOM?
>  
> OPENSTACK_UBUNTU_14_IMAGE: "ubuntu-14-04-cloud-amd64"
> OPENSTACK_PUBLIC_NET_ID: "971040b2-7059-49dc-b220-4fab50cb2ad4"
> OPENSTACK_OAM_NETWORK_ID: "31b5d82c-bfd3-44bf-a830-4bc0b628013f"
> OPENSTACK_OAM_SUBNET_ID: "658d0e1b-8e2c-45c3-94e3-e7a1df1ed475"
> OPENSTACK_OAM_NETWORK_CIDR: "10.10.2.0/24"
>  
> We had them for Heat, to tell the Orchestrator what image and network to use 
> when creating ONAP VMs. For vFW/vLB use cases, those parameters are passed as 
> SDNC preload.
>  
> Marco
>  
> From: <onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>> on behalf of Alexis de Talhouët 
> <adetalhoue...@gmail.com <mailto:adetalhoue...@gmail.com>>
> Date: Thursday, January 18, 2018 at 11:47 AM
> To: Pavel Paroulek <parou...@objectify.sk <mailto:parou...@objectify.sk>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [**EXTERNAL**] oom openstack config in the pod lab
>  
> Hi,
>  
> I don’t know which tenant you’re using, but for the OOM tenant, here is my 
> onap-parameters.yaml file.
>  
> Note: this was my parameters two months ago, I do not guarantee the values 
> are still accurate.
>  
> # Look at the images
> OPENSTACK_UBUNTU_14_IMAGE: "ubuntu-14-04-cloud-amd64"
> # Look at the networks
> OPENSTACK_PUBLIC_NET_ID: "971040b2-7059-49dc-b220-4fab50cb2ad4"
> OPENSTACK_OAM_NETWORK_ID: "31b5d82c-bfd3-44bf-a830-4bc0b628013f"
> OPENSTACK_OAM_SUBNET_ID: "658d0e1b-8e2c-45c3-94e3-e7a1df1ed475"
> OPENSTACK_OAM_NETWORK_CIDR: "10.10.2.0/24"
> # your credentials
> OPENSTACK_USERNAME: “

Re: [onap-discuss] [**EXTERNAL**] oom openstack config in the pod lab

2018-01-18 Thread Alexis de Talhouët
Marco,

Well that’s the thing I’m currently looking at. I know Robot needs them for 
whatever reason.

I’m currently about to test a deployment without those parameters, because as 
you pointed out, they don’t necessarily make sense for OOM.

I have to validate this, but I’m validating other thing at the same time. 
Because with the introduction of DCAE, we potentially can configure tree 
different OpenStack:

- 1 where to deploy VNF
- 1 where to deploy DCAE
- 1 where DNS Designate is supported

So I’m re-doing the onap-parameters.yaml to take this in consideration. Note, 
it could also be the same OpenStack instance for all of them, but as the 
flexibility is giving to us
by DCAE, let’s leverage this.

Moreover, this separation is useful when going in prod.

Alexis

> On Jan 18, 2018, at 12:06 PM, PLATANIA, MARCO (MARCO) 
> <plata...@research.att.com> wrote:
> 
> Alexis,
>  
> What are these parameters used for in OOM?
>  
> OPENSTACK_UBUNTU_14_IMAGE: "ubuntu-14-04-cloud-amd64"
> OPENSTACK_PUBLIC_NET_ID: "971040b2-7059-49dc-b220-4fab50cb2ad4"
> OPENSTACK_OAM_NETWORK_ID: "31b5d82c-bfd3-44bf-a830-4bc0b628013f"
> OPENSTACK_OAM_SUBNET_ID: "658d0e1b-8e2c-45c3-94e3-e7a1df1ed475"
> OPENSTACK_OAM_NETWORK_CIDR: "10.10.2.0/24"
>  
> We had them for Heat, to tell the Orchestrator what image and network to use 
> when creating ONAP VMs. For vFW/vLB use cases, those parameters are passed as 
> SDNC preload.
>  
> Marco
>  
> From: <onap-discuss-boun...@lists.onap.org 
> <mailto:onap-discuss-boun...@lists.onap.org>> on behalf of Alexis de Talhouët 
> <adetalhoue...@gmail.com <mailto:adetalhoue...@gmail.com>>
> Date: Thursday, January 18, 2018 at 11:47 AM
> To: Pavel Paroulek <parou...@objectify.sk <mailto:parou...@objectify.sk>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [**EXTERNAL**] oom openstack config in the pod lab
>  
> Hi,
>  
> I don’t know which tenant you’re using, but for the OOM tenant, here is my 
> onap-parameters.yaml file.
>  
> Note: this was my parameters two months ago, I do not guarantee the values 
> are still accurate.
>  
> # Look at the images
> OPENSTACK_UBUNTU_14_IMAGE: "ubuntu-14-04-cloud-amd64"
> # Look at the networks
> OPENSTACK_PUBLIC_NET_ID: "971040b2-7059-49dc-b220-4fab50cb2ad4"
> OPENSTACK_OAM_NETWORK_ID: "31b5d82c-bfd3-44bf-a830-4bc0b628013f"
> OPENSTACK_OAM_SUBNET_ID: "658d0e1b-8e2c-45c3-94e3-e7a1df1ed475"
> OPENSTACK_OAM_NETWORK_CIDR: "10.10.2.0/24"
> # your credentials
> OPENSTACK_USERNAME: “YOUR_USER"
> OPENSTACK_API_KEY: “YOUR_PASSWORD"
> # the tenant to use, the name and id
> OPENSTACK_TENANT_NAME: "OOM"
> OPENSTACK_TENANT_ID: "dbe658c72ee7426fa979e319fd8cacc7"
> # the cloud region, usually RegionOne for OpenStack
> OPENSTACK_REGION: “RegionOne"
> # keystone URL
> OPENSTACK_KEYSTONE_URL: "http://10.12.25.2:5000 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__10.12.25.2-3A5000=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=KgFIQiUJzSC0gUhJaQxg8eC3w16GC3sKgWIcs4iIee0=P30mexfy2QtZzF7TJbV-bBD__vyMnWre376ngo3OcR4=0CFvSpWFDKqJm9p089ICYZeVCVzHIOJtYGirkajpt3M=>"
> # Look at the flavor
> OPENSTACK_FLAVOUR_MEDIUM: "m1.medium”
> # Let them as is
> OPENSTACK_SERVICE_TENANT_NAME: "service"
> DMAAP_TOPIC: "AUTO"
> DEMO_ARTIFACTS_VERSION: “1.1.1"
>  
> Thanks,
> Alexis
> 
> 
>> On Jan 18, 2018, at 11:41 AM, Pavel Paroulek <parou...@objectify.sk 
>> <mailto:parou...@objectify.sk>> wrote:
>>  
>> Hi Alexis, 
>>  
>> does it make sense to provide sample values (in the sample config file) for 
>> the winriver pod lab or a description how to obtain them? For example I am 
>> not allowed (403) to read the openstack services so I am not sure how to get 
>> the service tenant name (maybe I am using the wrong command). It would also 
>> be interesting to know what subset of these config keys is mandatory (if 
>> any) and which are optional.
>>  
>> Br,
>> Pavel
>> 
>>  
>>  On Thu, 18 Jan 2018 17:28:57 +0100 Alexis de 
>> Talhouët<adetalhoue...@gmail.com <mailto:adetalhoue...@gmail.com>> wrote 
>>  
>>> Hello, 
>>>  
>>> The onap-parameters.yaml file have significantly changed on Amsterdam, 
>>> since the work to get DCAE deployed by OOM has been merged.
>>>  
>>> I’m currently re-working this file, to first: add explanation for every 
>>> parameters, and second, to make it more modulable. 
>>>

Re: [onap-discuss] [SO][SDC]Distribution Client Register Failed.

2018-01-16 Thread Alexis de Talhouët
Hi,

How do you know it’s picking the asdc-contoller1 config to connect?
What I’ve noticed is SO comes with two pre-configured asdc-controllers, but the 
thing is, one is a dummy one (asdc-controller2), but the asdc code in SO will 
try to establish the connection to all the controllers provided in the 
asdc-connections list, hence the issue you’re facing. You probably are seeing 
the logs of the second one, and the first one has successfully connect.
Try removing the dummy asdc-controller entry, and restart SO. I tend to think 
the stacktrace you mentioned will disappear.

Alexis

> On Jan 15, 2018, at 9:29 PM, Chenchuanyu  wrote:
> 
> Hi SDC Team,
>I found that Distribution Client of SO cannot registered successful to SDC.
> Below is the errormso.log and the SDC configuration , asdc-controller1 is 
> used to register the distribution client. The response message from SDC is 
> CONF_INVALID_ASDC_FQDN.
> Because of this SO cannot get the template information designed in SDC, can 
> anyone help on this?
>  
> 2017-12-02T23:25:30.003Z|trace-#|EJB default - 
> 9|InitASDC||ASDC||WARN|BusinessProcesssError|ASDCControllerException in 
> checkInStoppedState|Exception raised: 
> org.openecomp.mso.asdc.client.exceptions.ASDCControllerException: 
> Initialization of the ASDC Controller failed with reason: configuration is 
> invalid: CONF_INVALID_ASDC_FQDN -   at 
> org.openecomp.mso.asdc.client.ASDCController.initASDC(ASDCController.java:237)
>  -   at 
> org.openecomp.mso.asdc.client.ASDCGlobalController.checkInStoppedState(ASDCGlobalController.java:130)
>  -  at 
> org.openecomp.mso.asdc.ASDCControllerSingleton.periodicControllerTask(ASDCControllerSingleton.java:63)
>  -  at sun.reflect.GeneratedMethodAccessor367.invoke(Unknown Source) -
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  -at java.lang.reflect.Method.invoke(Method.java:498) -at 
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>  -   at 
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) 
> -  at 
> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:57)
>  - at 
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:61)
>  - at 
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) 
> -  at 
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>  - at 
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
>  -at 
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:95)
>  -   at 
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:61)
>  - at 
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) 
> -  at 
> org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:57)
>  - at 
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:61)
>  - at 
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) 
> -  at 
> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>  -  at 
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) 
> -  at 
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>  - at 
> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
>  -   at 
> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>  -  at 
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) 
> -  at 
>  
> {
> "asdc-connections":{
> "asdc-controller1":{
> "user":"mso",
> "consumerGroup":"sdc-OpenSource-Env1-mso-dockero",
> "consumerId":"sdc-COpenSource-Env11-mso-dockero",
> "environmentName":"SDC-OpenSource-Env1",
> "asdcAddress":"c2.vm1.sdc.simpledemo.openecomp.org:8443 
> ",
> 
> "password":"613AF3483E695524F9857643B697FA51C7A9A0951094F53791485BF3458F9EADA37DBACCCEBD0CB242B85B4062745247",
> "pollingInterval":"60",
> "pollingTimeout":"60",
> "relevantArtifactTypes":"HEAT,HEAT_ENV,HEAT_VOL",
> "activateServerTLSAuth":"false",
> "keyStorePassword":"",
> "keyStorePath":""
> },
> "asdc-controller2":{
> 

Re: [onap-discuss] [OOM] - restart pod behavoir with SDNC data

2018-01-16 Thread Alexis de Talhouët
Hi Brian,

Resiliency is part of this epic: OOM-346  
and it has not being done yet.

I tend to think ODL data is not being persisted in the SDNC-163 
 so we will have to address this, 
whether it’s for master or amsterdam.
Also, I’m not sure we should persist to whole ODL deployment 
(/opt/opendaylight/current), but instead have a mechanism that creates 
regularly snapshots and backup those upon restart (like 
cluster-admin:backup-datastore 

 or daexim 
, 
that I’m sure you already know)

Alexis

> On Jan 15, 2018, at 5:46 PM, FREEMAN, BRIAN D  wrote:
> 
> Michael, Alexis,
>  
> I did a test where I created an OOM environment, sent preload into SDNC and 
> then deleted the SDNC Pod.
> K8 restarted the POD but the data saved to SDNC wasnt there.
> This was Amsterdam.
>  
> Do we need to have the /opt/opendaylight/current/ directory persisted (or 
> current/journal) ?
>  
> I think the clustering team may have addressed this as well but cold recovery 
> of an SDNC cluster created by OOM requires something stored on the hard disk.
>  
> Brian
>  
> ___
> 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] [Policy][TCA] Relationship between Policy and tca_policy

2018-01-15 Thread Alexis de Talhouët
Pam,

Thanks for the answer, I understand the gap now.
I also understand the need for resources, when I’ll have spare cycles, I’ll 
jump in the weekly meetings. But I’m currently very invested in OOM.

Regards,
Alexis

> On Jan 15, 2018, at 8:20 AM, DRAGOSH, PAMELA L (PAM) 
> <pdrag...@research.att.com> wrote:
> 
> Alexis,
> 
> During Amsterdam post-RC1 it was determined that the DCAE team had 
> expectations for the Policy API that would not work in their architecture. It 
> was too late for Policy to make change the API to accommodate them. Thus, any 
> updates will not work. I don’t know what the workaround is for DCAE as Policy 
> does work with updates.
> 
> It was agreed to fix it in Beijing: POLICY-434 and DCAEGEN2196 are tracking 
> this.
> 
> Regards,
> 
> Pam
> 
> Ps I can’t emphasize enough that help these teams (POLICY, DCAE, etc) need 
> from other companies. These projects are not finished yet. In fact, DCAEGEN2 
> is brand new. There is still a lot of work to be done and I ask other 
> companies within ONAP to help provide resources to harden, test and help fix 
> issues.
> 
> On 1/12/18, 3:13 PM, "onap-discuss-boun...@lists.onap.org on behalf of Alexis 
> de Talhouët" <onap-discuss-boun...@lists.onap.org on behalf of 
> adetalhoue...@gmail.com> wrote:
> 
>Hi experts,
> 
>I’m trying to understand how Policy works. Hence I tried to update the vFW 
> policy (MS) to reduce the thresholds. My expectation was to see this being 
> applied to the TCA application, but it seems it didn’t pick it up, tca_policy 
> in CDAP remained un-changed.
> 
>What should be the process to update a policy, and have this update 
> probably reflected in TCA?
> 
>Thanks,
>Alexis
>___
>onap-discuss mailing list
>onap-discuss@lists.onap.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=jwTiArcEj6aUX0HjV0M3dT12gUtk7rC07xpgpVZkS_4=HCMIEMWko9lPKkjqFMnASx5luljbnTjMLIClSlB0S2k=3jXal6Qt3V_-ZW1d6gBdbOelU5LhUqUydHHD6w7GuNI=
>  
> 
> 

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


[onap-discuss] [Policy][TCA] Relationship between Policy and tca_policy

2018-01-12 Thread Alexis de Talhouët
Hi experts,

I’m trying to understand how Policy works. Hence I tried to update the vFW 
policy (MS) to reduce the thresholds. My expectation was to see this being 
applied to the TCA application, but it seems it didn’t pick it up, tca_policy 
in CDAP remained un-changed.

What should be the process to update a policy, and have this update probably 
reflected in TCA?

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


Re: [onap-discuss] [DCAE] problems with dcae bootstrap VM

2018-01-12 Thread Alexis de Talhouët
Hi, Here is an example I faced, maybe it can help you.

To debug, I have done the following:

go in the boot container

docker exec -it boot bash
Activate the virtual environment created by the installer

source dcaeinstall/bin/activate
Run the command provided in the failed execution logs to see the logs output 
which might point to the failure

 Réduire la source
(dcaeinstall) installer@e6120e566d15:~/consul$ cfy events list --tail 
--include-logs --execution-id 3b9a6058-3b35-4406-a077-8430fff5a518
Listing events for execution id 3b9a6058-3b35-4406-a077-8430fff5a518 
[include_logs=True]
Execution of workflow install for deployment ves failed. [error=Traceback (most 
recent call last):
  File "/tmp/pip-build-c5GA7o/cloudify-plugins-common/cloudify/dispatch.py", 
line 472, in _remote_workflow_child_thread
  File "/tmp/pip-build-c5GA7o/cloudify-plugins-common/cloudify/dispatch.py", 
line 504, in _execute_workflow_function
  File 
"/opt/mgmtworker/env/lib/python2.7/site-packages/cloudify/plugins/workflows.py",
 line 27, in install
node_instances=set(ctx.node_instances))
  File 
"/opt/mgmtworker/env/lib/python2.7/site-packages/cloudify/plugins/lifecycle.py",
 line 28, in install_node_instances
processor.install()
  File 
"/opt/mgmtworker/env/lib/python2.7/site-packages/cloudify/plugins/lifecycle.py",
 line 83, in install
graph_finisher_func=self._finish_install)
  File 
"/opt/mgmtworker/env/lib/python2.7/site-packages/cloudify/plugins/lifecycle.py",
 line 103, in _process_node_instances
self.graph.execute()
  File 
"/opt/mgmtworker/env/lib/python2.7/site-packages/cloudify/workflows/tasks_graph.py",
 line 133, in execute
self._handle_terminated_task(task)
  File 
"/opt/mgmtworker/env/lib/python2.7/site-packages/cloudify/workflows/tasks_graph.py",
 line 207, in _handle_terminated_task
raise RuntimeError(message)
RuntimeError: Workflow failed: Task failed 
'dockerplugin.create_and_start_container_for_components_with_streams' -> 500 
Server Error: Internal Server Error ("{"message":"Get 
https://nexus3.onap.org:10001/v2/onap/org.onap.dcaegen2.collectors.ves.vescollector/manifests/v1.1.0:
 read tcp 10.0.0.13:46574-\u003e199.204.45.137:10001: read: no route to host"}")
]
Unfortunatly for me, Nexus decided to crap on me at the exact time it tried to 
query it...
Anyway, here try to understand the issue, and/or send the output to the 
mailing-list. In my case, I tried to uninstall and re-installed the ves and it 
worked.

Uninstall the failed deployment

 Réduire la source
(dcaeinstall) installer@e6120e566d15:~/consul$ cfy uninstall  -d ves

Install the deployment

(dcaeinstall) installer@e6120e566d15:~/consul$ cfy install -p 
./blueprints/ves/ves.yaml -b ves -d ves -i ../config/vesinput.yaml

Thanks,
Alexis


> On Jan 12, 2018, at 5:51 AM, ESWAR RAO  wrote:
> 
> Hi All,
> 
> I am using ONAP amsterdam release.
> 
> I am facing problems with DCAE bootstrapVM.
> 
> 
> 
> Can some one please help me in resolving the issue ??
> 
> 
> 
> # docker logs boot 
> 
> 2018-01-12 10:15:04 CFY  'install' workflow execution succeeded
> 
> Plugin validated successfully
> 
> Downloading from 
> https://nexus.onap.org/service/local/repositories/raw/content/org.onap.dcaegen2.platform.plugins/releases/plugins/relationshipplugin/relationshipplugin-1.0.0-py27-none-any.wgn
>  
> 
>  to 
> /tmp/tmpsd_8XB/relationshipplugin-1.0.0-py27-none-any.wgn
> Bootstrap failed! (HTTPSConnectionPool(host='nexus.onap.org 
> ', port=443): Read timed out.)
> Executing teardown due to failed bootstrap...
> 
> 2018-01-12 10:17:10 CFY  Starting 'uninstall' workflow execution
> 2018-01-12 10:17:37 CFY  'uninstall' workflow execution succeeded
> 
> 
> I think for small intermittent time-out , the uninstall workflow gets kick-in 
> and docker is killed.
> 
> root@onap-dcae-bootstrap:/home/ubuntu# docker ps -a
> CONTAINER IDIMAGE 
>   COMMAND  CREATED STATUS 
>  PORTS   NAMES
> 0f489b90232f
> nexus3.onap.org:10001/onap/org.onap.dcaegen2.deployments.bootstrap:v1.1.0 
> 
>"/bin/sh -c 'exec ..."   2 hours ago Exited (1) 35 minutes ago 
>   boot
> root@onap-dcae-bootstrap:/home/ubuntu#
> 
> | 596424a8-f38d-4dac-86a2-04c63603dbd0 | dcaeorcl00  | ACTIVE | 
> oam_onap_fKHc=10.0.0.5, 192.168.21.220   | centos-7 |
> 
> [root@dcaeorcl00 

Re: [onap-discuss] OOM Robot Distribute

2018-01-11 Thread Alexis de Talhouët
That’s a good solution Brian, not that we haven’t thought about it. 

We’re looking into un-forking every config bit we forked to integrate the fork 
we’ve done correctly in each project.

ONAP has 80+ containers, hence we forked config at first, but there is a long 
journey in front of us to un-fork things, and it’s not always as strait-forward 
as in this case.
Moreover, it implies ppl are willing to accept update to their config to 
satisfy OOM needs. In R1 we were told OOM isn’t the default deploy solution, so 
our updates were discarded.

Now Amsterdam is out, ppl are getting more aware of the mechanic of OOM. 
because it’s getting better. So Maybe now is a good time to fix things.

But the issue is slightly bigger than this. Basically, we should centralized 
configuration and derived properties of properties files from there. This way, 
we update only one place, and everybody is happy. But that’s another battle for 
another time.

Long story short, fork was easier for us to get where we are, but we always 
knew this was not a permanent solution: see OOM-10 
<https://jira.onap.org/browse/OOM-10>

Alexis

> On Jan 11, 2018, at 4:39 PM, FREEMAN, BRIAN D <bf1...@att.com> wrote:
> 
> So why not submit a change to testsuite so they split it into two IP’s and 
> modify the robot_vm_install.sh to ocpy the input into the two variable so 
> that we can use the same asdc_interface.robot for either HEAT or OOM ?
>  
> Testsuite will be adding to the asdc_interface.robot over time (as in this 
> case) .
>  
> I’m sure you dont want to maintain these files in OOM long term.
>  
> Brian
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Thursday, January 11, 2018 4:29 PM
> To: FREEMAN, BRIAN D <bf1...@att.com <mailto:bf1...@att.com>>
> Cc: onap-discuss@lists.onap.org <mailto:onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] OOM Robot Distribute
>  
> It’s the same IP address in the HEAT deployment. In OOM it’s not the same.
>  
> sdc-fe.onap-sdc for frontend —> GLOBAL_INJECTED_SDC_FE_IP_ADDR
> sdc-be.onap-sdc for backend —> GLOBAL_INJECTED_SDC_BE_IP_ADDR
>  
> Alexis
> 
> 
> On Jan 11, 2018, at 4:07 PM, FREEMAN, BRIAN D <bf1...@att.com 
> <mailto:bf1...@att.com>> wrote:
>  
> The front end and back of SDC are the same IP address so its not clear to me 
> why you had to change anything in the asdc_interface.robot ?
>  
> Brian
>  
>  
> root@onapoom3:/dockerdata-nfs/onap/robot/robot/resources# diff 
> asdc_interface.robot asdc_interface.robot.old
> 47,48c47,48
> < ${ASDC_FE_ENDPOINT} 
> ${GLOBAL_ASDC_SERVER_PROTOCOL}://${GLOBAL_INJECTED_SDC_IP_ADDR}:${GLOBAL_ASDC_FE_PORT}
> < ${ASDC_BE_ENDPOINT} 
> ${GLOBAL_ASDC_SERVER_PROTOCOL}://${GLOBAL_INJECTED_SDC_IP_ADDR}:${GLOBAL_ASDC_BE_PORT}
> ---
> > ${ASDC_FE_ENDPOINT} 
> > ${GLOBAL_ASDC_SERVER_PROTOCOL}://${GLOBAL_INJECTED_SDC_FE_IP_ADDR}:${GLOBAL_ASDC_FE_PORT}
> > ${ASDC_BE_ENDPOINT} 
> > ${GLOBAL_ASDC_SERVER_PROTOCOL}://${GLOBAL_INJECTED_SDC_BE_IP_ADDR}:${GLOBAL_ASDC_BE_PORT}
> 56d55
> < ${catalog_resources}=   Create Dictionary
> 62d60
> < \Set To Dictionary${catalog_resources}   
> ${loop_catalog_resource_id}=${loop_catalog_resource_resp}
> 74,75c72,73
> < [Return]${catalog_service_resp['name']}
> ${loop_catalog_resource_resp['name']}${vf_module}   
> ${catalog_resource_ids}${catalog_service_id}   ${catalog_resources}
> < 
> ---
> > [Return]${catalog_service_resp['name']}
> > ${loop_catalog_resource_resp['name']}${vf_module}   
> > ${catalog_resource_ids}${catalog_service_id}
> > 
> 297,298c295,296
> <  [Documentation]Creates an asdc Software Product and returns its id
> <  [Arguments]${software_product_id}${file_path}  
> ${version_id}=0.1
> ---
> > [Documentation]Creates an asdc Software Product and returns its id
> > [Arguments]${software_product_id}${file_path}   
> > ${version_id}=0.1
> 301,302c299,300
> <  ${resp}=Run ASDC Post Files Request   
> ${ASDC_VENDOR_SOFTWARE_PRODUCT_PATH}/${software_product_id}/versions/${version_id}${ASDC_VENDOR_SOFTWARE_UPLOAD_PATH}
>   ${files}${ASDC_DESIGNER_USER_ID}
> <  Should Be Equal As Strings          ${resp.status_code}   200
> ---
> > ${resp}=Run ASDC Post Files Request
> > ${ASDC_VENDOR_SOFTWARE_PRODUCT_PATH}/${software_product_id}/versions/${version_id}${ASDC_VENDOR_SOFTWARE_UPLOAD_PATH}
> >  ${files}${ASDC_DESIGNER_USER_ID}
> >   Should Be Equal As Strings  ${resp.status_code} 200
>  
> From: Alexis de Ta

Re: [onap-discuss] OOM Robot Distribute

2018-01-11 Thread Alexis de Talhouët
It’s the same IP address in the HEAT deployment. In OOM it’s not the same.

sdc-fe.onap-sdc for frontend —> GLOBAL_INJECTED_SDC_FE_IP_ADDR
sdc-be.onap-sdc for backend —> GLOBAL_INJECTED_SDC_BE_IP_ADDR

Alexis

> On Jan 11, 2018, at 4:07 PM, FREEMAN, BRIAN D <bf1...@att.com> wrote:
> 
> The front end and back of SDC are the same IP address so its not clear to me 
> why you had to change anything in the asdc_interface.robot ?
>  
> Brian
>  
>  
> root@onapoom3:/dockerdata-nfs/onap/robot/robot/resources# diff 
> asdc_interface.robot asdc_interface.robot.old
> 47,48c47,48
> < ${ASDC_FE_ENDPOINT} 
> ${GLOBAL_ASDC_SERVER_PROTOCOL}://${GLOBAL_INJECTED_SDC_IP_ADDR}:${GLOBAL_ASDC_FE_PORT}
> < ${ASDC_BE_ENDPOINT} 
> ${GLOBAL_ASDC_SERVER_PROTOCOL}://${GLOBAL_INJECTED_SDC_IP_ADDR}:${GLOBAL_ASDC_BE_PORT}
> ---
> > ${ASDC_FE_ENDPOINT} 
> > ${GLOBAL_ASDC_SERVER_PROTOCOL}://${GLOBAL_INJECTED_SDC_FE_IP_ADDR}:${GLOBAL_ASDC_FE_PORT}
> > ${ASDC_BE_ENDPOINT} 
> > ${GLOBAL_ASDC_SERVER_PROTOCOL}://${GLOBAL_INJECTED_SDC_BE_IP_ADDR}:${GLOBAL_ASDC_BE_PORT}
> 56d55
> < ${catalog_resources}=   Create Dictionary
> 62d60
> < \Set To Dictionary${catalog_resources}   
> ${loop_catalog_resource_id}=${loop_catalog_resource_resp}
> 74,75c72,73
> < [Return]${catalog_service_resp['name']}
> ${loop_catalog_resource_resp['name']}${vf_module}   
> ${catalog_resource_ids}${catalog_service_id}   ${catalog_resources}
> < 
> ---
> > [Return]${catalog_service_resp['name']}
> > ${loop_catalog_resource_resp['name']}${vf_module}   
> > ${catalog_resource_ids}${catalog_service_id}
> > 
> 297,298c295,296
> <  [Documentation]Creates an asdc Software Product and returns its id
> <  [Arguments]${software_product_id}${file_path}  
> ${version_id}=0.1
> ---
> > [Documentation]Creates an asdc Software Product and returns its id
> > [Arguments]${software_product_id}${file_path}   
> > ${version_id}=0.1
> 301,302c299,300
> <  ${resp}=Run ASDC Post Files Request   
> ${ASDC_VENDOR_SOFTWARE_PRODUCT_PATH}/${software_product_id}/versions/${version_id}${ASDC_VENDOR_SOFTWARE_UPLOAD_PATH}
>   ${files}${ASDC_DESIGNER_USER_ID}
> <  Should Be Equal As Strings  ${resp.status_code}   200
> ---
> > ${resp}=Run ASDC Post Files Request
> > ${ASDC_VENDOR_SOFTWARE_PRODUCT_PATH}/${software_product_id}/versions/${version_id}${ASDC_VENDOR_SOFTWARE_UPLOAD_PATH}
> >  ${files}${ASDC_DESIGNER_USER_ID}
> >   Should Be Equal As Strings  ${resp.status_code} 200
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Thursday, January 11, 2018 4:01 PM
> To: FREEMAN, BRIAN D <bf1...@att.com>
> Cc: onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] OOM Robot Distribute
>  
>  
> 
> 
> On Jan 11, 2018, at 4:00 PM, Alexis de Talhouët <adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>> wrote:
>  
> Robot can point to HEAT’s VM IP, whereas robot point to the service directly..
>  
> Not clear. In the HEAT setup, robot points to the SDC VM IP for that 
> resources, whereas for the OOM setup, we point directly to the frontend or 
> backend service.

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


Re: [onap-discuss] OOM Robot Distribute

2018-01-11 Thread Alexis de Talhouët


> On Jan 11, 2018, at 4:00 PM, Alexis de Talhouët <adetalhoue...@gmail.com> 
> wrote:
> 
> Robot can point to HEAT’s VM IP, whereas robot point to the service directly..

Not clear. In the HEAT setup, robot points to the SDC VM IP for that resources, 
whereas for the OOM setup, we point directly to the frontend or backend service.

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


Re: [onap-discuss] OOM Robot Distribute

2018-01-11 Thread Alexis de Talhouët
Brian,

For some reason, we had to fork asdc_interface.robot script, that’s why it’s 
not up-to-date, please create a ticket for this and assign it to me.
The reasons are hostname resolution are different from HEAT and OOM. Robot can 
point to HEAT’s VM IP, whereas robot point to the service directly..

Thanks,
Alexis

> On Jan 11, 2018, at 3:47 PM, FREEMAN, BRIAN D  wrote:
> 
> Alexis, Michael,
>  
> I was using robot ete-k8s.sh from amsterdam release and the version of 
> asdc_interface.robot in dockerdata-nfs was out of date.
> I cant seem to find where it got loaded from since the asdc_interface.robot 
> wasn’t compatible with the robot testsuite (the return parameter list from 
> Model Distribution in the testsuite didnt match the number returns by the 
> asdc-interface so an error of “16:03:12.828 FAIL   Cannot set 
> variables: Expected 6 return values, got 5.
> “ was being returned for each model that was distributed. The models did 
> successful distrubte but robot was failing on the check. When I did a git 
> clone and copy the asdc_interface.robot to the dockerdata-nfs directory for 
> robot ete-k8.sh distribute succeeded.
>  
> Is this just something I did in using cd.sh -b amsterdam or something else ?
>  
> Brian
>  
> ___
> 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


[onap-discuss] Did You Know?

2018-01-11 Thread Alexis de Talhouët

Did You Know?
OOM makes services available on any Node in a K8S cluster using a NodePort.
 
This allows a service to be reachable on any node in the cluster, using a 
statically assigned NodePort (default range: 3-32767). NodePorts are 
automatically mapped to the internal port of a service.

Some examples of services available today using NodePorts:
30023 --> 8080 (m)so

All services are mapped here: in OOM wiki 
.



https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport 


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


[onap-discuss] Infra is down

2018-01-10 Thread Alexis de Talhouët
Greetings,

Looks like the infra is down? Gerrit, Jira, Confluence

Can someone help please?

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


Re: [onap-discuss] [AAI][SO] How to add another LCP Region

2018-01-10 Thread Alexis de Talhouët
Ok, creating another Region in OpenStack , alongs with its service endpoints is 
working.

So is it fair to say X distinct OpenStack instances must have unique Region(s) 
to be used in ONAP? e.g. two instance cannot have the same Region.

Thanks for the help,
Alexis

> On Jan 10, 2018, at 9:57 AM, FREEMAN, BRIAN D <bf1...@att.com> wrote:
> 
> I would name the second openstack something other than RegionOne in that 
> Openstack :)  I suspect the design assumes the cloud regions have unique 
> names but I didnt think robot needed the cloud region in their vanilla 
> openstack keystone queries (but its been a while since I looked at a trace). 
> I know Rackspace does have unique region names (IAD, DFW, etc) and we do in 
> our installations but not sure if vanilla would require that.
>  
> Brian
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Wednesday, January 10, 2018 9:53 AM
> To: FREEMAN, BRIAN D <bf1...@att.com <mailto:bf1...@att.com>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
> Ok, haven’t thought about deploying another robot.
>  
> Regarding my attempt with RegionAlex, the thing is this region doesn’t exist 
> in my Openstack, it’s RegionOne that exist. That’s why it’s not working. But 
> I have to use a different name so mso can differentiate.
> But maybe I haven’t updated all the python scripts. I’ll have another look at 
> it.
>  
> Thanks,
> Alexis
> 
> 
> On Jan 10, 2018, at 9:49 AM, FREEMAN, BRIAN D <bf1...@att.com 
> <mailto:bf1...@att.com>> wrote:
>  
> I dont think robot can handle multiple cloud regions from one isntance.
>  
> I would run two robot’s – one for each cloud region in all honesty or do what 
> robot does via POSTMAN
>  
> One thing though: 
>  
> Keystone address/Tenant/Username/Password have been changed as per as the 
> Cloud Identity Service: id=ALEX_KEYSTONE
> Now the issue:
> —> If the region is RegionAlex, Robot can’t connect
>  
> That should have worked.  Are you sure you updated urls, tenantid, 
> tenantname, credentials etc in all the .py’s needed ?
>  
> Brian
>  
>  
>  
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com 
> <mailto:adetalhoue...@gmail.com>] 
> Sent: Wednesday, January 10, 2018 9:31 AM
> To: FREEMAN, BRIAN D <bf1...@att.com <mailto:bf1...@att.com>>
> Cc: onap-discuss <onap-discuss@lists.onap.org 
> <mailto:onap-discuss@lists.onap.org>>
> Subject: Re: [onap-discuss] [AAI][SO] How to add another LCP Region
>  
> When you have two OpenStack having the same region, e.g. RegionOne, the thing 
> is pretty complex and I haven’t figured it out completely.
>  
> Create a region in AAI with a different name, like RegionAlex as example 
> bellow, and add your tenant to the region. Everything down to instantiation 
> is working. 
> But then, we need to use heatbridge, which uses values in the 
> vm_properties.py of robot container. In there, if I put my dummy region 
> (RegionAlex), connection to the OpenStack is impossible.
> If I put the valid region, e.g. RegionOne, connection is possible, but then 
> heatbridge will try to populate the RegionOne CloudRegion in AAI for the 
> given tenant, which of course exist under RegionAlex, and not RegionOne, so 
> heatbridge fails with 404.
> So then, if you create the tenant under RegionOne, heatbridge will work, but 
> then you’re AAI is messed-up.
>  
> To have VID listing the region and the tenant, you need to create them in 
> AAI. The cloud-region-id has the match the value in the mso-cloud-config, so 
> correlation can happen and authentication is successful.
>  
> To recap, this is what I have:
>  
> In MSO:
>  
> Cloud Sites:
> CloudSite: id=RegionOne, regionId=RegionOne, 
> identityServiceId=DEFAULT_KEYSTONE, aic_version=2.5, clli=RegionOne
> CloudSite: id=RegionAlex, regionId=RegionOne, 
> identityServiceId=ALEX_KEYSTONE, aic_version=2.5, clli=RegionAlex
>  
> Cloud Identity Services:
> Cloud Identity Service: id=DEFAULT_KEYSTONE, 
> identityUrl=http://10.195.194.216:5000/v2.0 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__10.195.194.216-3A5000_v2.0=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=VUJoYm3UcavMJOo3tmXNf9nc82hLgiwojUtRW6iqYOk=T1EDl6plW6A--L5I-BnDXr7lX0IkPRXSDxN9CdIfmt0=>,
>  msoId=nso, adminTenant=service, memberRole=admin, tenantMetadata=true, 
> identityServerType=KEYSTONE, identityAuthenticationType=USERNAME_PASSWORD
> Cloud Identity Service: id=ALEX_KEYSTONE, 
> identityUrl=http://10.195.194.213:

  1   2   >