遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/1702)
<a href="https://www.bestpractices.dev/projects/1702"><img src="https://www.bestpractices.dev/projects/1702/badge"></a>
ONAP orchestration arranges, sequences, and implements tasks based on rules and policies to coordinate the creation, modification, or removal of logical and physical resources in the managed environment. The Service Orchestrator (SO) manages orchestration at the top level and facilitates additional orchestration that takes place within underlying controllers.
https://google.github.io/styleguide/javaguide.html
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
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
Current members are listed at
https://wiki.onap.org/pages/viewpage.action?pageId=8226539
SO has 10 committers and multiple contributors who are listed in https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-ServiceOrchestrator All 10 committers have access 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 and has the required flexibility to adapt as per the growing needs.
All SO project committers actively contribute to the codebase. Details on the committers is stored in INFO.yaml files for each project. Example: https://github.com/onap/so/blob/master/INFO.yaml Example of the contributions: https://gerrit.onap.org/r/#/q/project:so+status:merged
https://wiki.onap.org/display/DW/Service+Orchestrator+Project Provided the release wise updates and the detailed documentation.
https://docs.onap.org/en/latest/submodules/so.git/docs/architecture/architecture.html
https://onap.readthedocs.io/en/latest/guides/onap-developer/architecture/onap-architecture.html#id1
A security sub-committee is driving all components release requirements, best practices. Agreed recommendations become integral parts of an ONAP release and are assessed during milestones. URL : https://wiki.onap.org/display/DW/ONAP+Security+coordination 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. SO Specific Vulnerabilities are tracked per release. Example: https://wiki.onap.org/pages/viewpage.action?pageId=51282544
Information on setting up ONAP can be found at https://onap.readthedocs.io/en/latest/guides/onap-developer/settingup/index.html For Policy Project, each release has documentation on how to develop with the software: https://docs.onap.org/en/latest/submodules/so.git/docs/architecture/architecture.html#so-deployment-view
https://docs.onap.org/en/dublin/submodules/so.git/docs/index.html
Our project page has the link embedded https://wiki.onap.org/display/DW/Service+Orchestrator+Project
Overall ONAP adherence to this is probably going to be handled ONAP wide,
i8n is probably going to be handled ONAP wide, SO will schedule it as a feature for future releases for its monitoring page as and when required.
The project does not store password in the website, repository or downloads.
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=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.
Vulnerabilities handling is documented in https://wiki.onap.org/pages/viewpage.action?pageId=6591711
Coding style is defined in https://wiki.onap.org/display/DW/Java+code+style
SO project utilizes the Sonar static check using the Sonar tool embeddedto the maven build.
SO is written primarily in Java and does not create native binary applications. There is Groovy for workflow and JS code that is used for monitorng feature alone.
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. 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 Policy/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. We store most of our common dependencies in our policy/parent project's pom.xml https://github.com/onap/so/blob/master/pom.xml
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
We 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. We will be also adding more CSIT test cases to the existing suite to make them reliable.
We require JUnit tests to be added to support bug fixes if they are not present.
we have currently met 67 % of the line coverage
https://sonar.onap.org/component_measures?id=org.onap.so%3Aso&metric=coverage
https://wiki.onap.org/display/DW/Development+Procedures+and+Policies
It uses ONAP defined policy https://wiki.onap.org/display/DW/Development+Procedures+and+Policies
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.
Currently SO APIs are using http, we will be using the auth over https based APIs in the E-release.
SO does not use any weaker cryptographic algorithms.
Certificates are managed through AAF micro-service which will be deployed with ONAP suite. which would be used going forward from E-release.
All authentication credentials are stored in configuration files separate from codebase itself. These configuration files are located within the kubernetes helmes charts and are overridable.
All release artifacts are signed by the Linux Foundation prior to release.
All release artifacts are cryptographically signed by the Linux Foundation prior to release.
SO projects validates its inputs against the pre-registered models from SDC and the bpmn recipies that are invoked later on. Any discrepency here would lead to a exception in the flow,
SO projects validates its inputs against the pre-registered models from SDC and the bpmn recipies that are invoked later on. Any discrepency here would lead to a exception in the flow, The inout data is not persisted by SO for its not error prone,
The project release wikis document all our security vulnerabilities. The release notes in the documentation provides list of fixes done per release. https://wiki.onap.org/pages/viewpage.action?pageId=51282544
https://sonar.onap.org/coding_rules#languages=java
JAVA is used which performs memory management.
后退