Date   

TSC Cancelation Notices

Ray Kinsella
 

To whom it concerns,

Please note that the weekly FD.io TSC meeting is cancelled for the next two weeks.
Those are the meetings on the 21st and 28th of July.

The TSC will reconvene in August to discuss 2023 budgetary planning.

Thank you,

Ray Kinsella
FD.io TSC Member


Ray to chair today's meeting

Dave Wallace
 

Folks,

I am unable to attend today's TSC meeting and Ray has graciously agreed to chair today's TSC Meeting.

Thanks,
-daw-


June LFN DTF Event Survey

Kenny Paul
 

Dear FD.io Community Members,

 

If you attended the June DTF, either in-person or remotely, and have not already provided your survey feedback yet, please take a moment to do so.

https://linuxfoundation.surveymonkey.com/r/LFNDTFJune22

 

 

Thanks!

-kenny


Kenny Paul, Sr. Technical Community Architect

  ONAP Project & LFN Governing Board

  kpaul@...,  +1.510.766.5945, US Pacific time zone.

  Find time on my calendar: https://doodle.com/mm/kennypaul/book-a-time

 


Vratko to proxy for me in TSC meetings on 14-Jul and 21-Jul.

Maciek Konstantynowicz (mkonstan)
 

I will be away on vacation. Thank you. -Maciek


Latest News on FD.io

Dave Wallace
 

Folks,

FD.io TSC member Ray Kinsella has been blogging recently on FD.io VPP.  His blog posts are now included on the FD.io web site under 'The Latest'->'Latest News' [0].

I highly recommend that you check them out.

Many thanks to Ray for his contributions to the FD.io Community!
-daw-

[0] https://fd.io/latest/news/


Re: [tsc-private] [csit-dev] TRex - replacing CVL with MLX for 100GbE

Maciek Konstantynowicz (mkonstan)
 

Hi Dave,

Per my action from the last week TSC meeting (item 4.c. in [1]), here is
the list of HW that FD.io project needs and that we can order any
time:

1. 28 NICs, 2p100 GbE from Nvidia / Mellanox - preferred:
   MCX613106A-VDAT, less preferred: MCX556A-EDAT, to cover the following
   testbeds:

   a. Performance 3-Node-ICX, 2 testbeds, 4 SUTs, 2 TGs
   b. Performance 2-Node-ICX, 4 testbeds, 4 SUTs, 4 TGs
   c. ICX TGs for other systems, 3 TGs
   d. 3-Node-Alt (Ampere Altra Arm N1), 1 testbed, 2 SUTs, 1 TG
   e. (exact breakdown in my email from 28 Jan 2022 in the thread below)

2. If we also want to add a MLX NIC for functional vpp_device test, that
   would be additional 2 MLX 2p100GbE NICs.

Things that we originally planned, but can't place orders as the HW is
not available yet:

3. TBC number of 2-socket Xeon SapphireRapids servers

   a. Intel Xeon processor SKUs are not available yet to us - expecting
      update any week now. 
   b. Related SuperMicro SKUs are not available yet to us - expecting
      update any week now.

Hope this helps. Happy to answer any questions.

Cheers,
-Maciek


On 5 Apr 2022, at 12:55, Maciek Konstantynowicz (mkonstan) <mkonstan@...> wrote:

Super, thanks!

On 4 Apr 2022, at 20:22, Dave Wallace <dwallacelf@...> wrote:

Hi Maciek,

I have added this information to the TSC Agenda [0].

Thanks,
-daw-
[0] https://wiki.fd.io/view/TSC#Agenda

On 4/4/2022 10:46 AM, Maciek Konstantynowicz (mkonstan) wrote:


Begin forwarded message:

From: mkonstan <mkonstan@...>
Subject: Re: [tsc-private] [csit-dev] TRex - replacing CVL with MLX for 100GbE
Date: 3 March 2022 at 16:23:08 GMT
To: Ed Warnicke <eaw@...>

+Lijian

Hi,

Resending email from January, so it’s refreshed in our collective memory, as discussed on TSC call just now.

Number of 2p100GE MLX NICs needed for performance testing of Ampere Altra servers are listed under point 4 below.

Let me know if anything unclear and/or if any questions.

Cheers,
Maciek

On 28 Jan 2022, at 17:35, Maciek Konstantynowicz (mkonstan) via lists.fd.io <mkonstan=cisco.com@...> wrote:

Hi Ed, Trishan,

One correction regarding my last email from 25-Jan:-

For Intel Xeon Icelake testbeds, apart from just replacing E810s on TRex servers, we should also considder adding MLX 100GbE NICs for SUTs, so that FD.io could benchmark MLX on latest Intel Xeon CPUs. Exactly as discussed on in our side conversation, Ed.

Here an updated calc with breakdown for Icelake (ICX) builds (the Cascadelake part stays as per previous email):

// Sorry to TL;DR, if you just want the number of NICs, scroll to the bottom of this message :)

(SUT, system under test, server running VPP+NICs under test)
(TG, traffic generator, server running TRex, needs link speeds matching SUTs')

1. 3-Node-ICX, 2 testbeds, 4 SUTs, 2 TGs
   - 4 SUT/VPP/dpdk servers
     - 4 ConnectX NIC, 1 per SUT - test ConnectX on SUT
   - 2 TG/TRex servers
     - 2 ConnectX NICs, 1 per TG - replace E810s and test E810 on SUT
     - 2 ConnectX NICs, 1 per TG - test ConnectX on SUT
     - 1 ConnectX NIC, 1 per testbed type - for TRex calibration
   - sub-total 9 NICs

2. 2-Node-ICX, 4 testbeds, 4 SUTs, 4 TGs
   - 4 SUT/VPP/dpdk servers
     - 4 ConnectX NIC, 1 per SUT - test ConnectX on SUT
   - 4 TG/TRex servers
     - 4 ConnectX NICs, 1 per TG - replace E810s and test E810 on SUT
     - 4 ConnectX NICs, 1 per TG - test ConnectX on SUT
     - 1 ConnectX NIC, 1 per testbed type - for TRex calibration
   - sub-total 13 NICs

3. ICX TGs for other systems, 3 TGs
   - 3 TG/TRex servers
     - 3 ConnectX NICs, 1 per TG - replace E810s and test ConnectX and other 100GbE NICs on SUTs
     - 1 ConnectX NIC, 1 per testbed type - for TRex calibration
   - sub-total 4 NICs

4. 3-Node-Alt (Ampere Altra Arm N1), 1 testbed, 2 SUTs, 1 TG
   - 2 SUT/VPP/dpdk servers
     - 2 ConnectX NIC, 1 per SUT - test ConnectX on SUT
   - 1 TG/TRex server
     - will use one of the ICX TGs as listed in point 3.
   - sub-total 2 NICs

Total 28 NICs.

Hope this makes sense ...

Cheers,
Maciek

P.S. I'm on PTO now until 7-Feb, so email responses delayed.

On 25 Jan 2022, at 16:38, mkonstan <mkonstan@...> wrote:

Hi Ed, Trishan,

Following from the last TSC call, here are the details about Nvidia Mellanox NICs that we are after for CSIT.

For existing Intel Xeon Cascadelake testbeds we have one option:

- MCX556A-EDAT NIC 2p100GbE - $1,195.00 - details in [2].
- need 4 NICs, plus 1 spare => 5 NICs

For the new Intel Xeon Icelake testbeds we have two options:

- MCX556A-EDAT NIC 2p100GbE - $1,195.00 - same as above, OR
- MCX613106A-VDAT 2p100GbE - $1,795.00 - details in [3] (limited availability)
- need 7 NICs, plus 1 spare => 8 NICs.

We need Nvidia Mellanox advice and assistance with two things:

1. What NIC model we should get for Icelake with PCIe Gen4 x16 slots?
2. How many of listed NIC quantities can Nvidia Mellanox donate, vs LFN FD.io project purchasing them thru retail channel?

Let me know if you’re still good to help here and next steps.

Hope this makes sense, let me know if questions.

Cheers,
Maciek

Begin forwarded message:

From: "Maciek Konstantynowicz (mkonstan) via lists.fd.io" <mkonstan=cisco.com@...>
Subject: [csit-dev] TRex - replacing CVL with MLX for 100GbE
Date: 23 January 2022 at 20:03:59 GMT
To: csit-dev <csit-dev@...>
Reply-To: mkonstan@...

Hi,

Following discussion on CSIT call last Wednesday [1], we would like to move
forward with using only Mellanox NICs to drive 100 GbE links and
disconnectiong (or removing) E810 CVL NICs from TG(TRex) servers.
This is due to a number of show-stopper issues preventing CSIT use of TRex
with DPDK ICE driver[ICE] and no line of sight to have them addressed.

This impacts our production 2n-clx testbeds, as well as the new icx testbeds
that are being built.

For 2n-clx, I believe we agreed on a call to use the same NIC model that is
already there, MCX556A-EDAT (ConnectX-5 Ex) 2p100GbE [2]. Just add more NICs
for 100GbE capacity.

For icx testbeds, with servers supporting PCIe Gen4, we could also use
MCX556A-EDAT (it supports PCIe Gen4), or take it up a notch and use
ConnectX-6 MCX613106A-VDAT[3] that is advertised with "Up to 215 million
messages/sec", which may mean "215 Mpps". If anybody has experience (or knows
someone who does) with ConnectX-6 with DPDK driver, it would be great to
hear.

Anyways, here a quick calculation about how many NICs we would need:

1. 2n-clx, 3 testbeds, 3 TG servers => 4 NICs
  - s34-t27-tg1, s36-t28-tg1, s38-t29-tg1, see [4]
  - NIC model: MCX556A-EDAT NIC 2p100GbE
  - 1 NIC per TG server => 3 NICs
  - 1 NIC per TG server type for calibration => 1 NIC

2. 2n-icx, 4 testbeds, 4 TG servers => 5 NICs
  - NIC model: MCX556A-EDAT 2p100GbE QSFP48
    - Or MCX613106A-VDAT 2p100GbE (accepts QSFP28 NRZ per [5])
  - 1 NIC per TG server => 4 NICs
  - 1 NIC per TG server type for calibration => 1 NIC

3. 3n-icx, 2 testbeds, 2 TG servers => 2 NICs
  - NIC model: MCX556A-EDAT NIC 2p100GbE
    - Or MCX613106A-VDAT 2p100GbE (accepts QSFP28 NRZ per [5])
  - 1 NIC per TG server => 2 NICs

Thoughts?

Cheers,
Maciek

[1] https://ircbot.wl.linuxfoundation.org/meetings/fdio-meeting/2022/fd_io_tsc/fdio-meeting-fd_io_tsc.2022-01-13-16.00.log.html#l-79
[2] https://store.nvidia.com/en-us/networking/store/product/MCX556A-EDAT/nvidiamcx556a-edatconnectx-5exvpiadaptercardedr100gbe/
[3] https://store.nvidia.com/en-us/networking/store/product/MCX613106A-VDAT/nvidiamcx613106a-vdatconnectx-6enadaptercard200gbe/
[4] https://git.fd.io/csit/tree/docs/lab/testbed_specifications.md#n1189
[5] https://community.mellanox.com/s/question/0D51T00008Cdv1g/qsfp56-ports-accept-qsfp28-devices

[ICE] Summary of issues with DPDK ICE driver support for TRex:

   1. TO-DO. Drop All. CVL rte-flow doesn’t support match criteria of ANY.
      - TRex: HW assist for rx packet counters; SW mode not fit for purpose.
      - Status: POC attempted, incomplete.
   2. TO-DO. Steer all to a queue. CVL rte-flow doesn’t support matching criteria of ANY.
      - TRex: HW assist for TODO; needed for STL; SW mode not fit for purpose.
      - Status: POC attempted, incomplete.
   3. TO-VERIFY. CVL doesn’t support ipv4.id.
      - TRex: HW assist for flow stats and latency streams redirect.
      - Status: Completed in DPDK 21.08.
   4. TO-VERIFY. CVL PF doesn’t support LL (Low Latency)/HP (High Priority) for PF queues.
      - TRex: Needed for ASTF (stateful).
      - Status: CVL (E810) NIC does not have this API but has the capability.

--------------------------------------------------------------------------------









2022 LFN Governing Board Committer Representative Election

Casey Cain
 

Hello, everyone.

This is to inform you that the self-nomination period for the LFN Governing Board Committer Representative (LGBMCR) election has started.  

Role:
  • The role of the LFN Governing Board Member Committers Representative (LGBMCR) is to represent the committers and contributors to LFN projects at the LFN Governing board.  The expectation of the LGBMCR is to attend all LFN Governing board meetings (and any appropriate ancillary meetings), gather input from the committer community for issues raised at the board level, and to communicate to the committer community key activities from board.
  • LGBMCR is elected for the 1 year. Re-election is not possible.
Eligible candidates:
  • Candidates must be active committers to at least one LFN project.
  • Candidates can self-nominate, or be nominated by other community members. In the latter case, candidates must accept the nomination before the election is conducted.
  • Candidates must be an active committer to a LFN project which differs from the LFN project that the currently servicing LGBMCR is an active committer of.
    • The 2021 LGBMCR was from the ONAP Community
If you are interested in becoming the technical representative to the Governing Body and you meet the eligibility requirements, please self-nominate at the link below by July 6th, 2022.
https://wiki.lfnetworking.org/x/7gJzB

Voting will begin at the conclusion of the self-nomination period.

If you would like more information on the LGBMCR, please see https://wiki.lfnetworking.org/x/AgIiAQ or reach out to your community Technical Program Manager / Community Architect.


Best,
Casey Cain
Senior Technical Community Architect
Linux Foundation
_________________
WeChat: okaru6
WhatsApp: +1.503.779.4519


Re: GoVPP committer promotion - Nathan Skrzypczak

Dave Wallace
 

Nathan,

Congratulations!  The TSC has approved your nomination as a GoVPP Committer [0].

Please follow the LF Committer Self-Help management documentation [1] to submit a gerrit change with the requisite information added to the INFO.yaml file.  Once an existing GoVPP committer merges it, you will have the ability to merge changes.

Thanks,
-daw-

[0] https://ircbot.wl.linuxfoundation.org/meetings/fdio-meeting/2022/fd_io_tsc/fdio-meeting-fd_io_tsc.2022-06-16-15.01.html
[1] https://docs.releng.linuxfoundation.org/en/latest/committer-management.html

On 6/16/22 9:51 AM, Vladimir Lavor via lists.fd.io wrote:

Hello TSC,

 

I want to inform you (also on behalf of Ondrej Fabry) that voting for Nathan’s nomination was closed.

Thanks for all your votes.

 

Here are links to the voting threads:

https://lists.fd.io/g/govpp-dev/topic/91516719#98
https://lists.fd.io/g/govpp-dev/topic/91724929#100

 

I also repeat my +1 here because it was lost somewhere in the voting thread.

 

Thanks,

--vl

 

From: Vladimir Lavor -X (vlavor - PANTHEON TECH SRO at Cisco)
Sent: piatok 3. júna 2022 9:04
To: govpp-dev@...
Cc: tsc@...
Subject: GoVPP committer promotion - Nathan Skrzypczak

 

Hi GoVPP committers,

 

I would like to nominate Nathan Skrzypczak as a new committer for the GoVPP project.

 

Nathan has been contributing to GoVPP since 2020 and already has several contributions:

 

https://gerrit.fd.io/r/gitweb?p=govpp.git;a=search;s=Nathan+Skrzypczak;st=author

 

Let's close the nomination period by Wednesday 15th June 20:00 UTC.

 

Please vote in this e-mail thread.

 

Thanks,






Re: GoVPP committer promotion - Nathan Skrzypczak

Vladimir Lavor
 

Hello TSC,

 

I want to inform you (also on behalf of Ondrej Fabry) that voting for Nathan’s nomination was closed.

Thanks for all your votes.

 

Here are links to the voting threads:

https://lists.fd.io/g/govpp-dev/topic/91516719#98
https://lists.fd.io/g/govpp-dev/topic/91724929#100

 

I also repeat my +1 here because it was lost somewhere in the voting thread.

 

Thanks,

--vl

 

From: Vladimir Lavor -X (vlavor - PANTHEON TECH SRO at Cisco)
Sent: piatok 3. júna 2022 9:04
To: govpp-dev@...
Cc: tsc@...
Subject: GoVPP committer promotion - Nathan Skrzypczak

 

Hi GoVPP committers,

 

I would like to nominate Nathan Skrzypczak as a new committer for the GoVPP project.

 

Nathan has been contributing to GoVPP since 2020 and already has several contributions:

 

https://gerrit.fd.io/r/gitweb?p=govpp.git;a=search;s=Nathan+Skrzypczak;st=author

 

Let's close the nomination period by Wednesday 15th June 20:00 UTC.

 

Please vote in this e-mail thread.

 

Thanks,


Re: FDIO Maintenance - 2022-06-09 15:30 UTC to 1930 UTC

Vanessa Valderrama
 

Maintenance is complete. Please open a ticket at support.linuxfoundation.org if you have any issues.

Thanks,

Vanessa

On 6/9/22 9:26 AM, Vanessa Valderrama wrote:

Putting Jenkins in shutdown mode in preparation for maintenance.

On 6/8/22 2:19 PM, Vanessa Valderrama wrote:

This maintenance is pending TSC approval tomorrow.

What:

  • Jenkins production
    • OS and security updates
    • Jenkins upgrade
    • Plugin upgrades
    • JDK upgrade
    • Jenkins performance tuning
  • Gerrit
    • OS and security updates
    • Gerrit upgrade
    • JDK upgrade
When:  2022-06-09 15:30 UTC to 1930 UTC

Why:

We normally do not perform maintenance during a release cycle but we're seeing intermittent timeouts on VPP/CSIT jobs. I discussed this with Dave and we agreed we'd like to try resolve these issues before the start of RC2.


Impact:

Jenkins will be placed in shutdown mode at 1430 UTC. All running jobs will be terminated at 15:30 UTC.

The following services will be unavailable during the maintenance window:
  • Jenkins sandbox and production
  • Gerrit


Re: FDIO Maintenance - 2022-06-09 15:30 UTC to 1930 UTC

Vanessa Valderrama
 

Putting Jenkins in shutdown mode in preparation for maintenance.

On 6/8/22 2:19 PM, Vanessa Valderrama wrote:

This maintenance is pending TSC approval tomorrow.

What:

  • Jenkins production
    • OS and security updates
    • Jenkins upgrade
    • Plugin upgrades
    • JDK upgrade
    • Jenkins performance tuning
  • Gerrit
    • OS and security updates
    • Gerrit upgrade
    • JDK upgrade
When:  2022-06-09 15:30 UTC to 1930 UTC

Why:

We normally do not perform maintenance during a release cycle but we're seeing intermittent timeouts on VPP/CSIT jobs. I discussed this with Dave and we agreed we'd like to try resolve these issues before the start of RC2.


Impact:

Jenkins will be placed in shutdown mode at 1430 UTC. All running jobs will be terminated at 15:30 UTC.

The following services will be unavailable during the maintenance window:
  • Jenkins sandbox and production
  • Gerrit


Vratko to proxy for me in TSC meeting today.

Maciek Konstantynowicz (mkonstan)
 

// resending to tsc list for posterity :)

I have a conflict. Thank you. -Maciek


FDIO Maintenance - 2022-06-09 15:30 UTC to 1930 UTC

Vanessa Valderrama
 

This maintenance is pending TSC approval tomorrow.

What:

  • Jenkins production
    • OS and security updates
    • Jenkins upgrade
    • Plugin upgrades
    • JDK upgrade
    • Jenkins performance tuning
  • Gerrit
    • OS and security updates
    • Gerrit upgrade
    • JDK upgrade
When:  2022-06-09 15:30 UTC to 1930 UTC

Why:

We normally do not perform maintenance during a release cycle but we're seeing intermittent timeouts on VPP/CSIT jobs. I discussed this with Dave and we agreed we'd like to try resolve these issues before the start of RC2.


Impact:

Jenkins will be placed in shutdown mode at 1430 UTC. All running jobs will be terminated at 15:30 UTC.

The following services will be unavailable during the maintenance window:
  • Jenkins sandbox and production
  • Gerrit


Re: [lfn-TAC] Remote Participation at the Porto DTF

Kenny Paul
 

Dear Communities,

 

Based upon discussions between the LF and the venue and conversation during today’s event committee meeting, the following decisions have been made regarding remote attendance and the virtual-only track for the event.  All other aspects of Heather’s original email to the community from May 19th (attached) regarding remote attendance still apply.

 

What has changed:

  • The Project representatives on the event committee have agreed to manage the scheduling and coordination of virtual sessions for their communities. Please contact your committee rep for any updates or changes to a virtual-only session.  ( Your reps are listed on the upper right of the wiki landing page for the event.  https://wiki.lfnetworking.org/x/oQboAw )
  • Virtual-only sessions are now included on the main event schedule along with all of the other sessions https://teamup.com/ksgw6qzqcmg9zbzsfq?date=2022-06-13&view=md4 .
    • The old virtual-only scheduling page has been locked and is considered deprecated.
  • The Ariane 1 conference room in Portugal has been set aside for on-site attendees to view all virtual-only sessions if they desire.
    • This room will be equipped with a dedicated laptop that will simply stream the assigned zoom bridge all day long.
    • This is the only room where virtual sessions will take place.
  • To better facilitate remote attendance to community-wide topics, integrated A/V is being configured for the plenary sessions on day-1 ONLY.

 

What is the same:

  • Remote attendance is still being accommodated on a best-effort basis only. Access and/or connectivity to any session cannot be guaranteed.
  • All virtual-only sessions will remain single tracked.
  • Zoom bridges will be allocated to all of the rooms, just as we usually do.
  • It remains the responsibility of the presenters to join those bridges and share content, audio, and record the session all via their own laptop.
  • There is no managed network being provisioned for the presenters.
  • There will be no integration into any of the in-room microphone and A/V set ups. (Excluding the day-1 plenary sessions as previously noted above.)
  • Onsite technical support is unavailable for troubleshooting audio or other issues related to remote connectivity.

 

Hopefully these changes will better accomodate those that are unable to join us in person.

I’m looking forward to seeing you all at the event! :-D

 

Thanks!

-kenny


Kenny Paul, Sr. Technical Community Architect

  ONAP Project & LFN Governing Board

  kpaul@...,  +1.510.766.5945, US Pacific time zone.

 

From: lfn-tac@... <lfn-tac@...> On Behalf Of Heather Kirksey
Sent: Thursday, May 19, 2022 8:08 PM
To: TAC <lfn-tac@...>; odim-tsc@...; onap-tsc <onap-tsc@...>; anuket-tsc@...; xgvela-tsc@...; tsc@...; TSC <tsc@...>; emco-tsc@...; TF TSC <tsc@...>; l3af-tsc@...
Subject: [lfn-TAC] Remote Participation at the Porto DTF

 

Dear Communities,

 

We are getting numerous requests for our June Developer and Testing Forum to be a hybrid event. We understand why: some geographies are still experiencing surges, corporate travel policies remain conservative, and some community members are not yet ready to travel. These are all valid.

 

The answer is, sadly, that we can’t. Bluntly, enabling a hybrid event would incur about a full 30% increase in total cost for what is a free event. We cannot do this and remain fiscally responsible. Additionally, it’s not a great experience for either on-site or remote participants. 

 

As Unix philosophy states, “Do one thing and do it well.”

 

Since Unix philosophy also asserts the "need to work together,” LFN staff have come up with some adhoc solutions to enable community participation that will be provided on an unmanaged, self-serve, best effort basis.  Please note that last sentence and note it well. We can enable but not ensure remote participation.

 

Here is what it looks like:

 

  • Zoom bridges will be allocated to all of the rooms just as we have always done, with these caveats:

 

o   All devices will be on the same Wifi network, including the presenter/facilitator slide show (i.e., subject to venue Wifi and public internet considerations) – there will be no managed network for presenter laptops.

 

o   We cannot guarantee integration into the in-room microphone and A/V set-up. Attendees can obviously use things like USB speakers to aid in listening to discussions, but obviously quality will be best-effort. This may work fine for small breakout sessions but will likely be inadequate for larger rooms.

o   Did I say Best Effort? That means there will not be full onsite technical support to troubleshoot audio or other issues related to remote connectivity. Please do not confuse your community architects with onsite IT. :)

 

  • Consider the experience of those on-site. Half an hour spent asking “Can you hear me now” is a poor use of time for those humans sitting together in a room halfway around the world. Nor does it advance our work.

 

  • We are setting up one virtual-only track for folks to use as they see fit.  
    • No meeting rooms will be assigned to virtual-only sessions. If folks on-site elect to attend a virtual-only presentation, they can simply join the associated zoom session just like any other zoom call on any day of the week.
    • The program committee will not take virtual-only sessions into account during their scheduling and planning. Please do not expect them to move things around to accommodate a conflict between an on-site and virtual-only session. Be kind to your programming committee.
    • Virtual-only sessions still require a Topic Page and the following all of the traditional ground rules.
    • Scheduling  a virtual-only session is first-come, first-served. Simply add your session to the wiki page: https://wiki.lfnetworking.org/x/pa4ZB  

 

As our event team works with the venue and A/V team, we will let you know if anything changes.

 

Finally, one last bit of Unix philosophy: “Economy and elegance of design through resource constraints.” The pandemic lockdowns started suddenly, but we find that they’re not ending that way. Connecting in-person again turns out to be bumpy and sometimes painful. We’re all doing our best, as a set of communities under constraints. This can either be a source of conflict or a source of creativity. Our choice. None but ours.

 

I appreciate everyone’s optimism, flexibility, and patience at this time as we all figure it out.

 

Heather

 

--

Heather Kirksey

VP, Ecosystem and Community

LF Networking

Mobile: +1.512.917.7938

Email/Google Talk: hkirksey@...

IRC: HKirksey

 


GoVPP committer promotion - Nathan Skrzypczak

Vladimir Lavor
 

Hi GoVPP committers,

 

I would like to nominate Nathan Skrzypczak as a new committer for the GoVPP project.

 

Nathan has been contributing to GoVPP since 2020 and already has several contributions:

 

https://gerrit.fd.io/r/gitweb?p=govpp.git;a=search;s=Nathan+Skrzypczak;st=author

 

Let's close the nomination period by Wednesday 15th June 20:00 UTC.

 

Please vote in this e-mail thread.

 

Thanks,


Re: FD.io Jenkins Sandbox

Vanessa Valderrama
 

Sandbox is back up and available.

Thank you,

Vanessa

On 6/1/22 2:55 PM, Vanessa Valderrama wrote:
I sent this message a little too soon. After plugin updates, we're getting errors on startup. Investigating now.

On 6/1/22 1:43 PM, Vanessa Valderrama wrote:
Sandbox testing is complete. Production upgrades will be after the 22.06 release.

Thank you,

Vanessa

On 5/25/22 11:09 AM, Vanessa Valderrama wrote:
We are going to be testing a Jenkins and JDK upgrade on the sandbox. There may be downtime during testing. Please feel free to ping me via Slack if you have any issues or concerns.

Thank you,
Vanessa


Re: FD.io Jenkins Sandbox

Vanessa Valderrama
 

I sent this message a little too soon. After plugin updates, we're getting errors on startup. Investigating now.

On 6/1/22 1:43 PM, Vanessa Valderrama wrote:
Sandbox testing is complete. Production upgrades will be after the 22.06 release.

Thank you,

Vanessa

On 5/25/22 11:09 AM, Vanessa Valderrama wrote:
We are going to be testing a Jenkins and JDK upgrade on the sandbox. There may be downtime during testing. Please feel free to ping me via Slack if you have any issues or concerns.

Thank you,
Vanessa


Re: FD.io Jenkins Sandbox

Vanessa Valderrama
 

Sandbox testing is complete. Production upgrades will be after the 22.06 release.

Thank you,

Vanessa

On 5/25/22 11:09 AM, Vanessa Valderrama wrote:
We are going to be testing a Jenkins and JDK upgrade on the sandbox. There may be downtime during testing. Please feel free to ping me via Slack if you have any issues or concerns.

Thank you,
Vanessa


FD.io at LFN D&TF

Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
 

Follow up to discussion about announced FD.io topics

for LFN Developer & Testing Forum.

 

June:

 

Good informative wiki sub-page: https://wiki.lfnetworking.org/display/LN/2022-06-DD+-+FD.io%3A+StoneWork+introduction

Less informative parent wiki page: https://wiki.lfnetworking.org/pages/viewpage.action?pageId=65537697
Event page (just linking to the wiki above): https://events.linuxfoundation.org/lfn-developer-testing-forum/
Community page (bad info; copy from January): https://community.lfnetworking.org/events/details/linux-foundation-lfn-developer-testing-forums-presents-lfn-developer-testing-forum-june-2022/

November:

I found just this stub: https://lfnetworking.org/event/lfn-developer-testing-forum-november/

 

Vratko.


FD.io Jenkins Sandbox

Vanessa Valderrama
 

We are going to be testing a Jenkins and JDK upgrade on the sandbox. There may be downtime during testing. Please feel free to ping me via Slack if you have any issues or concerns.

Thank you,
Vanessa

21 - 40 of 1727