Date   

job reconfigurations

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

I spent some time investigating the current behavior.

I do not claim to understand it fully,

but I have formed an opinion.

I am sharing it here, so similarly curious minds

(e.g. me in a year, after forgetting half of this)

do not have to investigate again.

 

Some years ago, the job [0] that edits job configurations

upon merge into ci-management repository was acting smart.

It detected which jobs should have a different configuration,

and updated only those, skipping over the rest.

Nowadays, it "reconfigures" all the jobs, no matter what.

 

Furthermore, job configuration history shows many changes (example: [1]),

although most of them look like this: [2].

The Older Change shows the state after the jjb merge job,

the Newer Change shows the state after the reconfigured job was run

(that is why less active jobs show less frequent configuration changes).

On Sandbox, the Newer Change edits are also applied

when configuring the job manually (via webUI).

 

My opinion: Newer Jenkins version are postponing their edits

(such as adding plugin versions) to avoid lagging

when many jobs are configured (or when plugins are upgraded).

Jenkins Job Builder either does not have enough visibility

into the intended edits, or it does not care (to save CPU cycles).

Also, Jenkins has troubles keeping XML formatting consistent for some time [4].

Config history plugin already hides some edits,

so maybe later versions can hide some of the noise.

In [2] there is already button Hide Version Changes,

although it does not do anything for me.

 

Overall, it seems the lazy behaviors (of both Jenkins and JJB)

seem to work fine together, the typical merge run spends [3]

only 30 seconds (out of its almost 3 minutes of runtime)

reconfiguring 434 jobs and 8 views.

Noisy history and unability to tell which jobs were "really"

reconfigured are the only downsides.

 

Vratko.

[0] https://jenkins.fd.io/view/ci-management/job/ci-management-jjb-merge/

[1] https://jenkins.fd.io/view/ci-management/job/ci-management-jjb-verify/jobConfigHistory/
[2] https://jenkins.fd.io/view/ci-management/job/ci-management-jjb-verify/jobConfigHistory/showDiffFiles?timestamp1=2021-08-26_08-32-22&timestamp2=2021-08-26_08-48-07
[3] https://logs.fd.io/production/vex-yul-rot-jenkins-1/ci-management-jjb-merge/795/console-timestamp.log.gz
[4] https://issues.jenkins.io/browse/JENKINS-41177


Re: Committer Nomination: Peter Mikus

Dave Wallace
 

I will add it to next week's TSC agenda and make sure it gets voted on.

Thanks,
-daw-

On 7/16/21 11:23 AM, Andrew Grimberg wrote:
Yes, and Ed Warnicke voted as well so we're unanimous. Just needs to be
brought to the TSC for ratification. Since I don't generally attend
those, would someone like to do it for me?

-Andy-

On 7/16/21 8:08 AM, Dave Wallace wrote:
I merged 33154 and updated the wiki to reflect the current state of
INFO.yaml
With the removal of Ed Kern, this makes the total 6.

Thanks,
-daw-

On 7/15/2021 11:51 AM, Andrew Grimberg wrote:
Correction, after looking over the actual committer list somehow I've
been named twice (Once as PTL with a different LFID I don't use and once
as myself)

Actual number of committers currently listed: 9, and minus CJ and Thanh
brings us to 7.

I've got change https://gerrit.fd.io/r/c/ci-management/+/33154 open to
remove CJ and Thanh and cleanup my records

-Andy-

On 7/15/21 8:40 AM, Andrew Grimberg via lists.fd.io wrote:
+1

That puts us at 5 of 10 currently listed committers.

Which reminds me, we should probably do a committer cleanup I see the
following people still listed a committers that haven't done anything a
very long time now:

Thanh Ha (zxiiro)
CJ Collier

I also see the following folks that have not responded to this thread
listed:

hagbard (Ed Warnicke)
ejk (Ed Kern)

I know we can reach hagbard (he's likely lurking on the list) but I
don't have a contact address for ejk since I'm under the impression he
left Cisco and the address I see is a Cisco one.

If we clean out Thanh and CJ that brings us to a bit over quorum.

-Andy-

On 7/12/21 1:01 PM, Dave Wallace wrote:
Folks,

I would like to nominate Peter Mikus as a committer for ci-management.

Peter's commit history:
https://gerrit.fd.io/r/q/owner:pmikus%2540cisco.com+project:ci-management+is:merged

I spoke with Peter and verified that he would like to become a
ci-management committer.  Peter is active in the CSIT project and
manages the FD.io physical testbeds in the Vexxhost data centers.  He
brings a wealth of linux operations experience which will be beneficial
all of the FD.io projects in the role of committer for ci-management.

I will start the voting with +1 for Peter.

Thanks,
-daw-





Re: Committer Nomination: Peter Mikus

Andrew Grimberg
 

Yes, and Ed Warnicke voted as well so we're unanimous. Just needs to be
brought to the TSC for ratification. Since I don't generally attend
those, would someone like to do it for me?

-Andy-

On 7/16/21 8:08 AM, Dave Wallace wrote:
I merged 33154 and updated the wiki to reflect the current state of
INFO.yaml
With the removal of Ed Kern, this makes the total 6.

Thanks,
-daw-

On 7/15/2021 11:51 AM, Andrew Grimberg wrote:
Correction, after looking over the actual committer list somehow I've
been named twice (Once as PTL with a different LFID I don't use and once
as myself)

Actual number of committers currently listed: 9, and minus CJ and Thanh
brings us to 7.

I've got change https://gerrit.fd.io/r/c/ci-management/+/33154 open to
remove CJ and Thanh and cleanup my records

-Andy-

On 7/15/21 8:40 AM, Andrew Grimberg via lists.fd.io wrote:
+1

That puts us at 5 of 10 currently listed committers.

Which reminds me, we should probably do a committer cleanup I see the
following people still listed a committers that haven't done anything a
very long time now:

Thanh Ha (zxiiro)
CJ Collier

I also see the following folks that have not responded to this thread
listed:

hagbard (Ed Warnicke)
ejk (Ed Kern)

I know we can reach hagbard (he's likely lurking on the list) but I
don't have a contact address for ejk since I'm under the impression he
left Cisco and the address I see is a Cisco one.

If we clean out Thanh and CJ that brings us to a bit over quorum.

-Andy-

On 7/12/21 1:01 PM, Dave Wallace wrote:
Folks,

I would like to nominate Peter Mikus as a committer for ci-management.

Peter's commit history:
https://gerrit.fd.io/r/q/owner:pmikus%2540cisco.com+project:ci-management+is:merged

I spoke with Peter and verified that he would like to become a
ci-management committer.  Peter is active in the CSIT project and
manages the FD.io physical testbeds in the Vexxhost data centers.  He
brings a wealth of linux operations experience which will be beneficial
all of the FD.io projects in the role of committer for ci-management.

I will start the voting with +1 for Peter.

Thanks,
-daw-




--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation


Re: Committer Nomination: Peter Mikus

Dave Wallace
 

I merged 33154 and updated the wiki to reflect the current state of INFO.yaml
With the removal of Ed Kern, this makes the total 6.

Thanks,
-daw-

On 7/15/2021 11:51 AM, Andrew Grimberg wrote:

Correction, after looking over the actual committer list somehow I've
been named twice (Once as PTL with a different LFID I don't use and once
as myself)

Actual number of committers currently listed: 9, and minus CJ and Thanh
brings us to 7.

I've got change https://gerrit.fd.io/r/c/ci-management/+/33154 open to
remove CJ and Thanh and cleanup my records

-Andy-

On 7/15/21 8:40 AM, Andrew Grimberg via lists.fd.io wrote:
+1

That puts us at 5 of 10 currently listed committers.

Which reminds me, we should probably do a committer cleanup I see the
following people still listed a committers that haven't done anything a
very long time now:

Thanh Ha (zxiiro)
CJ Collier

I also see the following folks that have not responded to this thread
listed:

hagbard (Ed Warnicke)
ejk (Ed Kern)

I know we can reach hagbard (he's likely lurking on the list) but I
don't have a contact address for ejk since I'm under the impression he
left Cisco and the address I see is a Cisco one.

If we clean out Thanh and CJ that brings us to a bit over quorum.

-Andy-

On 7/12/21 1:01 PM, Dave Wallace wrote:
Folks,

I would like to nominate Peter Mikus as a committer for ci-management.

Peter's commit history:
https://gerrit.fd.io/r/q/owner:pmikus%2540cisco.com+project:ci-management+is:merged

I spoke with Peter and verified that he would like to become a
ci-management committer.  Peter is active in the CSIT project and
manages the FD.io physical testbeds in the Vexxhost data centers.  He
brings a wealth of linux operations experience which will be beneficial
all of the FD.io projects in the role of committer for ci-management.

I will start the voting with +1 for Peter.

Thanks,
-daw-










    


Re: Committer Nomination: Peter Mikus

Edward Warnicke
 

+1

On Thu, Jul 15, 2021 at 10:51 AM Andrew Grimberg <agrimberg@...> wrote:
Correction, after looking over the actual committer list somehow I've
been named twice (Once as PTL with a different LFID I don't use and once
as myself)

Actual number of committers currently listed: 9, and minus CJ and Thanh
brings us to 7.

I've got change https://gerrit.fd.io/r/c/ci-management/+/33154 open to
remove CJ and Thanh and cleanup my records

-Andy-

On 7/15/21 8:40 AM, Andrew Grimberg via lists.fd.io wrote:
> +1
>
> That puts us at 5 of 10 currently listed committers.
>
> Which reminds me, we should probably do a committer cleanup I see the
> following people still listed a committers that haven't done anything a
> very long time now:
>
> Thanh Ha (zxiiro)
> CJ Collier
>
> I also see the following folks that have not responded to this thread
> listed:
>
> hagbard (Ed Warnicke)
> ejk (Ed Kern)
>
> I know we can reach hagbard (he's likely lurking on the list) but I
> don't have a contact address for ejk since I'm under the impression he
> left Cisco and the address I see is a Cisco one.
>
> If we clean out Thanh and CJ that brings us to a bit over quorum.
>
> -Andy-
>
> On 7/12/21 1:01 PM, Dave Wallace wrote:
>> Folks,
>>
>> I would like to nominate Peter Mikus as a committer for ci-management.
>>
>> Peter's commit history:
>> https://gerrit.fd.io/r/q/owner:pmikus%2540cisco.com+project:ci-management+is:merged
>>
>> I spoke with Peter and verified that he would like to become a
>> ci-management committer.  Peter is active in the CSIT project and
>> manages the FD.io physical testbeds in the Vexxhost data centers.  He
>> brings a wealth of linux operations experience which will be beneficial
>> all of the FD.io projects in the role of committer for ci-management.
>>
>> I will start the voting with +1 for Peter.
>>
>> Thanks,
>> -daw-
>>
>>
>>
>>
>>
>
>
>
>
>

--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation





Re: Committer Nomination: Peter Mikus

Andrew Grimberg
 

Correction, after looking over the actual committer list somehow I've
been named twice (Once as PTL with a different LFID I don't use and once
as myself)

Actual number of committers currently listed: 9, and minus CJ and Thanh
brings us to 7.

I've got change https://gerrit.fd.io/r/c/ci-management/+/33154 open to
remove CJ and Thanh and cleanup my records

-Andy-

On 7/15/21 8:40 AM, Andrew Grimberg via lists.fd.io wrote:
+1

That puts us at 5 of 10 currently listed committers.

Which reminds me, we should probably do a committer cleanup I see the
following people still listed a committers that haven't done anything a
very long time now:

Thanh Ha (zxiiro)
CJ Collier

I also see the following folks that have not responded to this thread
listed:

hagbard (Ed Warnicke)
ejk (Ed Kern)

I know we can reach hagbard (he's likely lurking on the list) but I
don't have a contact address for ejk since I'm under the impression he
left Cisco and the address I see is a Cisco one.

If we clean out Thanh and CJ that brings us to a bit over quorum.

-Andy-

On 7/12/21 1:01 PM, Dave Wallace wrote:
Folks,

I would like to nominate Peter Mikus as a committer for ci-management.

Peter's commit history:
https://gerrit.fd.io/r/q/owner:pmikus%2540cisco.com+project:ci-management+is:merged

I spoke with Peter and verified that he would like to become a
ci-management committer.  Peter is active in the CSIT project and
manages the FD.io physical testbeds in the Vexxhost data centers.  He
brings a wealth of linux operations experience which will be beneficial
all of the FD.io projects in the role of committer for ci-management.

I will start the voting with +1 for Peter.

Thanks,
-daw-







--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation


Re: Committer Nomination: Peter Mikus

Andrew Grimberg
 

+1

That puts us at 5 of 10 currently listed committers.

Which reminds me, we should probably do a committer cleanup I see the
following people still listed a committers that haven't done anything a
very long time now:

Thanh Ha (zxiiro)
CJ Collier

I also see the following folks that have not responded to this thread
listed:

hagbard (Ed Warnicke)
ejk (Ed Kern)

I know we can reach hagbard (he's likely lurking on the list) but I
don't have a contact address for ejk since I'm under the impression he
left Cisco and the address I see is a Cisco one.

If we clean out Thanh and CJ that brings us to a bit over quorum.

-Andy-

On 7/12/21 1:01 PM, Dave Wallace wrote:
Folks,

I would like to nominate Peter Mikus as a committer for ci-management.

Peter's commit history:
https://gerrit.fd.io/r/q/owner:pmikus%2540cisco.com+project:ci-management+is:merged

I spoke with Peter and verified that he would like to become a
ci-management committer.  Peter is active in the CSIT project and
manages the FD.io physical testbeds in the Vexxhost data centers.  He
brings a wealth of linux operations experience which will be beneficial
all of the FD.io projects in the role of committer for ci-management.

I will start the voting with +1 for Peter.

Thanks,
-daw-




--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation


Re: Committer Nomination: Peter Mikus

Eric Ball
 

+1

On Tue, Jul 13, 2021 at 8:12 AM Vanessa Valderrama <vvalderrama@...> wrote:

+1 for sure

On 7/13/21 6:35 AM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via lists.fd.io wrote:

> Peter Mikus as a committer for ci-management.

 

+1.

 

> commit history

 

Peter is also active in reviews [1].

 

Vratko.

 

[1] https://gerrit.fd.io/r/q/project:ci-management+commentby:pmikus%2540cisco.com+-owner:pmikus%2540cisco.com

 

From: ci-management-dev@... <ci-management-dev@...> On Behalf Of Dave Wallace
Sent: Monday, 2021-July-12 22:02
To: ci-management-dev@...
Subject: [ci-management-dev] Committer Nomination: Peter Mikus

 

Folks,

I would like to nominate Peter Mikus as a committer for ci-management.

Peter's commit history:
https://gerrit.fd.io/r/q/owner:pmikus%2540cisco.com+project:ci-management+is:merged

I spoke with Peter and verified that he would like to become a ci-management committer.  Peter is active in the CSIT project and manages the FD.io physical testbeds in the Vexxhost data centers.  He brings a wealth of linux operations experience which will be beneficial all of the FD.io projects in the role of committer for ci-management.

I will start the voting with +1 for Peter.

Thanks,
-daw-



    




Re: Committer Nomination: Peter Mikus

Vanessa Valderrama
 

+1 for sure

On 7/13/21 6:35 AM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via lists.fd.io wrote:

> Peter Mikus as a committer for ci-management.

 

+1.

 

> commit history

 

Peter is also active in reviews [1].

 

Vratko.

 

[1] https://gerrit.fd.io/r/q/project:ci-management+commentby:pmikus%2540cisco.com+-owner:pmikus%2540cisco.com

 

From: ci-management-dev@... <ci-management-dev@...> On Behalf Of Dave Wallace
Sent: Monday, 2021-July-12 22:02
To: ci-management-dev@...
Subject: [ci-management-dev] Committer Nomination: Peter Mikus

 

Folks,

I would like to nominate Peter Mikus as a committer for ci-management.

Peter's commit history:
https://gerrit.fd.io/r/q/owner:pmikus%2540cisco.com+project:ci-management+is:merged

I spoke with Peter and verified that he would like to become a ci-management committer.  Peter is active in the CSIT project and manages the FD.io physical testbeds in the Vexxhost data centers.  He brings a wealth of linux operations experience which will be beneficial all of the FD.io projects in the role of committer for ci-management.

I will start the voting with +1 for Peter.

Thanks,
-daw-





Re: Committer Nomination: Peter Mikus

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

> Peter Mikus as a committer for ci-management.

 

+1.

 

> commit history

 

Peter is also active in reviews [1].

 

Vratko.

 

[1] https://gerrit.fd.io/r/q/project:ci-management+commentby:pmikus%2540cisco.com+-owner:pmikus%2540cisco.com

 

From: ci-management-dev@... <ci-management-dev@...> On Behalf Of Dave Wallace
Sent: Monday, 2021-July-12 22:02
To: ci-management-dev@...
Subject: [ci-management-dev] Committer Nomination: Peter Mikus

 

Folks,

I would like to nominate Peter Mikus as a committer for ci-management.

Peter's commit history:
https://gerrit.fd.io/r/q/owner:pmikus%2540cisco.com+project:ci-management+is:merged

I spoke with Peter and verified that he would like to become a ci-management committer.  Peter is active in the CSIT project and manages the FD.io physical testbeds in the Vexxhost data centers.  He brings a wealth of linux operations experience which will be beneficial all of the FD.io projects in the role of committer for ci-management.

I will start the voting with +1 for Peter.

Thanks,
-daw-


Committer Nomination: Peter Mikus

Dave Wallace
 

Folks,

I would like to nominate Peter Mikus as a committer for ci-management.

Peter's commit history:
https://gerrit.fd.io/r/q/owner:pmikus%2540cisco.com+project:ci-management+is:merged

I spoke with Peter and verified that he would like to become a ci-management committer.  Peter is active in the CSIT project and manages the FD.io physical testbeds in the Vexxhost data centers.  He brings a wealth of linux operations experience which will be beneficial all of the FD.io projects in the role of committer for ci-management.

I will start the voting with +1 for Peter.

Thanks,
-daw-


one merge run for multiple submits

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

Hi.

 

For larger context, see today's discussion

on fd.io slack channel #fdio-infra.

TLDR: Bad things happened, we think because too many runs got scheduled.

 

Historically, merge jobs are not concurrent,

and they always checkout HEAD of $GERRIT_BRANCH.

In FD.io Jenkins that means if multiple Gerrit changes

are submitted in quick succession, multiple runs

of the merge job are scheduled, most of them

ending up building the same HEAD.

 

I know that merge jobs in OpenDaylight do not behave like that.

Instead of scheduling a run for each change,

at most one run is waiting in the queue,

effectively skipping building of non-last commits.

Example, copied from the slack channel:

 

  For example this [0] merge run has been triggered by this [1] change,

 but by the time it got to cloning, 5 more changes were merged.

 The next [2] merge run has been triggered by this [3] change,

 which was next in the chain. The "5 more" changes did not trigger their own runs.

 

But I was unable to figure out which configuration knob

makes the difference in merge job behavior.

I compared a vpp job config [4] with ODL job config [5],

but I see nothing obvious.

Incidentally, both jobs have string parameter GERRIT_REFSPEC,

even though the value is not used anywhere.

 

Is it something related to the timed trigger?

I know CSIT periodic jobs also avoid scheduling more than one run

(again without any obvious knob, except concurrent: false).

 

Vratko.

 

[0] https://jenkins.opendaylight.org/releng/view/Merge-Jobs/job/controller-maven-merge-master/204/

[1] https://git.opendaylight.org/gerrit/c/controller/+/91723

[2] https://jenkins.opendaylight.org/releng/view/Merge-Jobs/job/controller-maven-merge-master/205/

[3] https://git.opendaylight.org/gerrit/c/controller/+/91756

[4] https://jenkins.fd.io/view/vpp/job/vpp-arm-merge-master-ubuntu1804/configure

[5] https://jenkins.opendaylight.org/releng/view/Merge-Jobs/job/controller-maven-merge-master/configure

 


ci-management-jjb-merge job failures

Dave Wallace
 

Folks,

The ci-management-jjb-merge job [0] has been failing consistently.  In fact, Vratko's remerge [1] of 27904 this morning kicked off a job [2] which subsequently failed [3], but was never reported in gerrit as either being started or having failed.

All of the failures have been timeouts where the Jenkins job reconfigurations are going along fine, then randomly get stalled for ~1/2 hour to an hour.  The last successful run [3] completed in 5 min 38 seconds.

I have opened a case [4] to investigate / resolve this issue.

Thanks,
-daw-

[0]
https://jenkins.fd.io/view/ci-management/job/ci-management-jjb-merge/
[1] https://gerrit.fd.io/r/c/ci-management/+/27904/2#message-1855d69b1308af25a2a927cf35b2ba48a4d4d9e0
[2] https://jenkins.fd.io/view/ci-management/job/ci-management-jjb-merge/583/
[3] https://jenkins.fd.io/view/ci-management/job/ci-management-jjb-merge/578/
    https://logs.fd.io/production/vex-yul-rot-jenkins-1/ci-management-jjb-merge/578/console-timestamp.log.gz
[4] https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-20242


Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

Pei, Yulong
 

Hi Florin & Ping,

 

My comment about vpp built with openssl-3.0.0,

See inline,

 

From: csit-dev@... <csit-dev@...> On Behalf Of Florin Coras
Sent: Tuesday, June 23, 2020 9:59 AM
To: Yu, Ping <ping.yu@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; vrpolak@...; Dave Wallace <dwallacelf@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>; csit-dev@...; ci-management-dev@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hi Ping, 



On Jun 22, 2020, at 6:48 PM, Yu, Ping <ping.yu@...> wrote:

 

Hi, Florin,

 

After testing, we found that if without VPP patch, the performance will dropped too much, thus it is not meaningfully to integrate VPP master only and provide the CSIT result, which will disappointed people.

 

Approximately what type of difference are we talking about? I guess this is mainly due to the way accepted connections are load balanced across vcl workers? 



At the other hand, we’d like to integrate with OpenSSL 3.0.0 alpha release even without changing code in VPP master branch, so this is definitely different from sanity VPP.

 

Okay, that’s a different type of problem, unfortunately, and that does indeed need different binaries. 

 

[Yulong Pei]  I think that VPP master branch may move to build with openssl 3.0.0 sooner or later, Maybe currently VPP can provide an experiment branch built with openssl3.0.0.

 

 

Based on above problem, we’d like to separate VSAP VPP build from native VPP build.   Does it make sense?

We will look forward to the VSAP repo based build, and before this repo comes out, we’d like to change the vpp build name to avoid conflict.

 

That’s fine with me, but ultimately the CSIT maintainers need to agree to this :-)

 

Cheers,

Florin



 

Ping

 

From: Florin Coras <fcoras.lists@...> 
Sent: Monday, June 22, 2020 10:08 PM
To: Yu, Ping <ping.yu@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; vrpolak@...; Dave Wallace <dwallacelf@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>; csit-dev@...; ci-management-dev@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

What do you mean by that, Ping? 

 

Florin




On Jun 22, 2020, at 1:42 AM, Yu, Ping <ping.yu@...> wrote:

 

Hello, all

 

I once talked with Florin that VSAP can temporarily use un-patch version, but it seems the performance is very poor, so it will not show any performance for VSAP. We’d like to consider Vratko’s solution.

Before the vsap repository comes out, we can replace vpp packet name to be vsap_vpp to avoid conflict with vpp master branch.

 

Ping

 

From: Jiang, XiaolongX <xiaolongx.jiang@...> 
Sent: Monday, June 22, 2020 10:09 AM
To: Pei, Yulong <yulong.pei@...>; vrpolak@...; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>
Cc: csit-dev@...; ci-management-dev@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io

 

I agree with Vratko, too. 

VSAP greatly improves the performance of Nginx, which may be helpful for the promotion of VPP.

 

Best Regards

Xiaolong Jiang

 

From: Pei, Yulong <yulong.pei@...> 
Sent: Thursday, June 18, 2020 2:06 PM
To: vrpolak@...; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io

 

Hi,

 

I agree  Vratko’s stream abstraction solution,  if no other objection,

 

1. who can help to set up  https://packagecloud.io/fdio/vsap  repository ? 

 

2. how to get permission  to manage to run  ` package_cloud push fdio/vsap  /path/to/local/vsap/package` ?

 

Best Regards

Yulong Pei

 

From: csit-dev@... <csit-dev@...> On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via lists.fd.io
Sent: Friday, June 12, 2020 6:42 PM
To: Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io

 

I assume readers are familiar with most of the context

discussed in other communication channels.

If not, I recommend to take a peek at the long discussion

on "fdio-infra" channel of fdio slack,

starting from June 1st.

 

After some thinking, I have realized ci-management

is already conceptually prepared to handle

multiple "areas" of compatibility,

where artifacts within the same area are compatible,

but artifacts from different areas are not compatible.

 

For snapshot artifacts, the compatibility is assumed

only for the latest uploaded versions.

Temporary breakages due to API changes are tolerated.

Because of that, the concept is not named area,

but it is named "stream".

 

It is an abstraction, evolved from the concept of branch name;

needed for integration of sub-projects whose branch names do not match exactly.

(In fd.io ci-management, packagecloud repository name

matches the stream exactly, but it is not a requirement.

For example, when we used Nexus, repository name did not match directly.)

 

Anyway, in this sense, master package repository [0]

is for VPP artifacts built from VPP master branch,

and any other artifacts compatible with (latest version of) them.

VPP code in stable/2005 branch creates snapshot artifacts

uploaded to 2005 package repository [1].

 

If VSAP needs VPP builds different from both master and 2005,

it means new stream needs to be created, for example called "vsap".

VSAP merge job for vsap stream can use VSAP master branch,

and there will be no VSAP merge job for master stream.

 

In future, if VPP project accepts all VSAP-related settings,

(and VPP verify job ensures production APIs are never changed)

the following process can be applied.

A new VSAP branch (called "vsap") is cut from master branch,

and the VSAP merge job for stream vsap starts using that branch.

In VSAP master branch, the build scripts are changed

to no longer build VPP artifacts (maybe download but delete before pushing).

Then a VSAP merge job for stream master is created,

using VSAP master branch, and uploading VSAP (but not VPP) artifacts to [0].

For a period of time, both streams will be tested,

to confirm that VSAP artifacts from stream master

work equally well than VSAP (and VPP) artifacts from stream vsap.

Then, vsap branch can stop being updated and all vsap stream jobs can be deleted.

 

In other words, the "vsap" stream acts as a "feature branch" for VPP project,

except that it is maintained by VSAP (not VPP) developers.

This is more flexible than my previous idea of giving

each sub-project their own packagecloud repository.

Firstly, work can be done on multiple features.

For example streams "vsap_speed" and "vsap_scale" can at first

hardcode a particular "speed versus memory" tradeoffs,

each can be upstreamed to VPP at a different time.

Secondly, when we have more cooperating sub-projects,

they can push their artifacts into the same repository,

so that users (and testers) have easier time installing them.

 

There was some discussion on TSC meeting,

mostly related to hICN sub-project instead.

As usual, I am trying to find a solution suitable for both hICN and VSAP.

For hICN, the stream solution is to mark their merge job

(which uses hICN master branch) as stream 2005.

That assumes 2005 VPP snapshots are stable enough for them.

 

What do you think?

Any important question that does not fit into the stream abstraction?

 

Vratko.

 

 

From: csit-dev@... <csit-dev@...> On Behalf Of Pei, Yulong
Sent: Tuesday, 2020-June-09 11:20
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io
Importance: High

 

Hi Guys,

 

If a packagecloud sandbox is not a good way,  could you kindly help to give suggestion about how to proceed this work ?  Sorry to mark this email with high importance since it is really blocked for a long time.

 

Best Regards

Yulong Pei

 

From: Pei, Yulong 
Sent: Monday, June 8, 2020 11:31 AM
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <XiaolongX.Jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io

 

Hi Dave,

 

Thanks for your comments,

 

My answers inline,

 

 

 

From: Dave Wallace <dwallacelf@...> 
Sent: Wednesday, June 3, 2020 9:25 PM
To: Pei, Yulong <yulong.pei@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io

 

Hi Yulong,

On 6/3/2020 1:00 AM, Pei, Yulong wrote:

Anyway,  could we have a temporary repo for VSAP at packagecloud?  then Jenkins build and verify job for VSAP work and CSIT test cases for TLS with VSAP work can be proceeded,  they are blocked for a long time 😊,

This is a possibility as long as there are some controls in place to limit access to the repo to CI jobs and/or periodic purging of the repo artifacts.  However, this does come with the cost of overseeing/managing the repo contents so is not the optimal solution IMHO.

[Yulong Pei]  could we regard “temporary repo” as a packagecloude sandbox, just like fdio Jenkins sandbox ? It do not need keep it for a long time.

 

When issue about VSAP specific patch merged to VPP master was fixed,   then we can move VSAP built package to standard repo at packagecloud at that time.

Once code is merged to VPP then it becomes available in the regular VPP packages.  VSAP built packages are temporary thus will never be moved.

However, this model introduces an additional layer of CI jobs to test those features that exist in VPP plus those features that are only supported in the VSAP project packages.  
There are limitations on the availability of CSIT testbeds to cover VPP features.  Therefore duplication test execution against the VSAP artifacts and VPP artifacts is not feasible without additional testbed resources dedicated to the VSAP project.  So this will require movement of test cases from VSAP to VPP which may introduce additional challenges. 

 

[Yulong Pei]  Currently we can limit VSAP test only run on one skx or clx CSIT testbed, trigger one test weekly is enough,  and I think it will deploy more ICELake testbeds in CSIT lab in the future.


Another issue is ongoing trending & failure analysis of the CSIT test results of the VSAP artifacts.  The CSIT & VPP teams work together on identifying & resolving test failures and performance regressions.  Managing all of that for VPP and VSAP is going to be very challenging.  IMHO, it is unrealistic to expect the CSIT & VPP teams to handle VSAP in addition to VPP.  How much additional work this is for CSIT & VSAP is not currently understood.

[Yulong Pei]  Actually  VSAP test  is to show  VPP TLS/tcp performance,  VSAP is only a modified Nginx, it change Nginx socket layer to fit for VPP VCL or LDP,  we may also regard VSAP(Nginx) as a test tool  for VPP TLS/tcp test, 

As you know, VPP has a internal http_static server, but if test VPP TLS/tcp with that,  the performance is  bad.  so from test view, VSAP test is VPP test,  not Nginx test.  And Intel team also can help on failure analysis.


Given the number of unknowns in the process and deployment/consumption of resources (both human & automation), I think that it would be best to pick a very small set of tests (maybe as small as 1) as an initial deployment of the project CI pipeline.  Then evaluate/refactor the pipeline before including everything that you have implemented to date. 

[Yulong Pei]   I agree that it is better to pick small set of tests as an initial deployment of the project CI pipeline.

 

Best Regards

Yulong Pei


Thanks,
-daw-

 

Best Regards

Yulong Pei

 

From: Yu, Ping <ping.yu@...> 
Sent: Wednesday, June 3, 2020 11:04 AM
To: Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch)<ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>; Yu, Ping <ping.yu@...>; Yu, Ping <ping.yu@...>
Subject: RE: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Yes, for this specific issue, we’d like to move forward, and as a general packaging, there is definitely some code which requires customize VPP. For example, some company wants us to give them the version for CBDMA, and we also consider to release this code to VSAP first. 

 

@Andrew Yourtchenko (ayourtch)fixme means there is some problem, but actually it is just not merged to master branch yet. This is quite different hint to users.

 

Ping 

 

From: Florin Coras <fcoras.lists@...> 
Sent: Wednesday, June 3, 2020 6:57 AM
To: Yu, Ping <ping.yu@...>
Cc: Andrew Yourtchenko (ayourtch) <ayourtch@...>; Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hi Ping, 

 

I guess there are two improvements that have not entirely made their way into vpp:

- Pinning vpp workers to vcl workers. If we have a patch that’s generic enough, we could try merging it into master. 

- A non-locking vls alternative. I believe [1] considerably improved locking performance for multi-process applications. Do we know if vls is still a bottleneck after this? 

 

To get things moving, could we start by using existing vpp packages in combination with vsap nginx? That would give us time to clarify the two points above and a performance baseline. 

 

Regards,

Florin

 

 

 

On Jun 2, 2020, at 3:43 AM, Yu, Ping <ping.yu@...> wrote:

 

Okay, the idea to build a different name is okay, but we’d like to call it as “VSAP_vpp”.

 

For the reason why some patches could not merged into VPP master branch is that we are now working to make VPP host stack work smoothly in Nginx, and Nginx is a single-thread multiple process application, thus we can remove some “lock” mechanism in VPP to speed up the performance. We also make a group-partition method to speed up the performance in Nginx, but community (florin) think it is not a general solution yet, and we’d like to enhance it, but some customers need this patch to get their Nginx speed up.  

 

 

From: Andrew Yourtchenko (ayourtch) <ayourtch@...> 
Sent: Tuesday, June 2, 2020 5:18 PM
To: Yu, Ping <ping.yu@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hi Ping,

 

On 2 Jun 2020, at 11:05, Yu, Ping <ping.yu@...> wrote:

 

Hi, Andrew

 

You know, VPP has made some changes for DPDK, and not all of the patches are merged into DPDK master branch. It is the same in VSAP.

 

The difference is VPP doesn’t try to upload the patched version of DPDK, does it ?

 

The VPP patch in VSAP is definitely useful, but it is not necessary in VPP master branch due to complicated considerations.

 

Could you try to outline the considerations or give a pointer where I can read up?

 

I also don’t think it is completely reasonable that someone install all fd.io project at once. If someone wants to use VSAP,   some customized VPP is required, just VPP wants to customize DPDK.  

 

Do you add a custom repository for each package that you install on your system ?

 

The solution is not difficult, and just provide repo for each project.

 

Private repos are a workaround to not having a proper packaging. I maintain that having more than one package called “vpp” in the FD.io repo that does slightly different thing is not the right thing to do. 

 

This needs to be discussed at TSC I think. 

 

Till then I would suggest for VSAP to add another patch to VPP which patches the packaging to rename all the “vpp/VPP” references in the packages into “fixmevsap/FIXMEVSAP”. 

 

This way there is no confusion, no need for separate repos and no packaging conflict, the packaging issue is clearly highlighted, and you are not blocked in the interim before the TSC?

 

—a

 

 

Ping

 

From: Andrew Yourtchenko (ayourtch) <ayourtch@...> 
Sent: Monday, June 1, 2020 10:26 PM
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io

 

 

1) it is not completely unreasonable to imagine someone want to install all of the FD.io projects at once, so the process and workflow must allow for that. Debian has thousands of packages maintained by thousands of volunteers in the same repo. 

 

2) having the artifacts with the same name and description but different code is a road to a lot of pain for everyone. If a patch is useful for VPP consumption, it must be in VPP master, and there should be only one version of the master artifacts, then the VSAP should be able to act as a plugin and/or consume VPP as a wholesale dependency.

 

What are the obstacles that prevent that ?

 

--a

 

On 1 Jun 2020, at 15:39, Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...> wrote:

 

> Just like VPP:

 

Currently, it is a "fdio" repository,

projects other than VPP are uploading there too.

 

> In order to avoid confusion, we would like to have a new packagecloud repository.

> VSAP maybe like this:

 

So this is a different pattern,

but I agree it is probably the simplest solution

for allowing different project to upload packages of the same name.

Later you will probably also need /vsap/release repo.

 

Looking at [2], there already are several repositories

unrelated to STREAM variable.

So creating vsap/master could work,

unless packagecloud limits the repository level.

In that case we could create something like vsap-master.

 

The main issue will be in the merge job,

as packagecloud_push.sh directly uses PCIO_CO [3] env var.

You would need to introduce a new environment variable

(to pass "vsap" while keeping STREAM for "master")

and change the logic to insert that everywhere between ${PCIO_CO} and ${STREAM}

(without affecting jobs that do not set the new environment variable).

 

What do you think?

Should we start creating per-project repositories,

or should we keep trying to reuse fdio/master?

I personally prefer per-project repositories,

just so I do not have to investigate console output

of every new project verify/merge job. :)

 

I think it would also help with HICN release frequency,

if users could install VPP from fdio/2005 and HICN from fdio/hicn/master.

 

Vratko.

 

 

From: Jiang, XiaolongX <xiaolongx.jiang@...> 
Sent: Monday, 2020-June-01 09:29
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>
Cc: csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io

 

> When installing the nginx .deb package,

> does it contain statically linked parts of VPP it needs,

> or does a user need to also install the patched vpp .deb packages?

 

The latter.

 

 

> If the latter, how do we distinguish "vanilla" VPP from "vsap" VPP?

 

In order to avoid confusion, we would like to have a new packagecloud repository.

Just like VPP:

 

VSAP maybe like this:

 

 

Best Regards

Xiaolong Jiang

 

From: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...> 
Sent: Friday, May 29, 2020 10:08 PM
To: Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Jiang, XiaolongX <xiaolongx.jiang@...>
Cc: csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io

 

Before we enable VSAP merge job,

I would like to understand the build process more.

 

So I looked at verify job console output.

(Link [0] will stop working when Sandbox is cleared over weekend.)

 

Observations (and some comments) first:

 

 > git fetch --tags --progress -- git://10.30.48.3/mirror/vsap refs/heads/master # timeout=10

 

The job was triggered for VSAP master head. Ok.

 

 > git config --get submodule.vpp.url # timeout=10

 

Vpp repository is acts as a submodule for VSAP. Ok.

 

--- building openssl 3.0.0-alpha2 - log: /w/workspace/vsap-verify-master-ubuntu1804-vcl/_build/openssl.build.log

 

Openssl is built, I assume there is a good reason to do that.

 

Applying patch: 0001-3.0.0.patch

patching file src/plugins/crypto_openssl/CMakeLists.txt

 

So VSAP does not use "vanilla" VPP,

but applies some patches.

That is normal during the development,

VSAP working with the patched VPP

acts as a kind of indirect verify job

for upstreaming the patch into VPP repo.

 

dpkg-deb: building package 'vpp' in '../vpp_20.09-rc0~73-ge7df8cbb6~b19_amd64.deb'.

 

Note that packagecloud already contains a vpp ~73 .deb [1],

it comes from VPP merge job.

The dangerous part is that even the ge part is the same,

despite the patches being applied here.

Only the ~b part happens to be different,

but in production also that could happen to be the same.

 

{:timestamp=>"2020-05-29T03:56:39.897262+0000", :message=>"Created package", :path=>"/w/workspace/vsap-verify-master-ubuntu1804-vcl/_install/deb-vcl/nginx_1.14.2-ubuntu18.04_amd64.deb"}

 

I believe this is the main output the VSAP merge job will upload to packagecloud.

 

Now the main question.

 

When installing the nginx .deb package,

does it contain statically linked parts of VPP it needs,

or does a user need to also install the patched vpp .deb packages?

 

If the former, the VSAP build process should make sure

any unneeded .deb files are deleted (or better yet not even created)

before proceeding to packagecloud upload.

 

If the latter, how do we distinguish "vanilla" VPP from "vsap" VPP?

Uploading them to the same packagecloud repository will certainly confuse users.

One possibility is to prepend vsap- prefix to all VPP packages created by VSAP build.

Short term by patching VPP makefiles,

longer-term by upstreaming a Change that takes prefix from an environment variable.

 

Vratko.

 

 

From: csit-dev@... <csit-dev@...> On Behalf Of Pei, Yulong
Sent: Friday, 2020-May-29 08:21
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Jiang, XiaolongX <xiaolongx.jiang@...>
Cc: csit-dev@...; ci-management-dev@...; Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>;maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io

 

Forgot to add Ping & Xiaolong in the email To list.

 

From: Pei, Yulong 
Sent: Friday, May 29, 2020 2:19 PM
To: Dave Wallace <dwallacelf@...>
Cc: csit-dev@...; ci-management-dev@...; Vratko Polak <vrpolak@...>; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus <pmikus@...>
Subject: About how to upload package topackagecloud.io and download package from packagecloud.io

 

Hello Dave, 

 

Could you kindly help about how to upload package to packagecloud.io and download package from packagecloud.io ?

 

Currently we are working on to integrate FDIO VSAP project build  to FDIO infrastructure, we can add build job to ci-management, example as below,

 

 

Next step it need to upload the VSAP built packages to packagecloud.io,  I guess that it may need set up a repo for VSAP project in packageclould.io,  right ?

 

And then we also need download VSAP built packages from packagecloud.io for CSIT to run VSAP performance test,  to use which way to get this ?

 

Best Regards

Yulong Pei

 

 

 

 

 

 


Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

Dave Wallace
 

Ping,

Additional comment inline...


On 6/22/20 9:59 PM, Florin Coras wrote:
Hi Ping, 

On Jun 22, 2020, at 6:48 PM, Yu, Ping <ping.yu@...> wrote:

Hi, Florin,
 
After testing, we found that if without VPP patch, the performance will dropped too much, thus it is not meaningfully to integrate VPP master only and provide the CSIT result, which will disappointed people.

Approximately what type of difference are we talking about? I guess this is mainly due to the way accepted connections are load balanced across vcl workers? 

At the other hand, we’d like to integrate with OpenSSL 3.0.0 alpha release even without changing code in VPP master branch, so this is definitely different from sanity VPP.

Okay, that’s a different type of problem, unfortunately, and that does indeed need different binaries. 

Based on above problem, we’d like to separate VSAP VPP build from native VPP build.   Does it make sense?
We will look forward to the VSAP repo based build, and before this repo comes out, we’d like to change the vpp build name to avoid conflict.
There is an additional complication here -- who supports the forked VSAP version of VPP?

This issue was raised during the VSAP approval by the TSC who strongly objected to having a publicly available fork of VPP as part of the VSAP project.  It is acceptable to have experimental contributions to VPP as part of the VPP project (e.g. quic plugin). IMHO any modifications made to enhance VSAP performance test results must be part of the VPP project for the results to be meaningful.

Anyone can fork an open source project, modify it for a specific use case while in the process making changes which are unacceptable to the project maintainers.  In that case whomever creates the fork is responsible for supporting the entire forked repository.  

VSAP is an official FD.io project, thus any modifications to VPP are by association owned by the VPP maintainers.  Which means the VPP code used by VSAP must have been reviewed, approved, and merged by the VPP committers.  If you insist on changing the charter of the VSAP project, then I would recommend that we bring this proposal to the TSC for approval.

Thanks,
-daw-

That’s fine with me, but ultimately the CSIT maintainers need to agree to this :-)

Cheers,
Florin

 
Ping
 
From: Florin Coras <fcoras.lists@...> 
Sent: Monday, June 22, 2020 10:08 PM
To: Yu, Ping <ping.yu@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; vrpolak@...; Dave Wallace <dwallacelf@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>; csit-dev@...; ci-management-dev@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io
 
What do you mean by that, Ping? 
 
Florin


On Jun 22, 2020, at 1:42 AM, Yu, Ping <ping.yu@...> wrote:
 
Hello, all
 
I once talked with Florin that VSAP can temporarily use un-patch version, but it seems the performance is very poor, so it will not show any performance for VSAP. We’d like to consider Vratko’s solution.
Before the vsap repository comes out, we can replace vpp packet name to be vsap_vpp to avoid conflict with vpp master branch.
 
Ping
 
From: Jiang, XiaolongX <xiaolongx.jiang@...> 
Sent: Monday, June 22, 2020 10:09 AM
To: Pei, Yulong <yulong.pei@...>; vrpolak@...; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>
Cc: csit-dev@...; ci-management-dev@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io
 
I agree with Vratko, too. 
VSAP greatly improves the performance of Nginx, which may be helpful for the promotion of VPP.
 
Best Regards
Xiaolong Jiang
 
From: Pei, Yulong <yulong.pei@...> 
Sent: Thursday, June 18, 2020 2:06 PM
To: vrpolak@...; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io
 
Hi,
 
I agree  Vratko’s stream abstraction solution,  if no other objection,
 
1. who can help to set up  https://packagecloud.io/fdio/vsap  repository ? 
 
2. how to get permission  to manage to run  ` package_cloud push fdio/vsap  /path/to/local/vsap/package` ?
 
Best Regards
Yulong Pei
 
From: csit-dev@... <csit-dev@...> On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via lists.fd.io
Sent: Friday, June 12, 2020 6:42 PM
To: Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io
 
I assume readers are familiar with most of the context
discussed in other communication channels.
If not, I recommend to take a peek at the long discussion
on "fdio-infra" channel of fdio slack,
starting from June 1st.
 
After some thinking, I have realized ci-management
is already conceptually prepared to handle
multiple "areas" of compatibility,
where artifacts within the same area are compatible,
but artifacts from different areas are not compatible.
 
For snapshot artifacts, the compatibility is assumed
only for the latest uploaded versions.
Temporary breakages due to API changes are tolerated.
Because of that, the concept is not named area,
but it is named "stream".
 
It is an abstraction, evolved from the concept of branch name;
needed for integration of sub-projects whose branch names do not match exactly.
(In fd.io ci-management, packagecloud repository name
matches the stream exactly, but it is not a requirement.
For example, when we used Nexus, repository name did not match directly.)
 
Anyway, in this sense, master package repository [0]
is for VPP artifacts built from VPP master branch,
and any other artifacts compatible with (latest version of) them.
VPP code in stable/2005 branch creates snapshot artifacts
uploaded to 2005 package repository [1].
 
If VSAP needs VPP builds different from both master and 2005,
it means new stream needs to be created, for example called "vsap".
VSAP merge job for vsap stream can use VSAP master branch,
and there will be no VSAP merge job for master stream.
 
In future, if VPP project accepts all VSAP-related settings,
(and VPP verify job ensures production APIs are never changed)
the following process can be applied.
A new VSAP branch (called "vsap") is cut from master branch,
and the VSAP merge job for stream vsap starts using that branch.
In VSAP master branch, the build scripts are changed
to no longer build VPP artifacts (maybe download but delete before pushing).
Then a VSAP merge job for stream master is created,
using VSAP master branch, and uploading VSAP (but not VPP) artifacts to [0].
For a period of time, both streams will be tested,
to confirm that VSAP artifacts from stream master
work equally well than VSAP (and VPP) artifacts from stream vsap.
Then, vsap branch can stop being updated and all vsap stream jobs can be deleted.
 
In other words, the "vsap" stream acts as a "feature branch" for VPP project,
except that it is maintained by VSAP (not VPP) developers.
This is more flexible than my previous idea of giving
each sub-project their own packagecloud repository.
Firstly, work can be done on multiple features.
For example streams "vsap_speed" and "vsap_scale" can at first
hardcode a particular "speed versus memory" tradeoffs,
each can be upstreamed to VPP at a different time.
Secondly, when we have more cooperating sub-projects,
they can push their artifacts into the same repository,
so that users (and testers) have easier time installing them.
 
There was some discussion on TSC meeting,
mostly related to hICN sub-project instead.
As usual, I am trying to find a solution suitable for both hICN and VSAP.
For hICN, the stream solution is to mark their merge job
(which uses hICN master branch) as stream 2005.
That assumes 2005 VPP snapshots are stable enough for them.
 
What do you think?
Any important question that does not fit into the stream abstraction?
 
Vratko.
 
 
From: csit-dev@... <csit-dev@...> On Behalf Of Pei, Yulong
Sent: Tuesday, 2020-June-09 11:20
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io
Importance: High
 
Hi Guys,
 
If a packagecloud sandbox is not a good way,  could you kindly help to give suggestion about how to proceed this work ?  Sorry to mark this email with high importance since it is really blocked for a long time.
 
Best Regards
Yulong Pei
 
From: Pei, Yulong 
Sent: Monday, June 8, 2020 11:31 AM
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <XiaolongX.Jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io
 
Hi Dave,
 
Thanks for your comments,
 
My answers inline,
 
 
 
From: Dave Wallace <dwallacelf@...> 
Sent: Wednesday, June 3, 2020 9:25 PM
To: Pei, Yulong <yulong.pei@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io
 
Hi Yulong,

On 6/3/2020 1:00 AM, Pei, Yulong wrote:
Anyway,  could we have a temporary repo for VSAP at packagecloud?  then Jenkins build and verify job for VSAP work and CSIT test cases for TLS with VSAP work can be proceeded,  they are blocked for a long time 😊,
This is a possibility as long as there are some controls in place to limit access to the repo to CI jobs and/or periodic purging of the repo artifacts.  However, this does come with the cost of overseeing/managing the repo contents so is not the optimal solution IMHO.

[Yulong Pei]  could we regard “temporary repo” as a packagecloude sandbox, just like fdio Jenkins sandbox ? It do not need keep it for a long time.
 
When issue about VSAP specific patch merged to VPP master was fixed,   then we can move VSAP built package to standard repo at packagecloud at that time.
Once code is merged to VPP then it becomes available in the regular VPP packages.  VSAP built packages are temporary thus will never be moved.

However, this model introduces an additional layer of CI jobs to test those features that exist in VPP plus those features that are only supported in the VSAP project packages.  
There are limitations on the availability of CSIT testbeds to cover VPP features.  Therefore duplication test execution against the VSAP artifacts and VPP artifacts is not feasible without additional testbed resources dedicated to the VSAP project.  So this will require movement of test cases from VSAP to VPP which may introduce additional challenges. 
 
[Yulong Pei]  Currently we can limit VSAP test only run on one skx or clx CSIT testbed, trigger one test weekly is enough,  and I think it will deploy more ICELake testbeds in CSIT lab in the future.


Another issue is ongoing trending & failure analysis of the CSIT test results of the VSAP artifacts.  The CSIT & VPP teams work together on identifying & resolving test failures and performance regressions.  Managing all of that for VPP and VSAP is going to be very challenging.  IMHO, it is unrealistic to expect the CSIT & VPP teams to handle VSAP in addition to VPP.  How much additional work this is for CSIT & VSAP is not currently understood.

[Yulong Pei]  Actually  VSAP test  is to show  VPP TLS/tcp performance,  VSAP is only a modified Nginx, it change Nginx socket layer to fit for VPP VCL or LDP,  we may also regard VSAP(Nginx) as a test tool  for VPP TLS/tcp test, 
As you know, VPP has a internal http_static server, but if test VPP TLS/tcp with that,  the performance is  bad.  so from test view, VSAP test is VPP test,  not Nginx test.  And Intel team also can help on failure analysis.


Given the number of unknowns in the process and deployment/consumption of resources (both human & automation), I think that it would be best to pick a very small set of tests (maybe as small as 1) as an initial deployment of the project CI pipeline.  Then evaluate/refactor the pipeline before including everything that you have implemented to date. 

[Yulong Pei]   I agree that it is better to pick small set of tests as an initial deployment of the project CI pipeline.
 
Best Regards
Yulong Pei


Thanks,
-daw-

 
Best Regards
Yulong Pei
 
From: Yu, Ping <ping.yu@...> 
Sent: Wednesday, June 3, 2020 11:04 AM
To: Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch)<ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>; Yu, Ping <ping.yu@...>; Yu, Ping <ping.yu@...>
Subject: RE: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io
 
Yes, for this specific issue, we’d like to move forward, and as a general packaging, there is definitely some code which requires customize VPP. For example, some company wants us to give them the version for CBDMA, and we also consider to release this code to VSAP first. 
 
@Andrew Yourtchenko (ayourtch)fixme means there is some problem, but actually it is just not merged to master branch yet. This is quite different hint to users.
 
Ping 
 
From: Florin Coras <fcoras.lists@...> 
Sent: Wednesday, June 3, 2020 6:57 AM
To: Yu, Ping <ping.yu@...>
Cc: Andrew Yourtchenko (ayourtch) <ayourtch@...>; Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io
 
Hi Ping, 
 
I guess there are two improvements that have not entirely made their way into vpp:
- Pinning vpp workers to vcl workers. If we have a patch that’s generic enough, we could try merging it into master. 
- A non-locking vls alternative. I believe [1] considerably improved locking performance for multi-process applications. Do we know if vls is still a bottleneck after this? 
 
To get things moving, could we start by using existing vpp packages in combination with vsap nginx? That would give us time to clarify the two points above and a performance baseline. 
 
Regards,
Florin
 
 

 

On Jun 2, 2020, at 3:43 AM, Yu, Ping <ping.yu@...> wrote:
 
Okay, the idea to build a different name is okay, but we’d like to call it as “VSAP_vpp”.
 
For the reason why some patches could not merged into VPP master branch is that we are now working to make VPP host stack work smoothly in Nginx, and Nginx is a single-thread multiple process application, thus we can remove some “lock” mechanism in VPP to speed up the performance. We also make a group-partition method to speed up the performance in Nginx, but community (florin) think it is not a general solution yet, and we’d like to enhance it, but some customers need this patch to get their Nginx speed up.  
 
 
From: Andrew Yourtchenko (ayourtch) <ayourtch@...> 
Sent: Tuesday, June 2, 2020 5:18 PM
To: Yu, Ping <ping.yu@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io
 
Hi Ping,

 

On 2 Jun 2020, at 11:05, Yu, Ping <ping.yu@...> wrote:

 
Hi, Andrew
 
You know, VPP has made some changes for DPDK, and not all of the patches are merged into DPDK master branch. It is the same in VSAP.
 
The difference is VPP doesn’t try to upload the patched version of DPDK, does it ?

 

The VPP patch in VSAP is definitely useful, but it is not necessary in VPP master branch due to complicated considerations.
 
Could you try to outline the considerations or give a pointer where I can read up?
 
I also don’t think it is completely reasonable that someone install all fd.io project at once. If someone wants to use VSAP,   some customized VPP is required, just VPP wants to customize DPDK.  
 
Do you add a custom repository for each package that you install on your system ?

 

The solution is not difficult, and just provide repo for each project.
 
Private repos are a workaround to not having a proper packaging. I maintain that having more than one package called “vpp” in the FD.io repo that does slightly different thing is not the right thing to do. 
 
This needs to be discussed at TSC I think. 
 
Till then I would suggest for VSAP to add another patch to VPP which patches the packaging to rename all the “vpp/VPP” references in the packages into “fixmevsap/FIXMEVSAP”. 
 
This way there is no confusion, no need for separate repos and no packaging conflict, the packaging issue is clearly highlighted, and you are not blocked in the interim before the TSC?
 
—a

 

 
Ping
 
From: Andrew Yourtchenko (ayourtch) <ayourtch@...> 
Sent: Monday, June 1, 2020 10:26 PM
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io
 
 
1) it is not completely unreasonable to imagine someone want to install all of the FD.io projects at once, so the process and workflow must allow for that. Debian has thousands of packages maintained by thousands of volunteers in the same repo. 
 
2) having the artifacts with the same name and description but different code is a road to a lot of pain for everyone. If a patch is useful for VPP consumption, it must be in VPP master, and there should be only one version of the master artifacts, then the VSAP should be able to act as a plugin and/or consume VPP as a wholesale dependency.
 
What are the obstacles that prevent that ?
 
--a

 

On 1 Jun 2020, at 15:39, Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...> wrote:

 
> Just like VPP:
 
Currently, it is a "fdio" repository,
projects other than VPP are uploading there too.
 
> In order to avoid confusion, we would like to have a new packagecloud repository.
> VSAP maybe like this:
 
So this is a different pattern,
but I agree it is probably the simplest solution
for allowing different project to upload packages of the same name.
Later you will probably also need /vsap/release repo.
 
Looking at [2], there already are several repositories
unrelated to STREAM variable.
So creating vsap/master could work,
unless packagecloud limits the repository level.
In that case we could create something like vsap-master.
 
The main issue will be in the merge job,
as packagecloud_push.sh directly uses PCIO_CO [3] env var.
You would need to introduce a new environment variable
(to pass "vsap" while keeping STREAM for "master")
and change the logic to insert that everywhere between ${PCIO_CO} and ${STREAM}
(without affecting jobs that do not set the new environment variable).
 
What do you think?
Should we start creating per-project repositories,
or should we keep trying to reuse fdio/master?
I personally prefer per-project repositories,
just so I do not have to investigate console output
of every new project verify/merge job. :)
 
I think it would also help with HICN release frequency,
if users could install VPP from fdio/2005 and HICN from fdio/hicn/master.
 
Vratko.
 
 
From: Jiang, XiaolongX <xiaolongx.jiang@...> 
Sent: Monday, 2020-June-01 09:29
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>
Cc: csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io
 
> When installing the nginx .deb package,
> does it contain statically linked parts of VPP it needs,
> or does a user need to also install the patched vpp .deb packages?
 
The latter.
 
 
> If the latter, how do we distinguish "vanilla" VPP from "vsap" VPP?
 
In order to avoid confusion, we would like to have a new packagecloud repository.
Just like VPP:
 
VSAP maybe like this:
 
 
Best Regards
Xiaolong Jiang
 
From: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...> 
Sent: Friday, May 29, 2020 10:08 PM
To: Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Jiang, XiaolongX <xiaolongx.jiang@...>
Cc: csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io
 
Before we enable VSAP merge job,
I would like to understand the build process more.
 
So I looked at verify job console output.
(Link [0] will stop working when Sandbox is cleared over weekend.)
 
Observations (and some comments) first:
 
 > git fetch --tags --progress -- git://10.30.48.3/mirror/vsap refs/heads/master # timeout=10
 
The job was triggered for VSAP master head. Ok.
 
 > git config --get submodule.vpp.url # timeout=10
 
Vpp repository is acts as a submodule for VSAP. Ok.
 
--- building openssl 3.0.0-alpha2 - log: /w/workspace/vsap-verify-master-ubuntu1804-vcl/_build/openssl.build.log
 
Openssl is built, I assume there is a good reason to do that.
 
Applying patch: 0001-3.0.0.patch
patching file src/plugins/crypto_openssl/CMakeLists.txt
 
So VSAP does not use "vanilla" VPP,
but applies some patches.
That is normal during the development,
VSAP working with the patched VPP
acts as a kind of indirect verify job
for upstreaming the patch into VPP repo.
 
dpkg-deb: building package 'vpp' in '../vpp_20.09-rc0~73-ge7df8cbb6~b19_amd64.deb'.
 
Note that packagecloud already contains a vpp ~73 .deb [1],
it comes from VPP merge job.
The dangerous part is that even the ge part is the same,
despite the patches being applied here.
Only the ~b part happens to be different,
but in production also that could happen to be the same.
 
{:timestamp=>"2020-05-29T03:56:39.897262+0000", :message=>"Created package", :path=>"/w/workspace/vsap-verify-master-ubuntu1804-vcl/_install/deb-vcl/nginx_1.14.2-ubuntu18.04_amd64.deb"}
 
I believe this is the main output the VSAP merge job will upload to packagecloud.
 
Now the main question.
 
When installing the nginx .deb package,
does it contain statically linked parts of VPP it needs,
or does a user need to also install the patched vpp .deb packages?
 
If the former, the VSAP build process should make sure
any unneeded .deb files are deleted (or better yet not even created)
before proceeding to packagecloud upload.
 
If the latter, how do we distinguish "vanilla" VPP from "vsap" VPP?
Uploading them to the same packagecloud repository will certainly confuse users.
One possibility is to prepend vsap- prefix to all VPP packages created by VSAP build.
Short term by patching VPP makefiles,
longer-term by upstreaming a Change that takes prefix from an environment variable.
 
Vratko.
 
 
From: csit-dev@... <csit-dev@...> On Behalf Of Pei, Yulong
Sent: Friday, 2020-May-29 08:21
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Jiang, XiaolongX <xiaolongx.jiang@...>
Cc: csit-dev@...; ci-management-dev@...; Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>;maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package topackagecloud.io and download package from packagecloud.io
 
Forgot to add Ping & Xiaolong in the email To list.
 
From: Pei, Yulong 
Sent: Friday, May 29, 2020 2:19 PM
To: Dave Wallace <dwallacelf@...>
Cc: csit-dev@...; ci-management-dev@...; Vratko Polak <vrpolak@...>; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus <pmikus@...>
Subject: About how to upload package topackagecloud.io and download package from packagecloud.io
 
Hello Dave, 
 
Could you kindly help about how to upload package to packagecloud.io and download package from packagecloud.io ?
 
Currently we are working on to integrate FDIO VSAP project build  to FDIO infrastructure, we can add build job to ci-management, example as below,
 
 
Next step it need to upload the VSAP built packages to packagecloud.io,  I guess that it may need set up a repo for VSAP project in packageclould.io,  right ?
 
And then we also need download VSAP built packages from packagecloud.io for CSIT to run VSAP performance test,  to use which way to get this ?
 
Best Regards
Yulong Pei
 
 

 

 
 



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

Edward Warnicke
 

Done

Ed

On Thu, Jun 18, 2020 at 9:42 AM Dave Wallace (dwallace) <dwallace@...> wrote:

Luca,

 

Thank you for the excellent write-up on our meeting!

 

@Ed Warnicke, can you please create the hicn repo on packagecloud.io (https://packagecloud/fdio/hicn)?

 

-daw-

 

From: Luca Muscariello <muscariello@...>
Sent: Thursday, June 18, 2020 2:43 AM
To: Andrew 👽 Yourtchenko <ayourtch@...>; Vanessa Valderrama <vvalderrama@...>; Dave Wallace (dwallace) <dwallace@...>; tsc@...
Cc: hicn-dev@...; cicn-dev@...; ci-management-dev@...
Subject: Re: [tsc] fdio/release repository on packagecloud now contains 19900 with some odd artifacts

 

Hi,

 

After meeting with Andrew, Dave and Vanessa, we have decided to

opt for option 4 described in this thread. Tradeoffs have been 

explained in this thread.

 

This decision requires 

- the creation of a new repo https://packagecloud/fdio/hicn;

- update to ci-management on hicn JJB to push artifacts there;

- therefore previous releases are pushed manually to 

   https://packagecloud/fdio/release  via LF tickets.

Plus:

- clean up the release repo to keep actual releases only (there is

  a ci-management patch written by Mauro for this);

- lockdown releases from JJB push;

- https://packagecloud/fdio/attic is used by ci-management to cleanup

  release/ but it may be used to cleanup fdio/hicn at stationary

  regime in the long term.

 

Action points:

- merge the ci-management cleanup job

- create new packagecloud repo

- update hicn ci-management

- lockdown release

 

Thanks

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

Luca Muscariello
 

Hi,

After meeting with Andrew, Dave and Vanessa, we have decided to
opt for option 4 described in this thread. Tradeoffs have been 
explained in this thread.

This decision requires 
- the creation of a new repo https://packagecloud/fdio/hicn;
- update to ci-management on hicn JJB to push artifacts there;
- therefore previous releases are pushed manually to 
   https://packagecloud/fdio/release  via LF tickets.
Plus:
- clean up the release repo to keep actual releases only (there is
  a ci-management patch written by Mauro for this);
- lockdown releases from JJB push;
- https://packagecloud/fdio/attic is used by ci-management to cleanup
  release/ but it may be used to cleanup fdio/hicn at stationary
  regime in the long term.

Action points:
- merge the ci-management cleanup job
- create new packagecloud repo
- update hicn ci-management
- lockdown release

Thanks
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: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

Pei, Yulong
 

Hi,

 

I agree  Vratko’s stream abstraction solution,  if no other objection,

 

1. who can help to set up  https://packagecloud.io/fdio/vsap  repository ?

 

2. how to get permission  to manage to run  ` package_cloud push fdio/vsap  /path/to/local/vsap/package` ?

 

Best Regards

Yulong Pei

 

From: csit-dev@... <csit-dev@...> On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via lists.fd.io
Sent: Friday, June 12, 2020 6:42 PM
To: Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

I assume readers are familiar with most of the context

discussed in other communication channels.

If not, I recommend to take a peek at the long discussion

on "fdio-infra" channel of fdio slack,

starting from June 1st.

 

After some thinking, I have realized ci-management

is already conceptually prepared to handle

multiple "areas" of compatibility,

where artifacts within the same area are compatible,

but artifacts from different areas are not compatible.

 

For snapshot artifacts, the compatibility is assumed

only for the latest uploaded versions.

Temporary breakages due to API changes are tolerated.

Because of that, the concept is not named area,

but it is named "stream".

 

It is an abstraction, evolved from the concept of branch name;

needed for integration of sub-projects whose branch names do not match exactly.

(In fd.io ci-management, packagecloud repository name

matches the stream exactly, but it is not a requirement.

For example, when we used Nexus, repository name did not match directly.)

 

Anyway, in this sense, master package repository [0]

is for VPP artifacts built from VPP master branch,

and any other artifacts compatible with (latest version of) them.

VPP code in stable/2005 branch creates snapshot artifacts

uploaded to 2005 package repository [1].

 

If VSAP needs VPP builds different from both master and 2005,

it means new stream needs to be created, for example called "vsap".

VSAP merge job for vsap stream can use VSAP master branch,

and there will be no VSAP merge job for master stream.

 

In future, if VPP project accepts all VSAP-related settings,

(and VPP verify job ensures production APIs are never changed)

the following process can be applied.

A new VSAP branch (called "vsap") is cut from master branch,

and the VSAP merge job for stream vsap starts using that branch.

In VSAP master branch, the build scripts are changed

to no longer build VPP artifacts (maybe download but delete before pushing).

Then a VSAP merge job for stream master is created,

using VSAP master branch, and uploading VSAP (but not VPP) artifacts to [0].

For a period of time, both streams will be tested,

to confirm that VSAP artifacts from stream master

work equally well than VSAP (and VPP) artifacts from stream vsap.

Then, vsap branch can stop being updated and all vsap stream jobs can be deleted.

 

In other words, the "vsap" stream acts as a "feature branch" for VPP project,

except that it is maintained by VSAP (not VPP) developers.

This is more flexible than my previous idea of giving

each sub-project their own packagecloud repository.

Firstly, work can be done on multiple features.

For example streams "vsap_speed" and "vsap_scale" can at first

hardcode a particular "speed versus memory" tradeoffs,

each can be upstreamed to VPP at a different time.

Secondly, when we have more cooperating sub-projects,

they can push their artifacts into the same repository,

so that users (and testers) have easier time installing them.

 

There was some discussion on TSC meeting,

mostly related to hICN sub-project instead.

As usual, I am trying to find a solution suitable for both hICN and VSAP.

For hICN, the stream solution is to mark their merge job

(which uses hICN master branch) as stream 2005.

That assumes 2005 VPP snapshots are stable enough for them.

 

What do you think?

Any important question that does not fit into the stream abstraction?

 

Vratko.

 

[0] https://packagecloud.io/fdio/master

[1] https://packagecloud.io/fdio/2005

 

From: csit-dev@... <csit-dev@...> On Behalf Of Pei, Yulong
Sent: Tuesday, 2020-June-09 11:20
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io
Importance: High

 

Hi Guys,

 

If a packagecloud sandbox is not a good way,  could you kindly help to give suggestion about how to proceed this work ?  Sorry to mark this email with high importance since it is really blocked for a long time.

 

Best Regards

Yulong Pei

 

From: Pei, Yulong
Sent: Monday, June 8, 2020 11:31 AM
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <XiaolongX.Jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [ci-management-dev] [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hi Dave,

 

Thanks for your comments,

 

My answers inline,

 

 

 

From: Dave Wallace <dwallacelf@...>
Sent: Wednesday, June 3, 2020 9:25 PM
To: Pei, Yulong <yulong.pei@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hi Yulong,

On 6/3/2020 1:00 AM, Pei, Yulong wrote:

Anyway,  could we have a temporary repo for VSAP at packagecloud?  then Jenkins build and verify job for VSAP work and CSIT test cases for TLS with VSAP work can be proceeded,  they are blocked for a long time 😊,

This is a possibility as long as there are some controls in place to limit access to the repo to CI jobs and/or periodic purging of the repo artifacts.  However, this does come with the cost of overseeing/managing the repo contents so is not the optimal solution IMHO.

[Yulong Pei]  could we regard “temporary repo” as a packagecloude sandbox, just like fdio Jenkins sandbox ? It do not need keep it for a long time.

 

When issue about VSAP specific patch merged to VPP master was fixed,   then we can move VSAP built package to standard repo at packagecloud at that time.

Once code is merged to VPP then it becomes available in the regular VPP packages.  VSAP built packages are temporary thus will never be moved.

However, this model introduces an additional layer of CI jobs to test those features that exist in VPP plus those features that are only supported in the VSAP project packages. 
There are limitations on the availability of CSIT testbeds to cover VPP features.  Therefore duplication test execution against the VSAP artifacts and VPP artifacts is not feasible without additional testbed resources dedicated to the VSAP project.  So this will require movement of test cases from VSAP to VPP which may introduce additional challenges. 

 

[Yulong Pei]  Currently we can limit VSAP test only run on one skx or clx CSIT testbed, trigger one test weekly is enough,  and I think it will deploy more ICELake testbeds in CSIT lab in the future.


Another issue is ongoing trending & failure analysis of the CSIT test results of the VSAP artifacts.  The CSIT & VPP teams work together on identifying & resolving test failures and performance regressions.  Managing all of that for VPP and VSAP is going to be very challenging.  IMHO, it is unrealistic to expect the CSIT & VPP teams to handle VSAP in addition to VPP.  How much additional work this is for CSIT & VSAP is not currently understood.

[Yulong Pei]  Actually  VSAP test  is to show  VPP TLS/tcp performance,  VSAP is only a modified Nginx, it change Nginx socket layer to fit for VPP VCL or LDP,  we may also regard VSAP(Nginx) as a test tool  for VPP TLS/tcp test,

As you know, VPP has a internal http_static server, but if test VPP TLS/tcp with that,  the performance is  bad.  so from test view, VSAP test is VPP test,  not Nginx test.  And Intel team also can help on failure analysis.


Given the number of unknowns in the process and deployment/consumption of resources (both human & automation), I think that it would be best to pick a very small set of tests (maybe as small as 1) as an initial deployment of the project CI pipeline.  Then evaluate/refactor the pipeline before including everything that you have implemented to date.

[Yulong Pei]   I agree that it is better to pick small set of tests as an initial deployment of the project CI pipeline.

 

Best Regards

Yulong Pei


Thanks,
-daw-

 

Best Regards

Yulong Pei

 

From: Yu, Ping <ping.yu@...>
Sent: Wednesday, June 3, 2020 11:04 AM
To: Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>; Yu, Ping <ping.yu@...>; Yu, Ping <ping.yu@...>
Subject: RE: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Yes, for this specific issue, we’d like to move forward, and as a general packaging, there is definitely some code which requires customize VPP. For example, some company wants us to give them the version for CBDMA, and we also consider to release this code to VSAP first.

 

@Andrew Yourtchenko (ayourtch)fixme means there is some problem, but actually it is just not merged to master branch yet. This is quite different hint to users.

 

Ping

 

From: Florin Coras <fcoras.lists@...>
Sent: Wednesday, June 3, 2020 6:57 AM
To: Yu, Ping <ping.yu@...>
Cc: Andrew Yourtchenko (ayourtch) <ayourtch@...>; Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hi Ping, 

 

I guess there are two improvements that have not entirely made their way into vpp:

- Pinning vpp workers to vcl workers. If we have a patch that’s generic enough, we could try merging it into master. 

- A non-locking vls alternative. I believe [1] considerably improved locking performance for multi-process applications. Do we know if vls is still a bottleneck after this? 

 

To get things moving, could we start by using existing vpp packages in combination with vsap nginx? That would give us time to clarify the two points above and a performance baseline. 

 

Regards,

Florin

 

 

 

On Jun 2, 2020, at 3:43 AM, Yu, Ping <ping.yu@...> wrote:

 

Okay, the idea to build a different name is okay, but we’d like to call it as “VSAP_vpp”.

 

For the reason why some patches could not merged into VPP master branch is that we are now working to make VPP host stack work smoothly in Nginx, and Nginx is a single-thread multiple process application, thus we can remove some “lock” mechanism in VPP to speed up the performance. We also make a group-partition method to speed up the performance in Nginx, but community (florin) think it is not a general solution yet, and we’d like to enhance it, but some customers need this patch to get their Nginx speed up.  

 

 

From: Andrew Yourtchenko (ayourtch) <ayourtch@...> 
Sent: Tuesday, June 2, 2020 5:18 PM
To: Yu, Ping <ping.yu@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hi Ping,

 

On 2 Jun 2020, at 11:05, Yu, Ping <ping.yu@...> wrote:

 

Hi, Andrew

 

You know, VPP has made some changes for DPDK, and not all of the patches are merged into DPDK master branch. It is the same in VSAP.

 

The difference is VPP doesn’t try to upload the patched version of DPDK, does it ?

 

The VPP patch in VSAP is definitely useful, but it is not necessary in VPP master branch due to complicated considerations.

 

Could you try to outline the considerations or give a pointer where I can read up?

 

I also don’t think it is completely reasonable that someone install all fd.io project at once. If someone wants to use VSAP,   some customized VPP is required, just VPP wants to customize DPDK.  

 

Do you add a custom repository for each package that you install on your system ?

 

The solution is not difficult, and just provide repo for each project.

 

Private repos are a workaround to not having a proper packaging. I maintain that having more than one package called “vpp” in the FD.io repo that does slightly different thing is not the right thing to do. 

 

This needs to be discussed at TSC I think. 

 

Till then I would suggest for VSAP to add another patch to VPP which patches the packaging to rename all the “vpp/VPP” references in the packages into “fixmevsap/FIXMEVSAP”. 

 

This way there is no confusion, no need for separate repos and no packaging conflict, the packaging issue is clearly highlighted, and you are not blocked in the interim before the TSC?

 

—a

 

 

Ping

 

From: Andrew Yourtchenko (ayourtch) <ayourtch@...> 
Sent: Monday, June 1, 2020 10:26 PM
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

 

1) it is not completely unreasonable to imagine someone want to install all of the FD.io projects at once, so the process and workflow must allow for that. Debian has thousands of packages maintained by thousands of volunteers in the same repo. 

 

2) having the artifacts with the same name and description but different code is a road to a lot of pain for everyone. If a patch is useful for VPP consumption, it must be in VPP master, and there should be only one version of the master artifacts, then the VSAP should be able to act as a plugin and/or consume VPP as a wholesale dependency.

 

What are the obstacles that prevent that ?

 

--a

 

On 1 Jun 2020, at 15:39, Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...> wrote:

 

> Just like VPP:

 

Currently, it is a "fdio" repository,

projects other than VPP are uploading there too.

 

> In order to avoid confusion, we would like to have a new packagecloud repository.

> VSAP maybe like this:

 

So this is a different pattern,

but I agree it is probably the simplest solution

for allowing different project to upload packages of the same name.

Later you will probably also need /vsap/release repo.

 

Looking at [2], there already are several repositories

unrelated to STREAM variable.

So creating vsap/master could work,

unless packagecloud limits the repository level.

In that case we could create something like vsap-master.

 

The main issue will be in the merge job,

as packagecloud_push.sh directly uses PCIO_CO [3] env var.

You would need to introduce a new environment variable

(to pass "vsap" while keeping STREAM for "master")

and change the logic to insert that everywhere between ${PCIO_CO} and ${STREAM}

(without affecting jobs that do not set the new environment variable).

 

What do you think?

Should we start creating per-project repositories,

or should we keep trying to reuse fdio/master?

I personally prefer per-project repositories,

just so I do not have to investigate console output

of every new project verify/merge job. :)

 

I think it would also help with HICN release frequency,

if users could install VPP from fdio/2005 and HICN from fdio/hicn/master.

 

Vratko.

 

 

From: Jiang, XiaolongX <xiaolongx.jiang@...> 
Sent: Monday, 2020-June-01 09:29
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>
Cc: csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

> When installing the nginx .deb package,

> does it contain statically linked parts of VPP it needs,

> or does a user need to also install the patched vpp .deb packages?

 

The latter.

 

 

> If the latter, how do we distinguish "vanilla" VPP from "vsap" VPP?

 

In order to avoid confusion, we would like to have a new packagecloud repository.

Just like VPP:

 

VSAP maybe like this:

 

 

Best Regards

Xiaolong Jiang

 

From: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...> 
Sent: Friday, May 29, 2020 10:08 PM
To: Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Jiang, XiaolongX <xiaolongx.jiang@...>
Cc: csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Before we enable VSAP merge job,

I would like to understand the build process more.

 

So I looked at verify job console output.

(Link [0] will stop working when Sandbox is cleared over weekend.)

 

Observations (and some comments) first:

 

 > git fetch --tags --progress -- git://10.30.48.3/mirror/vsap refs/heads/master # timeout=10

 

The job was triggered for VSAP master head. Ok.

 

 > git config --get submodule.vpp.url # timeout=10

 

Vpp repository is acts as a submodule for VSAP. Ok.

 

--- building openssl 3.0.0-alpha2 - log: /w/workspace/vsap-verify-master-ubuntu1804-vcl/_build/openssl.build.log

 

Openssl is built, I assume there is a good reason to do that.

 

Applying patch: 0001-3.0.0.patch

patching file src/plugins/crypto_openssl/CMakeLists.txt

 

So VSAP does not use "vanilla" VPP,

but applies some patches.

That is normal during the development,

VSAP working with the patched VPP

acts as a kind of indirect verify job

for upstreaming the patch into VPP repo.

 

dpkg-deb: building package 'vpp' in '../vpp_20.09-rc0~73-ge7df8cbb6~b19_amd64.deb'.

 

Note that packagecloud already contains a vpp ~73 .deb [1],

it comes from VPP merge job.

The dangerous part is that even the ge part is the same,

despite the patches being applied here.

Only the ~b part happens to be different,

but in production also that could happen to be the same.

 

{:timestamp=>"2020-05-29T03:56:39.897262+0000", :message=>"Created package", :path=>"/w/workspace/vsap-verify-master-ubuntu1804-vcl/_install/deb-vcl/nginx_1.14.2-ubuntu18.04_amd64.deb"}

 

I believe this is the main output the VSAP merge job will upload to packagecloud.

 

Now the main question.

 

When installing the nginx .deb package,

does it contain statically linked parts of VPP it needs,

or does a user need to also install the patched vpp .deb packages?

 

If the former, the VSAP build process should make sure

any unneeded .deb files are deleted (or better yet not even created)

before proceeding to packagecloud upload.

 

If the latter, how do we distinguish "vanilla" VPP from "vsap" VPP?

Uploading them to the same packagecloud repository will certainly confuse users.

One possibility is to prepend vsap- prefix to all VPP packages created by VSAP build.

Short term by patching VPP makefiles,

longer-term by upstreaming a Change that takes prefix from an environment variable.

 

Vratko.

 

 

From: csit-dev@... <csit-dev@...> On Behalf Of Pei, Yulong
Sent: Friday, 2020-May-29 08:21
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Jiang, XiaolongX <xiaolongx.jiang@...>
Cc: csit-dev@...; ci-management-dev@...; Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>;maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Forgot to add Ping & Xiaolong in the email To list.

 

From: Pei, Yulong 
Sent: Friday, May 29, 2020 2:19 PM
To: Dave Wallace <dwallacelf@...>
Cc: csit-dev@...; ci-management-dev@...; Vratko Polak <vrpolak@...>; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus <pmikus@...>
Subject: About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hello Dave, 

 

Could you kindly help about how to upload package to packagecloud.io and download package from packagecloud.io ?

 

Currently we are working on to integrate FDIO VSAP project build  to FDIO infrastructure, we can add build job to ci-management, example as below,

 

 

Next step it need to upload the VSAP built packages to packagecloud.io,  I guess that it may need set up a repo for VSAP project in packageclould.io,  right ?

 

And then we also need download VSAP built packages from packagecloud.io for CSIT to run VSAP performance test,  to use which way to get this ?

 

Best Regards

Yulong Pei

 

 

 

 

 


Re: Bumping global-jjb

Andrew Grimberg
 

On 2020-06-11 02:02, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at
Cisco) via lists.fd.io wrote:
Hello.

Is there a document describing the steps needed
to upgrade global-jjb (as a submodule of ci-management git repository)?

Motivation:
"git describe" says we are currently using v0.53.1,
but .2 has a fix [0] we want.
After looking at git history, we probably want .3.

Update:
After reading a random tutorial [1],
I was able to create the Change [2].
But I am still not sure how I would review such a Change from another
contributor.

Vratko.

[0]
https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/release-notes.html#v0-53-2
[1] https://www.vogella.com/tutorials/GitSubmodules/article.html
So... global-jjb upgrades (as well as common-packer upgrades) are rather
interesting and unique since they're submodule updates.

Firstly I as committer expect that the verify jobs pass (which in
general they should) but if there is anything in the release notes that
talk about upgrades then I will generally do the following:

1) make sure I'm on latest HEAD of ci-management with all the submodules
at their proper version
2) run a `jenkins-jobs test -o target/ jjb/` with the current setup
3) pull the change and update the submodules
4) run a `jenkons-jobs test -o target2/ jjb/` with the new setup
5) compare what changed between the job runs using diff

If nothing is really nasty standing out, then I accept the change.

If there is nothing really extraordinary in the release notes that
concerns me I generally just take the update after verifying it really
is pointing at the version it's supposed to ;)

-Andy-

--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation


Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

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

I assume readers are familiar with most of the context

discussed in other communication channels.

If not, I recommend to take a peek at the long discussion

on "fdio-infra" channel of fdio slack,

starting from June 1st.

 

After some thinking, I have realized ci-management

is already conceptually prepared to handle

multiple "areas" of compatibility,

where artifacts within the same area are compatible,

but artifacts from different areas are not compatible.

 

For snapshot artifacts, the compatibility is assumed

only for the latest uploaded versions.

Temporary breakages due to API changes are tolerated.

Because of that, the concept is not named area,

but it is named "stream".

 

It is an abstraction, evolved from the concept of branch name;

needed for integration of sub-projects whose branch names do not match exactly.

(In fd.io ci-management, packagecloud repository name

matches the stream exactly, but it is not a requirement.

For example, when we used Nexus, repository name did not match directly.)

 

Anyway, in this sense, master package repository [0]

is for VPP artifacts built from VPP master branch,

and any other artifacts compatible with (latest version of) them.

VPP code in stable/2005 branch creates snapshot artifacts

uploaded to 2005 package repository [1].

 

If VSAP needs VPP builds different from both master and 2005,

it means new stream needs to be created, for example called "vsap".

VSAP merge job for vsap stream can use VSAP master branch,

and there will be no VSAP merge job for master stream.

 

In future, if VPP project accepts all VSAP-related settings,

(and VPP verify job ensures production APIs are never changed)

the following process can be applied.

A new VSAP branch (called "vsap") is cut from master branch,

and the VSAP merge job for stream vsap starts using that branch.

In VSAP master branch, the build scripts are changed

to no longer build VPP artifacts (maybe download but delete before pushing).

Then a VSAP merge job for stream master is created,

using VSAP master branch, and uploading VSAP (but not VPP) artifacts to [0].

For a period of time, both streams will be tested,

to confirm that VSAP artifacts from stream master

work equally well than VSAP (and VPP) artifacts from stream vsap.

Then, vsap branch can stop being updated and all vsap stream jobs can be deleted.

 

In other words, the "vsap" stream acts as a "feature branch" for VPP project,

except that it is maintained by VSAP (not VPP) developers.

This is more flexible than my previous idea of giving

each sub-project their own packagecloud repository.

Firstly, work can be done on multiple features.

For example streams "vsap_speed" and "vsap_scale" can at first

hardcode a particular "speed versus memory" tradeoffs,

each can be upstreamed to VPP at a different time.

Secondly, when we have more cooperating sub-projects,

they can push their artifacts into the same repository,

so that users (and testers) have easier time installing them.

 

There was some discussion on TSC meeting,

mostly related to hICN sub-project instead.

As usual, I am trying to find a solution suitable for both hICN and VSAP.

For hICN, the stream solution is to mark their merge job

(which uses hICN master branch) as stream 2005.

That assumes 2005 VPP snapshots are stable enough for them.

 

What do you think?

Any important question that does not fit into the stream abstraction?

 

Vratko.

 

[0] https://packagecloud.io/fdio/master

[1] https://packagecloud.io/fdio/2005

 

From: csit-dev@... <csit-dev@...> On Behalf Of Pei, Yulong
Sent: Tuesday, 2020-June-09 11:20
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>; Kinsella, Ray <ray.kinsella@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io
Importance: High

 

Hi Guys,

 

If a packagecloud sandbox is not a good way,  could you kindly help to give suggestion about how to proceed this work ?  Sorry to mark this email with high importance since it is really blocked for a long time.

 

Best Regards

Yulong Pei

 

From: Pei, Yulong
Sent: Monday, June 8, 2020 11:31 AM
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <XiaolongX.Jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [ci-management-dev] [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hi Dave,

 

Thanks for your comments,

 

My answers inline,

 

 

 

From: Dave Wallace <dwallacelf@...>
Sent: Wednesday, June 3, 2020 9:25 PM
To: Pei, Yulong <yulong.pei@...>; Yu, Ping <ping.yu@...>; Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [ci-management-dev] [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hi Yulong,

On 6/3/2020 1:00 AM, Pei, Yulong wrote:

Anyway,  could we have a temporary repo for VSAP at packagecloud?  then Jenkins build and verify job for VSAP work and CSIT test cases for TLS with VSAP work can be proceeded,  they are blocked for a long time 😊,

This is a possibility as long as there are some controls in place to limit access to the repo to CI jobs and/or periodic purging of the repo artifacts.  However, this does come with the cost of overseeing/managing the repo contents so is not the optimal solution IMHO.

[Yulong Pei]  could we regard “temporary repo” as a packagecloude sandbox, just like fdio Jenkins sandbox ? It do not need keep it for a long time.

 

When issue about VSAP specific patch merged to VPP master was fixed,   then we can move VSAP built package to standard repo at packagecloud at that time.

Once code is merged to VPP then it becomes available in the regular VPP packages.  VSAP built packages are temporary thus will never be moved.

However, this model introduces an additional layer of CI jobs to test those features that exist in VPP plus those features that are only supported in the VSAP project packages. 
There are limitations on the availability of CSIT testbeds to cover VPP features.  Therefore duplication test execution against the VSAP artifacts and VPP artifacts is not feasible without additional testbed resources dedicated to the VSAP project.  So this will require movement of test cases from VSAP to VPP which may introduce additional challenges. 

 

[Yulong Pei]  Currently we can limit VSAP test only run on one skx or clx CSIT testbed, trigger one test weekly is enough,  and I think it will deploy more ICELake testbeds in CSIT lab in the future.


Another issue is ongoing trending & failure analysis of the CSIT test results of the VSAP artifacts.  The CSIT & VPP teams work together on identifying & resolving test failures and performance regressions.  Managing all of that for VPP and VSAP is going to be very challenging.  IMHO, it is unrealistic to expect the CSIT & VPP teams to handle VSAP in addition to VPP.  How much additional work this is for CSIT & VSAP is not currently understood.

[Yulong Pei]  Actually  VSAP test  is to show  VPP TLS/tcp performance,  VSAP is only a modified Nginx, it change Nginx socket layer to fit for VPP VCL or LDP,  we may also regard VSAP(Nginx) as a test tool  for VPP TLS/tcp test,

As you know, VPP has a internal http_static server, but if test VPP TLS/tcp with that,  the performance is  bad.  so from test view, VSAP test is VPP test,  not Nginx test.  And Intel team also can help on failure analysis.


Given the number of unknowns in the process and deployment/consumption of resources (both human & automation), I think that it would be best to pick a very small set of tests (maybe as small as 1) as an initial deployment of the project CI pipeline.  Then evaluate/refactor the pipeline before including everything that you have implemented to date.

[Yulong Pei]   I agree that it is better to pick small set of tests as an initial deployment of the project CI pipeline.

 

Best Regards

Yulong Pei


Thanks,
-daw-

 

Best Regards

Yulong Pei

 

From: Yu, Ping <ping.yu@...>
Sent: Wednesday, June 3, 2020 11:04 AM
To: Florin Coras <fcoras.lists@...>; Andrew Yourtchenko (ayourtch) <ayourtch@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>; Yu, Ping <ping.yu@...>; Yu, Ping <ping.yu@...>
Subject: RE: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Yes, for this specific issue, we’d like to move forward, and as a general packaging, there is definitely some code which requires customize VPP. For example, some company wants us to give them the version for CBDMA, and we also consider to release this code to VSAP first.

 

@Andrew Yourtchenko (ayourtch)fixme means there is some problem, but actually it is just not merged to master branch yet. This is quite different hint to users.

 

Ping

 

From: Florin Coras <fcoras.lists@...>
Sent: Wednesday, June 3, 2020 6:57 AM
To: Yu, Ping <ping.yu@...>
Cc: Andrew Yourtchenko (ayourtch) <ayourtch@...>; Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hi Ping, 

 

I guess there are two improvements that have not entirely made their way into vpp:

- Pinning vpp workers to vcl workers. If we have a patch that’s generic enough, we could try merging it into master. 

- A non-locking vls alternative. I believe [1] considerably improved locking performance for multi-process applications. Do we know if vls is still a bottleneck after this? 

 

To get things moving, could we start by using existing vpp packages in combination with vsap nginx? That would give us time to clarify the two points above and a performance baseline. 

 

Regards,

Florin

 

 

 

On Jun 2, 2020, at 3:43 AM, Yu, Ping <ping.yu@...> wrote:

 

Okay, the idea to build a different name is okay, but we’d like to call it as “VSAP_vpp”.

 

For the reason why some patches could not merged into VPP master branch is that we are now working to make VPP host stack work smoothly in Nginx, and Nginx is a single-thread multiple process application, thus we can remove some “lock” mechanism in VPP to speed up the performance. We also make a group-partition method to speed up the performance in Nginx, but community (florin) think it is not a general solution yet, and we’d like to enhance it, but some customers need this patch to get their Nginx speed up.  

 

 

From: Andrew Yourtchenko (ayourtch) <ayourtch@...> 
Sent: Tuesday, June 2, 2020 5:18 PM
To: Yu, Ping <ping.yu@...>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hi Ping,

 

On 2 Jun 2020, at 11:05, Yu, Ping <ping.yu@...> wrote:

 

Hi, Andrew

 

You know, VPP has made some changes for DPDK, and not all of the patches are merged into DPDK master branch. It is the same in VSAP.

 

The difference is VPP doesn’t try to upload the patched version of DPDK, does it ?

 

The VPP patch in VSAP is definitely useful, but it is not necessary in VPP master branch due to complicated considerations.

 

Could you try to outline the considerations or give a pointer where I can read up?

 

I also don’t think it is completely reasonable that someone install all fd.io project at once. If someone wants to use VSAP,   some customized VPP is required, just VPP wants to customize DPDK.  

 

Do you add a custom repository for each package that you install on your system ?

 

The solution is not difficult, and just provide repo for each project.

 

Private repos are a workaround to not having a proper packaging. I maintain that having more than one package called “vpp” in the FD.io repo that does slightly different thing is not the right thing to do. 

 

This needs to be discussed at TSC I think. 

 

Till then I would suggest for VSAP to add another patch to VPP which patches the packaging to rename all the “vpp/VPP” references in the packages into “fixmevsap/FIXMEVSAP”. 

 

This way there is no confusion, no need for separate repos and no packaging conflict, the packaging issue is clearly highlighted, and you are not blocked in the interim before the TSC?

 

—a

 

 

Ping

 

From: Andrew Yourtchenko (ayourtch) <ayourtch@...> 
Sent: Monday, June 1, 2020 10:26 PM
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>
Cc: Jiang, XiaolongX <xiaolongx.jiang@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

 

1) it is not completely unreasonable to imagine someone want to install all of the FD.io projects at once, so the process and workflow must allow for that. Debian has thousands of packages maintained by thousands of volunteers in the same repo. 

 

2) having the artifacts with the same name and description but different code is a road to a lot of pain for everyone. If a patch is useful for VPP consumption, it must be in VPP master, and there should be only one version of the master artifacts, then the VSAP should be able to act as a plugin and/or consume VPP as a wholesale dependency.

 

What are the obstacles that prevent that ?

 

--a



On 1 Jun 2020, at 15:39, Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...> wrote:

 

> Just like VPP:

 

Currently, it is a "fdio" repository,

projects other than VPP are uploading there too.

 

> In order to avoid confusion, we would like to have a new packagecloud repository.

> VSAP maybe like this:

 

So this is a different pattern,

but I agree it is probably the simplest solution

for allowing different project to upload packages of the same name.

Later you will probably also need /vsap/release repo.

 

Looking at [2], there already are several repositories

unrelated to STREAM variable.

So creating vsap/master could work,

unless packagecloud limits the repository level.

In that case we could create something like vsap-master.

 

The main issue will be in the merge job,

as packagecloud_push.sh directly uses PCIO_CO [3] env var.

You would need to introduce a new environment variable

(to pass "vsap" while keeping STREAM for "master")

and change the logic to insert that everywhere between ${PCIO_CO} and ${STREAM}

(without affecting jobs that do not set the new environment variable).

 

What do you think?

Should we start creating per-project repositories,

or should we keep trying to reuse fdio/master?

I personally prefer per-project repositories,

just so I do not have to investigate console output

of every new project verify/merge job. :)

 

I think it would also help with HICN release frequency,

if users could install VPP from fdio/2005 and HICN from fdio/hicn/master.

 

Vratko.

 

 

From: Jiang, XiaolongX <xiaolongx.jiang@...> 
Sent: Monday, 2020-June-01 09:29
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>; Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>
Cc: csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

> When installing the nginx .deb package,

> does it contain statically linked parts of VPP it needs,

> or does a user need to also install the patched vpp .deb packages?

 

The latter.

 

 

> If the latter, how do we distinguish "vanilla" VPP from "vsap" VPP?

 

In order to avoid confusion, we would like to have a new packagecloud repository.

Just like VPP:

 

VSAP maybe like this:

 

 

Best Regards

Xiaolong Jiang

 

From: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...> 
Sent: Friday, May 29, 2020 10:08 PM
To: Pei, Yulong <yulong.pei@...>; Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Jiang, XiaolongX <xiaolongx.jiang@...>
Cc: csit-dev@...; ci-management-dev@...; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: RE: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Before we enable VSAP merge job,

I would like to understand the build process more.

 

So I looked at verify job console output.

(Link [0] will stop working when Sandbox is cleared over weekend.)

 

Observations (and some comments) first:

 

 > git fetch --tags --progress -- git://10.30.48.3/mirror/vsap refs/heads/master # timeout=10

 

The job was triggered for VSAP master head. Ok.

 

 > git config --get submodule.vpp.url # timeout=10

 

Vpp repository is acts as a submodule for VSAP. Ok.

 

--- building openssl 3.0.0-alpha2 - log: /w/workspace/vsap-verify-master-ubuntu1804-vcl/_build/openssl.build.log

 

Openssl is built, I assume there is a good reason to do that.

 

Applying patch: 0001-3.0.0.patch

patching file src/plugins/crypto_openssl/CMakeLists.txt

 

So VSAP does not use "vanilla" VPP,

but applies some patches.

That is normal during the development,

VSAP working with the patched VPP

acts as a kind of indirect verify job

for upstreaming the patch into VPP repo.

 

dpkg-deb: building package 'vpp' in '../vpp_20.09-rc0~73-ge7df8cbb6~b19_amd64.deb'.

 

Note that packagecloud already contains a vpp ~73 .deb [1],

it comes from VPP merge job.

The dangerous part is that even the ge part is the same,

despite the patches being applied here.

Only the ~b part happens to be different,

but in production also that could happen to be the same.

 

{:timestamp=>"2020-05-29T03:56:39.897262+0000", :message=>"Created package", :path=>"/w/workspace/vsap-verify-master-ubuntu1804-vcl/_install/deb-vcl/nginx_1.14.2-ubuntu18.04_amd64.deb"}

 

I believe this is the main output the VSAP merge job will upload to packagecloud.

 

Now the main question.

 

When installing the nginx .deb package,

does it contain statically linked parts of VPP it needs,

or does a user need to also install the patched vpp .deb packages?

 

If the former, the VSAP build process should make sure

any unneeded .deb files are deleted (or better yet not even created)

before proceeding to packagecloud upload.

 

If the latter, how do we distinguish "vanilla" VPP from "vsap" VPP?

Uploading them to the same packagecloud repository will certainly confuse users.

One possibility is to prepend vsap- prefix to all VPP packages created by VSAP build.

Short term by patching VPP makefiles,

longer-term by upstreaming a Change that takes prefix from an environment variable.

 

Vratko.

 

 

From: csit-dev@... <csit-dev@...> On Behalf Of Pei, Yulong
Sent: Friday, 2020-May-29 08:21
To: Dave Wallace <dwallacelf@...>; Yu, Ping <ping.yu@...>; Jiang, XiaolongX <xiaolongx.jiang@...>
Cc: csit-dev@...; ci-management-dev@...; Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpolak@...>;maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus -X (pmikus - PANTHEON TECH SRO at Cisco) <pmikus@...>
Subject: Re: [csit-dev] About how to upload package to packagecloud.io and download package from packagecloud.io

 

Forgot to add Ping & Xiaolong in the email To list.

 

From: Pei, Yulong 
Sent: Friday, May 29, 2020 2:19 PM
To: Dave Wallace <dwallacelf@...>
Cc: csit-dev@...; ci-management-dev@...; Vratko Polak <vrpolak@...>; maciek@...; Kinsella, Ray <ray.kinsella@...>; Peter Mikus <pmikus@...>
Subject: About how to upload package to packagecloud.io and download package from packagecloud.io

 

Hello Dave, 

 

Could you kindly help about how to upload package to packagecloud.io and download package from packagecloud.io ?

 

Currently we are working on to integrate FDIO VSAP project build  to FDIO infrastructure, we can add build job to ci-management, example as below,

 

 

Next step it need to upload the VSAP built packages to packagecloud.io,  I guess that it may need set up a repo for VSAP project in packageclould.io,  right ?

 

And then we also need download VSAP built packages from packagecloud.io for CSIT to run VSAP performance test,  to use which way to get this ?

 

Best Regards

Yulong Pei

 

 

 

 

 

1 - 20 of 218