遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/1579)
<a href="https://www.bestpractices.dev/projects/1579"><img src="https://www.bestpractices.dev/projects/1579/badge"></a>
ONAP APPC is one of the components of the ONAP platform. It is responsible for handling the Life Cycle Management (LCM) of Virtual Network Functions (VNFs). ONAP APPC infrastructure is implemented on virtual machine in an OpenStack cloud in the Amsterdam release. ONAP APPC is created on the top of the OpenDaylight (ODL) platform. ONAP APPC contains three containers: VM#1: ONAP APPC(ODL Framework & APPC OSGI Bundles), VM#2: MYSQL DB, VM#3: DG Builder ( as of Amsterdam release) The ONAP APPC HTTP API supports LCM commands, allowing users to manage virtual applications and their components via other ONAP components.
The Javascript code should meet the requirements except for the number of characters in a line of code specified by the styleguide https://google.github.io/styleguide/jsguide.html We avoid the restriction on the number of characters in one line of code to improve readability.
ONAP requires both a Developer Certificate of Origin (DCO), and a Contributor License Agreement (CLA).
https://wiki.onap.org/display/DW/Contribution+Agreements
The project governance is described at
https://wiki.onap.org/display/DW/Community+Offices+and+Governance
Further information can be found at https://wiki.onap.org/display/DW/ONAP+Technical+Community+Document
https://lfprojects.org/policies/code-of-conduct/
The key roles in the project and their responsibilities are described at
Current members are listed at
https://wiki.onap.org/pages/viewpage.action?pageId=8226539
For APPC we have 4 committers and multiple contributes who are listed in https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-ApplicationController All 4 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
All the projects covered in this report have more than 2 persons who actively contribute and maintain code. The following link provides with list of commit owners for the project which list at least these 4 persons(Taka Cho, Patrick Brady, Aaron Hay, Ramya Balaji) in common in alphabetical order https://gerrit.onap.org/r/#/q/owner:%22Takamune+Cho+%253Ctakamune.cho%2540att.com%253E%22 https://gerrit.onap.org/r/#/q/owner:%22Patrick+Brady+%253Cpatrick.brady%2540att.com%253E%22 https://gerrit.onap.org/r/#/q/owner:%22Aaron+Hay+%253Cah415j%2540att.com%253E%22 https://gerrit.onap.org/r/#/q/owner:%22Ramya+Balaji+%253Crb111y%2540att.com%253E%22
Road map for APPC can be found in https://wiki.onap.org/display/DW/APPC+Dublin+M1+Release+Planning
Architecture of APPC can be found in https://wiki.onap.org/display/DW/Controllers
https://wiki.onap.org/display/DW/Recommended+Protocols
Information on setting up ONAP can be found at https://onap.readthedocs.io/en/latest/guides/onap-developer/settingup/index.html
Documentation is updated with each release.
will do
APPC's CDT User Interface has no Accessibility as of now.
APPC's CDT User Interface does not support i18n as of now.
The project only store password in the website, repository or downloads for testing purpose for FQDN: onap.org,
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
Jira is used to track issues. https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA
Vulnerabilities can be reported using the link https://wiki.onap.org/pages/viewpage.action?pageId=51282466 The raw has the green color with strikethrough line n the table shows the we resolved.
Vulnerabilities handling is documented in https://wiki.onap.org/pages/viewpage.action?pageId=51282466
Coding style is defined in https://wiki.onap.org/display/DW/Java+code+style
For APPC, we follow: http://google.github.io/styleguide/javaguide.html, and use google java code style eclipse/inteiilij formatter
The application does not create native binaries.
APPC uses mvn build, all the dependency artifacts store in the pom file in each subdirectory (sub-module)
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. In case 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.
The compiled docker images and jar files can be installed/used as the user sees fit. Both run on JVM or docker. So there is no reason to selecting locations etc.
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 APPC/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
https://gerrit.onap.org/r/gitweb?p=appc.git;a=tree https://gerrit.onap.org/r/gitweb?p=appc/cdt.git;a=tree https://gerrit.onap.org/r/gitweb?p=appc/deployment.git;a=tree https://gerrit.onap.org/r/gitweb?p=appc/parent.git;a=tree
NexusIQ sonar scan is run on all the projects on a weekly basis
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
APPC avoid depending on deprecated/obsolete functions.
Automatic test suites are run every time before merging the code. The code check in cannot pass with out jenkins posting a +1 on the review.
When regressions occur, APPC add tests for them.
https://sonar.onap.org/component_measures?id=org.onap.appc%3Aappc&metric=line_coverage
APPC coverage is 83.7% as of 4/1/2019
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.
The project strives to implement secure design principles. TBD
APPC runs security scan software to uncover any security risks.
Certificates are managed through AAF micro-service which will be deployed with ONAP suite
APPC stores authentication credentials in the config file or pem file separately.
The projects supports secure TLS and HTTPS and Insecure protocols are disabled by default in these applications, they cab be over-ridden by user configuration
The products support TLS version 1.2
Certificate validation is done before sending any responses.
The certificate is validated before sending http headers or private information.
All release artifacts are signed by the Linux Foundation prior to release.
LFN itself does not support cryptographically signed for the the release
APPC tries to validate all input to functions. The inputs that are provided to the services are checked against existing models such as OXM or search-abstraction layer and only valid inputs are allowed to be pass through
APPC tries to use hardening mechanism whenever possible. Eg APPC uses unique transaction id for tracking transactions through multiple services and also APPC uses http headers to identify the application where possible
APPC project releases documented all our security vulnerabilities, provided list of fixes done per release.
https://onap.readthedocs.io/en/dublin/submodules/appc.git/docs/release-notes.html
Sonar uses different rules for static code analysis. The list of rules used by APPC is: https://sonar.onap.org/coding_rules#qprofile=java-sonar-way-74911|activation=true
APPC uses Java
后退