...
- 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.
- 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).
- Need to develop a full Agile CI-CD pipeline. Full Chain to run automatically the sanity HC, CSIT, E2E. Everything running continuously.
- How to make better usage of XCI-CD environment (OPNFV,...)
- 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).
- 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).
More ONS-NA Feedback: The amount of time to setup the dev environment is a barrier to engagement - Developers don’t want to invest a lot of time on that.
-Improve CSIT coverage to cover all features that the project delivers and to reduce manual testing (if any)
...
- 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.
- Lack of formality to freeze model and scope increasing risks to put any milestone in jeopardy
- Reset expectation on Milestone meaning (enforcement?).
- Grouping of Projects (staggered): to address Release dependency.
- Idea of 3 months project (push back at TSC)
- Defining another milestone (no that good idea?)
- Start early pair-wise testing?
• JIRA Management
- 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.
- Adopt a singe JIRA workflow. Currently 2 are in place (1 from openecomp, 1 simple from Open-o).
- PTLs are owner of the scope of iteration.
- Review the 2 JIRA workflows and define 1 workflow for ALL.
...
- 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.
- Nexus 3 slowness. This has been impacting Integration Team tremendously as it tooks 3-4 more times just to download Docker images.
- 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.
- For the record, it was decided that the community would not account for JavaScript in using Sonar (code coverage) in Beijing Release.
- Slowness of the full IT chain (jenkins, nexus, wiki,..)
- Local testing: how easy to setup an env for a developer to perform its own testing before submitting code. Need reference VNF, AAI, ... (too much time spend to setup environment). Idea of lab reference to be used as a model for configuration. (currently SB-07 serves that purpose).
- Pair wise testing for a great value added in Beijing release.
- 72 hours helps to identify defects. Docker Upgrades went fine.
- Backup and restore capacity for SB 04-07 in Windriver? Have we ever asked Windriver?
- Feature parity on LABS (do not over taxe Windriver).
- Nexus IQ scan performed during the verify. If error then block the build.
- Idea of parallel on a single job. Currently atomic at build level. To investigate-optimize Jenkins Jobs. (time to build the VMs, ...).
• PTL Role
- More ONS-NA feedback:
“Either you commit or you forfeit. There really isn’t any middle ground here."
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.
PTL-cross PTL discussion: feeling of not involvement in some decision. Having a place for PTLs to speak up.
...
- 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.
- More ONS-NA feedback:
- internal company staff meetings/decisions != project team meetings/decisions
- Maturity of the community to understand the release is time-boxed and thus we have to adjust on scope and quality. Process adherence.
• Others
- Commit process: code review. Dialog necessary.
- 1) Concerns on big code merge. 2) That comes late. In case big code should come in, define an upper timeframe limit.
- Use Case: more details functional requirements. more focus on cross system integration (architecture). Lack of defined type, flow and content of messages (need additional details).
...