Date   

Regrets

Joel Halpern
 

I am co-chairing another meeting at the time of the fd.io TSC call this week.

Yours,

Joel


Re: Production Jenkins Incident

Vanessa Valderrama
 

The upgrade is complete and Jenkins has been restarted. We will continue
to monitor for additional issues. If you experience any issues, please
open a ticket at support.linuxfoundation.org.

Thank you,
Vanessa

On 5/13/20 11:14 AM, Vanessa Valderrama wrote:
Jenkins is currently in shutdown mode. We need to do an emergency JDK
upgrade to OpenJDK 8u252 (1.8.0_252-b09). We believe the upgrade on
April 28th introduced a new defect that is resolved in the latest version

JDK-8219597: (bf) Heap buffer state changes could provoke unexpected
exceptions

Release Notes - https://adoptopenjdk.net/release_notes.html#jdk8u252

Thank you,
Vanessa


On 5/13/20 10:38 AM, Vanessa Valderrama wrote:
We are experiencing intermittent issues with jenkins.fd.io. We are
working on resolving the issues as quickly as possible.

Thank you,
Vanessa


Re: Production Jenkins Incident

Vanessa Valderrama
 

Jenkins is currently in shutdown mode. We need to do an emergency JDK
upgrade to OpenJDK 8u252 (1.8.0_252-b09). We believe the upgrade on
April 28th introduced a new defect that is resolved in the latest version

JDK-8219597: (bf) Heap buffer state changes could provoke unexpected
exceptions

Release Notes - https://adoptopenjdk.net/release_notes.html#jdk8u252

Thank you,
Vanessa

On 5/13/20 10:38 AM, Vanessa Valderrama wrote:
We are experiencing intermittent issues with jenkins.fd.io. We are
working on resolving the issues as quickly as possible.

Thank you,
Vanessa


Production Jenkins Incident

Vanessa Valderrama
 

We are experiencing intermittent issues with jenkins.fd.io. We are
working on resolving the issues as quickly as possible.

Thank you,
Vanessa


Re: CSIT-2001 update: Xeon Skylake Performance and Progressions/Regressions RCAs

Maciek Konstantynowicz (mkonstan)
 

Slides used on today’s VPP call: https://wiki.fd.io/view/File:200512-csit-vpp-readout.pptx

On 12 May 2020, at 15:18, Maciek Konstantynowicz (mkonstan) <mkonstan@...> wrote:

Dear All,

We have finally pushed out an update to CSIT-2001 report with VPP
performance data for testbeds with Intel Xeon Skylake processors (2n-skx
and 3n-skx testbeds), with SUT and TG servers impacted by firmware and
OS upgrades (BIOS, ucode, kernel updates with mitigations against the
newly discovered Spectre-Meltdown security vulnerabilities).

The updated CSIT-2001 report should be available for browsing just
before 15:00 UTC today, subject to Jenkins job execution (will have
updated version timestamp):

https://docs.fd.io/csit/rls2001/report/
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/csit_release_notes.html

In addition to 2n-skx and 3n-skx performance data available at the usual
locations in the report (see links [r1] to [r4] referenced below), we
have expanded the way we do VPP release-to-release comparisons and root
cause analysis (RCA) for any identified performance progressions and
regressions:

- CSIT test environment is now versioned, with ver. 1 associated
with CSIT rls1908 git branch as of 2019-08-21, and ver. 2
associated with CSIT master and rls2001 git branches as of
2020-03-27.

- To identify SUT performance change(s) due to CSIT test environment
change(s) from ver. 1 to ver. 2, VPP v19.08.1 has been re-tested
in ver. 2 and results compared against the past data obtained with
ver. 1. RCA1 analysis has been applied to this part. See [r5].

- To identify SUT performance change(s) due to VPP code change(s)
from v19.08.1 to v20.01.0, both VPP versions have been tested in
CSIT environment ver. 2 and results compared. Separate RCA2
analysis has been applied to this part. See [r5].

- At this stage RCA1 and RCA2 analyses are focusing on progressions > +5%
and regressions < -5%.

Attached pasted complete list of RCAs identified as part of this
exercise [1] to [12].

Hope it makes sense. For any questions and comments please contact
csit-dev@....

Regards,
Maciek
(on behalf of FD.io CSIT team)


Specific links within the report:

[r1] VPP throughput graphs,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/index.html

[r2] VPP throughput speedup multi-core,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/throughput_speedup_multi_core/ip4-2n-skx-xxv710.html

[r3] VPP packet latency,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_latency/index.html

[r4] VPP soak tests,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/soak_tests/index.html

[r5] 2n-skx PDR comparison with RCA,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/comparisons/current_vs_previous_release.html#n-skx

[r6] 3n-skx PDR comparison with RCA,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/comparisons/current_vs_previous_release.html#id1

RCA1:

[1] DONE, Impact of upgrades: i) Skx ucode from 0x2000043 to 0x2000065,
[ii) Linux kernel from 4.15.0-60 to 4.15.0-72 and iii) SuperMicro
[motherboard BIOS from 3.0c to 3.2.

[2] DONE, Applied fix of FVL NIC firmware 6.0.1 for increasing TRex pps
rate from 27 Mpps to 37 Mpps, [CSIT-1503], [TRex-519].

[3] DONE, Applied VPP PAPI fix to enable memif zero-copy, [CSIT-1592],
[VPP-1764].

[4] OPEN, Higher than before StDev of PDR throughput for VPP vhost-user
with VPP-inside-VM, under investigation, [CSIT-1699], [CSIT-1704].

RCA2:

[5] OPEN, dot1q-l2xcbase progression, retro-inspection of weekly ndrpdr
tests points to ge-22805, automated bisect script does not work
due to frequent API changes, [CSIT-1699], [CSIT-1705].

[6] DONE, ip4base-nat44 regression, ge-23963
(https://gerrit.fd.io/r/c/vpp/+/23963#message-044278e6_752c3327).

[7] WIP, avf-ip4scale regression, CANDIDATE(S) before ge-22699, [
CSIT-1699], [CSIT-1706].

[8] OPEN, VPP vhost-user with VPP-inside-VM higher than before stdev
of PDR throughput, under investigation, [CSIT-1699], [CSIT-1704].

[9] WIP, vhost-user with testpmd-in-VM progression, CANDIDATE(S)
before 22277, [CSIT-1699], [CSIT-1707].

[10] WIP, avf-ip4base regression, CANDIDATE(S) range
ge-18361..ge-24505, [CSIT-1699], [CSIT-1708].

[11] DONE, memif regression, CANDIDATE(S) confirmed ge-23801.

[12] WIP, ipsec tnl sw scale regression, CANDIDATE(S) before ge-23557,
[CSIT-1699], [CSIT-1712].


CSIT-2001 update: Xeon Skylake Performance and Progressions/Regressions RCAs

Maciek Konstantynowicz (mkonstan)
 

Dear All,

We have finally pushed out an update to CSIT-2001 report with VPP
performance data for testbeds with Intel Xeon Skylake processors (2n-skx
and 3n-skx testbeds), with SUT and TG servers impacted by firmware and
OS upgrades (BIOS, ucode, kernel updates with mitigations against the
newly discovered Spectre-Meltdown security vulnerabilities).

The updated CSIT-2001 report should be available for browsing just
before 15:00 UTC today, subject to Jenkins job execution (will have
updated version timestamp):

https://docs.fd.io/csit/rls2001/report/
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/csit_release_notes.html

In addition to 2n-skx and 3n-skx performance data available at the usual
locations in the report (see links [r1] to [r4] referenced below), we
have expanded the way we do VPP release-to-release comparisons and root
cause analysis (RCA) for any identified performance progressions and
regressions:

- CSIT test environment is now versioned, with ver. 1 associated
with CSIT rls1908 git branch as of 2019-08-21, and ver. 2
associated with CSIT master and rls2001 git branches as of
2020-03-27.

- To identify SUT performance change(s) due to CSIT test environment
change(s) from ver. 1 to ver. 2, VPP v19.08.1 has been re-tested
in ver. 2 and results compared against the past data obtained with
ver. 1. RCA1 analysis has been applied to this part. See [r5].

- To identify SUT performance change(s) due to VPP code change(s)
from v19.08.1 to v20.01.0, both VPP versions have been tested in
CSIT environment ver. 2 and results compared. Separate RCA2
analysis has been applied to this part. See [r5].

- At this stage RCA1 and RCA2 analyses are focusing on progressions > +5%
and regressions < -5%.

Attached pasted complete list of RCAs identified as part of this
exercise [1] to [12].

Hope it makes sense. For any questions and comments please contact
csit-dev@....

Regards,
Maciek
(on behalf of FD.io CSIT team)


Specific links within the report:

[r1] VPP throughput graphs,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/index.html

[r2] VPP throughput speedup multi-core,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/throughput_speedup_multi_core/ip4-2n-skx-xxv710.html

[r3] VPP packet latency,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_latency/index.html

[r4] VPP soak tests,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/soak_tests/index.html

[r5] 2n-skx PDR comparison with RCA,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/comparisons/current_vs_previous_release.html#n-skx

[r6] 3n-skx PDR comparison with RCA,
https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/comparisons/current_vs_previous_release.html#id1

RCA1:

[1] DONE, Impact of upgrades: i) Skx ucode from 0x2000043 to 0x2000065,
[ii) Linux kernel from 4.15.0-60 to 4.15.0-72 and iii) SuperMicro
[motherboard BIOS from 3.0c to 3.2.

[2] DONE, Applied fix of FVL NIC firmware 6.0.1 for increasing TRex pps
rate from 27 Mpps to 37 Mpps, [CSIT-1503], [TRex-519].

[3] DONE, Applied VPP PAPI fix to enable memif zero-copy, [CSIT-1592],
[VPP-1764].

[4] OPEN, Higher than before StDev of PDR throughput for VPP vhost-user
with VPP-inside-VM, under investigation, [CSIT-1699], [CSIT-1704].

RCA2:

[5] OPEN, dot1q-l2xcbase progression, retro-inspection of weekly ndrpdr
tests points to ge-22805, automated bisect script does not work
due to frequent API changes, [CSIT-1699], [CSIT-1705].

[6] DONE, ip4base-nat44 regression, ge-23963
(https://gerrit.fd.io/r/c/vpp/+/23963#message-044278e6_752c3327).

[7] WIP, avf-ip4scale regression, CANDIDATE(S) before ge-22699, [
CSIT-1699], [CSIT-1706].

[8] OPEN, VPP vhost-user with VPP-inside-VM higher than before stdev
of PDR throughput, under investigation, [CSIT-1699], [CSIT-1704].

[9] WIP, vhost-user with testpmd-in-VM progression, CANDIDATE(S)
before 22277, [CSIT-1699], [CSIT-1707].

[10] WIP, avf-ip4base regression, CANDIDATE(S) range
ge-18361..ge-24505, [CSIT-1699], [CSIT-1708].

[11] DONE, memif regression, CANDIDATE(S) confirmed ge-23801.

[12] WIP, ipsec tnl sw scale regression, CANDIDATE(S) before ge-23557,
[CSIT-1699], [CSIT-1712].


Re: fdio/release repository on packagecloud now contains 19900 with some odd artifacts

Luca Muscariello
 



On Wed, May 6, 2020 at 4:25 PM Andrew ūüĎĹ Yourtchenko <ayourtch@...> wrote:
Luca,

Excellent, thank you!

So, ballpark timeline-wise, do you think you might get it done to still qualify as a ‚Äúspring cleaning project‚ÄĚ ? :-)

Message well received :-)


Re: fdio/release repository on packagecloud now contains 19900 with some odd artifacts

Luca Muscariello
 

Andrew,

The implementation of (3) is indeed safe and can be done quickly and
does not require any additional decision to be made right now.

Short term, we'll work on (3). There may be some ci-management updates
to force packagecloud to keep the N latest packages only as a FIFO cache
on the currently active release. N can be as small as, say, 5.
For previous releases only one set of packages is kept in the repo.


We are going to do some ci-management updates in any case because we
are currently in the process of catching up with VPP 20.05 so this may
be the right moment.

Thanks
Luca


On Wed, May 6, 2020 at 3:28 PM Andrew ūüĎĹ Yourtchenko <ayourtch@...> wrote:
Dear Luca,

My opinion hasn’t changed - it’s possibly a combination of the below two approaches:

3 - we have no need to keep all these artifacts. So we could just keep the latest 
artifacts for each hicn release for archival reasons only. We do not backport anything 
in previous releases nor we support our user base with older releases. Packagecloud has a 
REST API to manage that well.

4 - as an alternative we could create an independent repo for the hicn project. Still we'd 
like to delete obsolete artifacts ad in option 3.

I would suggest starting with the step (3) and the safest option to implement is the two stage process:

- moving outdated hicn project artifacts from fdio/release to fdio/attic (to be created if exists)

- deleting the hicn artifacts from fdio/atticthat were added in the previous cleanup cycle or before that.

This approach in itself is implementable in two phases, and the first phase (release=>attic) is reversible, should any glitch arise and should any unnecessary packages be archived.

Since that work will be useful to verify even after the testing, and since from experience we know we can go to bit higher quantify of packages before the wheels fall off, I would also suggest that you can use the current state of fdio/release repo as a verification that the implementation of step (3) works correctly.

We can then revisit the situation and assess whether the step (4) is even needed, or if (3) is good enough.

What do you think ?

--a

On 6 May 2020, at 14:45, Luca Muscariello <muscariello@...> wrote:

3 - we have no need to keep all these artifacts. So we could just keep the latest 
artifacts for each hicn release for archival reasons only. We do not backport anything 
in previous releases nor we support our user base with older releases. Packagecloud has a 
REST API to manage that well.

4 - as an alternative we could create an independent repo for the hicn project. Still we'd 
like to delete obsolete artifacts ad in option 3.


Re: fdio/release repository on packagecloud now contains 19900 with some odd artifacts

Luca Muscariello
 

Dear Andrew,

thanks for bringing this to our attention.

As mitigation I'll file another ticket to LF to remove unnecessary packages.
Concerning the long term solution I'm not sure which one has been agreed.

We did not get much feedback on how to proceed except from you.
We had a pending vote to get Mauro approved as committer in ci-management,
as these options require us to have someone to pay attention to hicn patches
during the release phase.

Please share your opinion on what is preferable so that we can implement it.

Thanks and apologies if that is not yet fixed.
Luca





On Wed, May 6, 2020 at 1:03 PM Andrew ūüĎĹ Yourtchenko <ayourtch@...> wrote:
Dear Luca,

As we are approaching the VPP release 20.05, I wanted to revive this thread.

At the moment of this writing, the fdio/release has 7408 packages.

Could you please give an update where you are with the implementation of the plans we discussed ? (As per the quoted mail thread).

Thanks a lot !

--a

On 7 Feb 2020, at 11:40, Luca Muscariello <muscariello@...> wrote:

ÔĽŅ
Andrew,

Agree, this is just mitigation. 
4+3 is something we could work on in ci-management and plan to deploy for the next release.

Golden releases, as you say, is to be understood for hicn, we don't have muscles to backport bug fixes in golden releases.
We would end up putting (tomb)stone releases :-) 
For the time being we stay cheap and little and maintain one release.

Thanks
Luca

On Fri, Feb 7, 2020 at 11:28 AM Andrew ūüĎĹ Yourtchenko <ayourtch@...> wrote:
Excellent, thanks Luca.

Longer term I still suggest option 4+3, and if you have ‚Äúgolden‚ÄĚ releases (which in turn will work with released VPP versions) then you might put them under the fdio/release, thus replicating the behavior of VPP repos.

--a

On 7 Feb 2020, at 11:21, Luca Muscariello <muscariello@...> wrote:

ÔĽŅ
FYI

we have reduced the number of artifacts to 3200.


This should fix the problem.

Luca



On Fri, Jan 31, 2020 at 9:51 AM Luca Muscariello <muscariello@...> wrote:
Dear tsc members,

(with hicn/cicn PTL's hat on)

The current release repo https://packagecloud.io/fdio/release contains 20214 
artifacts almost entirely from our projects.
The current binary distribution is composed of 60 deb packages and 30 rpm packages.

Among hicn dependencies we have the latest VPP release, currently 20.01. 
The hICN project is composed of 6 committers and we do not support multiple releases 
but just the master HEAD. 

Our git repo has one single master branch (w/o release branches) and releases are based 
on git tags. The branch is tagged with the latest VPP release code, i.e. v20.01 which
is pushed after the VPP project has released the new version. We start catching up
with all VPP updates during the weeks of release preparation made by Andrew.
As soon as Andrew releases the new distribution under "release/" we merge our patches and 
change git tag in the hicn repo.

1 - We do not publish hicn binaries under master/ as the vpp dependencies there would not be
compatible with "hicn master" which depends on "vpp stable/"

2 - If we publish under #stable/, we'd create as many artifacts there as currently under 
"release/" and at each release we need to update ci-management. 

3 - we have no need to keep all these artifacts. So we could just keep the latest 
artifacts for each hicn release for archival reasons only. We do not backport anything 
in previous releases nor we support our user base with older releases. Packagecloud has a 
REST API to manage that well.

4 - as an alternative we could create an independent repo for the hicn project. Still we'd 
like to delete obsolete artifacts ad in option 3.

*Option 1* is unfeasible because it requires our user base to have a complex configuration 
of apt repos, which BTW only works if packages are well created. This is not always the case.

*Option 2* does not look like a solution to reduce the number of artifacts in a release folder.
It may work in conjunction with option 3. It may work well if we also get one of our committers 
in ci-management, e.g. Mauro Sardara who's substantially contributed to ci-management already.

*Option 3* seems useful in general and would allow to 
 (i) keep host configuration simple, 
 (ii) keep repo size to the right size, 
 (iii) avoid  repo duplication as in 4. 
if we keep artifacts under release our user-base would be happier as it need not host upgrades.

*Option 4 + 3* would be ok as well.

Thanks for you feedback
Best
Luca



On Thu, Jan 30, 2020 at 7:37 PM Andrew ūüĎĹ Yourtchenko <ayourtch@...> wrote:
Dear TSC,

In the capacity of the VPP 20.01 release manager, I would like to raise your attention to the fact that the fdio/release now contains 19900 files, and the there are some invalid packages, like ‚Äúhoneycomb‚ÄĚ, and ‚Äú-dev‚ÄĚ.

This was found as we started CSIT testing for VPP 20.01, and Peter Mikus has a workaround - so it doesn’t impact the schedule for the 20.01 testing. (VPP packages download fine)

However, I wanted to raise this concern.

Are some projects doing so many releases, that it results in almost 20000 files?

Thanks for consideration.

--a


Register for the LFN TAC Webinar, May 12th, 10:00 AM PT

Brandon Wick
 

LFN Community, 

Following last week's inaugural LFN Webinar, The State of Open Source Networking & the Edge, next week representatives from the LFN Technical Advisory Council (TAC) will be giving a presentation on the open source networking opportunity and the LFN projects. This will be based on the findings of the new LFN TAC Whitepaper published last week. We encourage you to join the webinar live and to ask questions. Registration is required!

May 12, 2020, 10:00 AM PT
Speakers: Ranny Haiby, Samsung; Abhijit Kumhare, Ericsson; Chaker Al Hakim, Futurewei; Davide Cherubini, Vodafone
Building the future open networks ‚Äď How LF Networking provides the building blocks

The LFN Technical Advisory Council (TAC) is made up of technical experts from LF Networking (LFN) members who meet regularly to facilitate communication and collaboration among the 8 technical projects in LFN. The TAC recently completed a comprehensive whitepaper about the LFN available here: https://www.lfnetworking.org/resources/2020/04/28/lf-networking-whitepaper/. In this webinar, representatives from the TAC will review the major elements of the paper, including the role of open source in modern network design, how Linux Foundation projects may be used as building blocks for modern networks, project highlights, and an E2E use case. System architects, developers, product and project managers, network operators, system integrators, and more will learn how to approach and incorporate open source and LFN projects into their next-generation project designs and product roadmaps. Register Today!

Register Here.

See the full list of upcoming LFN Webinars here. Have a webinar idea? Please review the LFN Webinar Guidelines and fill in the LFN Webinar Submission Form.

Please let us know if you have any questions or comments. Thanks!

Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960




Re: Review projects for archive

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

> trex is alive and well… just no longer using gerrit

 

Do we have a process for archiving a git repository,

as opposed to archiving a project?

If yes, we could place a notice into the repository

and archive it.

 

We did something similar in OpenDaylight [0],

though that involved also splitting the project.

But the main idea should apply also here,

assuming we can get a TRex committer so merge the notice.

 

Vratko.

 

[0] https://github.com/opendaylight/archived-integration

 

From: tsc@... <tsc@...> On Behalf Of Edward Warnicke via lists.fd.io
Sent: Saturday, 2020-May-02 01:34
To: Vanessa Valderrama <vvalderrama@...>
Cc: tsc@...
Subject: Re: [tsc] Review projects for archive

 

Vanessa… trex is alive and well… just no longer using gerrit … they are using GitHub.

 

Ed



On Apr 29, 2020, at 3:26 PM, Vanessa Valderrama <vvalderrama@...> wrote:

 

I'd like to propose the TSC review these inactive projects to determine if they can be archived. The projects in red have been inactive for 18 months or longer.

  • Project: DMM
  • Last commit: Wed Apr 3 12:01:33 2019 +0000
  • Project: HC2VPP
  • Last commit: Wed Apr 3 12:01:33 2019 +0000
  • Project: Honeycomb
  • Last commit: Tue Jun 4 15:57:23 2019 +0200
  • Project: JVPP
  • Last commit: Mon Jun 17 08:36:03 2019 +0200

 

  • Project: NSH_SFC
    • Last commit: Sat Jun 2 02:23:05 2018 +0800
    • Comment: All the code in NSH_SFC has been merged into VPP master branch
  • Project: ODP4VPP
    • Initial commit: Sun Apr 23 12:38:20 2017 -0400
  • Project: ONE
    • Last commit: Tue Oct 31 15:49:06 2017 +0000

 

  • Project: PMA_TOOLS
    • Initial commit: Tue Oct 16 21:57:39 2018 -0700exit

 

  • Project: PUPPET-FDIO
    • Last commit: Tue Jan 30 14:35:45 2018 +0100
    • Comment: The project is not active but may still be consumed by tripleo project in OpenStack

 

  • Project: P4VPP
    • Initial commit: Fri Aug 25 17:17:23 2017 +0000
  • Project: RPM_DPDK
    • Last commit: Thu Jul 5 13:14:14 2018 -0400
    • Comment: The project is not active. PTL recommends project termination
  • Project: Sweetcomb
    • Initial commit: Fri Aug 30 14:05:35 2019 +0800
  • Project: TREX
    • Last commit: Thu Mar 30 18:39:16 2017 +0300
    • Comment: Using GitHub
  • Project: VPPSB
    • Initial commit: Fri May 24 19:29:36 2019 +0200

Thank you,
Vanessa

 

 


Re: Review projects for archive

Edward Warnicke
 

Vanessa… trex is alive and well… just no longer using gerrit … they are using GitHub.

Ed

On Apr 29, 2020, at 3:26 PM, Vanessa Valderrama <vvalderrama@...> wrote:

I'd like to propose the TSC review these inactive projects to determine if they can be archived. The projects in red have been inactive for 18 months or longer.

  • Project: DMM
  • Last commit: Wed Apr 3 12:01:33 2019 +0000
  • Project: HC2VPP
  • Last commit: Wed Apr 3 12:01:33 2019 +0000
  • Project: Honeycomb
  • Last commit: Tue Jun 4 15:57:23 2019 +0200
  • Project: JVPP
  • Last commit: Mon Jun 17 08:36:03 2019 +0200

  • Project: NSH_SFC
    • Last commit: Sat Jun 2 02:23:05 2018 +0800
    • Comment: All the code in NSH_SFC has been merged into VPP master branch
  • Project: ODP4VPP
    • Initial commit: Sun Apr 23 12:38:20 2017 -0400
  • Project: ONE
    • Last commit: Tue Oct 31 15:49:06 2017 +0000

  • Project: PMA_TOOLS
    • Initial commit: Tue Oct 16 21:57:39 2018 -0700exit

  • Project: PUPPET-FDIO
    • Last commit: Tue Jan 30 14:35:45 2018 +0100
    • Comment: The project is not active but may still be consumed by tripleo project in OpenStack

  • Project: P4VPP
    • Initial commit: Fri Aug 25 17:17:23 2017 +0000
  • Project: RPM_DPDK
    • Last commit: Thu Jul 5 13:14:14 2018 -0400
    • Comment: The project is not active. PTL recommends project termination
  • Project: Sweetcomb
    • Initial commit: Fri Aug 30 14:05:35 2019 +0800
  • Project: VPPSB
    • Initial commit: Fri May 24 19:29:36 2019 +0200
Thank you,
Vanessa



Re: Cannot join TSC tomorrow

Edward Warnicke
 

Hope he feels well soon!  He will be missed.

Ed

On Apr 30, 2020, at 6:05 AM, George Zhao <george.zhao@...> wrote:

Hi

This is George's wife sending this email per his request.  George has  a very bad stomach ache and has been throwing up the whole night.  He won't be able to join the TSC meeting tomorrow.

Regards,




Cannot join TSC tomorrow

George Zhao
 

Hi

This is George's wife sending this email per his request.  George has  a very bad stomach ache and has been throwing up the whole night.  He won't be able to join the TSC meeting tomorrow.

Regards,



Review projects for archive

Vanessa Valderrama
 

I'd like to propose the TSC review these inactive projects to determine if they can be archived. The projects in red have been inactive for 18 months or longer.

  • Project: DMM
  • Last commit: Wed Apr 3 12:01:33 2019 +0000
  • Project: HC2VPP
  • Last commit: Wed Apr 3 12:01:33 2019 +0000
  • Project: Honeycomb
  • Last commit: Tue Jun 4 15:57:23 2019 +0200
  • Project: JVPP
  • Last commit: Mon Jun 17 08:36:03 2019 +0200

  • Project: NSH_SFC
    • Last commit: Sat Jun 2 02:23:05 2018 +0800
    • Comment: All the code in NSH_SFC has been merged into VPP master branch
  • Project: ODP4VPP
    • Initial commit: Sun Apr 23 12:38:20 2017 -0400
  • Project: ONE
    • Last commit: Tue Oct 31 15:49:06 2017 +0000

  • Project: PMA_TOOLS
    • Initial commit: Tue Oct 16 21:57:39 2018 -0700exit

  • Project: PUPPET-FDIO
    • Last commit: Tue Jan 30 14:35:45 2018 +0100
    • Comment: The project is not active but may still be consumed by tripleo project in OpenStack

  • Project: P4VPP
    • Initial commit: Fri Aug 25 17:17:23 2017 +0000
  • Project: RPM_DPDK
    • Last commit: Thu Jul 5 13:14:14 2018 -0400
    • Comment: The project is not active. PTL recommends project termination
  • Project: Sweetcomb
    • Initial commit: Fri Aug 30 14:05:35 2019 +0800
  • Project: VPPSB
    • Initial commit: Fri May 24 19:29:36 2019 +0200
Thank you,
Vanessa


Re: FD.io Maintenance: Tuesday April 28, 2020 1800 UTC to 2200 UTC

Vanessa Valderrama
 

Maintenance is complete. If you experience any issues, please submit a ticket at support.linuxfoundation.org

Thank you,
Anton & Vanessa


On 4/28/20 1:06 PM, Vanessa Valderrama wrote:

Starting maintenance

On 4/28/20 12:02 PM, Vanessa Valderrama wrote:

Jenkins has been placed into shutdown mode in preparation for maintenance. Please contact me via Slack or IRC if jobs cannot be terminated at 1800 UTC.

Thank you,
Vanessa


On 4/16/20 4:12 PM, Vanessa Valderrama wrote:

When:  Tuesday April 28, 2020 1800 UTC to 2200 UTC

What: Linux foundation upgrades, OS updates, and security patches
  • Jenkins
    • Upgrade to 2.222.x
    • OS and security updates
    • Plugin updates
  • Nexus
    • Upgrade to 2.14.17-01
    • OS and security updates
  • Jira
    • Upgrade to 8.6.1
    • OS and security updates
  • Gerrit
    • Upgrade to 3.1.x
    • OS and security updates
  • OpenGrok
    • OS and security updates
Impact:

Gerrit will be unavailable for all or part of the window as we do the following:
  • Convert the existing database to NoteDB
  • Upgrade Gerrit to 3.1.x
  • Rebuild indexes
The standard upgrades and maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1700 UTC. Running jobs will be aborted at 1800 UTC, please let us know if that will cause a problem for your project.

The following systems will be unavailable during the maintenance window:
  • ¬†¬†¬† Jenkins sandbox
  • ¬†¬†¬† Jenkins production
  • ¬†¬†¬† Nexus
  • ¬†¬†¬† Jira
  • ¬†¬†¬† Gerrit
  • ¬†¬†¬† OpenGrok


RPM_DPDK Questions

Vanessa Valderrama
 

Ed,

Can we start the process to archive/terminate the RPM_DPDK project?

Thank you,
Vanessa


-------- Forwarded Message --------
Subject: Re: RPM_DPDK Questions
Date: Thu, 30 Jan 2020 13:43:11 -0500
From: Thomas F Herbert <therbert@...>
To: Vanessa Valderrama <vvalderrama@...>, bmcfall@...


Vanessa,

I was the PTL. However, the project is no longer active. I would recommend engaging the formal fd.io process to terminate that project unless someone else plans to become PTL and become active in the project.

--Tom


On 1/30/20 1:24 PM, Vanessa Valderrama wrote:
Is the RPM_DPDK project still using Gerrit and Jenkins? Is there a PTL
for the project?

Thank you,
Vanessa

--
Thomas F Herbert
NFV and Fast Data Planes
Networking Group Office of the CTO
Red Hat


Re: FD.io Maintenance: Tuesday April 28, 2020 1800 UTC to 2200 UTC

Vanessa Valderrama
 

Starting maintenance

On 4/28/20 12:02 PM, Vanessa Valderrama wrote:

Jenkins has been placed into shutdown mode in preparation for maintenance. Please contact me via Slack or IRC if jobs cannot be terminated at 1800 UTC.

Thank you,
Vanessa


On 4/16/20 4:12 PM, Vanessa Valderrama wrote:

When:  Tuesday April 28, 2020 1800 UTC to 2200 UTC

What: Linux foundation upgrades, OS updates, and security patches
  • Jenkins
    • Upgrade to 2.222.x
    • OS and security updates
    • Plugin updates
  • Nexus
    • Upgrade to 2.14.17-01
    • OS and security updates
  • Jira
    • Upgrade to 8.6.1
    • OS and security updates
  • Gerrit
    • Upgrade to 3.1.x
    • OS and security updates
  • OpenGrok
    • OS and security updates
Impact:

Gerrit will be unavailable for all or part of the window as we do the following:
  • Convert the existing database to NoteDB
  • Upgrade Gerrit to 3.1.x
  • Rebuild indexes
The standard upgrades and maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1700 UTC. Running jobs will be aborted at 1800 UTC, please let us know if that will cause a problem for your project.

The following systems will be unavailable during the maintenance window:
  • ¬†¬†¬† Jenkins sandbox
  • ¬†¬†¬† Jenkins production
  • ¬†¬†¬† Nexus
  • ¬†¬†¬† Jira
  • ¬†¬†¬† Gerrit
  • ¬†¬†¬† OpenGrok


Re: FD.io Maintenance: Tuesday April 28, 2020 1800 UTC to 2200 UTC

Vanessa Valderrama
 

Jenkins has been placed into shutdown mode in preparation for maintenance. Please contact me via Slack or IRC if jobs cannot be terminated at 1800 UTC.

Thank you,
Vanessa


On 4/16/20 4:12 PM, Vanessa Valderrama wrote:

When:  Tuesday April 28, 2020 1800 UTC to 2200 UTC

What: Linux foundation upgrades, OS updates, and security patches
  • Jenkins
    • Upgrade to 2.222.x
    • OS and security updates
    • Plugin updates
  • Nexus
    • Upgrade to 2.14.17-01
    • OS and security updates
  • Jira
    • Upgrade to 8.6.1
    • OS and security updates
  • Gerrit
    • Upgrade to 3.1.x
    • OS and security updates
  • OpenGrok
    • OS and security updates
Impact:

Gerrit will be unavailable for all or part of the window as we do the following:
  • Convert the existing database to NoteDB
  • Upgrade Gerrit to 3.1.x
  • Rebuild indexes
The standard upgrades and maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1700 UTC. Running jobs will be aborted at 1800 UTC, please let us know if that will cause a problem for your project.

The following systems will be unavailable during the maintenance window:
  • ¬†¬†¬† Jenkins sandbox
  • ¬†¬†¬† Jenkins production
  • ¬†¬†¬† Nexus
  • ¬†¬†¬† Jira
  • ¬†¬†¬† Gerrit
  • ¬†¬†¬† OpenGrok


Re: FD.io Maintenance: Tuesday April 28, 2020 1800 UTC to 2200 UTC

Vanessa Valderrama
 

Maintenance reminder

On 4/16/20 4:12 PM, Vanessa Valderrama wrote:

When:  Tuesday April 28, 2020 1800 UTC to 2200 UTC

What: Linux foundation upgrades, OS updates, and security patches
  • Jenkins
    • Upgrade to 2.222.x
    • OS and security updates
    • Plugin updates
  • Nexus
    • Upgrade to 2.14.17-01
    • OS and security updates
  • Jira
    • Upgrade to 8.6.1
    • OS and security updates
  • Gerrit
    • Upgrade to 3.1.x
    • OS and security updates
  • OpenGrok
    • OS and security updates
Impact:

Gerrit will be unavailable for all or part of the window as we do the following:
  • Convert the existing database to NoteDB
  • Upgrade Gerrit to 3.1.x
  • Rebuild indexes
The standard upgrades and maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1700 UTC. Running jobs will be aborted at 1800 UTC, please let us know if that will cause a problem for your project.

The following systems will be unavailable during the maintenance window:
  • ¬†¬†¬† Jenkins sandbox
  • ¬†¬†¬† Jenkins production
  • ¬†¬†¬† Nexus
  • ¬†¬†¬† Jira
  • ¬†¬†¬† Gerrit
  • ¬†¬†¬† OpenGrok