Topics

AAF Agent helm OOM deploy fails #oom #aaf


Fiachra Corcoran
 

Hi AAF Team,

 

I am testing the new dynamic cert distribution flow for OOM deploy on one of our components. Was hoping to catch you at the AAF meeting but Sai explained you were busy.

 

I am deploying OOM using microk8s on my local machine.

 

I have updated the helm charts to include the Init container and configured it correctly. (I think!)

I am also mounting the relevant path to the /dockerdata-nfs (not sure if this is ok).

Attached are the updated charts for dmaap-dr-node.

 

When I deploy AAF OOM the dmaap-dr artifacts say that no X509's Creds instantiated. Is this OK?

I did try to run the agent.sh script but fails due to container linkage failure.

 

The dmaap-dr-node artifact is left as is:

 

When I deploy dmaap-dr, the init container runs but doesn't produce the jks file.

On my container the following are produced:

 

/opt $ ls -larth /opt/app/osaaf/local/
total 144
-rw-r--r--    1 root     root      115.2K Aug 13 16:27 truststoreONAPall.jks
-r--------    1 root     root        2.0K Aug 13 16:27 org.onap.dmaap-dr.keyfile
-rw-r--r--    1 root     root          16 Aug 13 16:27 VERSION
-rw-r--r--    1 root     root        1.3K Aug 13 16:27 org.onap.dmaap-dr.props
-rw-r--r--    1 root     root         285 Aug 13 16:27 org.onap.dmaap-dr.location.props
-rw-r--r--    1 root     root         548 Aug 13 16:27 org.onap.dmaap-dr.cred.props

 

 

The props file looks to have the correct data but no jks or p12.

 

/opt $ cat /opt/app/osaaf/local/org.onap.dmaap-dr.props
############################################################
# Properties Generated by AT&T Certificate Manager
#   by root
#   on 2019-08-13T15:27:48.120+0000
# @copyright 2019, AT&T
############################################################
aaf_env=DEV
aaf_id=dmaap-dr-node@...
aaf_locate_url=https://aaf-locate.onap:8095
aaf_locator_app_ns=org.onap.dmaap-dr
aaf_locator_container=oom
aaf_locator_container_ns=onap
aaf_locator_fqdn=dmaap-dr-node
aaf_oauth2_introspect_url=https://AAF_LOCATE_URL/%CNS.%AAF_NS.introspect:2.1/introspect
aaf_oauth2_token_url=https://AAF_LOCATE_URL/%CNS.%AAF_NS.token:2.1/token
aaf_url=https://AAF_LOCATE_URL/%CNS.%AAF_NS.service:2.1
aaf_url_cm=https://aaf-locate.onap:8095/locate/onap.org.onap.dmaap-dr.cm:2.1
aaf_url_fs=https://aaf-locate.onap:8095/locate/onap.org.osaaf.aaf.fs:2.1
aaf_url_gui=https://aaf-locate.onap:8095/locate/onap.org.osaaf.aaf.gui:2.1
aaf_url_hello=https://aaf-locate.onap:8095/locate/onap.org.osaaf.aaf.hello:2.1
aaf_url_oauth=https://aaf-locate.onap:8095/locate/onap.org.osaaf.aaf.oauth:2.1
cadi_prop_files=/opt/app/osaaf/local/org.onap.dmaap-dr.location.props:/opt/app/osaaf/local/org.onap.dmaap-dr.cred.props
cadi_protocols=TLSv1.1,TLSv1.2
cm_url=https://AAF_LOCATE_URL/%CNS.%AAF_NS.cm:2.1
fs_url=https://AAF_LOCATE_URL/%CNS.%AAF_NS.fs:2.1
gui_url=https://AAF_LOCATE_URL/%CNS.%AAF_NS.gui:2.1

My assumption was that the container would get the jks and p12 mounted to the relevant path and could be loaded into the server at deploy time.

 

Could you advise on what the issue might be?

 

Thanks,

Fiachra