Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Work in Progress

Lesson Learned

Retrospective

Identification of issues - earlier than later

• Pair-wise testing performed by the project teams

• 72h stability test run

Need for continuous integration testing:

  • Some experience is based on HPA testing on vCPE use case.  vCPE use case, even though, it was tested on Amsterdam successfully, it took a while to make vCPE  work on Beijing components.  It could be that there was some regression.  Since HPA depends on vCPE use case, it could not be tested till the end.  This can be avoided if previously tested use cases are verified continuously.  Automation of use case testing & continuous integration verifications are key to add new functionalities in future releases.


Lesson Learned Areas

• Communication – Wiki, Mailing Lists, IRC

  1. When you are a mailing list moderator do not approve subscription requests from accounts with obviously pornographic domain names.  (yes, this really happened. recently.)
  2. Lack of transparency on LF IT ticket raised by the community. The LF RT tools has poor capability to email properly the whole set of information. The ONAP community has no visibility on what LF IT is currently working on.
  3. Feedback compiled by Kenny Paulfrom ONS-NA: (See TSC 2018-04-05 Agenda slides)

    1. Onboarding an engineer is very hard; The wiki isn’t laid out well and is confusing, needs to be cleaned up

    2. Responsiveness from existing Community members answering new contributor questions can be a challenge

    3. All approved projects should be required to post meeting minutes to the wiki

    4. The volume of untagged emails makes filtering almost impossible

  4. Need absolutely clear and unambiguous validation that RocketChat can be used via https from China and most companies without requiring a VPN, or the use of an alternative device/network -kenny
  5. Would like the Community to decide whether the use of IRC as the "official" minute mechanism is a practice worth continuing or not; very few people are using it, many can't use it and unlike other communities, virtually no one contributes to the minutes. Compare that with the fact that everyone can use zoom chat and there is always a great deal of contribution being performed there. -kenny

• Labs & Test Environment

  1. After M4 code freeze, the community is spending a lot of time to get the Health Check sanity test to pass. HealthCheck is the kind of automated test that MUST pass everyday all along the release lifecycle. 
  2. Despite the effort made by some ONAP partners in providing Labs, we have reached the limit on current labs infrastructure. This is preventing further needed testing (like test job during the verify phase).
  3. Need to develop a full Agile CI-CD pipeline.
  4. How to make better usage of XCI-CD environment (OPNFV,...)
  5. CSIT tests under integration repo must branch early to support the other component branches and their test automation (at least must branch on code freeze deadline to provide enough time to fix the CSIT tests in the release branches).
  6. Supporting HEAT and OOM based deployments is getting harder with duplicate maintenance of the config values (it may help if we can somehow abstract such duplication of config values).

  7. MoreONS-NA Feedback: The amount of time to sett up the dev environment is a barrier to engagement - Developers don’t want to invest a lot of time on that

• Release Management

  1. Progress check between M2 and M4 of intermediate development by release manager might help to improve the quality of the final product (for example scheduling the demos of each component to show the current progress at M3 deadline might be right choice too). This avoids any misunderstanding of the features or requirements by the dev team and can receive feedback from the usecase or architecture teams to improve them when there is still time until code freeze.

• JIRA Management

  1. Often lack of updated information in "Status" field, that prevent to know if someone is working on a defect. This issue varies depending on project and people.
  2. Adopt a singe JIRA workflow. Currently 2 are in place (1 from openecomp, 1 simple from openo)

• Code Review

  1. Requires active committers and more active code reviewers (right now only few committers or reviewers are always reviewing and merging the code).

• Development Infrastructure

  1. The LF toolchain that is currently in place, do allow to merge in master code that has not been thoroughly tested. This leads to massive disruption in the testing.
  2. Nexus 3 slowness. This has been impacting Integration Team tremendously as it tooks 3-4 more times just to download Docker images.
  3. Current 1/3 party scan security tool (Nexus IQ) do not work for Python and JavaScript packages and thus prevent the community to have an holistic view on vulnerabilities.
  4. For the record, it was decided that the community would not account for JavaScript in using Sonar (code coverage) in Beijing Release.

• PTL Role

  1. More ONS-NA feedback:

    1. “Either you commit or you forfeit. There really isn’t any middle ground here."

    2. If you can’t attend a meeting, assign a delegate. If you send a delegate more often than you attend, you shouldn’t be a PTL.


• Architecture

  • Need for simplifying ONAP Micro-Service architecture by leveraging best practices from Industry :
    • Certificate enrollment (for Mutual TLS communication among services)  in Beijing was manual, time consuming and error prone.  Need automation of certificate enrollment is needed. 
    • Scale-out of ONAP is removed from the scope in Beijing release. Services that attempt do it has some learnings. Scale-Out/Load balancing/Circuit-breaking/DB-sync related functionality should be removed from actual micro services to sidecars/side-kicks to avoid each developer spending time and getting it right.

• Use cases:

  • Increase the scope of vCPE use case in deploying multiple virtual Gateways (Multi-Customer support)

• Open Source Values

  1. One critical aspect of Open Source is transparency (but opposition to Silos). We still see some corporation submitting huge pile of code days prior to major milestones. This approach is preventing the whole community to collaborate effectively.
  2. More ONS-NA feedback:
    1. internal company staff meetings/decisions != project team meetings/decisions

• Others

  1. a
  2. b



Process Improvement


  • No labels