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 76 Next »

These meetings were initiated in response to ongoing discussions in the TSC and PTL meetings about dealing with dependencies on unmaintained projects, as well as documentation.

Meeting Minutes

January 09, 2022

Attendees: David McBride , Amy Zwarico , Thomas Kulik 

  • text

December 12, 2022

Attendees: David McBride , Amy Zwarico , Jessica Gonzalez 

December 5, 2022

Attendees: David McBride , Amy Zwarico , Fiachra Corcoran , Jessica Gonzalez 

  • Process (supplements use of Version Evolution Tool):
    • from the release merge jobs within Jenkins
    • generate a list of runs of release jobs across all ONAP (artifacts + images)
    • use the last successful run date to determine how recently the item was touched
    • Use this list to communicate with PTLs
  • Jessica to join the meeting again next week (Dec 12).
  • Note that Dec 12 will be our last meeting of the calendar year.  We will resume on Jan 9.
  • Jessica Gonzalez investigate API to automate generation of candidate list from Jenkins release merge jobs
  • Jessica Gonzalez make Jenkins release merge a permanent tab
  • Fiachra Corcoran generate a list of projects that still have helm charts in OOM that haven't participated in an ONAP release recently to review for removal from OOM
  • Bert Sloan (AT&T resource) use Jenkins API to pull all repos from Jenkins release-jobs list

November 28, 2022

Attendees: David McBride , Amy Zwarico , Fiachra Corcoran 

  • Amy asks, what do we want to accomplish for the London release?
  • Reviewed five closed unmaintained repo tasks assigned to Kohn.
  • Note: version evolution tool needs to be updated to include the Kohn branch
    • Fiachra will coordinate with Michal to update the script.
  • Amy and Fiachra noted that we would still like to talk with Jessica.
    • David to invite Jess to the Dec 5 meeting.
  • Next meeting is Dec 5.
  • Meeting is canceled Dec 19, Dec 26, Jan 2.

November 21, 2022

Attendees: David McBride  

  • Meeting canceled due to low participation.
  • Next meeting is Nov 28.

November 14, 2022

Canceled due to ONE Summit

November 7, 2022

Attendees: David McBride  , Thomas Kulik , Fiachra Corcoran 

  • Meeting canceled due to low participation.
  • Next week (Nov 14) is canceled due to ONE Summit.

October 31, 2022

Meeting canceled.

October 24, 2022

Attendees: David McBride  , Muddasar Ahmed , Tony Hansen , Byung-Woo Jun , Amy Zwarico 

  • David to invite Jessica to the Oct 31 meeting.

October 17, 2022

Attendees: David McBride  , Muddasar Ahmed , Tony Hansen , Thomas Kulik, Fiachra Corcoran , Thomas Kulik 

  • Update request to PTL (conversation with Jessica):
    • Is the image used by the project (already doing this)?
    • Is the image used by any other project (already doing this)?
    • What is the repo associated with the image or component?
    • Does the repo contain anything else that is still in use within the project, or anywhere in ONAP?
  • Process for archiving a repository (conversation with Jessica)
    • PTL - Deprecate the Jenkins jobs that generate the image
    • Submit ticket to IT to deprecate the repo (archive)
      • Indicate in the ticket whether NexusIQ and Sonar reports should be retained
  • Muddasar Ahmed points out that step 5 in the RACI belongs with step 1
    • Muddasar to combine step 5 into step 1, then delete step 5

October 10, 2022

Attendees: David McBride  , Amy Zwarico , Muddasar Ahmed , Tony Hansen , Byung-Woo Jun , Kenny Paul 

  • VFC-1978 was updated with a comment that shows the repo associated with the image vfc-huawei-vnfm-driver
  • IT ticket updated to request that repo be archived
  • We also need to confirm that there is nothing else in the repo that is still in use
  • How do we determine the repo from the image that is displayed by the version evolution tool?
  • Do we need to follow two steps:  1) stop image generation; 2) archive repo
  • David to discuss docker generation with RELENG.  How do we stop it?
  • David to submit request to IT to remove all instances of the image policy-mariadb (POLICY-4308)
  • Muddasar Ahmed points out that we should finish polishing the unmaintained repo process, then present it to the PTLs.
    • Tentatively plan on Oct 24 or Oct 31

October 3, 2022

Attendees: David McBride  , Amy Zwarico , Muddasar Ahmed , Tony Hansen 

  • Discussed issue of authority for archiving repositories, since this came up at the TSC meeting last week.  We agreed on the following.
    • PTL may authorize archiving.  No TSC approval needed.
    • If PTL is unavailable, then the TSC must authorize archiving.
    • Archiving a single repo or subset of repos is different that archiving a project, or otherwise changing the project lifecycle state. That requires TSC approval.
  • IT reports that they are unable to find vfc-huawei-vnfm-driver (VFC-1978).  Left note in Jira asking PTL to show us the location.

September 26, 2022

Attendees: David McBride  , Amy Zwarico , Muddasar Ahmed , Fiachra Corcoran 

  • Some records reported by the version evolution tool are docker images, rather than repos (e.g., POLICY-4308)
  • Fiachra Corcoran suggests an improvement to the tool to differentiate between "infra" and source code repos
  • Agreement that we should focus on code repos from Nexus3.  We will reconsider docker images later.
  • Reviewed unmaintained Jira tickets
    • DCAEGEN2-3233 - deferred to London release
    • VFC-1978 - will propose archiving vfc-huawei-vnfm-driver to the TSC
    • POLICY-4308 - This refers to a docker image. The team decided that we will focus on code repos for now.  However, we may look at this again in the future.
    • MSB-701 -Docker image - see notes above
    • AAI-3514 - AAI PTL reports that repos are still in use.  Lack of updates appears to be due to the lack of new development, but also due to a lack of updating vulnerable packages.  Left comment to PTL to that effect.

September 19, 2022

Attendees: David McBride   , Thomas Kulik , Amy Zwarico , Muddasar Ahmed 

  • Reviewed Jira issues assigned by Amy to projects with candidates for unmaintained repo processing.
  • Created Jira epics
  • David to propose to the TSC archiving vfc-huawei-vnfm-driver (VFC-1978).

August 29, 2022

Attendees: David McBride   , Thomas Kulik , Amy Zwarico  , Tony Hansen

  • Meeting canceled next week (Sept 5) due to the Labor Day holiday.  Next meeting, Sept 12.

August 22, 2022

Attendees: David McBride   , Thomas Kulik , Amy Zwarico  , Tony Hansen

  • Review RACI (see link below)

August 15, 2022

Attendees: David McBride   , Thomas Kulik , Amy Zwarico , Byung-Woo Jun   , Tony Hansen , Kenny Paul 

  • If a project is not participating in a release, can they CLOSE - won't do, or defer to the next release?
    • Team feels that projects should continue to support unmaintained repo activities / information gathering, even if they are not participating in the release
    • Need an escalation process
    • Kenny Paul suggests that RM should escalate
  • RACI:  Project State: Unmaintained
    • Review next week

August 8, 2022

Attendees: David McBride  , Andreas Geißler  , Thomas Kulik , Amy Zwarico , Byung-Woo Jun   , Tony Hansen , Kenny Paul 

  • Feedback

July 25, 2022

Attendees: David McBride  , Andreas Geißler  , Thomas Kulik , Amy Zwarico , Byung-Woo Jun , Muddasar Ahmed , Paweł Pawlak , Tony Hansen 

  • Feedback from Fiachra on status of version evolution tool:  The Linux Foundation Mail - status of version evolution tool?.pdf
  • Andreas reports that version evolution tool has been activated on DT.  Example.
  • What does it mean when a project does not participate in a release?
    • What if the project has required changes?
    • If there is a change to the project, are they still subject to release management tasks?
    • Can we define a minimal participation for a release (i.e., bug fixes only + support tasks)

July 18, 2022

Attendees: David McBride  , Andreas Geißler  , Thomas Kulik , Thomas Kulik , Amy Zwarico , Byung-Woo Jun , Muddasar Ahmed 

June 27, 2022

Attendees: David McBride  , Tony Hansen , Thomas Kulik , Thomas Kulik , Muddasar Ahmed 

  • Status of docker version evolution tool?  Are there still issues?
  • Repo.yaml
    • Use as a reference for status of every repo ("single source of truth")
      • For example, documenting the status of repos and projects in ONAP documentation
    • Process?
      • Use a release management task at M1 or M2 for PTLs to review repos.yaml and update as needed
      • Need a process for projects that dissolve and where the PTL and committers are unavailable
    • Format
      • still an open question
      • use yaml?
      • enumeration of states?
      • file validation?
    • Need to align changes to repos.yaml file with process flow document

May 30, 2022

Canceled due to Memorial Day holiday

May 23, 2022

Attendees: David McBride  , Tony Hansen , Timo Perala , Paweł Pawlak 

  • Tony suggests that we re-visit the need and the purpose for the repos yaml file to determine how it fits into the archiving work flow that Amy has been presenting the past few weeks.
    • Agenda item for June 6
  • Meeting ended early due to light attendance
  • Meeting canceled next week (May 30) due to the Memorial Day holiday

May 16, 2022

Attendees: David McBride , Amy Zwarico , Muddasar Ahmed  , Fiachra Corcoran , Maggie C, Andreas Geißler , Tony Hansen , Robert Heinemann 

  • Amy to present unmaintained project process document to the TSC this week
  • Docker Version Evolution tool
    • Appears that there may still be some errors.  Fiachra will investigate.
    • May not be showing every docker image.  Only shows images that are deployed by default.
    • Fiachra Corcoran to check what contrib components can be disabled for daily/prod deployment
  • Amy suggests that we identify a subset of repos, using the gray filter in the docker version tool, to resolve for the Kohn release
  • Do we want to pursue projects (e.g., portal) or components or both?
  • Tool evaluates to N-2 (includes maintenance releases).  Is that sufficient?
    • Consensus is that N-2 is fine for now.
  • Amy to propose some components for evaluation in the Kohn release, using the list generated by the docker version tool (gray filter)
  • Repos identified by grey filter should be discussed with projects during arch review
    • If still required, why has no technical debt been retired?
    • If not required, then retire the repo
    • Invite Chakar next week to discuss

May 2, 2022

Meeting canceled.

Apr 25, 2022

Attendees: David McBride , Amy Zwarico , Muddasar Ahmed  , Fiachra Corcoran , Paweł Pawlak, Maggie C, Thomas Kulik, Tony Hansen  

  • Archive process flow will be presented in today's PTL meeting (Amy)
    • See latest version attached to today's PTL meeting agenda
  • Unmaintained project dependency tracking using Global Requirements will be presented in today's PTL meeting (David)
  • Suggestion from Maggie to use color coding from slide in the documentation
  • Re-confirmed with team to pursue GRs for Portal and AAF with Portal being completed in the Kohn release, and AAF in the London release.
  • Meeting canceled next week

Apr 18, 2022

Attendees: David McBride , Amy Zwarico , Muddasar Ahmed  

  • Amy Zwarico shares slide describing process flow leading to deprecation (archived) for different starting conditions.
  • Muddasar Ahmed : https://wiki.onap.org/x/Pw_LBQ
  • Follow up on actions:
    • TSC meeting was canceled last week, so unable to request exception to GR process
    • Thomas sent email to LFIT and followed up with meeting.
      • We will discuss the outcome of the meeting next week.

Apr 11, 2022

Attendees: David McBride , Amy Zwarico , Muddasar Ahmed   , Fiachra Corcoran , Paweł Pawlak, Maggie C, Thomas Kulik , Andreas Geißler 

  • Need to ask TSC for an exception to the Global Requirement process so that we can create a GR immediately, rather than going through the best practice phase.
    • David to make request in April 14 meeting
  • Plan is to create a REQ, then create child issues for each project that needs to remove a dependency
  • Start with AAF? Portal?
    • Portal for Kohn
    • Start socializing AAF for removal in London release
  • Process for identifying and documenting dependencies
    • Arch review?
    • Discuss / socialize in PTL meeting
    • Mailling list query
  • Thomas Kulik send email to LFIT to begin the discussion about using repos.yaml to automate processes for repositories. Follow up discussion in this meeting, or the PTL meeting (standing LFIT agenda item).

Apr 4, 2022

Attendees: David McBride , Thomas Kulik   , Amy Zwarico , Muddasar Ahmed   , Fiachra Corcoran, Tony Hansen , Paweł Pawlak, Kenny Paul ,  Maggie C, Timo Perala 

  • Follow up on Kenny's action item from Mar 7: checklist for steps to follow for project transitioning to unmaintained
  • Kenny Paul to check with Edge and other projects:  how do other major projects handle critical communication to end users
  • repo.yaml and schema
    • No progress with schema
    • Should we move forward with repo.yaml file without a schema

Mar 28, 2022

Attendees: David McBride , Thomas Kulik   , Amy Zwarico , Muddasar Ahmed   , Cédric Ollivier, Fiachra Corcoran, Tony Hansen , Paweł Pawlak

  • Gerrit:  https://gerrit.onap.org/r/c/relman/+/127959
  • Is "unmaintained" a project level, or a repo level, attribute?
  • Should we add another lifecycle state, "Closed"
    • Active (i.e., incubation, mature, core):  currently maintained and included in release
    • Unmaintained:  no longer active, but still part of a release.
      • Not a persistent state.  
      • Should be moving toward Closed  by removing dependencies.
    • Closed: no longer part of a release

Mar 21, 2022

Attendees: David McBride , Thomas Kulik   , Amy Zwarico , Muddasar Ahmed   , Cédric Ollivier, Fiachra Corcoran, Tony Hansen  

  • New repo (relman) created.
  • Next steps?
  • Thomas is working on the repos.yaml file, as well as a schema for validation.
  • What's the process when we need to branch an unmaintained project (i.e., in the case where there are dependencies on the unmaintained project)
    • One option:  create list of unmaintained projects that must be branched and submit as a ticket to IT
    • Another option:  relman committers have rights to branch unmaintained projects
  • Cedric advises that Jenkins jobs should be updated and/or removed as projects are removed from the release.  Removing them later can be difficult and tedious.
  • Present slide deck to PTLs on Mar 28
    • Fiachra Corcoran suggests AAF as a trial
    • Tracking:
      • Use Best Practice / Global Requirement process as a parent ticket with child tickets for reach project with a dependency

Mar 7, 2022

Attendees: David McBride , Thomas Kulik , Tony Hansen  , Amy Zwarico , Muddasar Ahmed , Kenny Paul , Robert Heinemann , Cédric Ollivier 

  • Need list of new committers for repo
    • David, Tony, Thomas
    • Propose to the TSC in an email
      • David McBride to send email to TSC with list of proposed committers for new RM repo
  • General consensus on process documented here
    • PTL develops plan for resolution of dependency.  Arch SC reviews and approves.
    • PTL requests exception from TSC
  • Documentation
    • Last available release notes and doc should be included for unmaintained project that is required for release due to dependencies
    • Add note that project is a) unmaintained; and b) included due to PTL request and TSC approval of exception
    • updated: Branching I: Branching is required for every repo (warning) that is planned to be included into the release - regardless if it is "maintained" or "unmaintained" (Important Note: "unmaintained" repos/projects are added to a release only with exception of the TSC; this exception also includes a plan how to resolve the dependencies to the "unmaintained" repo/project; see above).
    • updated: Branching of unmaintained projects by LFIT/supercommitter?
    • updated: Branching II: If we follow this rule (Branching I) we do not need the "included_in:" section in repos.yaml
    • updated: There is still a information gap: By branching every repo that is part of the release we still do not know reliably, what version of the repo was used to build the container (which are going to be deployed in the ONAP release). How to solve this?
    • updated: We should remove all "latest" documentation links for unmaintained projects. (This requires the described TSC exceptions and branches for the respective, unmaintained repos/projects).
  • Check list for project becoming unmaintained
    • PTL available
    • PTL not available
  • Kenny Paul draft checklist for review in this meeting.
  • No meeting next week due to DTF Workshop event
  • Adjust time to two hours earlier due to DST shift of PTL meeting. (i.e., 6 a.m. Pacific)

Feb 28, 2022

Attendees: David McBride , Thomas Kulik , Tony Hansen  , Amy Zwarico 

  • TSC approved creation of a new repo without the need for a formal project
  • Question:  is yaml the best format, or should we use something else (json, xml)?
    • consistent with other config files

Feb 14, 2022

Attendees: David McBride , Kenny Paul  , Thomas Kulik , Tony Hansen  , Amy Zwarico 

  • Plan for creating new repo to contain repo status file
    • Request exception from TSC to create new repo without creating a new project
    • Could be useful for other artifacts, such as release management Jira task generation
    • Should we use GitLab?
    • Repo name?  How about "relman" or "rel-man"? Or "release-management" (like the already existing "ci-management" repo)?
  • Thomas Kulik has proposal for file configuration (a very first draft: repos.yaml).
    • Avoid repeating information found in the info.yaml file
    • Should we capture project association?  The project association for most repos can be identified by the path name.  However, some (e.g., "oparent" belongs to INT) are not obvious.

Feb 7, 2022

Attendees: David McBride , Kenny Paul , Fiachra Corcoran , Thomas Kulik , Eric Debeau , Tony Hansen , Cédric Ollivier , Amy Zwarico 

  • Consensus that repo yaml file proposal is a good start.  May want to add additional data later.
    • repos.yaml
    • Create new repository called "release management" or similar for file
    • Maybe a repo in the integration space if OK with the PTL.
      • should not create ongoing work for the Integration team (beyond initial repo creation)
      • Release Manager would need to have +2 rights for the repo.
      • if in a existing repo committer privs should be decoupled from the privs of the parent repo
      • May cause more issues than it is worth 
      • stand alone may be more appropriate even if more initial work to create.
  • Envision this as being the authoritative source for this info.
  • Start with just capturing which repos are in use for a particular release in the file - once established it can then be leveraged by other tooling.
  • Who ends up being responsible for updating INFO.yaml and repos.yaml files if the PTL is gone?
    • can rely on RelEng super committer rights if need be
  • Request for a json version to also be generated from the repos.yaml

Jan 31, 2022

Attendees: David, Kenny, Fiachra, Amy, Thomas, Eric, Pawel, Timo, Tony

Re-cap from Dec 13 - discussion

  • Eric reports that the REST call scanning tool may work well at the project level, but there is not enough information to identify dependencies to the repo level.
  • Fiachra says that there are also some Kubernetes tools that might be useful (https://learnk8s.io/visualise-dependencies-kubernetes).
  • Cédric Ollivier suggests maintaining a text file in git that documents the status of all repos used by the project
    • This would be one file for all projects
    • Use a structured markup.  YAML?
    • PTLs would update as a release management task.  Probably at M1.

Jan 24, 2022

Attendees: David, Muddasar, Amy, Thomas, Tony, Kenny, Eric, Cedric

  • Re-cap from Dec 13 - discussion
  • Thomas says that we should start with dependencies at the project level, since we don't have an obvious way to get repo level dependencies
  • Eric made an attempt to create a dependency graph.
    • Very complex and time consuming manual operation! However, we believe that relationships are stable, so this may be worthwhile.
    • Note that some dependencies are optional; however, the map does not currently differentiate between optional and required.
  • Cedric suggests an alternative, automated way to identify dependencies:  develop script to analyze code and detect REST calls
    • Eric / Cedric to test with one or two components and report back to this meeting (next week?)
  • What might process look like? (tentative)
    1. Release management task:  PTLs review JSON file and make updates to dependencies
      1. This would be a pre-requisite to the architectural review between M1 and M2
    2. Run dependency tool to create map
    3. Review map against unmaintained projects list
      1. Who would do this? 
        1. PTL / arch subcommittee 
      2. Create Jira ticket to identify and track dependency?
    4. Start countdown clock for projects to remove dependency
      1. TSC must decide policy on how quickly dependencies must be resolved
        1. Strict:  no release with dependencies
        2. Flexible:  dependencies resolved over 2 or more releases

Dec 13, 2021

Attendees:  David, Pawel, Tony, Chaker, Thomas, Kenny

  • David McBride asks Chaker Al-Hakim to describe how the Arch Subcommittee works with project dependencies
  • Chaker says that dependencies are tracked at the project level, not the repo level.
  • Need to map dependencies to the repo level
    • Example:  DMAAP archived a repo, but the project is still active.  What if active projects have a dependency on the repo that was archived?
  • Chaker shares the review template with a new section that asks about dependencies.
    • Thomas Kulik suggests that "critical dependencies" should be replaced by "dependencies".
  • Chaker believes that mapping dependencies between projects at the repo level is outside of the scope of the architectural review.
  • Need to understand both build dependencies and functional dependencies.
  • Kenny:  Force updates by removing unmaintained projects from OOM.  
    • Build failures and test failures will highlight dependencies.

Dec 6, 2021

Attendees:  David, Kenny, Amy, Andreas, Muddasar, Pawel, Tony, Cedric

  • Andreas:  how are unmaintained projects represented in the arch diagram
    • Chaker says that the diagram includes unmaintained projects for one release past when they were moved to unmaintained
  • Unmaintained Project Dependencies.pdf
  • Audit (propose to TSC on Thursday)
    • Develop a map of dependencies between components
    • David to present to the TSC
  • Unmaintained => Archived should happen when there are no longer any dependencies on the unmaintained project
    • Already documented?  Kenny will check.

Actions:

  • David McBride ask Chaker to attend next week's meeting to discuss arch subcommittee and unmaintained project dependencies

Nov 29, 2021

Attendees:  David, Kenny, Amy, Cedric, Thomas

  • Scope:
    • Documentation
    • Software dependencies (incl. uses cases)
    • Understand what repos are actually part of a release - not just the projects in a release.
    • Increased transparency on software modules included in an ONAP release
    • Need an x-project dependency tree from the PTLs of all active projects
      • repos with no dependencies should be locked
      • repos with dependencies where unmaintained need to have the conversation
      • end state needs to be an awareness of unmaintained dependencies.
  • Release notes should document any use of or dependency on unmaintained projects/repos
  • Amy:  goal should be no dependency on unmaintained projects.  However, we will still have exceptions
  • Suggestion that we look at ESR/Logging and Portal as the litmus test for Jakarta
  • Doc team will not include non-branched / unmaintained content going forward.
  • Need an automated way for identifying the dependencies.  SBOM?
  • Should the arch subcommittee be tasked with determining whether a use case has a dependency on an unmaintained project?
    • Example:  Cannot pass arch review if there is a dependency on an unmaintained project without an exception from the TSC.

  • No labels