遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/1591)
<a href="https://www.bestpractices.dev/projects/1591"><img src="https://www.bestpractices.dev/projects/1591/badge"></a>
Active and Available Inventory (AAI) is the ONAP subsystem that provides real-time views of Resources and Services and their relationships. AAI not only forms a registry of active, available, and assigned assets, it also maintains up-to-date views of the multidimensional relationships among these assets, including their relevance to different components of ONAP.
This project targets a logically centralized reference point for service and resource details serving other ONAP components and non-ONAP systems to enable fulfillment, closed loop, reporting, and other operational use cases. A&AI is critical to ONAP as the existing sources of truth do not provide a cross domain view and are not designed to serve this information to multiple clients.
https://wiki.onap.org/display/DW/Development+Procedures+and+Policies describes requirements for acceptable contributions and is linked from the AAI project page. https://wiki.onap.org/display/DW/Java+code+style shows java code style. https://wiki.onap.org/display/DW/Developer+Best+Practices
ONAP requires both a Developer Certificate of Origin (DCO), and a Contributor License Agreement (CLA).
https://wiki.onap.org/display/DW/Contribution+Agreements
ONAP adheres to the Linux Foundation Code of Conduct, found at https://lfprojects.org/policies/code-of-conduct/
The key roles in the project and their responsibilities are described at
https://wiki.onap.org/display/DW/Community+Offices+and+Governance
Current members are listed at
https://wiki.onap.org/pages/viewpage.action?pageId=8226539
For AAIwe have multiple committers and multiple contributes who are listed in https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-ActiveandAvailableInventory All committers have access and rights to maintain the code base, approve and review incoming changes and release a new version of the artifact. This will let the project continue with minimal to no interruption if one person is incapacitated. Also this project is controlled by the linux foundation so we can add more committers if needed
The project covered in this report have more than 2 persons who actively contribute and maintain code. https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-ActiveandAvailableInventory
Road map for AAI can be found in https://wiki.onap.org/display/DW/AAI+R3+Platform+Maturity?preview=%2F35523310%2F35523289%2FAAI+Roadmap+2018-01-05.pdf
Architecture of AAI can be found in https://wiki.onap.org/pages/viewpage.action?pageId=1015836
Information on setting up ONAP can be found at https://onap.readthedocs.io/en/latest/guides/onap-developer/settingup/index.html
Documentation is updated on a regular bases when needed.
https://wiki.onap.org/display/DW/Active+and+Available+Inventory+Project
No user interfaces; the project site is configurable for font size/colors.
It is not applicable at this point in time as the software will only be used by technical people and not by general public
AAI is working on fixing these issues.
All major releases are tagged in gerrit and the artifacts are stored with the release information on onap.nexus. So we can access all old versions of the artifact. If and when a upgrade requires certain steps to be followed they are being added to the release documents as needed
https://jira.onap.org/projects/AAI/issues/AAI-671?filter=allopenissues
Vulnerabilities can be reported using the link https://wiki.onap.org/pages/viewpage.action?pageId=6591711 Currently we dont have any vulnerabilities reported, but the wiki page explains on how to report a vulnerability and how to report anonymously if you do not want the credit for it.
Vulnerability handling is documented in https://wiki.onap.org/pages/viewpage.action?pageId=6591711
Google coding style is used in ONAP https://github.com/google/styleguide
maven-checkstyle-plugin
The application does not create native binaries.
All releases are tagged in gerrit(git), and the builds are controlled using jenkins. By providing the git tag information the same image can be build over and over again with same bit-for-bit result.
All packages are delivered either as an jar artifact or a docker image. Incase of maven artifacts, they can be removed using the pom file. In case of docker container. We can delete the container we dont want. Also control the orchestration in Kubernetes if you want to exclude certain docker images.
All the components require only java and maven to begin with for a developer to quickly install and test it. Even for deployment using OOM and the right amount of resources, we can deploy the full AAI/ONAP suite in less than a day. The steps are documented in https://onap.readthedocs.io/en/latest/submodules/oom.git/docs/oom_quickstart_guide.html
External dependencies are controlled using the pom file, which can be found in the root folder for the projects
警告:需要URL,但找不到URL。
We use sonatype CLM https://nexus-iq.wl.linuxfoundation.org/ and https://sonar.onap.org
External components are maintained through Maven. The user can get a list of all included components using the maven dependency tree and can update or reuse as they see fit
We choose free open source solutions in every case and choose up-to-date versions of the components.
https://jenkins.onap.org - on every commit, a verification job runs which runs an automated test suite. The code check in cannot pass with out jenkins posting a +1 on the review.
We add tests in these cases.
AAI is working toward additional coverage but lack of resources prevent us from acheiving it: https://sonar.onap.org
Contributing guide lines for development is recorded in https://wiki.onap.org/display/DW/Development+Procedures+and+Policies
This is documented on our wiki: https://wiki.onap.org/display/DW/Code+Coverage+and+Static+Code+Analysis
Build systems run the compile with test flag enabled by default. So any failure in test cases will fail the ci and the merge request.
AAI strives to implement secure design principles. We encrypt data where possible, and run security scans on the code and its dependencies.
We disallow SHA-1 or other insecure cryptographic algorithms.
We support mutiple cryptographic algorithms.
Credentials are separate and can be replaced without code compilation.
We use ssh2 internal to the cluster and TLS1.2+ for the external interfaces.
We only allow TLS1.2+
We perform certificate verfication.
We support TLS certification verification before exchange of private information.
The project strives to validate all input
Will work on this for the next release
https://sonar.onap.org
警告:需要更长的理由。
后退