From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id CFC8A42662; Thu, 28 Sep 2023 16:30:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C9BBB40273; Thu, 28 Sep 2023 16:30:15 +0200 (CEST) Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.48]) by mails.dpdk.org (Postfix) with ESMTP id 1CAA14021D for ; Thu, 28 Sep 2023 16:30:14 +0200 (CEST) Received: by mail-oo1-f48.google.com with SMTP id 006d021491bc7-57bb0f5d00aso5279638eaf.1 for ; Thu, 28 Sep 2023 07:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1695911413; x=1696516213; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=FY3iRjorQRIxU0/0rHbjYPi0DhaRcBOmgJOXD28Gd9o=; b=F5k+2ejvdybabgHcgMYu41PZIy9K53+GQtkQI+n2MOO7LsaVmPzKTwWLp3AO1gWyws mP6+YgVKpNYE2fkpUpbnNSgnq8f+A2l+JYELarBG4xM4dHmu41QgtPNBeK6wuEBIsLbS 6u2Jn9mn/0dR2CcU/ulwZeBKPuErMAqJaPPVk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695911413; x=1696516213; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=FY3iRjorQRIxU0/0rHbjYPi0DhaRcBOmgJOXD28Gd9o=; b=hqsopz4HG67JR/muVzuazEZN5bun8qQ5KjBNtwzCxWQt85s/OLbVYb+CzqHVrg0bSQ 3vNK3hwI7AP7U5+AEJQc+WWklNj3GJMkBYnOPiF04GhB1Bgk2Clun7Fbflx6T++FL+KV +HooxBCE/h8Lm9WIkqXY1yQao29j0Zm443BI/1HDzdvJ9YkH04Jcojc/TOHWkG9AkUr7 WXmTyGElr/0JdzzNnp4i94MqB2ayH56P4Ou9OtVkU6vaxDdYIXfrjlDFE/aEtW1n9hl7 xG2wEl779f2GDDyap0dkFtCWlibSCWipv2/+7YL8GDT+pNUdnw20ZxqfpMsr206G+GAs o9pA== X-Gm-Message-State: AOJu0YwnFx/56fKJhbqZ7hqI2wrkC3X8II6BrssxTkARCFSxNDYQIamb QStGM3Bs6cIyCVIgfpz+kIJG6g6BtH3gHTD6dkcUtokHfTHInEcV0cs= X-Google-Smtp-Source: AGHT+IH8pBcELwYJGDbMAcMF4mowx1ZTKUL8FzT8fYNlCNcz8Wx2gvsnRYF+5D9f5Sa+Y3c15TPm/vmKi0tL4Ddh/q4= X-Received: by 2002:a4a:3c58:0:b0:57b:6d88:4cb2 with SMTP id p24-20020a4a3c58000000b0057b6d884cb2mr1401788oof.1.1695911413099; Thu, 28 Sep 2023 07:30:13 -0700 (PDT) MIME-Version: 1.0 From: Patrick Robb Date: Thu, 28 Sep 2023 10:30:02 -0400 Message-ID: Subject: Community CI Meeting Minutes - September 28, 2023 To: ci@dpdk.org, dts@dpdk.org Content-Type: multipart/alternative; boundary="0000000000005949ee06066c2567" X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dts-bounces@dpdk.org --0000000000005949ee06066c2567 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable September 21, 2023 ##################################################################### Attendees 1. Patrick Robb 2. David Marchand 3. Paul Szczepanek 4. Aaron Conole 5. Thomas Monjalon 6. Honnappa Nagarahalli 7. Adam Hassick 8. Juraj Linke=C5=A1 ##################################################################### Agenda 1. General Announcements 2. CI Status 3. DTS Improvements & Test Development 4. Any other business ##################################################################### Minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General Announcements * DPDK Summit was Sept 12-13 * Patrick went to gov board and tech board dinners to give a lab update and talk about future plans for the lab/SOW talks * Add next-* staging branches for maintainers, like exists currently for LTS releases * =E2=80=9CTest on push=E2=80=9D function desired, like how 21.11-= staging works now? * =E2=80=9CReporting completeness=E2=80=9D by submitting PENDING to p= atchwork initially during a testrun, then overwriting later with PASS/FAIL (or similar solution also accomplishing showing reporting completeness) * Redundancy testing with other public labs? * Patrick produced a document showing what Intel lab tests which the community lab doesn=E2=80=99t: https://docs.google.com/document/d/1dDVhUFlk3DoQzf0AvyqaVYzJiCDFx5uAnU6_qbi= vxe4/edit?usp=3Dsharing * TLDR: For DTS, we have basically the same hardware and could likely add the functional tests and functional-smoke tests Intel Lab is using to our testruns. For compile testing, we mostly use the same distros, but a few gaps there can be easily bridged. The most interesting gap in compile testing is we almost exclusively compile with GCC and static library linking, whereas Intel Lab has more diversity like more extensive use of Clang than us, more extensive use of shared libraries vs static, and some use of debug build type. * Investigate testing DPDK using cloud platforms? * Honnappa asked about adding another DTS developer at the lab. This is probably possible, but it would require additional funding to the lab of course. Will have to discuss further with tech board and bring it to gov board if desired. * Poll the tech board to determine what CI testing improvements are needed in 2024 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CI Status --------------------------------------------------------------------- UNH-IOL Community Lab * Nvidia perf testing: * Hardware Refresh * The cx6 NIC is running with no reporting. It is testing at line rates for performance test runs with frame sizes 256-1518, but is falling below line rate for the test when run for 64B and 128B frames. The tx is not the bottleneck, it is dropping packets on the DUT side. * Ali will discuss with team * CX7: installed in NVIDIA DUT server, and Intel tester TG server. * Need to verify OFED will not disrupt the Intel testing * Need to aggregate info regarding any changes required for the system and send to Intel contacts * Do NOT install OFED - just need to use most recent distribution * Are there functional testsuites which should be run on these cards? * Intel 8970 QAT Accelerator card: * Have built a custom kernel which Ampere is running now, with QAT drivers statically built in * Seg fault when echoing a VF number into (device address)/sriov_numvfs. * TS-Factory ethdev testsuite has been run on cx5, xl710, and E810 NICS * Per conversation with the tech board at DPDK summit * We can run this testing periodically, and will be running the full testsuite (for now, no use of the new =E2=80=9Cdial=E2=80=9D feature which = reduces the scope from 6000 testcases to a lower number) * We will publish a human readable testing report to a =E2=80=9CBubli= k=E2=80=9D website instance on our dashboard * We won=E2=80=99t be comparing current runs against previous runs to determine a pass/fail/etc based on how current runs compare to older runs. Those human cycles would better be put into DTS. * We are reviewing/updating our apply patchset script(s). This is to remove dependencies on our internal infrastructure, so it is upstreamable, and make improvements like =E2=80=9Cdepends on patch=E2=80=9D support. We are r= eviewing our assumptions regarding the apply process on the CI mailing list, but some which can be discussed are: * 1. RFC series should be included in series to apply and run ci testing on * 2. Always check out to the current head of tree when applying a patch, regardless of whether the tree state has changed between patch submission and patch application in CI. * 3. If the cover letter contains =E2=80=9Cdepends-on,=E2=80=9D extract = the dependency series id(s), apply those, then attempt to apply the patch * 4. If patch does not cleanly apply to the branch supplied by pw_maintainers_cli.py, attempt to apply on dpdk main. If this also fails, report an apply failure. * If we can use pw-client and upstream the depends-on support, that would be a benefit for other projects too * Aaron: other projects may have no need for this * Git-pw can do a similar thing, and should be used instead of pwclient --------------------------------------------------------------------- Intel Lab * Patrick is reaching out figure out who is active in this lab * I have emailed John, but should email Robin Giller too * Issue with testing cryptodev on centos. John is going to reach out to Intel lab to see who is responsible for addressing this. --------------------------------------------------------------------- Loongarch Lab * Has been working well --------------------------------------------------------------------- Github Actions * Moving servers physically from MA. There is an internal security audit which will cause some jobs to be disrupted. * Security process will require spinning up new instances and redeployin= g * Working with IT infra to have a server ready to go at the new location, so the VM can be quickly migrated and downtime can be reduced. But, the downtime may still be up to 1 week. * Aaron is reviewing and will merge get_reruns.py * Should integrate with the robot fine =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DTS Improvements & Test Development * Dperf is a new DPDK application which can act as a traffic generator. The maintainer gave a talk at DPDK Summit and Honnappa and I chatted with him about whether we can create a traffic generator subclass for dperf, as an alternative to using Trex, which currently is our only option. We should sync on this as we get closer to 23.11 release and start thinking about 24.03 roadmap. * https://github.com/baidu/dperf * Perf testing examples: https://dperf.org/doc/html/dperf-performance-testing-basic * Can you send l2 traffic? * Patrick will reach out to the maintainer * Can the maintainer be asked to subclass the traffic gen in the new DTS framework * Is 23.11 roadmap emailed out? * How to inject ssh keys into the container running DTS? * It may be best to just bake it in from the Dockerfile, and people can just destroy the image and rebuild if they need a new key * Scatter testsuite: Will not write a class to wrap scapy functions, but may write a module for some packet building/manipulation functions which will be very common in writing DTS testsuites * Thomas: We can build up the module for packet manipulation as we go, according to needs which pop up as new testsuites are being written * Devtools update got merged. Jeremy should use the updated linter script for development going forward. * How to select a list of testsuites to run? * Sections of DPDK project touched in a patch * Environment information and NIC feature set info * Do we want to evaluate on a testsuite basis, or more granular, like testcases. Modules are associated with testcases currently. * 1. Does it make sense to have more than 1 testsuite class per module? * 2. Do we want to add relations between modules and testsuites, instead of just modules-testcases? * 3. Can we build a hierarchy for determining * 4. EXAMPLE: For ethdev, we could have 1 module associated with a list of testsuites * 5. Honnappa: organization should align with how code is organized. So, 1 module per library. * Can divide testsuites according to subdirs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Any other business * Next meeting is October 12, 2023 --0000000000005949ee06066c2567 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
September 21, 2023

################################= #####################################
Attendees
1. Patrick Robb
2.= David Marchand
3. Paul Szczepanek
4. Aaron Conole
5. Thomas Monja= lon
6. Honnappa Nagarahalli
7. Adam Hassick
8. Juraj Linke=C5=A1
#####################################################################=
Agenda
1. General Announcements
2. CI Status
3. DTS Improvemen= ts & Test Development
4. Any other business

#################= ####################################################
Minutes

=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
General Announcem= ents
* DPDK Summit was Sept 12-13
=C2=A0 =C2=A0* Patrick went to gov = board and tech board dinners to give a lab update and talk about future pla= ns for the lab/SOW talks
=C2=A0 =C2=A0 =C2=A0 * Add next-* staging branc= hes for maintainers, like exists currently for LTS releases
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0* =E2=80=9CTest on push=E2=80=9D function desired, = like how 21.11-staging works now?
=C2=A0 =C2=A0 =C2=A0 * =E2=80=9CReport= ing completeness=E2=80=9D by submitting PENDING to patchwork initially duri= ng a testrun, then overwriting later with PASS/FAIL (or similar solution al= so accomplishing showing reporting completeness)
=C2=A0 =C2=A0 =C2=A0 * = Redundancy testing with other public labs?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0* Patrick produced a document showing what Intel lab tests which the = community lab doesn=E2=80=99t: https://= docs.google.com/document/d/1dDVhUFlk3DoQzf0AvyqaVYzJiCDFx5uAnU6_qbivxe4/edi= t?usp=3Dsharing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* TLDR: For DTS, w= e have basically the same hardware and could likely add the functional test= s and functional-smoke tests Intel Lab is using to our testruns. For compil= e testing, we mostly use the same distros, but a few gaps there can be easi= ly bridged. The most interesting gap in compile testing is we almost exclus= ively compile with GCC and static library linking, whereas Intel Lab has mo= re diversity like more extensive use of Clang than us, more extensive use o= f shared libraries vs static, and some use of debug build type.
=C2=A0 = =C2=A0 =C2=A0 * Investigate testing DPDK using cloud platforms?
=C2=A0 = =C2=A0 =C2=A0 * Honnappa asked about adding another DTS developer at the la= b. This is probably possible, but it would require additional funding to th= e lab of course. Will have to discuss further with tech board and bring it = to gov board if desired.
=C2=A0 =C2=A0 =C2=A0 * Poll the tech board to d= etermine what CI testing improvements are needed in 2024
=C2=A0 =C2=A0 = =C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CI= Status

------------------------------------------------------------= ---------
UNH-IOL Community Lab
* Nvidia perf testing:
=C2=A0 =C2= =A0* Hardware Refresh
=C2=A0 =C2=A0 =C2=A0 * The cx6 NIC is running with= no reporting. It is testing at line rates for performance test runs with f= rame sizes 256-1518, but is falling below line rate for the test when run f= or 64B and 128B frames. The tx is not the bottleneck, it is dropping packet= s on the DUT side.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Ali will discuss= with team
=C2=A0 =C2=A0 =C2=A0 * CX7: installed in NVIDIA DUT server, a= nd Intel tester TG server.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Need to = verify OFED will not disrupt the Intel testing
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0* Need to aggregate info regarding any changes required for the s= ystem and send to Intel contacts
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Do = NOT install OFED - just need to use most recent distribution
=C2=A0 =C2= =A0 =C2=A0 * Are there functional testsuites which should be run on these c= ards?
* Intel 8970 QAT Accelerator card:
=C2=A0 =C2=A0* Have built a= custom kernel which Ampere is running now, with QAT drivers statically bui= lt in
=C2=A0 =C2=A0 =C2=A0 * Seg fault when echoing a VF number into (de= vice address)/sriov_numvfs.
* TS-Factory ethdev testsuite has been run o= n cx5, xl710, and E810 NICS
=C2=A0 =C2=A0* Per conversation with the tec= h board at DPDK summit
=C2=A0 =C2=A0 =C2=A0 * We can run this testing pe= riodically, and will be running the full testsuite (for now, no use of the = new =E2=80=9Cdial=E2=80=9D feature which reduces the scope from 6000 testca= ses to a lower number)
=C2=A0 =C2=A0 =C2=A0 * We will publish a human re= adable testing report to a =E2=80=9CBublik=E2=80=9D website instance on our= dashboard
=C2=A0 =C2=A0 =C2=A0 * We won=E2=80=99t be comparing current = runs against previous runs to determine a pass/fail/etc based on how curren= t runs compare to older runs. Those human cycles would better be put into D= TS.
* We are reviewing/updating our apply patchset script(s). This is t= o remove dependencies on our internal infrastructure, so it is upstreamable= , and make improvements like =E2=80=9Cdepends on patch=E2=80=9D support. We= are reviewing our assumptions regarding the apply process on the CI mailin= g list, but some which can be discussed are:
=C2=A0 =C2=A0* 1. RFC serie= s should be included in series to apply and run ci testing on
=C2=A0 =C2= =A0* 2. Always check out to the current head of tree when applying a patch,= regardless of whether the tree state has changed between patch submission = and patch application in CI.
=C2=A0 =C2=A0* 3. If the cover letter conta= ins =E2=80=9Cdepends-on,=E2=80=9D extract the dependency series id(s), appl= y those, then attempt to apply the patch
=C2=A0 =C2=A0* 4. If patch does= not cleanly apply to the branch supplied by pw_maintainers_cli.py, attempt= to apply on dpdk main. If this also fails, report an apply failure.
=C2= =A0 =C2=A0* If we can use pw-client and upstream the depends-on support, th= at would be a benefit for other projects too
=C2=A0 =C2=A0 =C2=A0 * Aaro= n: other projects may have no need for this
=C2=A0 =C2=A0 =C2=A0 * Git-p= w can do a similar thing, and should be used instead of pwclient

---= ------------------------------------------------------------------
Intel= Lab
* Patrick is reaching out figure out who is active in this lab
= =C2=A0 =C2=A0* I have emailed John, but should email Robin Giller too
* = Issue with testing cryptodev on centos. John is going to reach out to Intel= lab to see who is responsible for addressing this.

---------------= ------------------------------------------------------
Loongarch Lab
= * Has been working well

--------------------------------------------= -------------------------
Github Actions
* Moving servers physically = from MA. There is an internal security audit which will cause some jobs to = be disrupted.
=C2=A0 =C2=A0* Security process will require spinning up = new instances and redeploying
=C2=A0 =C2=A0* Working with IT infra to ha= ve a server ready to go at the new location, so the VM can be quickly migra= ted and downtime can be reduced. But, the downtime may still be up to 1 wee= k.
* Aaron is reviewing and will merge get_reruns.py
=C2=A0 =C2=A0* = Should integrate with the robot fine
=C2=A0 =C2=A0
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
DTS Improvements & Test Deve= lopment
* Dperf is a new DPDK application which can act as a traffic gen= erator. The maintainer gave a talk at DPDK Summit and Honnappa and I chatte= d with him about whether we can create a traffic generator subclass for dpe= rf, as an alternative to using Trex, which currently is our only option. We= should sync on this as we get closer to 23.11 release and start thinking a= bout 24.03 roadmap.
=C2=A0 =C2=A0* https://github.com/baidu/dperf
=C2=A0 =C2=A0* Perf testing ex= amples: https://dperf.org/doc/html/dperf-performance-testing-basic
=C2= =A0 =C2=A0* Can you send l2 traffic?
=C2=A0 =C2=A0 =C2=A0 * Patrick will= reach out to the maintainer
=C2=A0 =C2=A0* Can the maintainer be asked = to subclass the traffic gen in the new DTS framework
* Is 23.11 roadmap = emailed out?
* How to inject ssh keys into the container running DTS? =C2=A0 =C2=A0* It may be best to just bake it in from the Dockerfile, and= people can just destroy the image and rebuild if they need a new key
* = Scatter testsuite: Will not write a class to wrap scapy functions, but may = write a module for some packet building/manipulation functions which will b= e very common in writing DTS testsuites
=C2=A0 =C2=A0* Thomas: We can bu= ild up the module for packet manipulation as we go, according to needs whic= h pop up as new testsuites are being written
* Devtools update got merge= d. Jeremy should use the updated linter script for development going forwar= d.
* How to select a list of testsuites to run?
=C2=A0 =C2=A0* Sectio= ns of DPDK project touched in a patch
=C2=A0 =C2=A0* Environment informa= tion and NIC feature set info
=C2=A0 =C2=A0* Do we want to evaluate on a= testsuite basis, or more granular, like testcases. Modules are associated = with testcases currently.
=C2=A0 =C2=A0 =C2=A0 * 1. Does it make sense = to have more than 1 testsuite class per module?
=C2=A0 =C2=A0 =C2=A0 * 2= . Do we want to add relations between modules and testsuites, instead of ju= st modules-testcases?
=C2=A0 =C2=A0 =C2=A0 * 3. Can we build a hierarchy= for determining
=C2=A0 =C2=A0 =C2=A0 * 4. EXAMPLE: For ethdev, we could= have 1 module associated with a list of testsuites
=C2=A0 =C2=A0 =C2=A0= * 5. Honnappa: organization should align with how code is organized. So, 1= module per library.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Can divide test= suites according to subdirs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Any other business* Next meeting is October 12, 2023
--0000000000005949ee06066c2567--