All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [SPDK] For the Chandler testing pool
@ 2018-11-27  4:21 Harris, James R
  0 siblings, 0 replies; 10+ messages in thread
From: Harris, James R @ 2018-11-27  4:21 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 6187 bytes --]

The Chandler test pool is definitely slower than the Jenkins pool.  Jenkins can do two jobs in parallel (mostly) and will also abort early if a patch fails basic compilation and unit tests.  It seems Jenkins runs about 10 minutes per patch while the Chandler pool is about 15 minutes.  (12 minutes test time plus 3 minutes overhead to copy results, etc.)

I don't see a public version of https://ci.spdk.io/spdk/status/ for the Jenkins test pool though on http://spdk.io/ci.  Is there a public version of that available?  All of the Jenkins data I'm pulling is from the internal (to Intel) version of the status page.

Something that everyone can help with is looking at how to speed up the tests.  Each successful test run includes a flamegraph.  For example:

1) Look at a patch that has run through the test pool.  Here's one from today from the Chandler test pool:  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/.

2) Find which system took the longest to execute.  On the Chandler test pool, this is consistently fedora-03 (12+ minutes).  Since the Chandler CI doesn't run jobs in parallel, you'll only save time by shortening the longest test.  Here's the results for fedora-03 for that patch.  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/.

3) Open the flamegraph (the SVG file).  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/timing.svg

4)  Look where the time is being spent - see for areas that can be optimized, etc.

Thanks,

-Jim





On 11/26/18, 7:14 PM, "SPDK on behalf of Luse, Paul E" <spdk-bounces(a)lists.01.org on behalf of paul.e.luse(a)intel.com> wrote:

    Ok thanks. Agree on the requirement. Let’s figure out how to measure throughout time for you with Jenkins. If that’s still too slow we can expand the pool and/or look at some other options maybe including some local test systems. We need to wrap up the Jenkins tradition first though and your input helps define some real need around getting it done sooner than later so thanks.  
    
    Karol curious for your input on getting publicalky available  throughout times made available. I don’t mean exactly like the ch pool but maybe something on the status page after the test is done that shows submission and completion times
    
    -from my iPhone 
    
    > On Nov 26, 2018, at 7:02 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    > 
    > Hi Paul,
    > 
    > For the wait times in the Jenkins test pool, I cannot have the estimation since currently I cannot see the list of patches and also the execution time statistics. My request is that: Either what kinds of test pool use,  it should be friendly to users.  Since we are in different time zones,  I hope that we will not wait so much time for the results from the test pool in our own time zone, thus it is not efficient. 
    > 
    > Thanks.
    > 
    > 
    > 
    > 
    > Best Regards
    > Ziye Yang 
    > 
    > -----Original Message-----
    > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Luse, Paul E
    > Sent: Tuesday, November 27, 2018 9:56 AM
    > To: Storage Performance Development Kit <spdk(a)lists.01.org>
    > Subject: Re: [SPDK] For the Chandler testing pool
    > 
    > Hi Ziye,
    > 
    > That's a good observation. Can I ask real quick what your wait times typically look like with the Jenkins test pool?
    > 
    > One of the reasons for the transition to Janina is to improve scalability and I'm thinking the way it was implemented throughout time should already be better but I'd like to hear your perspective. 
    > 
    > We are going to retire the chandler pool soon once the final Jenkins issues are worked out. We have not been in a big hurry to make the move though because we don't want to make a mistake and disrupt things for an arbitrary deadline. 
    > 
    > Once this happens though it will be a full replacement. I may not be understanding your question about local testing but for a global fully transparent open community a solid extendible continuous integration system is not optional. Is that what you were asking or were you just wondering why we haven't totally moved to Jenkins yet?
    > 
    > Thx
    > Paul
    > 
    > -from my iPhone 
    > 
    >> On Nov 26, 2018, at 6:43 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    >> 
    >> Hi all,
    >> 
    >> These days, I found that the Chandler testing pool is very busy. When in PRC time zone, there are lots of patches are waiting to be tested. For example today,  from now, I see 27 patches are in the list. According to the testing process, each will waste 12 minutes, it means that the total time will be about 324 minutes,  which means that if you submit a patch this time, you need to wait at least 5.5 hours (after 14:30, you can see the results). Since we are global team, Poland team will nearly start work at 4:00 PM. So it left less time for PRC in the daily time. Usually, I will get the results of my patches after my working time.  So my question is that: Can we reduce this time since currently the testing time is too long?
    >> 
    >> PS: Why we need the Chandler test pool? Since it has different environments, you cannot verify your patch in the single local test environment.
    >> 
    >> Thanks.
    >> 
    >> 
    >> 
    >> 
    >> Best Regards
    >> Ziye Yang
    >> 
    >> _______________________________________________
    >> SPDK mailing list
    >> SPDK(a)lists.01.org
    >> https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    _______________________________________________
    SPDK mailing list
    SPDK(a)lists.01.org
    https://lists.01.org/mailman/listinfo/spdk
    


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [SPDK] For the Chandler testing pool
@ 2018-11-27 11:55 Luse, Paul E
  0 siblings, 0 replies; 10+ messages in thread
From: Luse, Paul E @ 2018-11-27 11:55 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 11601 bytes --]

That would be great Karol!  Yeah, doesn't solve Ziye's concern (bigger topic) of course but is a nice feature for everyone moving forward that can come out of this discussion.

Thx
Paul

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Latecki, Karol
Sent: Tuesday, November 27, 2018 2:15 AM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

Hi everyone!
I went through the conversation and would like to comment on some things.

(Paul)
> Karol curious for your input on getting publically available  
> throughout times made available. I don’t mean exactly like the ch pool 
> but maybe something on the status page after the test is done that 
> shows submission and completion times
I think this could be done. Currently we measure the time of full test run, so how much time has passed since build started on executor and was finished. What you want though, if I understand correctly, is the time between pushing the patch to gerrithub and getting the results, right? So that'd include time spent in queue as well.

(Jim)
> It seems Jenkins runs about 10 minutes per patch while the Chandler pool is about 15 minutes.
I'll be humble here - Jenkins test run takes about 15 minutes, assuming that only 1 build is done at a time. For 2 parallel builds it can take a little more time, and that's because we don't have 1:1 equipment  to run 2 builds fully in parallel (we don't have... yet!).

(Gang, Ziye)
> I think that Jim's suggestion to look at timings is right. We should start by looking through time stats in flamegraph charts and see which tests take the most time. Then we could either optimize the scripts or maybe even move some tests to nightly if it's OK. The number of tests will consistently grow, either by adding new component tests or adding test cases to existing ones, and it affects both CTP and JTP times. Since I've first run Jenkins per-patch job it has increased it's time by a couple of minutes at least.

Other areas to improve execution times include adding more executors in Jenkins. As I mentioned in reply to Jim - that'd include adding more test servers to the pool. More test servers and more VMs = more possible test executors = possibility to run more tests in parallel. This could remove the need to implement the time-zone based prioritization.

Thanks,
Karol

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Cao, Gang
Sent: Tuesday, November 27, 2018 6:06 AM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

This looks like a good idea and seems like easy to implement (or optimize). We can tag each submitter with the information of time zone and when now in that time zone roughly, the patch can be pulled in to test early, if there are other patches from same time zone, just run in order.

Thanks,
Gang

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Yang, Ziye
Sent: Tuesday, November 27, 2018 12:58 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

Hi Jim,

You are right. Every one need to pay attention to optimize the test cases. However, what I said is that there are too many batched patches every day when I see every day in PRC time. It means that those patches are submitted in different time zones. Could we optimize the patch testing progress? If the patch is submitted in a time zone A, it should be tested with low priority in time zone B. With such policy, it should mitigate the issue I mentioned.


Thanks.



Best Regards
Ziye Yang 


-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Harris, James R
Sent: Tuesday, November 27, 2018 12:21 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

The Chandler test pool is definitely slower than the Jenkins pool.  Jenkins can do two jobs in parallel (mostly) and will also abort early if a patch fails basic compilation and unit tests.  It seems Jenkins runs about 10 minutes per patch while the Chandler pool is about 15 minutes.  (12 minutes test time plus 3 minutes overhead to copy results, etc.)

I don't see a public version of https://ci.spdk.io/spdk/status/ for the Jenkins test pool though on http://spdk.io/ci.  Is there a public version of that available?  All of the Jenkins data I'm pulling is from the internal (to Intel) version of the status page.

Something that everyone can help with is looking at how to speed up the tests.  Each successful test run includes a flamegraph.  For example:

1) Look at a patch that has run through the test pool.  Here's one from today from the Chandler test pool:  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/.

2) Find which system took the longest to execute.  On the Chandler test pool, this is consistently fedora-03 (12+ minutes).  Since the Chandler CI doesn't run jobs in parallel, you'll only save time by shortening the longest test.  Here's the results for fedora-03 for that patch.  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/.

3) Open the flamegraph (the SVG file).  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/timing.svg

4)  Look where the time is being spent - see for areas that can be optimized, etc.

Thanks,

-Jim





On 11/26/18, 7:14 PM, "SPDK on behalf of Luse, Paul E" <spdk-bounces(a)lists.01.org on behalf of paul.e.luse(a)intel.com> wrote:

    Ok thanks. Agree on the requirement. Let’s figure out how to measure throughout time for you with Jenkins. If that’s still too slow we can expand the pool and/or look at some other options maybe including some local test systems. We need to wrap up the Jenkins tradition first though and your input helps define some real need around getting it done sooner than later so thanks.  
    
    Karol curious for your input on getting publicalky available  throughout times made available. I don’t mean exactly like the ch pool but maybe something on the status page after the test is done that shows submission and completion times
    
    -from my iPhone 
    
    > On Nov 26, 2018, at 7:02 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    > 
    > Hi Paul,
    > 
    > For the wait times in the Jenkins test pool, I cannot have the estimation since currently I cannot see the list of patches and also the execution time statistics. My request is that: Either what kinds of test pool use,  it should be friendly to users.  Since we are in different time zones,  I hope that we will not wait so much time for the results from the test pool in our own time zone, thus it is not efficient. 
    > 
    > Thanks.
    > 
    > 
    > 
    > 
    > Best Regards
    > Ziye Yang 
    > 
    > -----Original Message-----
    > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Luse, Paul E
    > Sent: Tuesday, November 27, 2018 9:56 AM
    > To: Storage Performance Development Kit <spdk(a)lists.01.org>
    > Subject: Re: [SPDK] For the Chandler testing pool
    > 
    > Hi Ziye,
    > 
    > That's a good observation. Can I ask real quick what your wait times typically look like with the Jenkins test pool?
    > 
    > One of the reasons for the transition to Janina is to improve scalability and I'm thinking the way it was implemented throughout time should already be better but I'd like to hear your perspective. 
    > 
    > We are going to retire the chandler pool soon once the final Jenkins issues are worked out. We have not been in a big hurry to make the move though because we don't want to make a mistake and disrupt things for an arbitrary deadline. 
    > 
    > Once this happens though it will be a full replacement. I may not be understanding your question about local testing but for a global fully transparent open community a solid extendible continuous integration system is not optional. Is that what you were asking or were you just wondering why we haven't totally moved to Jenkins yet?
    > 
    > Thx
    > Paul
    > 
    > -from my iPhone 
    > 
    >> On Nov 26, 2018, at 6:43 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    >> 
    >> Hi all,
    >> 
    >> These days, I found that the Chandler testing pool is very busy. When in PRC time zone, there are lots of patches are waiting to be tested. For example today,  from now, I see 27 patches are in the list. According to the testing process, each will waste 12 minutes, it means that the total time will be about 324 minutes,  which means that if you submit a patch this time, you need to wait at least 5.5 hours (after 14:30, you can see the results). Since we are global team, Poland team will nearly start work at 4:00 PM. So it left less time for PRC in the daily time. Usually, I will get the results of my patches after my working time.  So my question is that: Can we reduce this time since currently the testing time is too long?
    >> 
    >> PS: Why we need the Chandler test pool? Since it has different environments, you cannot verify your patch in the single local test environment.
    >> 
    >> Thanks.
    >> 
    >> 
    >> 
    >> 
    >> Best Regards
    >> Ziye Yang
    >> 
    >> _______________________________________________
    >> SPDK mailing list
    >> SPDK(a)lists.01.org
    >> https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    _______________________________________________
    SPDK mailing list
    SPDK(a)lists.01.org
    https://lists.01.org/mailman/listinfo/spdk
    

_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [SPDK] For the Chandler testing pool
@ 2018-11-27 11:47 Luse, Paul E
  0 siblings, 0 replies; 10+ messages in thread
From: Luse, Paul E @ 2018-11-27 11:47 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 6738 bytes --]

Good point on test times.  FYI I wrote a blog post last year detailing.. The steps Jim mentions below

https://spdk.io/news/2018/02/07/test-timing/  

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Harris, James R
Sent: Monday, November 26, 2018 9:21 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

The Chandler test pool is definitely slower than the Jenkins pool.  Jenkins can do two jobs in parallel (mostly) and will also abort early if a patch fails basic compilation and unit tests.  It seems Jenkins runs about 10 minutes per patch while the Chandler pool is about 15 minutes.  (12 minutes test time plus 3 minutes overhead to copy results, etc.)

I don't see a public version of https://ci.spdk.io/spdk/status/ for the Jenkins test pool though on http://spdk.io/ci.  Is there a public version of that available?  All of the Jenkins data I'm pulling is from the internal (to Intel) version of the status page.

Something that everyone can help with is looking at how to speed up the tests.  Each successful test run includes a flamegraph.  For example:

1) Look at a patch that has run through the test pool.  Here's one from today from the Chandler test pool:  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/.

2) Find which system took the longest to execute.  On the Chandler test pool, this is consistently fedora-03 (12+ minutes).  Since the Chandler CI doesn't run jobs in parallel, you'll only save time by shortening the longest test.  Here's the results for fedora-03 for that patch.  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/.

3) Open the flamegraph (the SVG file).  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/timing.svg

4)  Look where the time is being spent - see for areas that can be optimized, etc.

Thanks,

-Jim





On 11/26/18, 7:14 PM, "SPDK on behalf of Luse, Paul E" <spdk-bounces(a)lists.01.org on behalf of paul.e.luse(a)intel.com> wrote:

    Ok thanks. Agree on the requirement. Let’s figure out how to measure throughout time for you with Jenkins. If that’s still too slow we can expand the pool and/or look at some other options maybe including some local test systems. We need to wrap up the Jenkins tradition first though and your input helps define some real need around getting it done sooner than later so thanks.  
    
    Karol curious for your input on getting publicalky available  throughout times made available. I don’t mean exactly like the ch pool but maybe something on the status page after the test is done that shows submission and completion times
    
    -from my iPhone 
    
    > On Nov 26, 2018, at 7:02 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    > 
    > Hi Paul,
    > 
    > For the wait times in the Jenkins test pool, I cannot have the estimation since currently I cannot see the list of patches and also the execution time statistics. My request is that: Either what kinds of test pool use,  it should be friendly to users.  Since we are in different time zones,  I hope that we will not wait so much time for the results from the test pool in our own time zone, thus it is not efficient. 
    > 
    > Thanks.
    > 
    > 
    > 
    > 
    > Best Regards
    > Ziye Yang 
    > 
    > -----Original Message-----
    > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Luse, Paul E
    > Sent: Tuesday, November 27, 2018 9:56 AM
    > To: Storage Performance Development Kit <spdk(a)lists.01.org>
    > Subject: Re: [SPDK] For the Chandler testing pool
    > 
    > Hi Ziye,
    > 
    > That's a good observation. Can I ask real quick what your wait times typically look like with the Jenkins test pool?
    > 
    > One of the reasons for the transition to Janina is to improve scalability and I'm thinking the way it was implemented throughout time should already be better but I'd like to hear your perspective. 
    > 
    > We are going to retire the chandler pool soon once the final Jenkins issues are worked out. We have not been in a big hurry to make the move though because we don't want to make a mistake and disrupt things for an arbitrary deadline. 
    > 
    > Once this happens though it will be a full replacement. I may not be understanding your question about local testing but for a global fully transparent open community a solid extendible continuous integration system is not optional. Is that what you were asking or were you just wondering why we haven't totally moved to Jenkins yet?
    > 
    > Thx
    > Paul
    > 
    > -from my iPhone 
    > 
    >> On Nov 26, 2018, at 6:43 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    >> 
    >> Hi all,
    >> 
    >> These days, I found that the Chandler testing pool is very busy. When in PRC time zone, there are lots of patches are waiting to be tested. For example today,  from now, I see 27 patches are in the list. According to the testing process, each will waste 12 minutes, it means that the total time will be about 324 minutes,  which means that if you submit a patch this time, you need to wait at least 5.5 hours (after 14:30, you can see the results). Since we are global team, Poland team will nearly start work at 4:00 PM. So it left less time for PRC in the daily time. Usually, I will get the results of my patches after my working time.  So my question is that: Can we reduce this time since currently the testing time is too long?
    >> 
    >> PS: Why we need the Chandler test pool? Since it has different environments, you cannot verify your patch in the single local test environment.
    >> 
    >> Thanks.
    >> 
    >> 
    >> 
    >> 
    >> Best Regards
    >> Ziye Yang
    >> 
    >> _______________________________________________
    >> SPDK mailing list
    >> SPDK(a)lists.01.org
    >> https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    _______________________________________________
    SPDK mailing list
    SPDK(a)lists.01.org
    https://lists.01.org/mailman/listinfo/spdk
    

_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [SPDK] For the Chandler testing pool
@ 2018-11-27  9:15 Latecki, Karol
  0 siblings, 0 replies; 10+ messages in thread
From: Latecki, Karol @ 2018-11-27  9:15 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 11003 bytes --]

Hi everyone!
I went through the conversation and would like to comment on some things.

(Paul)
> Karol curious for your input on getting publically available  throughout times made available. I don’t mean exactly like the ch pool but maybe something on the status page after the test is done that shows submission and completion times
I think this could be done. Currently we measure the time of full test run, so how much time has passed since build started on executor and was finished. What you want though, if I understand correctly, is the time between pushing the patch to gerrithub and getting the results, right? So that'd include time spent in queue as well.

(Jim)
> It seems Jenkins runs about 10 minutes per patch while the Chandler pool is about 15 minutes.
I'll be humble here - Jenkins test run takes about 15 minutes, assuming that only 1 build is done at a time. For 2 parallel builds it can take a little more time, and that's because we don't have 1:1 equipment  to run 2 builds fully in parallel (we don't have... yet!).

(Gang, Ziye)
> I think that Jim's suggestion to look at timings is right. We should start by looking through time stats in flamegraph charts and see which tests take the most time. Then we could either optimize the scripts or maybe even move some tests to nightly if it's OK. The number of tests will consistently grow, either by adding new component tests or adding test cases to existing ones, and it affects both CTP and JTP times. Since I've first run Jenkins per-patch job it has increased it's time by a couple of minutes at least.

Other areas to improve execution times include adding more executors in Jenkins. As I mentioned in reply to Jim - that'd include adding more test servers to the pool. More test servers and more VMs = more possible test executors = possibility to run more tests in parallel. This could remove the need to implement the time-zone based prioritization.

Thanks,
Karol

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Cao, Gang
Sent: Tuesday, November 27, 2018 6:06 AM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

This looks like a good idea and seems like easy to implement (or optimize). We can tag each submitter with the information of time zone and when now in that time zone roughly, the patch can be pulled in to test early, if there are other patches from same time zone, just run in order.

Thanks,
Gang

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Yang, Ziye
Sent: Tuesday, November 27, 2018 12:58 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

Hi Jim,

You are right. Every one need to pay attention to optimize the test cases. However, what I said is that there are too many batched patches every day when I see every day in PRC time. It means that those patches are submitted in different time zones. Could we optimize the patch testing progress? If the patch is submitted in a time zone A, it should be tested with low priority in time zone B. With such policy, it should mitigate the issue I mentioned.


Thanks.



Best Regards
Ziye Yang 


-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Harris, James R
Sent: Tuesday, November 27, 2018 12:21 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

The Chandler test pool is definitely slower than the Jenkins pool.  Jenkins can do two jobs in parallel (mostly) and will also abort early if a patch fails basic compilation and unit tests.  It seems Jenkins runs about 10 minutes per patch while the Chandler pool is about 15 minutes.  (12 minutes test time plus 3 minutes overhead to copy results, etc.)

I don't see a public version of https://ci.spdk.io/spdk/status/ for the Jenkins test pool though on http://spdk.io/ci.  Is there a public version of that available?  All of the Jenkins data I'm pulling is from the internal (to Intel) version of the status page.

Something that everyone can help with is looking at how to speed up the tests.  Each successful test run includes a flamegraph.  For example:

1) Look at a patch that has run through the test pool.  Here's one from today from the Chandler test pool:  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/.

2) Find which system took the longest to execute.  On the Chandler test pool, this is consistently fedora-03 (12+ minutes).  Since the Chandler CI doesn't run jobs in parallel, you'll only save time by shortening the longest test.  Here's the results for fedora-03 for that patch.  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/.

3) Open the flamegraph (the SVG file).  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/timing.svg

4)  Look where the time is being spent - see for areas that can be optimized, etc.

Thanks,

-Jim





On 11/26/18, 7:14 PM, "SPDK on behalf of Luse, Paul E" <spdk-bounces(a)lists.01.org on behalf of paul.e.luse(a)intel.com> wrote:

    Ok thanks. Agree on the requirement. Let’s figure out how to measure throughout time for you with Jenkins. If that’s still too slow we can expand the pool and/or look at some other options maybe including some local test systems. We need to wrap up the Jenkins tradition first though and your input helps define some real need around getting it done sooner than later so thanks.  
    
    Karol curious for your input on getting publicalky available  throughout times made available. I don’t mean exactly like the ch pool but maybe something on the status page after the test is done that shows submission and completion times
    
    -from my iPhone 
    
    > On Nov 26, 2018, at 7:02 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    > 
    > Hi Paul,
    > 
    > For the wait times in the Jenkins test pool, I cannot have the estimation since currently I cannot see the list of patches and also the execution time statistics. My request is that: Either what kinds of test pool use,  it should be friendly to users.  Since we are in different time zones,  I hope that we will not wait so much time for the results from the test pool in our own time zone, thus it is not efficient. 
    > 
    > Thanks.
    > 
    > 
    > 
    > 
    > Best Regards
    > Ziye Yang 
    > 
    > -----Original Message-----
    > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Luse, Paul E
    > Sent: Tuesday, November 27, 2018 9:56 AM
    > To: Storage Performance Development Kit <spdk(a)lists.01.org>
    > Subject: Re: [SPDK] For the Chandler testing pool
    > 
    > Hi Ziye,
    > 
    > That's a good observation. Can I ask real quick what your wait times typically look like with the Jenkins test pool?
    > 
    > One of the reasons for the transition to Janina is to improve scalability and I'm thinking the way it was implemented throughout time should already be better but I'd like to hear your perspective. 
    > 
    > We are going to retire the chandler pool soon once the final Jenkins issues are worked out. We have not been in a big hurry to make the move though because we don't want to make a mistake and disrupt things for an arbitrary deadline. 
    > 
    > Once this happens though it will be a full replacement. I may not be understanding your question about local testing but for a global fully transparent open community a solid extendible continuous integration system is not optional. Is that what you were asking or were you just wondering why we haven't totally moved to Jenkins yet?
    > 
    > Thx
    > Paul
    > 
    > -from my iPhone 
    > 
    >> On Nov 26, 2018, at 6:43 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    >> 
    >> Hi all,
    >> 
    >> These days, I found that the Chandler testing pool is very busy. When in PRC time zone, there are lots of patches are waiting to be tested. For example today,  from now, I see 27 patches are in the list. According to the testing process, each will waste 12 minutes, it means that the total time will be about 324 minutes,  which means that if you submit a patch this time, you need to wait at least 5.5 hours (after 14:30, you can see the results). Since we are global team, Poland team will nearly start work at 4:00 PM. So it left less time for PRC in the daily time. Usually, I will get the results of my patches after my working time.  So my question is that: Can we reduce this time since currently the testing time is too long?
    >> 
    >> PS: Why we need the Chandler test pool? Since it has different environments, you cannot verify your patch in the single local test environment.
    >> 
    >> Thanks.
    >> 
    >> 
    >> 
    >> 
    >> Best Regards
    >> Ziye Yang
    >> 
    >> _______________________________________________
    >> SPDK mailing list
    >> SPDK(a)lists.01.org
    >> https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    _______________________________________________
    SPDK mailing list
    SPDK(a)lists.01.org
    https://lists.01.org/mailman/listinfo/spdk
    

_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [SPDK] For the Chandler testing pool
@ 2018-11-27  5:06 Cao, Gang
  0 siblings, 0 replies; 10+ messages in thread
From: Cao, Gang @ 2018-11-27  5:06 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 7798 bytes --]

This looks like a good idea and seems like easy to implement (or optimize). We can tag each submitter with the information of time zone and when now in that time zone roughly, the patch can be pulled in to test early, if there are other patches from same time zone, just run in order.

Thanks,
Gang

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Yang, Ziye
Sent: Tuesday, November 27, 2018 12:58 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

Hi Jim,

You are right. Every one need to pay attention to optimize the test cases. However, what I said is that there are too many batched patches every day when I see every day in PRC time. It means that those patches are submitted in different time zones. Could we optimize the patch testing progress? If the patch is submitted in a time zone A, it should be tested with low priority in time zone B. With such policy, it should mitigate the issue I mentioned.


Thanks.



Best Regards
Ziye Yang 


-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Harris, James R
Sent: Tuesday, November 27, 2018 12:21 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

The Chandler test pool is definitely slower than the Jenkins pool.  Jenkins can do two jobs in parallel (mostly) and will also abort early if a patch fails basic compilation and unit tests.  It seems Jenkins runs about 10 minutes per patch while the Chandler pool is about 15 minutes.  (12 minutes test time plus 3 minutes overhead to copy results, etc.)

I don't see a public version of https://ci.spdk.io/spdk/status/ for the Jenkins test pool though on http://spdk.io/ci.  Is there a public version of that available?  All of the Jenkins data I'm pulling is from the internal (to Intel) version of the status page.

Something that everyone can help with is looking at how to speed up the tests.  Each successful test run includes a flamegraph.  For example:

1) Look at a patch that has run through the test pool.  Here's one from today from the Chandler test pool:  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/.

2) Find which system took the longest to execute.  On the Chandler test pool, this is consistently fedora-03 (12+ minutes).  Since the Chandler CI doesn't run jobs in parallel, you'll only save time by shortening the longest test.  Here's the results for fedora-03 for that patch.  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/.

3) Open the flamegraph (the SVG file).  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/timing.svg

4)  Look where the time is being spent - see for areas that can be optimized, etc.

Thanks,

-Jim





On 11/26/18, 7:14 PM, "SPDK on behalf of Luse, Paul E" <spdk-bounces(a)lists.01.org on behalf of paul.e.luse(a)intel.com> wrote:

    Ok thanks. Agree on the requirement. Let’s figure out how to measure throughout time for you with Jenkins. If that’s still too slow we can expand the pool and/or look at some other options maybe including some local test systems. We need to wrap up the Jenkins tradition first though and your input helps define some real need around getting it done sooner than later so thanks.  
    
    Karol curious for your input on getting publicalky available  throughout times made available. I don’t mean exactly like the ch pool but maybe something on the status page after the test is done that shows submission and completion times
    
    -from my iPhone 
    
    > On Nov 26, 2018, at 7:02 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    > 
    > Hi Paul,
    > 
    > For the wait times in the Jenkins test pool, I cannot have the estimation since currently I cannot see the list of patches and also the execution time statistics. My request is that: Either what kinds of test pool use,  it should be friendly to users.  Since we are in different time zones,  I hope that we will not wait so much time for the results from the test pool in our own time zone, thus it is not efficient. 
    > 
    > Thanks.
    > 
    > 
    > 
    > 
    > Best Regards
    > Ziye Yang 
    > 
    > -----Original Message-----
    > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Luse, Paul E
    > Sent: Tuesday, November 27, 2018 9:56 AM
    > To: Storage Performance Development Kit <spdk(a)lists.01.org>
    > Subject: Re: [SPDK] For the Chandler testing pool
    > 
    > Hi Ziye,
    > 
    > That's a good observation. Can I ask real quick what your wait times typically look like with the Jenkins test pool?
    > 
    > One of the reasons for the transition to Janina is to improve scalability and I'm thinking the way it was implemented throughout time should already be better but I'd like to hear your perspective. 
    > 
    > We are going to retire the chandler pool soon once the final Jenkins issues are worked out. We have not been in a big hurry to make the move though because we don't want to make a mistake and disrupt things for an arbitrary deadline. 
    > 
    > Once this happens though it will be a full replacement. I may not be understanding your question about local testing but for a global fully transparent open community a solid extendible continuous integration system is not optional. Is that what you were asking or were you just wondering why we haven't totally moved to Jenkins yet?
    > 
    > Thx
    > Paul
    > 
    > -from my iPhone 
    > 
    >> On Nov 26, 2018, at 6:43 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    >> 
    >> Hi all,
    >> 
    >> These days, I found that the Chandler testing pool is very busy. When in PRC time zone, there are lots of patches are waiting to be tested. For example today,  from now, I see 27 patches are in the list. According to the testing process, each will waste 12 minutes, it means that the total time will be about 324 minutes,  which means that if you submit a patch this time, you need to wait at least 5.5 hours (after 14:30, you can see the results). Since we are global team, Poland team will nearly start work at 4:00 PM. So it left less time for PRC in the daily time. Usually, I will get the results of my patches after my working time.  So my question is that: Can we reduce this time since currently the testing time is too long?
    >> 
    >> PS: Why we need the Chandler test pool? Since it has different environments, you cannot verify your patch in the single local test environment.
    >> 
    >> Thanks.
    >> 
    >> 
    >> 
    >> 
    >> Best Regards
    >> Ziye Yang
    >> 
    >> _______________________________________________
    >> SPDK mailing list
    >> SPDK(a)lists.01.org
    >> https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    _______________________________________________
    SPDK mailing list
    SPDK(a)lists.01.org
    https://lists.01.org/mailman/listinfo/spdk
    

_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [SPDK] For the Chandler testing pool
@ 2018-11-27  4:57 Yang, Ziye
  0 siblings, 0 replies; 10+ messages in thread
From: Yang, Ziye @ 2018-11-27  4:57 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 7100 bytes --]

Hi Jim,

You are right. Every one need to pay attention to optimize the test cases. However, what I said is that there are too many batched patches every day when I see every day in PRC time. It means that those patches are submitted in different time zones. Could we optimize the patch testing progress? If the patch is submitted in a time zone A, it should be tested with low priority in time zone B. With such policy, it should mitigate the issue I mentioned.


Thanks.



Best Regards
Ziye Yang 


-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Harris, James R
Sent: Tuesday, November 27, 2018 12:21 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

The Chandler test pool is definitely slower than the Jenkins pool.  Jenkins can do two jobs in parallel (mostly) and will also abort early if a patch fails basic compilation and unit tests.  It seems Jenkins runs about 10 minutes per patch while the Chandler pool is about 15 minutes.  (12 minutes test time plus 3 minutes overhead to copy results, etc.)

I don't see a public version of https://ci.spdk.io/spdk/status/ for the Jenkins test pool though on http://spdk.io/ci.  Is there a public version of that available?  All of the Jenkins data I'm pulling is from the internal (to Intel) version of the status page.

Something that everyone can help with is looking at how to speed up the tests.  Each successful test run includes a flamegraph.  For example:

1) Look at a patch that has run through the test pool.  Here's one from today from the Chandler test pool:  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/.

2) Find which system took the longest to execute.  On the Chandler test pool, this is consistently fedora-03 (12+ minutes).  Since the Chandler CI doesn't run jobs in parallel, you'll only save time by shortening the longest test.  Here's the results for fedora-03 for that patch.  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/.

3) Open the flamegraph (the SVG file).  http://spdk.intel.com/public/spdk/builds/review/171498ede29337a2fd52ad13c6ff613cff3bf13b.1543288927/fedora-03/timing.svg

4)  Look where the time is being spent - see for areas that can be optimized, etc.

Thanks,

-Jim





On 11/26/18, 7:14 PM, "SPDK on behalf of Luse, Paul E" <spdk-bounces(a)lists.01.org on behalf of paul.e.luse(a)intel.com> wrote:

    Ok thanks. Agree on the requirement. Let’s figure out how to measure throughout time for you with Jenkins. If that’s still too slow we can expand the pool and/or look at some other options maybe including some local test systems. We need to wrap up the Jenkins tradition first though and your input helps define some real need around getting it done sooner than later so thanks.  
    
    Karol curious for your input on getting publicalky available  throughout times made available. I don’t mean exactly like the ch pool but maybe something on the status page after the test is done that shows submission and completion times
    
    -from my iPhone 
    
    > On Nov 26, 2018, at 7:02 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    > 
    > Hi Paul,
    > 
    > For the wait times in the Jenkins test pool, I cannot have the estimation since currently I cannot see the list of patches and also the execution time statistics. My request is that: Either what kinds of test pool use,  it should be friendly to users.  Since we are in different time zones,  I hope that we will not wait so much time for the results from the test pool in our own time zone, thus it is not efficient. 
    > 
    > Thanks.
    > 
    > 
    > 
    > 
    > Best Regards
    > Ziye Yang 
    > 
    > -----Original Message-----
    > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Luse, Paul E
    > Sent: Tuesday, November 27, 2018 9:56 AM
    > To: Storage Performance Development Kit <spdk(a)lists.01.org>
    > Subject: Re: [SPDK] For the Chandler testing pool
    > 
    > Hi Ziye,
    > 
    > That's a good observation. Can I ask real quick what your wait times typically look like with the Jenkins test pool?
    > 
    > One of the reasons for the transition to Janina is to improve scalability and I'm thinking the way it was implemented throughout time should already be better but I'd like to hear your perspective. 
    > 
    > We are going to retire the chandler pool soon once the final Jenkins issues are worked out. We have not been in a big hurry to make the move though because we don't want to make a mistake and disrupt things for an arbitrary deadline. 
    > 
    > Once this happens though it will be a full replacement. I may not be understanding your question about local testing but for a global fully transparent open community a solid extendible continuous integration system is not optional. Is that what you were asking or were you just wondering why we haven't totally moved to Jenkins yet?
    > 
    > Thx
    > Paul
    > 
    > -from my iPhone 
    > 
    >> On Nov 26, 2018, at 6:43 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
    >> 
    >> Hi all,
    >> 
    >> These days, I found that the Chandler testing pool is very busy. When in PRC time zone, there are lots of patches are waiting to be tested. For example today,  from now, I see 27 patches are in the list. According to the testing process, each will waste 12 minutes, it means that the total time will be about 324 minutes,  which means that if you submit a patch this time, you need to wait at least 5.5 hours (after 14:30, you can see the results). Since we are global team, Poland team will nearly start work at 4:00 PM. So it left less time for PRC in the daily time. Usually, I will get the results of my patches after my working time.  So my question is that: Can we reduce this time since currently the testing time is too long?
    >> 
    >> PS: Why we need the Chandler test pool? Since it has different environments, you cannot verify your patch in the single local test environment.
    >> 
    >> Thanks.
    >> 
    >> 
    >> 
    >> 
    >> Best Regards
    >> Ziye Yang
    >> 
    >> _______________________________________________
    >> SPDK mailing list
    >> SPDK(a)lists.01.org
    >> https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    > _______________________________________________
    > SPDK mailing list
    > SPDK(a)lists.01.org
    > https://lists.01.org/mailman/listinfo/spdk
    _______________________________________________
    SPDK mailing list
    SPDK(a)lists.01.org
    https://lists.01.org/mailman/listinfo/spdk
    

_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [SPDK] For the Chandler testing pool
@ 2018-11-27  2:14 Luse, Paul E
  0 siblings, 0 replies; 10+ messages in thread
From: Luse, Paul E @ 2018-11-27  2:14 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 3964 bytes --]

Ok thanks. Agree on the requirement. Let’s figure out how to measure throughout time for you with Jenkins. If that’s still too slow we can expand the pool and/or look at some other options maybe including some local test systems. We need to wrap up the Jenkins tradition first though and your input helps define some real need around getting it done sooner than later so thanks.  

Karol curious for your input on getting publicalky available  throughout times made available. I don’t mean exactly like the ch pool but maybe something on the status page after the test is done that shows submission and completion times

-from my iPhone 

> On Nov 26, 2018, at 7:02 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
> 
> Hi Paul,
> 
> For the wait times in the Jenkins test pool, I cannot have the estimation since currently I cannot see the list of patches and also the execution time statistics. My request is that: Either what kinds of test pool use,  it should be friendly to users.  Since we are in different time zones,  I hope that we will not wait so much time for the results from the test pool in our own time zone, thus it is not efficient. 
> 
> Thanks.
> 
> 
> 
> 
> Best Regards
> Ziye Yang 
> 
> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Luse, Paul E
> Sent: Tuesday, November 27, 2018 9:56 AM
> To: Storage Performance Development Kit <spdk(a)lists.01.org>
> Subject: Re: [SPDK] For the Chandler testing pool
> 
> Hi Ziye,
> 
> That's a good observation. Can I ask real quick what your wait times typically look like with the Jenkins test pool?
> 
> One of the reasons for the transition to Janina is to improve scalability and I'm thinking the way it was implemented throughout time should already be better but I'd like to hear your perspective. 
> 
> We are going to retire the chandler pool soon once the final Jenkins issues are worked out. We have not been in a big hurry to make the move though because we don't want to make a mistake and disrupt things for an arbitrary deadline. 
> 
> Once this happens though it will be a full replacement. I may not be understanding your question about local testing but for a global fully transparent open community a solid extendible continuous integration system is not optional. Is that what you were asking or were you just wondering why we haven't totally moved to Jenkins yet?
> 
> Thx
> Paul
> 
> -from my iPhone 
> 
>> On Nov 26, 2018, at 6:43 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
>> 
>> Hi all,
>> 
>> These days, I found that the Chandler testing pool is very busy. When in PRC time zone, there are lots of patches are waiting to be tested. For example today,  from now, I see 27 patches are in the list. According to the testing process, each will waste 12 minutes, it means that the total time will be about 324 minutes,  which means that if you submit a patch this time, you need to wait at least 5.5 hours (after 14:30, you can see the results). Since we are global team, Poland team will nearly start work at 4:00 PM. So it left less time for PRC in the daily time. Usually, I will get the results of my patches after my working time.  So my question is that: Can we reduce this time since currently the testing time is too long?
>> 
>> PS: Why we need the Chandler test pool? Since it has different environments, you cannot verify your patch in the single local test environment.
>> 
>> Thanks.
>> 
>> 
>> 
>> 
>> Best Regards
>> Ziye Yang
>> 
>> _______________________________________________
>> SPDK mailing list
>> SPDK(a)lists.01.org
>> https://lists.01.org/mailman/listinfo/spdk
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [SPDK] For the Chandler testing pool
@ 2018-11-27  2:01 Yang, Ziye
  0 siblings, 0 replies; 10+ messages in thread
From: Yang, Ziye @ 2018-11-27  2:01 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]

Hi Paul,

For the wait times in the Jenkins test pool, I cannot have the estimation since currently I cannot see the list of patches and also the execution time statistics. My request is that: Either what kinds of test pool use,  it should be friendly to users.  Since we are in different time zones,  I hope that we will not wait so much time for the results from the test pool in our own time zone, thus it is not efficient. 

Thanks.




Best Regards
Ziye Yang 

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Luse, Paul E
Sent: Tuesday, November 27, 2018 9:56 AM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] For the Chandler testing pool

Hi Ziye,

That's a good observation. Can I ask real quick what your wait times typically look like with the Jenkins test pool?

One of the reasons for the transition to Janina is to improve scalability and I'm thinking the way it was implemented throughout time should already be better but I'd like to hear your perspective. 

We are going to retire the chandler pool soon once the final Jenkins issues are worked out. We have not been in a big hurry to make the move though because we don't want to make a mistake and disrupt things for an arbitrary deadline. 

Once this happens though it will be a full replacement. I may not be understanding your question about local testing but for a global fully transparent open community a solid extendible continuous integration system is not optional. Is that what you were asking or were you just wondering why we haven't totally moved to Jenkins yet?

Thx
Paul

-from my iPhone 

> On Nov 26, 2018, at 6:43 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
> 
> Hi all,
> 
> These days, I found that the Chandler testing pool is very busy. When in PRC time zone, there are lots of patches are waiting to be tested. For example today,  from now, I see 27 patches are in the list. According to the testing process, each will waste 12 minutes, it means that the total time will be about 324 minutes,  which means that if you submit a patch this time, you need to wait at least 5.5 hours (after 14:30, you can see the results). Since we are global team, Poland team will nearly start work at 4:00 PM. So it left less time for PRC in the daily time. Usually, I will get the results of my patches after my working time.  So my question is that: Can we reduce this time since currently the testing time is too long?
> 
> PS: Why we need the Chandler test pool? Since it has different environments, you cannot verify your patch in the single local test environment.
> 
> Thanks.
> 
> 
> 
> 
> Best Regards
> Ziye Yang
> 
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [SPDK] For the Chandler testing pool
@ 2018-11-27  1:56 Luse, Paul E
  0 siblings, 0 replies; 10+ messages in thread
From: Luse, Paul E @ 2018-11-27  1:56 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

Hi Ziye,

That’s a good observation. Can I ask real quick what your wait times typically look like with the Jenkins test pool?

One of the reasons for the transition to Janina is to improve scalability and I’m thinking the way it was implemented throughout time should already be better but I’d like to hear your perspective. 

We are going to retire the chandler pool soon once the final Jenkins issues are worked out. We have not been in a big hurry to make the move though because we don’t want to make a mistake and disrupt things for an arbitrary deadline. 

Once this happens though it will be a full replacement. I may not be understanding your question about local testing but for a global fully transparent open community a solid extendible continuous integration system is not optional. Is that what you were asking or were you just wondering why we haven’t totally moved to Jenkins yet?

Thx
Paul

-from my iPhone 

> On Nov 26, 2018, at 6:43 PM, Yang, Ziye <ziye.yang(a)intel.com> wrote:
> 
> Hi all,
> 
> These days, I found that the Chandler testing pool is very busy. When in PRC time zone, there are lots of patches are waiting to be tested. For example today,  from now, I see 27 patches are in the list. According to the testing process, each will waste 12 minutes, it means that the total time will be about 324 minutes,  which means that if you submit a patch this time, you need to wait at least 5.5 hours (after 14:30, you can see the results). Since we are global team, Poland team will nearly start work at 4:00 PM. So it left less time for PRC in the daily time. Usually, I will get the results of my patches after my working time.  So my question is that: Can we reduce this time since currently the testing time is too long?
> 
> PS: Why we need the Chandler test pool? Since it has different environments, you cannot verify your patch in the single local test environment.
> 
> Thanks.
> 
> 
> 
> 
> Best Regards
> Ziye Yang
> 
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [SPDK] For the Chandler testing pool
@ 2018-11-27  1:43 Yang, Ziye
  0 siblings, 0 replies; 10+ messages in thread
From: Yang, Ziye @ 2018-11-27  1:43 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

Hi all,

These days, I found that the Chandler testing pool is very busy. When in PRC time zone, there are lots of patches are waiting to be tested. For example today,  from now, I see 27 patches are in the list. According to the testing process, each will waste 12 minutes, it means that the total time will be about 324 minutes,  which means that if you submit a patch this time, you need to wait at least 5.5 hours (after 14:30, you can see the results). Since we are global team, Poland team will nearly start work at 4:00 PM. So it left less time for PRC in the daily time. Usually, I will get the results of my patches after my working time.  So my question is that: Can we reduce this time since currently the testing time is too long?

PS: Why we need the Chandler test pool? Since it has different environments, you cannot verify your patch in the single local test environment.

Thanks.




Best Regards
Ziye Yang


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2018-11-27 11:55 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-27  4:21 [SPDK] For the Chandler testing pool Harris, James R
  -- strict thread matches above, loose matches on Subject: below --
2018-11-27 11:55 Luse, Paul E
2018-11-27 11:47 Luse, Paul E
2018-11-27  9:15 Latecki, Karol
2018-11-27  5:06 Cao, Gang
2018-11-27  4:57 Yang, Ziye
2018-11-27  2:14 Luse, Paul E
2018-11-27  2:01 Yang, Ziye
2018-11-27  1:56 Luse, Paul E
2018-11-27  1:43 Yang, Ziye

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.