From Alec: projects that participate to a release should not be forced to do mundane tasks such as adding new entries to configuration file that needs to be reviewed and committed for every single maintenance release when the release branch does not contain any new commits (which should be very common). If Fraser had 4 maintenance releases, that would force every project that has no changes to do that work 4 times. Instead releng could very well perform that task from script.

David McBride observes that the installer teams are becoming more efficient at integrating new versions of OpenStack and meeting MS3.x requirements

Cedric Ollivier suggests that we should decide on version of ODL to use prior to the start of a new release cycle, as we do with OpenStack. Cedric Ollivier to send email to community recommending same.

MS5 - March 02

Sam Hague (ODL) asks Cedric Ollivier if we should remove the former ODL csit neutron tests.

Tim Irnich says that it's ok to download a limited number of files to a location, then run installer that can access files in that location. This would be as opposed to pulling files directly off the internet by the installer, i.e. local repo.

Meetbot Minutes

Actions

Tim Irnich to raise question with infra WG of how can we simplify offline distribution of OPNFV artifacts?

Tim Irnich and David McBride to talk with rpaik about getting clarification from TSC about OPNFV distribution requirements? Is offline support required? What artifacts are acceptable? What about "git clone" approach used by JOID and Fuel?

Cristina Pauna says that she believes that Armband and Fuel do something similar to Apex

Yifei Xue says that during integration, compass will choose a specific tag (usually the latest one) on upsteam stable branch, unless encounters a bug, compass will not change the commit anymore, even when opnfv releases

Justin chi says All of PODs in Xi'an Lab will be migrated into Shanghai, the projects affected by migration can get PODs from Huawei Munich Lab or wait PODs resource re-online in Shanghai Lab

Tim Irnich says that we need to be able to better monitor status of installers and scenarios on stable branch in order to detect regressions, like the problem with Euphrates branch, as early as possible.

David McBride shares spreadsheet used to manually track status of scenarios

Tim Rozet and Tim Irnich agree that we need a dashboard that replicates function of spreadsheet

could this be an intern project or would it be better for bitergia?

David McBride to follow up with rpaik about best approach to develop dashboard

Actions

David McBride follow up with projects impacted by the Huawei lab migration

Tim Rozet asks about when CI resources may be diverted from previous release. Installer teams do this on an ad hoc basis, typically following the second SR. However, there is no formal policy. David McBride to make policy official.

Mark Beierl says that proposal is to add StorPerf similar to the ci/daily.sh from its git repo. This will create as many VMs as there are Ceph nodes detected, with a volume size of 1GB, fill them with random data, and then run 10 minutes of random read/write tests with block size of 16k and queue depth of 4. Should take less than 30 minutes total.

Minutes

Additional 2 weeks for MS5 is helping many projects with milestone compliance. However, projects like FDS is still dealing with upstream ODL issues as the ODL community is dealing with Karaf migration.

For MS6, Morgan noted that work needs to be done with test case integration for feature projects (in Functest).

There was a discussion that it will be difficult to agree on "common" tests for ODL and it would be preferable to give scenario owners the choice on what needs to be tested.

Minutes

MS5

Rescheduled to Aug 11, due to revised schedule approved by TSC on Aug 1.

David McBride asks PTLs who filed milestone exception requests to add a comment to the request page, withdrawing the request. This assumes that the revised schedule makes the exception request no longer necessary.

MS6

Rescheduled to Aug 25, due to revised schedule approved by TSC on Aug 1.

Trevor Cooper points out that a page titled "Euphrates Priorities", which is labeled "Draft," and is incomplete, could be potentially confusing to new users. David McBride will follow up.

AoB

David McBride will be on vacation Aug 7 - 18. Ray Paik will be hosting the release meeting on Aug 8 and Aug 15.

Minutes

Actions

Meetbot Minutes

June 13, 2017

Note: This will be a face-to-face meeting at the OPNFV Design Summit in Beijing. The meeting will be held at 4 p.m. in the Pastel Room at the JW Marriott Beijing. If you aren't available to attend F2F, the meeting will also be on IRC (opnfv-release).

April 11, 2017

Agenda

Minutes

Frank Brockners and others suggest that a release plan template might be useful for new projects.

Jack Morgan says that project teams should have JIRA tickets for each of their major goals for the release.

Bryan Sullivan cautions agains putting too much effort into a template. There are higher priorities.

Euphrates includes a requirements for projects to document their CI resource needs

Fatih Degirmenci emphasizes the need to refresh this information throughout the release cycle

Milestone 2 - test requirement documentation

Compliance questions for Euphrates will be simplified

Bryan Sullivan says we should add or strengthen project plan checks in which the project clarifies how their scope is covered by feature tests (e.g. Tempest or other), and if that coverage is incomplete (we're not bored yet) they include plans to make progress toward better coverage in the release.

Milestone 3 - installer integration with OpenStack

Bryan Sullivan would like for the installer teams to ive a little more detail as to what the issue was with Danube/Newton late readiness, so we can know whether the issue is likely to continue and what if anything we can do to improve the situation and de-risk future readiness for feature project development/testing.

Bryan Sullivan points out that project owners do not have visibility into resources (i.e. compliance Q #2)

Agree to drop compliance Q #2

Prakash Ramchandran says that compliance questions 3 and 4 would be redundant if asked of all the project owners, since many projects share scenarios. Better to ask the scenario owners those questions.

To clarify there are several underlying delay issues beyond the lab infra issues we experienced this time. I don't want to conflate these, but they are: (1) the timeline in which current upstream code is integrated in installers; (2) the complexity and resource requirements of OPNFV deploys

As a result this year I am shifting toward more independence from OPNFV scenarios as a basis for test/dev, with functest integration at the right time (when installers are ready) and using OPNFV CI/CD infra for all that testing, rather than my dev lab resources

This approach should enable more early/continual progress on current upstream release support and features - in essence this is like OPNFV on Devstack, and no/few tests will be OPNFV-specific (all will run on upstream dev environments

Trevor Cooper asks about preliminary documentation requirements. Sofia Wallin responds that the Doc WG is continuing to develop the requirements and will be meeting again on Wednesday.

AoB

Jose Lausuch reports that he has seen no test activity from Joid scenarios. Narinder Gupta reports that Joid has been impacted by the Intel lab migration.

Jack Morgan says that Intel POD5 Node5 needs to be reset due to IMPI being stuck.

Narinder Gupta will update the team on the status of Joid at the next release meeting.

Actions

Narinder Gupta update team on status of Joid following Intel lab migration activity

Minutes

Discussion about whether we should standardize on a particular Keystone API

Ulrich Kleber believes that this is necessary in order to do scenario consolidation

Dave Neary expresses concern that standardizing on a particular API version could lead to using the oldest version available, contrary to OPNFV philosophy about preferring to work with leading edge upstream components.

Serg Melikyan says: "we never know which software people running on our openstack and which API this software requires, we should not only consider our project or official openstack projects"

Frank Brockners says: "trying to harmonize all the components for a release does *not* make sense, because it would be a race to the lowest common denominator and hence stop progress." Tapio Tallgren agrees with this statement.

Gregory Elkinbard says: ""API compatibility is a difficult topic. API differences between installers will limit the compatibility of applications running on top. Just like Java, write once, test and debug every where. But installers are simply packaging commercial efforts and delivering them to the community, it is not possible to deviate in a major way. So we will have to live with a degree of uncertainty"

Danube schedule

David McBride summarizes the changes approved by the TSC in the last hour. MS5 moves to January 27. MS6 moves to February 17. Subsequent milestones, and the release date, remain unchanged.

Discussion about mitigating resource disruptions

Fatih Degirmenci suggests that we should map projects to resources so that it is easier to determine the scale of a disruption and which projects are affected.

Fatih Degirmenci and Ulrich Kleber say that we should allocate resources in a way that minimizes disruptions. E.g. don't have all resources for a particular project in one pod or one lab.

Ruan HE reports that Moon team plans to add support for additional installers in the 'E' release.

CI resource status

Gregory Elkinbard proposes maintaining a weekly build in order to support resolution of any critical issues identified before Danube is released. Tim Rozet points out that any bugs found could be resolved using manual builds. Morgan Richomme also suggested that the community lab could be used.

Discussion and then agreement to shift all CI resources to Danube now that the issue with Fuel on Colorado has been resolved.

Danube schedule

Discussion about requirements for MS5. David McBride points out that Jenkins jobs need to be in place with assigned resources; however, they do not need to be bug free at this point.

MS5 - Jan 13

MS6 - Jan 26

AoB

The link for swagger seems to be broken. Bryan Sullivan will investigate.

Minutes

Many having difficulty joining meeting due to last week's change in the GTM info. Also, David McBride forgot to update the meetings page when the GTM was changed (sigh).

David McBride said that the release meeting will be split between discussion of Colorado 2.0 / 3.0 and Danube for the next two months.

David McBride reminded the team that the Colorado 2.0 daily (M, Th, F) will begin on October 10.

Colorado 2.0 / 3.0

Jonas Bjurel raised a concern about interference between Colorado 2.0 and the OpenStack Summit.

A similar concern was raised last week about Col 3.0 and Plugfest in December. The consensus of the group on the call was that this should not be a major issue and the schedule does not need to be changed.

David McBride will follow up on action from last week to start an email thread on the subject

Morgan Richomme walked the team through improvements to the Functest dashboard, including graphs that show the scoring trend over time.

Review of current test results

Tim Rozet said that fd.io performance is misleading due to an issue in Functest. Tim will file a ticket with Functest.

Tim Rozet said that L3 performance is likely due to ODL bug. This will likely be resolved by using ODL Boron with new netvirt.

Prakash Ramchandran asked whether projects could join the release if they have not yet been approved by the TSC. Christopher Price replied that projects must exist (i.e. be approved) before they may join a release.

Discussion about the risk of installer updates in Col 2.0 or 3.0 that break dependent projects that stop their development at Col 1.0.

Gregory Elkinbard acknowledged that there is a "small risk" of this happening and that it deserves more discussion.

Gregory Elkinbard said that, in general, there should be better coordination between installers and dependent projects. Greg suggested a discussion at the upcoming plugfest/hackfest in NH.

David McBride took an action to propose this discussion as a breakout session at the hackfest in December.

David McBride requested that PTLs finish cleaning up the remaining unresolved JIRA issues assigned to Colorado 1.0. These issues should either be closed or reassigned to future releases (i.e. by updating the "fix version" field for each issue).

Jack Morgan commented that some projects still have unresolved Brahmaputra issues.

David McBride to follow up with PTLs to cleanup the remaining unresolved issues.

David McBride described a new project release plan template. This will be discussed in more detail next week.

David McBride describes two new planning documents proposed for Danube:

Test Plan - feature projects will prepare a simple test plan that describes how projects intend to verify their feature. This will be discussed in the Test Working Group. Benefits:

Add visibility and transparency to test planning for all stakeholders.

Encourage feature project teams to think through testing and CI integration early in the release process.

Encourage feature project teams to collaborate with the Test Working Group and Infra Working Group early in the release process.

Identify and bring visibility to requirements for non-existing capabilities or infrastructure

Infra/CI plan - the Infra Working Group will prepare a plan documenting tasks that they plan to complete for the current release and a schedule for those tasks. This will be discussed in the Infra Working Group.

Bryan Sullivan and Dan Lilliehorn raised concerns about the additional workload and advised that the new documents should be as lightweight as possible.

David McBride invited the team to stop by the OPNFV booth at the ODL summit this week to chat if they are available.

Actions

Start email thread about possible collision between Colorado 3.0 release and the December plugfest (David McBride)

Propose new topic for a breakout session at plugfest: Coordination between installer projects and dependent projects (David McBride)

Minutes

Sofia: General update, we are moving forward, remind people to add at least one from the docs team as reviewer

Sofia: make sure that the feature project knows that there is a feature configuration template available in /git/opnfvdocs/docs/installationprocedure (I don’t think that to many knows, yet some project has already provided an configuration guide)

Agreed that documentation should not be released prior to associated code. So, for example, if code will be released in Colorado 2.0, then the documentation should not be released before then.

August 9, 2016

Agenda

Minutes

Frank Brockners and others expressed concern that using the OPNFV help-desk ticketing system lacks sufficient transparency and might not be a good choice for use in the stable branch process.

Daniel Smith suggested a Service Level Agreement (SLA) that would guarantee a turnaround time for help-desk requests.

Aric Gardner said that he would turnaround any help-desk requests for a stable branch within 24 hours. Frank Brockners agreed that this would improve the odds for success of the proposed stable branch creation process.

David McBride agreed that cherry-picking would be from master to stable branch.

Minutes

Justin chi said that Compass integration is nearly complete; however, smoke tests are not yet running

The issue was raised that access is different for the deployments for each of the installers. David McBride asked if this was a requirement that could be documented and proposed by the Genesis project, then negotiated with the installer projects. Frank Brockners took an action to file a JIRA ticket with Genesis.

Narinder Gupta said that JOID has completed integration and is successfully running with ODL, ONOS, and nosdn. In addition, LXD is now enabled.

Gregory Elkinbard asked whether test project verification could be improved to reduce time lost due to a broken test framework. Morgan Richomme agreed to take an action to improve verification of test projects.

Discussed status of MS4 - detailed test descriptions.

Morgan Richomme said that he believes that most projects have reported their requirements.

Discussed status of MS5 - infrastructure

David McBride requested that infra team review input to scenario inventory page. Fatih Degirmenci took an action to do that at the next infra meeting.

David McBride reminded the PTLs that July 1 is the feature freeze milestone.

Actions

File a JIRA ticket with Genesis to establish a requirement for uniform access to deployments, regardless of installer. - Frank Brockners

Tim Rozet indicated that some projectds (e.g. Apex) are already using versions.

We will update all JIRA issues tied to Brahmaputra. Going forward, we will strive to do one of the following for all issues related to a particular release, BEFORE the release date:

CLOSE the issue

Defer the issue to a future release by updating the "Fix Version" field

Reviewed the status of installer / OpenStack integration

During this discussion, the subject of OpenDayLight integration came up.

There is some interest in attempting to integrate the "Boron" release which may be released in August.

Others insist that Boron is too risky and that OPNFV should use ODL "Beryllium".

Discussed a dependency issue that Maryam Tahhan raised in an email thread.

According to Maryam Tahhan: "For SFQM, the plugins we are developing rely on DPDK 16.04. However out of the Box Fuel 9 doesn't support this version of DPDK. The OVS4NFV project is likely to land the right version of DPDK on the Platform as part of their Fuel plugin."

Discussed the need to document the process for requesting test resources.

Question: how do we measure and manage test resource utilization so that we can enable all projects to complete testing for a release? We need a test resource scheduling tool that allows us to project resource needs vs. capacity.

Noted that not all OPNFV test resources are identical. Therefore, some projects will need to be scheduled to use specific resources.

Discussed the possibility of changing the release cadence, as discussed at the recent board meeting. Strong opinions for and against. This discussion is ongoing in a mailing list thread.

Reviewed an updated set of milestones. A new milestone has been added to reinforce the need to provide test case descriptions, including clear pass/fail criteria, early in the process.

Noted that the milestones require better definition.

Need a template for documenting test cases. Jose Lausuch said that this work is already underway.

Actions:

Fill in scenario inventory page with scenario associations for each project (PTLs)

April 13, 2016

Notes:

Discussed the difference between installer dependent scenarios and end-state dependent scenarios. We agreed that the latter should be the goal; however, installer dependence is a necessary, interim step as OPNFV matures.

Discussed the need for an inventory of scenarios, including owner, status, and dependencies. Frank Brockners agreed that preparing this inventory would be compatible with the work of the Genesis project. Bryan Sullivan offered to help, as well.

In order to avoid a proliferation of meetings, further discussions about scenarios will be done during the weekly Colorado release meeting.

Actions:

Finish proposing names as owners of current scenarios for review by the team. (David M)

Provide Frank and Bryan with a location for the table of scenarios and dependencies. (David M)