1. tsc@lists.fd.io
  2. Messages
   Date   
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.

https://packagecloud.io/app/fdio/release/

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.

https://packagecloud.io/app/fdio/release/

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
Re: fdio/release repository on packagecloud now contains 19900 with some odd artifacts

Luca Muscariello
 

FYI

we have reduced the number of artifacts to 3200.

https://packagecloud.io/app/fdio/release/

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
Re: [cicn-dev] nomination committer ci-management

Mauro Sardara (msardara) <msardara@...>
 

Hello Vanessa,

Yes we talked about this and I am available to become a committer of the ci-management project.

Regards,
Mauro.

From: cicn-dev@... <cicn-dev@...> on behalf of Luca Muscariello <muscariello@...>
Sent: Thursday, January 30, 2020, 8:40 PM
To: Vanessa Valderrama; Mauro Sardara (msardara)
Cc: ci-management-dev@...; hicn-dev@...; cicn-dev@...; tsc@...
Subject: Re: [cicn-dev] nomination committer ci-management

+ Mauro

yes of course, Mauro would be happy to become a committer in ci-management.

Thanks
Luca

On Thu, Jan 30, 2020 at 8:37 PM Vanessa Valderrama <vvalderrama@...> wrote:

Luca,

Have you discussed this Mauro and verified he is interested in becoming a committer?

Thank you,
Vanessa


On 1/30/20 1:25 PM, Luca Muscariello wrote:
Hi 

Mauro Sardara is a committer in cicn and hicn projects
and has contributed quite a bit in ci-management.

Below his contribution to ci-management,

https://gerrit.fd.io/r/q/project:ci-management+owner:msardara%2540cisco.com

In hicn it would be helpful to have a ci-management committer
to take care of our release management.

Thanks
Best
Luca
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
Re: [ci-management-dev] Committer Nomination: Dave Wallace

Edward Warnicke
 

Delighted to, will put it on tomorrows agenda :)

Ed

On Wed, Feb 5, 2020 at 6:10 AM Vanessa Valderrama <vvalderrama@...> wrote:

The ci-management committers have voted to approve Dave Wallace as a committer. Can we add this to the TSC agenda for tomorrow please?

Thank you,
Vanessa

-------- Forwarded Message --------
Subject: Re: [ci-management-dev] Committer Nomination: Dave Wallace
Date: Thu, 30 Jan 2020 14:14:48 -0800
From: Andrew Grimberg <agrimberg@...>
Organisation: The Linux Foundation
To: Vanessa Valderrama <vvalderrama@...>, ci-management-dev@... <ci-management-dev@...>


+1

On 2020-01-30 08:58, Vanessa Valderrama wrote:
Due to the confusion around the nomination and vote for Dave previously,
we are restarting the nomination and vote process. I'd like to nominate
Dave Wallace as a committer for ci-managment.

Dave's commit history: 
https://gerrit.fd.io/r/q/project:ci-management+is:merged+owner:dwallacelf%2540gmail.co

I spoke with Dave and verified he would like to become a ci-management
committer. Dave is active in CSIT and VPP projects. His role as a
committer will definitely benefit CSIT, VPP and ci-management.

Thank you,
Vanessa







-- 
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation

[ci-management-dev] Committer Nomination: Dave Wallace

Vanessa Valderrama
 

The ci-management committers have voted to approve Dave Wallace as a committer. Can we add this to the TSC agenda for tomorrow please?

Thank you,
Vanessa

-------- Forwarded Message --------
Subject: Re: [ci-management-dev] Committer Nomination: Dave Wallace
Date: Thu, 30 Jan 2020 14:14:48 -0800
From: Andrew Grimberg <agrimberg@...>
Organisation: The Linux Foundation
To: Vanessa Valderrama <vvalderrama@...>, ci-management-dev@... <ci-management-dev@...>


+1

On 2020-01-30 08:58, Vanessa Valderrama wrote:
Due to the confusion around the nomination and vote for Dave previously,
we are restarting the nomination and vote process. I'd like to nominate
Dave Wallace as a committer for ci-managment.

Dave's commit history: 
https://gerrit.fd.io/r/q/project:ci-management+is:merged+owner:dwallacelf%2540gmail.co

I spoke with Dave and verified he would like to become a ci-management
committer. Dave is active in CSIT and VPP projects. His role as a
committer will definitely benefit CSIT, VPP and ci-management.

Thank you,
Vanessa







-- 
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation

Re: nomination committer ci-management

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

> Alberto takes care of the release update, so in that case it would be

> his responsibility to take care of ci-management as well.

> Mauro would take care of reviewing

 

Alright then.

 

@Vanessa Valderrama Is this thread also for committer votes?

If yes: +1.

 

Vratko.

 

From: Luca Muscariello <muscariello@...>
Sent: Friday, January 31, 2020 1:37 PM
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>
Cc: Vanessa Valderrama <vvalderrama@...>; Mauro Sardara (msardara) <msardara@...>; ci-management-dev@...; hicn-dev@...; cicn-dev@...; tsc@...
Subject: Re: [tsc] nomination committer ci-management

 

 

 

On Fri, Jan 31, 2020 at 12:46 PM Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...> wrote:

> In hicn it would be helpful to have a ci-management committer

> to take care of our release management.

 

In ci-management, Gerrit does not allow an owner of a contribution

to vote +2 on it, even if the owner is a committer.

That means making Mauro a committer will not help Cicn nor Hicn directly,

unless somebody else starts contributing the needed changes.

 

Alberto takes care of the release update, so in that case it would be

his responsibility to take care of ci-management as well.

 

Mauro would take care of reviewing ci-management for what concerns these release

phases jointly with Alberto and myself.

In any case Mauro would continue to contribute to ci-management as usual.

 

In the past we have had problems for patches on ci-management pending for too long.

We are a small team and most of the time others do not pay attention to our own

patches. Any dependency with people that are not directly committed to our projects

means disruption and broken distributions to our user-base. It happened more than once.

 

This is why we'd need one team member to pay attention to our own patches in 

ci-management too, in due time, especially during new release phases.

 

 

 

Overall, ci-management could use more active committers,

I am just making sure the limits of their power are understood.

 

> https://gerrit.fd.io/r/q/project:ci-management+owner:msardara%2540cisco.com

 

The above link is something Vanessa has asked me to send because TSC requires 

to see measurable contributions for a committer to be nominated candidate

in a given project.

But the link you've shared gives additional arguments, thanks.

 

 

 

In other words, that link does not give you

the list of changes that could have gotten merged sooner

if Mauro were a committer.

This [1] link does.

 

Vratko.

 

[1] https://gerrit.fd.io/r/q/project:ci-management+(reviewedby:msardara%2540cisco.com+OR+reviewer:msardara%2540cisco.com)+-owner:msardara%2540cisco.com

 

 

From: tsc@... <tsc@...> On Behalf Of Luca Muscariello
Sent: Thursday, January 30, 2020 8:41 PM
To: Vanessa Valderrama <vvalderrama@...>; Mauro Sardara (msardara) <msardara@...>
Cc: ci-management-dev@...; hicn-dev@...; cicn-dev@...; tsc@...
Subject: Re: [tsc] nomination committer ci-management

 

+ Mauro

 

yes of course, Mauro would be happy to become a committer in ci-management.

 

Thanks

Luca

 

On Thu, Jan 30, 2020 at 8:37 PM Vanessa Valderrama <vvalderrama@...> wrote:

Luca,

Have you discussed this Mauro and verified he is interested in becoming a committer?

Thank you,
Vanessa

 

On 1/30/20 1:25 PM, Luca Muscariello wrote:

Hi 

 

Mauro Sardara is a committer in cicn and hicn projects

and has contributed quite a bit in ci-management.

 

Below his contribution to ci-management,

 

 

In hicn it would be helpful to have a ci-management committer

to take care of our release management.

 

Thanks

Best

Luca

 
RPM_DPDK Questions

Vanessa Valderrama
 




-------- 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
NSH_SFC Question

Vanessa Valderrama
 




-------- Forwarded Message --------
Subject: RE: NSH_SFC Question
Date: Fri, 31 Jan 2020 08:42:18 +0000
From: Ni, Hongjun <hongjun.ni@...>
To: Vanessa Valderrama <vvalderrama@...>


Hi Vanessa,

All the code in NSH_SFC has been merged into VPP master branch.
NSH_SFC project is not active now.

Thanks,
Hongjun

-----Original Message-----
From: Vanessa Valderrama <vvalderrama@...> Sent: Friday, January 31, 2020 2:36 AM
To: Ni, Hongjun <hongjun.ni@...>
Subject: NSH_SFC Question

Is NSH_SFC still an active project?

Thank you,
Vanessa
Re: nomination committer ci-management

Luca Muscariello
 



On Fri, Jan 31, 2020 at 12:46 PM Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...> wrote:

> In hicn it would be helpful to have a ci-management committer

> to take care of our release management.

 

In ci-management, Gerrit does not allow an owner of a contribution

to vote +2 on it, even if the owner is a committer.

That means making Mauro a committer will not help Cicn nor Hicn directly,

unless somebody else starts contributing the needed changes.


Alberto takes care of the release update, so in that case it would be
his responsibility to take care of ci-management as well.

Mauro would take care of reviewing ci-management for what concerns these release
phases jointly with Alberto and myself.
In any case Mauro would continue to contribute to ci-management as usual.

In the past we have had problems for patches on ci-management pending for too long.
We are a small team and most of the time others do not pay attention to our own
patches. Any dependency with people that are not directly committed to our projects
means disruption and broken distributions to our user-base. It happened more than once.

This is why we'd need one team member to pay attention to our own patches in 
ci-management too, in due time, especially during new release phases.

 

 

Overall, ci-management could use more active committers,

I am just making sure the limits of their power are understood.

 

> https://gerrit.fd.io/r/q/project:ci-management+owner:msardara%2540cisco.com


The above link is something Vanessa has asked me to send because TSC requires 
to see measurable contributions for a committer to be nominated candidate
in a given project.
But the link you've shared gives additional arguments, thanks.

 

 

In other words, that link does not give you

the list of changes that could have gotten merged sooner

if Mauro were a committer.

This [1] link does.

 

Vratko.

 

[1] https://gerrit.fd.io/r/q/project:ci-management+(reviewedby:msardara%2540cisco.com+OR+reviewer:msardara%2540cisco.com)+-owner:msardara%2540cisco.com

 

 

From: tsc@... <tsc@...> On Behalf Of Luca Muscariello
Sent: Thursday, January 30, 2020 8:41 PM
To: Vanessa Valderrama <vvalderrama@...>; Mauro Sardara (msardara) <msardara@...>
Cc: ci-management-dev@...; hicn-dev@...; cicn-dev@...; tsc@...
Subject: Re: [tsc] nomination committer ci-management

 

+ Mauro

 

yes of course, Mauro would be happy to become a committer in ci-management.

 

Thanks

Luca

 

On Thu, Jan 30, 2020 at 8:37 PM Vanessa Valderrama <vvalderrama@...> wrote:

Luca,

Have you discussed this Mauro and verified he is interested in becoming a committer?

Thank you,
Vanessa

 

On 1/30/20 1:25 PM, Luca Muscariello wrote:

Hi 

 

Mauro Sardara is a committer in cicn and hicn projects

and has contributed quite a bit in ci-management.

 

Below his contribution to ci-management,

 

 

In hicn it would be helpful to have a ci-management committer

to take care of our release management.

 

Thanks

Best

Luca

 
Re: nomination committer ci-management

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

> In hicn it would be helpful to have a ci-management committer

> to take care of our release management.

 

In ci-management, Gerrit does not allow an owner of a contribution

to vote +2 on it, even if the owner is a committer.

That means making Mauro a committer will not help Cicn nor Hicn directly,

unless somebody else starts contributing the needed changes.

 

Overall, ci-management could use more active committers,

I am just making sure the limits of their power are understood.

 

> https://gerrit.fd.io/r/q/project:ci-management+owner:msardara%2540cisco.com

 

In other words, that link does not give you

the list of changes that could have gotten merged sooner

if Mauro were a committer.

This [1] link does.

 

Vratko.

 

[1] https://gerrit.fd.io/r/q/project:ci-management+(reviewedby:msardara%2540cisco.com+OR+reviewer:msardara%2540cisco.com)+-owner:msardara%2540cisco.com

 

 

From: tsc@... <tsc@...> On Behalf Of Luca Muscariello
Sent: Thursday, January 30, 2020 8:41 PM
To: Vanessa Valderrama <vvalderrama@...>; Mauro Sardara (msardara) <msardara@...>
Cc: ci-management-dev@...; hicn-dev@...; cicn-dev@...; tsc@...
Subject: Re: [tsc] nomination committer ci-management

 

+ Mauro

 

yes of course, Mauro would be happy to become a committer in ci-management.

 

Thanks

Luca

 

On Thu, Jan 30, 2020 at 8:37 PM Vanessa Valderrama <vvalderrama@...> wrote:

Luca,

Have you discussed this Mauro and verified he is interested in becoming a committer?

Thank you,
Vanessa

 

On 1/30/20 1:25 PM, Luca Muscariello wrote:

Hi 

 

Mauro Sardara is a committer in cicn and hicn projects

and has contributed quite a bit in ci-management.

 

Below his contribution to ci-management,

 

 

In hicn it would be helpful to have a ci-management committer

to take care of our release management.

 

Thanks

Best

Luca

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

Luca Muscariello
 

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
LAST REMINDER: ONES NA CFP Closes Feb 3

Brandon Wick
 

LF Networking Community:

The Open Networking & Edge Summit (ONES) enables collaborative development and innovation across enterprises, service providers/telcos and cloud providers to shape the future of networking and edge computing.

ONES, will be held in North America April 20-21 in Los Angeles, CA. ONES is the premier event for:
  • Open collaborative community innovation & development across enterprises, service providers/telcos and cloud providers
  • Deep focused Technical, Architectural and Business Discussions in the area of Open Networking (NFVI/SDN/NFV/VNF – enabling automated 5G deployments, Cloud Native Telecom including Kubernetes Networking and Cloud Native Network Functions) & AI/ML enabled use cases for 5G, IoT, Edge and Enterprise deployments
  • Targeted Discussions on Edge/IoT Frameworks and Blueprints across Manufacturing, Retail, Oil and Gas, Transportation, Telco Edge cloud among others key areas
This is the flagship event for LF Networking & LF Edge and all project community members are strongly encouraged to participate. The CFP is now open and we welcome submissions from the LFN & LFE project communities. Proposals for ONES North America are due by 11:59pm PT on Monday, February 3. Learn more and submit here.

Registration is also open. Please register early to take advantage of early bird pricing. LF Members are entitled to a 20% discount off the registration price. Register here.

Please send any questions you may have to events@.... 

Note: Open Networking & Edge Summit Europe will take place Sept 29-30, in Antwerp. Registration and the CFP are also open. Learn more. 

Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960
Re: nomination committer ci-management

Luca Muscariello
 

+ Mauro

yes of course, Mauro would be happy to become a committer in ci-management.

Thanks
Luca

On Thu, Jan 30, 2020 at 8:37 PM Vanessa Valderrama <vvalderrama@...> wrote:

Luca,

Have you discussed this Mauro and verified he is interested in becoming a committer?

Thank you,
Vanessa


On 1/30/20 1:25 PM, Luca Muscariello wrote:
Hi 

Mauro Sardara is a committer in cicn and hicn projects
and has contributed quite a bit in ci-management.

Below his contribution to ci-management,

https://gerrit.fd.io/r/q/project:ci-management+owner:msardara%2540cisco.com

In hicn it would be helpful to have a ci-management committer
to take care of our release management.

Thanks
Best
Luca
481 - 500 of 1707