Date   
Re: FDIO Maintenance - 2020-02-20 1900 UTC to 2400 UTC

Vanessa Valderrama
 

Starting maintenance now.

On 2/20/20 12:04 PM, Vanessa Valderrama wrote:

Jenkins is being placed into shutdown mode now. Maintaince will start at 1900 UTC. Please let us know if there are any running jobs that cannot be terminated.

Thank you,
Vanessa



On 2/20/20 9:47 AM, Vanessa Valderrama wrote:

Reminder: Jenkins will be placed in shutdown mode at 1800 UTC

On 2/19/20 9:44 AM, Vanessa Valderrama wrote:
What: Standard updates and upgrade
  • Jenkins
    • OS and security updates
    • Upgrade
    • Plugin updates
  • Nexus
    • OS updates
  • Jira
    • OS updates
  • Gerrit
    • OS updates
  • Sonar
    • OS updates
  • OpenGrok
    • OS updates
When:  2020-02-20 1900 UTC to 2400 UTC

Impact:

Maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1800 UTC. Please let us know if specific jobs cannot be aborted.
The following systems will be unavailable during the maintenance window:
  •     Jenkins sandbox
  •     Jenkins production
  •     Nexus
  •     Jira
  •     Gerrit
  •     Sonar
  •     OpenGrok

Re: FDIO Maintenance - 2020-02-20 1900 UTC to 2400 UTC

Vanessa Valderrama
 

Jenkins is being placed into shutdown mode now. Maintaince will start at 1900 UTC. Please let us know if there are any running jobs that cannot be terminated.

Thank you,
Vanessa



On 2/20/20 9:47 AM, Vanessa Valderrama wrote:

Reminder: Jenkins will be placed in shutdown mode at 1800 UTC

On 2/19/20 9:44 AM, Vanessa Valderrama wrote:
What: Standard updates and upgrade
  • Jenkins
    • OS and security updates
    • Upgrade
    • Plugin updates
  • Nexus
    • OS updates
  • Jira
    • OS updates
  • Gerrit
    • OS updates
  • Sonar
    • OS updates
  • OpenGrok
    • OS updates
When:  2020-02-20 1900 UTC to 2400 UTC

Impact:

Maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1800 UTC. Please let us know if specific jobs cannot be aborted.
The following systems will be unavailable during the maintenance window:
  •     Jenkins sandbox
  •     Jenkins production
  •     Nexus
  •     Jira
  •     Gerrit
  •     Sonar
  •     OpenGrok

Test

Vanessa Valderrama
 

Testing list

Re: Removal of FD.io deb_dpdk resources

Edward Warnicke
 

Thank you both for your patience :)

The TSC voted today to archive the deb_dpdk project at FD.io:


Ed

On Thu, Jan 23, 2020 at 11:08 AM Edward Warnicke via Lists.Fd.Io <hagbard=gmail.com@...> wrote:
Luca, Christian,

Just as an update.  We discovered looking at the governance docs that the termination review doc needs to be out for two weeks for community review before we can vote on it.
I anticipate we will on Feb 6.  Thank you for all of your collaboration on this :)

Ed

On Thu, Jan 23, 2020 at 8:34 AM Luca Boccassi <bluca@...> wrote:
Hello Ed,

I'm happy with the document, and I have no preference for archival.

Thank you!

On Wed, 2020-01-22 at 19:42 -0600, Ed Warnicke wrote:
> Luca, Christian,
>
> I have prepared the Termination Review document for consideration at
> tomorrow's TSC meeting:
>
> https://wiki.fd.io/view/Deb_dpdk/Termination_Review
>
> If you could:
>
> a)  Indicate any preference you may have for where it is archived
> b)  Review and indicate here that you are cool with how it is
> presented in that document
>
> it would be most helpful to us :)
>
> Ed
>
>
> On Wed, Jan 15, 2020 at 10:15 AM Edward Warnicke via Lists.Fd.Io <
> hagbard=gmail.com@...> wrote:
> > We'll take it up at the TSC on Thu and get it done.  Thank you for
> > all you've done!
> >
> > Ed
> >
> >
> > On Wed, Jan 15, 2020 at 10:04 AM Luca Boccassi <bluca@...>
> > wrote:
> > > On Fri, 2020-01-10 at 09:18 +0100, Christian Ehrhardt wrote:
> > > >
> > > >
> > > > On Thu, Jan 9, 2020 at 6:20 PM Ed Warnicke (eaw) <eaw@...
> > > >
> > > > wrote:
> > > > > Christian,
> > > > > Thank you for reaching out.  We’ve enjoyed having you as part
> > > of
> > > > > our community, and appreciate the work you all do.
> > > > > Fd.io does not require you to use the Gerri and other
> > > resources we
> > > > > provide.  You are welcome to remain a fd.io project and not
> > > use
> > > > > them if you so choose.
> > > > > You are also welcome to elect to move on from being a
> > > > > fd.io project.  Those decisions are entirely in the hands of
> > > your
> > > > > project committers :)
> > > > >
> > > > >
> > > > > It would be helpful to us to know which of those choices you
> > > elect,
> > > > > so that we may proceed in a clear and orderly way :)
> > > > >
> > > >
> > > > 
> > > > While there is no bad history at all with the deb_dpdk FD.io
> > > project.
> > > > But I'd think that for clarity's sake and cleaning up I'd want
> > > to
> > > > remove the deb_dpdk FD.io project.
> > > >
> > > > @Luca - you are the only other project committers still active,
> > > are
> > > > you of the same opinion?
> > > > If yes, I think Ed can go on and trigger the full removal.
> > >
> > > Hi,
> > >
> > > Yes it's fine for me, having multiple "sources" is confusing for
> > > end
> > > users. Thanks for all the help!
> > >
> > > > > Ed
> > > > >
> > > > > > On Jan 9, 2020, at 9:52 AM, Christian Ehrhardt <
> > > > > > christian.ehrhardt@...> wrote:
> > > > > >
> > > > > > Hi FD.io,
> > > > > > The deb_dpdk project is thankful for the home and help that
> > > we
> > > > > > got in our early years.
> > > > > >
> > > > > > We used to use the project:
> > > > > > - https://wiki.fd.io/view/Deb_dpdk
> > > > > >
> > > > > > And along that resources for
> > > > > > - Gerrit https://gerrit.fd.io/r/gitweb?p=deb_dpdk.git
> > > > > > - I also saw a mirror on https://github.com/FDio/deb_dpdk
> > > > > > - CI
> > > > > >
> > > https://gerrit.fd.io/r/gitweb?p=ci-management.git;a=tree;f=jjb/deb_dpdk;h=efcd3beab9f199566ddd1c6e460600fc1f230d64;hb=HEAD
> > > > > >
> > > > > > But we have to admit that times have changed and these days
> > > we
> > > > > > are really at home at
> > > > > > - https://salsa.debian.org/debian/dpdk
> > > > > > - https://launchpad.net/ubuntu/+source/dpdk
> > > > > >
> > > > > > Therefore I wanted to let you know that you could free up
> > > the
> > > > > > resources.
> > > > > >
> > > > > > We can even discontinue the subproject itself if you let me
> > > know
> > > > > > which process I need to trigger - as an alternative I could
> > > also
> > > > > > just update the deb_dpdk wiki page to point to the new
> > > places.
> > > > > >
> > > > > > Keeping the git/gerrit is probably cheap and worth for
> > > history if
> > > > > > you like, but that is entirely up to you.
> > > > > >
> > > > > > --
> > > > > > Christian Ehrhardt
> > > > > > Staff Engineer, Ubuntu Server
> > > > > > Canonical Ltd
> > > >
> > > >
> > > >
>
>
--
Kind regards,
Luca Boccassi

Re: FDIO Maintenance - 2020-02-20 1900 UTC to 2400 UTC

Vanessa Valderrama
 

Reminder: Jenkins will be placed in shutdown mode at 1800 UTC

On 2/19/20 9:44 AM, Vanessa Valderrama wrote:
What: Standard updates and upgrade
  • Jenkins
    • OS and security updates
    • Upgrade
    • Plugin updates
  • Nexus
    • OS updates
  • Jira
    • OS updates
  • Gerrit
    • OS updates
  • Sonar
    • OS updates
  • OpenGrok
    • OS updates
When:  2020-02-20 1900 UTC to 2400 UTC

Impact:

Maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1800 UTC. Please let us know if specific jobs cannot be aborted.
The following systems will be unavailable during the maintenance window:
  •     Jenkins sandbox
  •     Jenkins production
  •     Nexus
  •     Jira
  •     Gerrit
  •     Sonar
  •     OpenGrok

2020 LFN Governing Board Committer Representative Self-Nomination Period Open

Edward Warnicke
 



---------- Forwarded message ---------
From: Casey Cain <ccain@...>
Date: Wed, Feb 19, 2020 at 7:31 PM
Subject: 2020 LFN Governing Board Committer Representative Self-Nomination Period Open
To:


 Hello, everyone.

This is to inform you that the self-nomination period for the LFN Governing Board Committer Representative (LGBMCR) has started.  If you have received this email, you have been identified as an eligible candidate. 
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.

If you are interested in becoming the technical representative to the Governing Body, please self-nominate at the link below by March 4th, 2020.

Voting will begin on March 5th, 2020 and close by March 19th, 2020 at 5pm Pacific Time.

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
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC - CaseyLF
WeChat - okaru6

REMINDER: ONES LFN/LFE Booth Demo Ideas Due Feb 26

Brandon Wick
 

LFN Community:

We hope that you are planning to attend the Open Networking & Edge Summit North America, April 20-21, in Los Angeles, California. Those in attendance at the last four ONS events will recall that we hosted an LF Networking Booth that showcased many community-driven demos from the LFN technical project communities. Our goal is to showcase compelling uses of LFN Networking & LF Edge project technology to solve real world industry challenges. See this blog post from ONS Europe last fall to get a sense for what types of demos have been shown in the LF Networking Booth.

In 2020, the Open Networking & Edge Summit is expanding to comprehensively cover Edge Computing, Edge Cloud, and IoT. Accordingly, the community demo zone is expanding to consider demo proposals from the LF Edge project community as well. Another change for this year is that demo managers and co-presenters need to be from LF Networking or LF Edge member companies. Submissions that include vendor companies also require that the vendors be sponsors of the Open Networking & Edge Summit event. Note: There are many event sponsorship options available at all price levels including a sponsorship option for the LFN/LFE Pavilion demos specifically. Please see the event prospectus to review the options and let me know if you have any questions.

The call for demo ideas for the Open Networking & Edge Summit North America is now open. 

Demos to be shown in the LFN/LFE booth will be chosen by LFN & LF Edge Project leadership using the following criteria:
  • Demos must include technology from at least one of the LF Networking or LF Edge projects (e.g. ONAP, OPNFV, Akraino, EdgeX Foundry)
    • Special consideration will be given to submissions that:
    • Showcase cross-project collaboration and integration
    • Map to a specific industry use case
    • Include participation and endorsement from a service provider organization
    • Show project diversity (e.g. projects not covered in other submissions)
The final number of demo stations is still TBD. Demos stations will again have a backdrop, signage, counter/table, chair(s) monitor, power, and Wi-Fi internet. Note: Apart from the event sponsorship requirement, there is no cost to host a standard demo in the LFN booth although additional power, internet, space, etc. may incur a cost.

Here are the key dates to keep in mind:
  • Feb 5: Demo idea solicitation email sent to community lists
  • Feb 26: Demo ideas submissions due
  • March 4: Demos ideas reviewed, chosen, and notifications sent
  • April 21-22: Demos shown at ONES North America
Demo manager responsibilities include:
  • Creating the demo concept and actual demo to be shown
  • Responding promptly to requests for information
  • Meeting all demo preparation deadlines
  • Setting up and testing the demo pre-show and taking down post-show
  • Staffing the demo during ONS expo hours (along with other designated team members to help share the load)
  • Being willing to participate in media activities, e.g. photos, videos
To submit your demo idea for consideration, please collect and provide the following information:
  • Demo title (10 words max)
  • Brief demo description (200 words max)
  • List of demo manager(s) with contact information 
  • List of open source projects involved
  • List of companies involved
  • Any extra requirements or special considerations
Submit your demo ideas by Feb 26th by filling in the Google Form here: https://docs.google.com/forms/d/e/1FAIpQLSfwjEfCcWUKMfiK404Uu51Zl70-8lqcRFCKKQ5vW3eeLOGAfw/viewform. If you cannot access the form, email bwick@... and I will send you the form over email.

Please let me know if you have any questions and we look forward to seeing your submissions!

Best, 

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960

PTO tomorrow

Ray Kinsella
 

Hi folks,

 

I am on PTO tomorrow.

Keith Wiles will be covering in my absence.

 

Thanks,

 

Ray K

 

Project Review

Vanessa Valderrama
 

I'd like to propose the TSC review these inactive projects to determine if they can be archived.

Projects that have been inactive for 18 months or longer

  • Project: ONE
    • Last commit: Tue Oct 31 15:49:06 2017 +0000
  • 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: 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: RPM_DPDK
    • Last commit: Thu Jul 5 13:14:14 2018 -0400
    • Comment: The project is not active. PTL recommends project termination
Projects that were never active (empty repositories)
  • Project: ODP4VPP
    • Initial commit: Tue Jan 31 20:11:51 2017 +0000
  • Project: P4VPP
    • Initial commit: Fri Aug 25 17:17:23 2017 +0000
Thank you,
Vanessa

FDIO Maintenance - 2020-02-20 1900 UTC to 2400 UTC

Vanessa Valderrama
 

What: Standard updates and upgrade
  • Jenkins
    • OS and security updates
    • Upgrade
    • Plugin updates
  • Nexus
    • OS updates
  • Jira
    • OS updates
  • Gerrit
    • OS updates
  • Sonar
    • OS updates
  • OpenGrok
    • OS updates
When:  2020-02-20 1900 UTC to 2400 UTC

Impact:

Maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1800 UTC. Please let us know if specific jobs cannot be aborted.
The following systems will be unavailable during the maintenance window:
  •     Jenkins sandbox
  •     Jenkins production
  •     Nexus
  •     Jira
  •     Gerrit
  •     Sonar
  •     OpenGrok

Re: FDIO Maintenance - 2020-02-20 1900 UTC to 2400 UTC

Vanessa Valderrama
 

Maintenance Reminder

On 2/12/20 10:01 AM, Vanessa Valderrama wrote:
Maintaince has been moved to February 20th

What: Standard updates and upgrade
  • Jenkins
    • OS and security updates
    • Upgrade to 2.204.1
    • Plugin updates
  • Nexus
    • OS updates
  • Jira
    • OS updates
  • Gerrit
    • OS updates
  • Sonar
    • OS updates
  • OpenGrok
    • OS updates
When:  2020-02-25 1900 UTC to 2400 UTC

Impact:

Maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1800 UTC. Please let us know if specific jobs cannot be aborted.
The following systems will be unavailable during the maintenance window:
  •     Jenkins sandbox
  •     Jenkins production
  •     Nexus
  •     Jira
  •     Gerrit
  •     Sonar
  •     OpenGrok


On 1/7/20 8:30 AM, Vanessa Valderrama wrote:
Please let us know as soon as possible if this maintenance conflicts with your project.

What:
  • Jenkins
    • OS and security updates
    • Upgrade to 2.204.1
    • Plugin updates
  • Nexus
    • OS updates
  • Jira
    • OS updates
  • Gerrit
    • OS updates
  • Sonar
    • OS updates
  • OpenGrok
    • OS updates
When:  2020-02-05 1900 UTC to 2400 UTC

Impact:

Maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1800 UTC. Please let us know if specific jobs cannot be aborted.
The following systems will be unavailable during the maintenance window:
  •     Jenkins sandbox
  •     Jenkins production
  •     Nexus
  •     Jira
  •     Gerrit
  •     Sonar
  •     OpenGrok

Published: FD.io CSIT-2001 Release Report

Maciek Konstantynowicz (mkonstan)
 

Hi All,

FD.io CSIT-2001 report has been published on FD.io docs site:

https://docs.fd.io/csit/rls2001/report/

Many thanks to All in CSIT, VPP and wider FD.io community who
contributed and worked hard to make CSIT-2001 happen!

Below three summaries:
- Intel Xeon 2n-skx, 3n-skx and 2n-clx Testbeds microcode issue.
- CSIT-2001 Release Summary, a high-level summary.
- Points of Note in CSIT-2001 Report, with specific links to report.

Welcome all comments, best by email to csit-dev@....

Cheers,
-Maciek

------------------------------------------------------------------------
NOTE: Intel Xeon 2n-skx, 3n-skx and 2n-clx Testbeds microcode issue.
------------------------------------------------------------------------
VPP and DPDK performance test data is not included in this report
version. This is due to the lower performance and behaviour
inconsistency of these systems following the upgrade of processor
microcode packages (skx ucode 0x2000064, clx ucode 0x500002c), done
as part of updating Ubuntu 18.04 LTS kernel version. Tested VPP and
DPDK applications (L3fwd) are affected. Skx and Clx test data will
be added in subsequent maintenance report version(s) once the issue
is resolved. See https://jira.fd.io/browse/CSIT-1675.

------------------------------------------------------------------------
CSIT-2001 Release Summary
------------------------------------------------------------------------
1. CSIT-2001 Report

- html link: https://docs.fd.io/csit/rls2001/report/
- pdf link: https://docs.fd.io/csit/rls2001/report/_static/archive/csit_rls2001.pdf

2. New Tests

- NFV density tests with IPsec encryption between DUTs.

- Full test coverage for VPP AVF driver for Fortville NICs.

- VPP Hoststack TCP/IP tests with wrk, iperf3 with LDPreload tests
without and with packet loss via VPP NSIM plugin), and QUIC/UDP/IP
transport tests.

- Mellanox ConnectX5-2p100GE NICs in 2n-clx testbeds using VPP native
rdma driver.

- Load Balancer tests.

3. Benchmarking

- Fully onboarded new Intel Xeon Cascadelake Testbeds with x710,
xxv710 and mcx556a-edat NIC cards.

- Added new High Dynamic Range Histogram latency measurements.

4. Infrastructure

- Full migration of CSIT from Python2.7 to Python3.6.

------------------------------------------------------------------------
Points of Note in the CSIT-2001 Report
------------------------------------------------------------------------
Indexed specific links listed at the bottom.

1. VPP release notes
a. Changes in CSIT-2001: [1]
b. Known issues: [2]

2. VPP performance - 64B/IMIX throughput graphs (selected NIC models):
a. Graphs explained: [3]
b. L2 Ethernet Switching: [4]
c. IPv4 Routing: [5]
d. IPv6 Routing: [6]
e. SRv6 Routing: [7]
f. IPv4 Tunnels: [8]
g. KVM VMs vhost-user: [9]
h. LXC/DRC Container Memif: [10]
e. IPsec IPv4 Routing: [11]
f. Virtual Topology System: [12]

3. VPP performance - multi-core and latency graphs:
a. Speedup Multi-Core: [13]
b. Latency: [14]

4. VPP performance comparisons
a. VPP-20.01 vs. VPP-19.08: [15]

5. VPP performance test details - all NICs:
a. Detailed results 64B IMIX 1518B 9kB: [16]
b. Configuration: [17]

DPDK Testpmd and L3fwd performance sections follow similar structure.

6. DPDK applications:
a. Release notes: [18]
b. DPDK performance - 64B throughput graphs: [19]
c. DPDK performance - latency graphs: [20]
d. DPDK performance - DPDK-19.08 vs. DPDK-19.05: [21]

Functional tests, including VPP_Device (functional device tests),
VPP_VIRL and HoneyComb are all included in the report.

Specific links within the report:

[1] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/csit_release_notes.html#changes-in-csit-release
[2] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/csit_release_notes.html#known-issues
[3] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/index.html
[4] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/l2.html
[5] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/ip4.html
[6] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/ip6.html
[7] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/srv6.html
[8] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/ip4_tunnels.html
[9] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/vm_vhost.html
[10] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/container_memif.html
[11] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/ipsec.html
[12] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_throughput_graphs/vts.html
[13] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/throughput_speedup_multi_core/index.html
[14] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/packet_latency/index.html
[15] https://docs.fd.io/csit/rls2001/report/vpp_performance_tests/comparisons/current_vs_previous_release.html
[16] https://docs.fd.io/csit/rls2001/report/detailed_test_results/vpp_performance_results/index.html
[17] https://docs.fd.io/csit/rls2001/report/test_configuration/vpp_performance_configuration/index.html
[18] https://docs.fd.io/csit/rls2001/report/dpdk_performance_tests/csit_release_notes.html
[19] https://docs.fd.io/csit/rls2001/report/dpdk_performance_tests/packet_throughput_graphs/index.html
[20] https://docs.fd.io/csit/rls2001/report/dpdk_performance_tests/packet_latency/index.html
[21] https://docs.fd.io/csit/rls2001/report/dpdk_performance_tests/comparisons/current_vs_previous_release.html
------------------------------------------------------------------------

REMINDER: Seeking LF Networking & LF Edge Booth Demo Ideas for ONES

Brandon Wick
 

LFN Community:

We hope that you are planning to attend the Open Networking & Edge Summit North America, April 20-21, in Los Angeles, California. Those in attendance at the last four ONS events will recall that we hosted an LF Networking Booth that showcased many community-driven demos from the LFN technical project communities. Our goal is to showcase compelling uses of LFN Networking & LF Edge project technology to solve real world industry challenges. See this blog post from ONS Europe last fall to get a sense for what types of demos have been shown in the LF Networking Booth.

In 2020, the Open Networking & Edge Summit is expanding to comprehensively cover Edge Computing, Edge Cloud, and IoT. Accordingly, the community demo zone is expanding to consider demo proposals from the LF Edge project community as well. Another change for this year is that demo managers and co-presenters need to be from LF Networking or LF Edge member companies. Submissions that include vendor companies also require that the vendors be sponsors of the Open Networking & Edge Summit event. Note: There are many event sponsorship options available at all price levels including a sponsorship option for the LFN/LFE Pavilion demos specifically. Please see the event prospectus to review the options and let me know if you have any questions.

The call for demo ideas for the Open Networking & Edge Summit North America is now open. 

Demos to be shown in the LFN/LFE booth will be chosen by LFN & LF Edge Project leadership using the following criteria:
  • Demos must include technology from at least one of the LF Networking or LF Edge projects (e.g. ONAP, OPNFV, Akraino, EdgeX Foundry)
    • Special consideration will be given to submissions that:
    • Showcase cross-project collaboration and integration
    • Map to a specific industry use case
    • Include participation and endorsement from a service provider organization
    • Show project diversity (e.g. projects not covered in other submissions)
The final number of demo stations is still TBD. Demos stations will again have a backdrop, signage, counter/table, chair(s) monitor, power, and Wi-Fi internet. Note: Apart from the event sponsorship requirement, there is no cost to host a standard demo in the LFN booth although additional power, internet, space, etc. may incur a cost.

Here are the key dates to keep in mind:
  • Feb 5: Demo idea solicitation email sent to community lists
  • Feb 26: Demo ideas submissions due
  • March 4: Demos ideas reviewed, chosen, and notifications sent
  • April 21-22: Demos shown at ONES North America
Demo manager responsibilities include:
  • Creating the demo concept and actual demo to be shown
  • Responding promptly to requests for information
  • Meeting all demo preparation deadlines
  • Setting up and testing the demo pre-show and taking down post-show
  • Staffing the demo during ONS expo hours (along with other designated team members to help share the load)
  • Being willing to participate in media activities, e.g. photos, videos
To submit your demo idea for consideration, please collect and provide the following information:
  • Demo title (10 words max)
  • Brief demo description (200 words max)
  • List of demo manager(s) with contact information 
  • List of open source projects involved
  • List of companies involved
  • Any extra requirements or special considerations
Submit your demo ideas by Feb 26th by filling in the Google Form here: https://docs.google.com/forms/d/e/1FAIpQLSfwjEfCcWUKMfiK404Uu51Zl70-8lqcRFCKKQ5vW3eeLOGAfw/viewform. If you cannot access the form, email bwick@... and I will send you the form over email.

Please let me know if you have any questions and we look forward to seeing your submissions!

Best, 

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960

FDIO Maintenance - 2020-02-20 1900 UTC to 2400 UTC

Vanessa Valderrama
 

Maintaince has been moved to February 20th


What: Standard updates and upgrade
  • Jenkins
    • OS and security updates
    • Upgrade to 2.204.1
    • Plugin updates
  • Nexus
    • OS updates
  • Jira
    • OS updates
  • Gerrit
    • OS updates
  • Sonar
    • OS updates
  • OpenGrok
    • OS updates
When:  2020-02-25 1900 UTC to 2400 UTC

Impact:

Maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1800 UTC. Please let us know if specific jobs cannot be aborted.
The following systems will be unavailable during the maintenance window:
  •     Jenkins sandbox
  •     Jenkins production
  •     Nexus
  •     Jira
  •     Gerrit
  •     Sonar
  •     OpenGrok


On 1/7/20 8:30 AM, Vanessa Valderrama wrote:
Please let us know as soon as possible if this maintenance conflicts with your project.

What:
  • Jenkins
    • OS and security updates
    • Upgrade to 2.204.1
    • Plugin updates
  • Nexus
    • OS updates
  • Jira
    • OS updates
  • Gerrit
    • OS updates
  • Sonar
    • OS updates
  • OpenGrok
    • OS updates
When:  2020-02-05 1900 UTC to 2400 UTC

Impact:

Maintenance will require a reboot of each FD.io system. Jenkins will be placed in shutdown mode at 1800 UTC. Please let us know if specific jobs cannot be aborted.
The following systems will be unavailable during the maintenance window:
  •     Jenkins sandbox
  •     Jenkins production
  •     Nexus
  •     Jira
  •     Gerrit
  •     Sonar
  •     OpenGrok

Re: Tomorrow's TSC

Edward Warnicke
 

Excellent, please feel free to update the agenda :)

Ed

On Wed, Feb 12, 2020 at 8:38 AM Ray Kinsella <ray.kinsella@...> wrote:

Ed & Team,

 

Some additional agenda items for tomorrow.

 

  1. Close out on the Scapy related IP concerns (Maciek & Ray).
  2. Discuss provisioning of a static analysis tool (Dave B & Ray).
  3. Co-locating FD.io event at DPDK Userspace (Trishan & Ray).

 

Thanks,

 

Ray K

 


on flight tomorrow, cannot join TSC

George Zhao
 

Hi,

I will be on flight tomorrow and I cannot join the TSC call. I will see if I can get a proxy for me.

Thanks,

George

Tomorrow's TSC

Ray Kinsella
 

Ed & Team,

 

Some additional agenda items for tomorrow.

 

  1. Close out on the Scapy related IP concerns (Maciek & Ray).
  2. Discuss provisioning of a static analysis tool (Dave B & Ray).
  3. Co-locating FD.io event at DPDK Userspace (Trishan & Ray).

 

Thanks,

 

Ray K

 

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

Andrew 👽 Yourtchenko <ayourtch@...>
 

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

Agenda Items For Next Week

Vanessa Valderrama
 

I'd like to add some items to the TSC agenda next week.

  • More detailed review of the infrastructure support documentation
  • Discuss 2020 plans for Nexus
    • Logs moving to S3
    • How do we plan to use Nexus in the future
  • Discuss 2020 plans for CI
    • Jenkins?
Thank you,
Vanessa

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

Luca Muscariello
 

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