[
https://issues.apache.org/jira/browse/BEAM-8213?focusedWorklogId=317631&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-317631
]
ASF GitHub Bot logged work on BEAM-8213:
----------------------------------------
Author: ASF GitHub Bot
Created on: 24/Sep/19 16:27
Start Date: 24/Sep/19 16:27
Worklog Time Spent: 10m
Work Description: chadrik commented on issue #9642: [BEAM-8213] Split up
monolithic python preCommit tests on jenkins
URL: https://github.com/apache/beam/pull/9642#issuecomment-534637532
> I think the concern is that we may have higher test concurrency since we
splitting the big python job into multiple pieces.
I don't really follow this point. We can't have higher concurrency than the
32 slots that are available, right? Splitting the work previously done by one
job across 5 jobs only affects the amount of work done concurrently at times
when all the slots in the queue were not previously full, i.e. there were more
slots that could have been expanded to, but not enough jobs to fill them. But
even in the case where we might now make use of those free slots (which is a
good thing!), the number of slots in use would still be less than or equal to
32.
I'm new to this project so there are some important details that I may be
overlooking, but that's how it looks to me based on my experience with work
queues.
> In addition, this may also lead higher stress on gcp resources usage, such
as CreateJobPerMinutePerUser, and computing engine quotas.
After this change it will be slightly more likely that multiple slots are
consumed by python jobs than before, since there are now more python job types
(if we assume the type of job in each spot is a random sample of all job
types). So in terms of CPU resources, there would be more stress than before
if we think that the python jobs are using more CPU resources than the Java and
Go jobs, which I find quite unlikely. However, If we're talking about IO
usage, it is plausible that there will be more stress on the system because it
will be more likely than before that two or more jobs are accessing the same
data for integration tests.
But all-in-all, since we're doing exactly the same work as before, and we
have a limit on the number of jobs that can run concurrently, it seems unlikely
to me that there will be a significant increase in resources used, time spent
waiting for the queue to clear, or stress on the existing resources.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 317631)
Time Spent: 1h 50m (was: 1h 40m)
> Run and report python tox tasks separately within Jenkins
> ---------------------------------------------------------
>
> Key: BEAM-8213
> URL: https://issues.apache.org/jira/browse/BEAM-8213
> Project: Beam
> Issue Type: Improvement
> Components: build-system
> Reporter: Chad Dombrova
> Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> As a python developer, the speed and comprehensibility of the jenkins
> PreCommit job could be greatly improved.
> Here are some of the problems
> - when a lint job fails, it's not reported in the test results summary, so
> even though the job is marked as failed, I see "Test Result (no failures)"
> which is quite confusing
> - I have to wait for over an hour to discover the lint failed, which takes
> about a minute to run on its own
> - The logs are a jumbled mess of all the different tasks running on top of
> each other
> - The test results give no indication of which version of python they use. I
> click on Test results, then the test module, then the test class, then I see
> 4 tests named the same thing. I assume that the first is python 2.7, the
> second is 3.5 and so on. It takes 5 clicks and then reading the log output
> to know which version of python a single error pertains to, then I need to
> repeat for each failure. This makes it very difficult to discover problems,
> and deduce that they may have something to do with python version mismatches.
> I believe the solution to this is to split up the single monolithic python
> PreCommit job into sub-jobs (possibly using a pipeline with steps). This
> would give us the following benefits:
> - sub job results should become available as they finish, so for example,
> lint results should be available very early on
> - sub job results will be reported separately, and there will be a job for
> each py2, py35, py36 and so on, so it will be clear when an error is related
> to a particular python version
> - sub jobs without reports, like docs and lint, will have their own failure
> status and logs, so when they fail it will be more obvious what went wrong.
> I'm happy to help out once I get some feedback on the desired way forward.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
