Take a look at the robot log.html that is attached to the following jira. Scroll down to see how robot creates the policy updates after the VM is instantiated. Then you can look at the files that are

#controlloop

https://docs.openstack.org/keystone/ussuri/api_curl_examples.html check and make sure that a) with project scope payload that you get the endpoints section and b) in multicloud you are setting the pro

#msb #multicloud

authenticate fails: did you check that the url, login and password , (and if v3 which it must be ) project domain and user domain are correct ? Brian

#msb #multicloud

The multi-cloud team may have a better answer but the Guilin version of multicloud.pike includes additional variables like ssl_enabled and msbprotocol to set up https on port 443 in addition to the ms

#msb #multicloud

I see weirdness all over the logs but the one that might be the critical one is the Multicloud getting an HTTP 500 back from 10.108.10.41 - - [08/Jan/2021:14:11:47 +0000] "POST /CloudOwner/k8sregionfo

Praveen, You can see an example of setting the path to the caFile in the DANOS VES collector (among others). In that example VNF we pass the caFile full path as a parameter to the vpp-measurement-repo

#ves

It looks like you have a Basic Auth header in your curl. I think even though you specified a -u that header is taking a priority. remove the basic auth and use -u or create a basic auth header with th

#ves

Jim, I have not setup the ingress controller so cant be much help. The readthedocs page has some guidance that you would need to customize for Azure with both the ingress controller and the dns setup

I think you have type and name flipped. vnf-type should be the model name and vnf-name should be an instancename. Although I could be interpreting your variable names incorrectly. Brian "vnf-name": "{

#guilin

As you can see in the log – SO cant talk to your cloud. Its getting an HTTP 404 back from the HTTP connection to openstack. Looks like you are using the keystone v2 config instead of the keystone v3 s

Check the SO openstack adapter for errors. The error message seems to indicate the source of the error is OPENSTACK. "extSystemErrorSource" : "OPENSTACK", but I’m not totally familiar with this error

Remembered that I had some postman queries for cluster state. In my environment peer voting status is healthy with all peer’s reporting true. sdnc ssl nodeport is 30267 https://{{sdnc_port}}/jolokia/r

Correcting some misleading typo’s Brian

If you look inside the guilin-sdnc-2 you will like see opendaylight errors in the karaf.log. I would delete the pods that have shared errors in karaf.log and make sure healthcheck for sdnc passes. the

Sounds like one of your sdnc containers is down (perhaps dev-sdnc-2). kubectl -n onap get pod | grep sdnc Sdnc failing healthcheck means you won’t be able to deploy a VNF anyway. I’d restart the faile

Looks like GLOBAL_INJECTED_PRIVATE_KEY is the variable in /share/config/robot_properties.py that contains the path to the keyfile and in your case it is null. Populate it in the robot container config

Might want to check with the SO team but I think I have seen this behavior when openstack is slow to do the instantiate for stack status. The default timers in SO will then trigger the re-submit logic

#so

Hmmm – its not the uri_to_delete it’s the STACK_NAME list. Not the double [[ so its not interpreting the STACK_NAMES line correctly. BTW- I would keep the STACK_NAME line and have both STACK_NAME (val

#frankfurt #robot

The problem might be that the Save For Delete doesn’t fire unless Orchestration (including heatbridge and validation) succeeds. I did a create and looked at the Save for Delete file and modified it to

#frankfurt #robot

Hmm robot being pesky. Let me get sb-00 configured and see what that script needs Thanks for the feedback. Brian Sent via the Samsung Galaxy S8, an AT&T 5G Evolution capable smartphone Get Outlook for

#frankfurt #robot