Release Data
============
+Version: 13.0.0
+---------------
+
+New Features
+------------
+
+- Spring Boot update in aai-common, resources and traversal from 2.1 to 2.4
+- Tracing support in resources and traversal
+- Optionally enable `database level caching for JanusGraph <https://docs.janusgraph.org/operations/cache/#database-level-caching>`_
+- Change default logging to write to stdout instead of files
+- Reduce log noise by not logging happy pass for liveness probes
+
+Fixes
+-----
+
+- Fix metrics monitoring via Prometheus
+
+:Release Date: 2022-11-10
+
Version: 11.0.0
---------------
+---------------
:Release Date: 2022-11-10
.. _`ONAP Release Downloads`: https://git.onap.org
Version: 10.0.0
---------------
+---------------
:Release Date: 2022-06-02
The R10 Jakarta release of ONAP A&AI addressed security vulnerabilities and enhanced the model for the CCVPN Use Case
- Schema updated for CCVPN use case mainly enhancing and bug fixes of the Cloud Leased Line (CLL) service
-- Updated versions for indy, httpclient, freemarker, activemq, commons-io, commons-compress, logback-core,
-commons-codec, groovy, netty-all, netty-handler, gson, and snakeyaml in various mS
+- Updated versions for indy, httpclient, freemarker, activemq, commons-io, commons-compress, logback-core, commons-codec, groovy, netty-all, netty-handler, gson, and snakeyaml in various mS
- Please note log4j is still on older versions in a transitive dependency for aaf auth for the following mS
* onap-aai-aai-common
* onap-aai-babel
* Micrometer integration
* Prometheus monitoring integration
-Known Limitations, Issues, and Workarounds
-==========================================
+Istanbul Known Limitations, Issues, and Workarounds
+---------------------------------------------------
Known Issues
------------
* None
-References
-==========
+Honolulu References
+-------------------
Quick links:
- Deprecation Notice
* Data-router, Search-data-service, Elastic, and Router-Core are put into maintenance mode and removed from release.
-Known Limitations, Issues, and Workarounds
-==========================================
+Honolulu Known Limitations, Issues, and Workarounds
+---------------------------------------------------
Known Issues
------------
* None
-References
-==========
+Istanbul References
+-------------------
Quick links:
* ESR GUI is retired
* AAI Sparky UI is not supported in Guilin nor is its supporting mS data-router, search-data-service, or elastic. Targeted for retirement in Honolulu.
-Known Limitations, Issues, and Workarounds
-==========================================
+Guilin Known Limitations, Issues, and Workarounds
+-------------------------------------------------
Known Issues
------------
kubectl n onap delete pod {POD1} {POD2} {POD3} {POD4}
//where POD1-4 are pod names of dev-aai-resources, dev-aai-traversal, dev-aai-graphadmin, and dev-aai-data-router, respectively.
-References
-==========
+Guilin References
+-----------------
Quick links:
champ, spike, and gizmo are deprecated and removed from the helm chart.
-Known Limitations, Issues, and Workarounds
-==========================================
+Frankfurt Known Limitations, Issues, and Workarounds
+----------------------------------------------------
Known Issues
------------
The community has been unable to make data-router communicate with DMaaP, we welcome contributors who can help resurrect this service, or it will be deprecated in Guilin.
-References
-==========
+Frankfurt References
+--------------------
Quick links:
**Known Issues**
-If the either the aai-resources or aai-traversal pod is deleted, haproxy will not automatically detect when the pod is re-instantiated. As a temporary workaround, you can delete the haproxy pod (the one named "aai", for example, "dev-aai-8794fbff5-clx7d") and when the aai pod restarts the service should operate normally. A proposed fix is here: https://gerrit.onap.org/r/#/c/51075/1 if you want to see how to configure the haproxy service to auto-recover when the IP address of either the aai-resources or aai-traversal pod changes.
+If the either the aai-resources or aai-traversal pod is deleted, haproxy will not automatically detect when the pod is re-instantiated. As a temporary workaround, you can delete the haproxy pod (the one named "aai", for example, "dev-aai-8794fbff5-clx7d") and when the aai pod restarts the service should operate normally. A proposed fix is `here <https://gerrit.onap.org/r/c/oom/+/51075/1>`_ if you want to see how to configure the haproxy service to auto-recover when the IP address of either the aai-resources or aai-traversal pod changes.
**Security Notes**
- `AAI-61 <https://jira.onap.org/browse/AAI-61>`_ AAI cleaned up references to OpenECOMP but in order to keep the release stable for R1, the XML namespace still contains openecomp.
-Client systems should use http://org.openecomp.aai.inventory/v11 as the XML namespace for ONAP AAI R1.
-
**Security Issues**
See Common Vulnerabilities and Exposures `CVE <https://cve.mitre.org>`
Code Review / aai / aai-common.git / blobdiff