遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/1720)
<a href="https://www.bestpractices.dev/projects/1720"><img src="https://www.bestpractices.dev/projects/1720/badge"></a>
The ONAP Optimization Framework provides a declarative, policy- and model-driven functionality for creating and managing optimization applications for a broad range of use cases within ONAP. Specifically, it provides a framework for rapidly developing new optimization applications independent of how the underlying optimization modules are implemented.
Acceptable contributions are based on the ONAP requirements captured here:
https://wiki.onap.org/display/DW/Development+Procedures+and+Policies https://wiki.onap.org/display/DW/Developing+ONAP https://wiki.onap.org/display/DW/Developer+Best+Practices
The Python 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/pyguide.html
We are in the process of ensuring that the seed code is adapted per the Google Style Guide and will require that new commits meet pylint --rcfile=
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
Follows LF Code of conduct
https://www.linuxfoundation.org/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
OOF has multiple committers and multiple contributes who are listed in : https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-OptimizationFramework
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. More committers can be included in the project, as this is supported by the linux foundation.
The project covered in this report has more than 2 persons who actively contribute and maintain code. At any point of time, the list of committers for the project is maintained here : https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-OptimizationFramework
The road map for OOF can be found in the corresponding release planning phase. For example,
https://wiki.onap.org/display/DW/OOF+Dublin+M1+Release+Planning
The high-level design and architecture of OOF (and its evolutions) can be found under each release planning phase. For example, in Dublin release:
https://wiki.onap.org/display/DW/OOF+Dublin+%28R4%29+Architecture+Alignment
A security sub-committee oversees the release requirements, best practices. Agreed recommendations become integral parts of an ONAP release and are assessed during milestones: https://wiki.onap.org/display/DW/ONAP+Security+coordination
Further, the release note clearly states what has been achieved, along with the release checklists and links to individual JIRA items that covers the above security requirements. OOF adheres to the overall security requirements of ONAP and also provides a per release vulnerability threat.
Information on setting up ONAP can be found at https://onap.readthedocs.io/en/latest/guides/onap-developer/settingup/index.html.
Project specific guides are also available: https://wiki.onap.org/display/DW/HAS+Developer+Guide
ONAP projects are required to update all documents on readthedocs.io as a part of the release process. The current documentation for OOF can be found at:
https://docs.onap.org/en/latest/guides/onap-developer/developing/index.html#optimization-framework
The project website displays the latest badge.
https://wiki.onap.org/display/DW/Optimization+Framework+Project
OOF has no user interfaces and is a runtime component; the project site is configurable for font size/colors.
OOF doesn't provide an end user interface currently.
All passwords are stored either as kubernetes secrets or imported from a secret management service. They are not stored as plain text within the project
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 an upgrade requires certain steps to be followed they are being added to the release documents as needed
Jira is used to track issues. https://jira.onap.org/projects/OPTFRA
Additional details are provided at: 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=6591711
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
SONAR compile time and Static Reporting tools enforce coding styles. For java applications, maven-checkstyle-plugin is used and is referenced in the parent POM. For Python applications, PEP8 checks is used.
The project does not create native binaries.
The project does not create native binaries. Each components build and installation process provides debugging information (eg. pip install)
There are no cross dependencies.
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 jar artifacts or as docker images. * Maven artifacts can be removed using the pom file. * Docker containers can be spun up easily using helm, and the orchestration through Kubernetes allows easy exclusion of specific containers. * Python components can be easily installed via pip
Docker containers are used for installation, so the conventions of the host operating system are not relevant. Python components are typically installed within their own virtual environments, which is a best practice.
OOM based deployment is documented clearly in https://onap.readthedocs.io/en/latest/submodules/oom.git/docs/oom_quickstart_guide.html. Each independent component has its own developers guide that prepares the required dev environment, the process of which is well automated.
For example: https://wiki.onap.org/display/DW/HAS+Developer+Guide
External dependencies are controlled using the pom file for java projects, and via requirements.txt that is used by pip for python projects.
https://gerrit.onap.org/r/gitweb?p=optf/has.git;a=blob;f=conductor/requirements.txt;h=d6d413d506df3fe82d2779f1e16fa2093a4f40f2;hb=HEAD https://gerrit.onap.org/r/gitweb?p=optf/osdf.git;a=blob;f=requirements.txt;h=23dc1b510f658d35dd8147b91b0201ef6fc42f7c;hb=HEAD https://gerrit.onap.org/r/gitweb?p=optf/cmso.git;a=blob;f=cmso-topology/pom.xml;h=553fe91bb27c9eb44d9bca8b78d991f1533c2f19;hb=HEAD
NexusIQ sonar scan is run on the project on a weekly basis: https://jenkins.onap.org/view/optf/
Identifying and Updating an external component simply involves making an update to the pom.xml or requirements.txt file for that project.
We avoid using deprecated and obsolete functions and APIs when possible. We use open source solutions in every case and choose up-to-date versions of the components.
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.
https://jenkins.onap.org/view/optf/
Tests are added for new code contributions and as regression occurs.
Code coverage is being enhanced progressively over each release, but it hasn't yet breached the 80% target.
Contributing guide lines for development is recorded in https://wiki.onap.org/display/DW/Development+Procedures+and+Policies
The code coverage requirement is listed as a developer best practice here: https://wiki.onap.org/display/DW/Code+Coverage+and+Static+Code+Analysis
Sonarqube is used to analyze and report code smells and warnings, and the project is committed to fixing them.
We use ONAP-wide recommended cryptographic protocols and algorithms: https://wiki.onap.org/pages/viewpage.action?pageId=15995347
All authentication credentials are being managed by an external secret management service. It will be fetched by the app during startup.
The project uses HTTPS protocol with TLS1.2
OOF components use AAF based certificate verification. https://jira.onap.org/browse/OPTFRA-223 https://jira.onap.org/browse/OPTFRA-263 https://jira.onap.org/browse/OPTFRA-461 https://jira.onap.org/browse/OPTFRA-391 https://jira.onap.org/browse/OPTFRA-293
Role based authentication with AAF certs is performed prior to any processing.
All OOF APIs are exposed only within the ONAP cluster except opt_eng which exposes APIs to the user to create, update, and delete optimization models. This is newly introduced in the frankfurt release and it is not part of the deployment. There is a basic input validation being done for these APIs, but it has to be improved to reject invalid inputs.
Sonar uses different rules for static code analysis. The list of rules used by OOF is at: https://sonar.onap.org/coding_rules#languages=py
The code is written in Python, which is a memory-safe language.
后退