Re: Go error when building containers

[Robert Burke]

Yup that is and always has been the right answer.

I can't look up the JIRA right now but once I've finished schemas, the plan
is to get Go Modules working which will be a much more reliable solution.

On Fri, Jul 24, 2020, 5:19 PM Brian Hulette  wrote:

> Spoke with Daniel about this offline and he suggested deleting all the
> vendor directories. I ran `find . -name vendor | xargs -I{} rm -rf {}` from
> my Beam clone and all is well now.
>
> On Fri, Jul 24, 2020 at 11:13 AM Brian Hulette 
> wrote:
>
>> I tried removing every .gogradle directory in Beam, as well
>> as ~/.cache/go-build and ~/.gradle/go/repo but it's still happening. Maybe
>> there's some other cache I'm missing? I also synced past
>> https://github.com/apache/beam/pull/12364 in case it was related.
>>
>> I thought maybe others were having the same issue but I guess this is a
>> problem unique to me.
>>
>> On Thu, Jul 23, 2020 at 6:33 PM Daniel Oliveira 
>> wrote:
>>
>>> It looks like the cached version of a package is stale and causing build
>>> errors when building beam. Chances are just deleting that
>>> /.gogradle directory will cause everything to rebuild from a clean state,
>>> so I'd try that. I think it should be /sdks/go/.gogradle
>>>
>>> On Thu, Jul 23, 2020 at 4:56 PM Ahmet Altay  wrote:
>>>
 This is probably : https://issues.apache.org/jira/browse/BEAM-10567
 

 On Thu, Jul 23, 2020 at 4:53 PM Brian Hulette 
 wrote:

> Whenever I build a container locally
> (:sdks:java:container:docker, :sdks:python:container:py37:docker, ..) I 
> get
> a Go error (log at the end of this message).
>
> I've discovered I can just comment
> out resolveBuildDependencies.dependsOn ":sdks:go:goBuild" in the relevant
> build.gradle file [1] whenever this happens, but it's getting old and I'm
> wondering if there's a better way. Is there something wrong with my
> environment that's causing these errors (It must not be an actual breakage
> in the Go SDK)? Can we remove or modify this statement to fix this?
>
> Thanks,
> Brian
>
> [1]
> https://github.com/apache/beam/blob/59b7200c8621b81804d53ded771fd3aa525fbb47/sdks/java/container/build.gradle#L32
>
> # github.com/apache/beam/sdks/go/test/integration/synthetic
> .gogradle/project_gopath/src/
> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:31:31:
> cannot use s (type "
> github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
> as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument
> to synthetic.SourceSingle
> .gogradle/project_gopath/src/
> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:33:24:
> cannot use s (type "
> github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
> as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument
> to synthetic.Step
> .gogradle/project_gopath/src/
> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:34:2:
> undefined: passert.Count
> .gogradle/project_gopath/src/
> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:51:25:
> cannot use s (type "
> github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
> as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument
> to synthetic.Source
> .gogradle/project_gopath/src/
> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:51:25:
> cannot use configs (type "
> github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".PCollection)
> as type "github.com/apache/beam/sdks/go/pkg/beam".PCollection in
> argument to synthetic.Source
> .gogradle/project_gopath/src/
> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:52:24:
> cannot use s (type "
> github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
> as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument
> to synthetic.Step
> .gogradle/project_gopath/src/
> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:61:2:
> undefined: passert.Count
>
> > Task :sdks:go:buildLinuxAmd64 FAILED
>

Re: Go error when building containers

[Brian Hulette]

Spoke with Daniel about this offline and he suggested deleting all the
vendor directories. I ran `find . -name vendor | xargs -I{} rm -rf {}` from
my Beam clone and all is well now.

On Fri, Jul 24, 2020 at 11:13 AM Brian Hulette  wrote:

> I tried removing every .gogradle directory in Beam, as well
> as ~/.cache/go-build and ~/.gradle/go/repo but it's still happening. Maybe
> there's some other cache I'm missing? I also synced past
> https://github.com/apache/beam/pull/12364 in case it was related.
>
> I thought maybe others were having the same issue but I guess this is a
> problem unique to me.
>
> On Thu, Jul 23, 2020 at 6:33 PM Daniel Oliveira 
> wrote:
>
>> It looks like the cached version of a package is stale and causing build
>> errors when building beam. Chances are just deleting that
>> /.gogradle directory will cause everything to rebuild from a clean state,
>> so I'd try that. I think it should be /sdks/go/.gogradle
>>
>> On Thu, Jul 23, 2020 at 4:56 PM Ahmet Altay  wrote:
>>
>>> This is probably : https://issues.apache.org/jira/browse/BEAM-10567
>>> 
>>>
>>> On Thu, Jul 23, 2020 at 4:53 PM Brian Hulette 
>>> wrote:
>>>
 Whenever I build a container locally
 (:sdks:java:container:docker, :sdks:python:container:py37:docker, ..) I get
 a Go error (log at the end of this message).

 I've discovered I can just comment
 out resolveBuildDependencies.dependsOn ":sdks:go:goBuild" in the relevant
 build.gradle file [1] whenever this happens, but it's getting old and I'm
 wondering if there's a better way. Is there something wrong with my
 environment that's causing these errors (It must not be an actual breakage
 in the Go SDK)? Can we remove or modify this statement to fix this?

 Thanks,
 Brian

 [1]
 https://github.com/apache/beam/blob/59b7200c8621b81804d53ded771fd3aa525fbb47/sdks/java/container/build.gradle#L32

 # github.com/apache/beam/sdks/go/test/integration/synthetic
 .gogradle/project_gopath/src/
 github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:31:31:
 cannot use s (type "
 github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
 as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument to
 synthetic.SourceSingle
 .gogradle/project_gopath/src/
 github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:33:24:
 cannot use s (type "
 github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
 as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument to
 synthetic.Step
 .gogradle/project_gopath/src/
 github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:34:2:
 undefined: passert.Count
 .gogradle/project_gopath/src/
 github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:51:25:
 cannot use s (type "
 github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
 as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument to
 synthetic.Source
 .gogradle/project_gopath/src/
 github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:51:25:
 cannot use configs (type "
 github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".PCollection)
 as type "github.com/apache/beam/sdks/go/pkg/beam".PCollection in
 argument to synthetic.Source
 .gogradle/project_gopath/src/
 github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:52:24:
 cannot use s (type "
 github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
 as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument to
 synthetic.Step
 .gogradle/project_gopath/src/
 github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:61:2:
 undefined: passert.Count

 > Task :sdks:go:buildLinuxAmd64 FAILED

>>>

Re: Python2.7 Beam End-of-Life Date

[Kenneth Knowles]

Regardless of the outcome, it would be good to have some more details here.
Can you share links for people to find out more about Python 3 support in
those products and their timeline? I did some quick searching out of
curiosity but I do not believe I found the authoritative information.

Separately, I am curious what the precise symptoms of dropping Python 2.7
support will be. I admit I haven't been able to follow all the threads on
the topic. Is it moving on to newer dependencies, or also wanting to use
new language features, or something more subtle?

Kenn

On Thu, Jun 18, 2020 at 5:01 PM Chad Dombrova  wrote:

> Hi all,
> Sorry I've been AWOL.  I've been pulled in a number of different
> directions.
>
> We are still increasing our use of Beam, and I have it on my todo list to
> reach out to Kenneth about how Beam could be expanded into the VFX /
> Animation industries.
>
> Our industry uses a number of specialized applications with embedded
> python interpreters.  We run Beam inside these interpreters, so we're
> waiting for them to switch to python3.
>
> Here's the status report for python3 adoption in our key applications:
>
> *Maya*:  In Beta
> *Houdini*:  Released
> *Nuke*: In Beta
> *Katana*:  Not started (Alpha?)
>
> I hate to be the one holding the project back, and I understand if you all
> ultimately decide it's untenable to wait any longer.  The good news is 3
> out of 4 applications should be ready in the next 2-3 months.  I can do
> some investigation into what workarounds might look like for Katana, or
> maybe we can use the Beta version once python3 support arrives, which would
> move our schedule forward.
>
> When would 2.24 release?
>
> -chad
>
>
>
>
>
>
>
>
>
> On Thu, Jun 18, 2020 at 4:33 PM Ahmet Altay  wrote:
>
>> OK, tweeted the message. Could you share on Slack?
>>
>> On Thu, Jun 18, 2020 at 4:28 PM Valentyn Tymofieiev 
>> wrote:
>>
>>> Alright, let's publish the message on Twitter and echo on Slack once
>>> that's done.
>>> Thank you!
>>>
>>> On Tue, Jun 16, 2020 at 5:31 PM Ahmet Altay  wrote:
>>>
 That sounds reasonable to me. I agree, it is better to get specific
 reasons rather than a yes/no answer.

 On Tue, Jun 16, 2020 at 1:50 PM Valentyn Tymofieiev <
 valen...@google.com> wrote:

> After thinking about it for a bit, I am not sure whether a poll would
> be actionable. For example, if 1000 users provide a positive response and 
> 5
> users provide a negative response, how do we interpret that and  where do
> we draw a line? How about instead we encourage users to reach out, and 
> tell
> what is not working for them? For example:
>
> Beam is considering making 2.23.0 a final release supporting Py2. If
> you are not able to switch to Python 3, please let us know why: [short 
> link
> to user@ thread] [1].
>
> Thoughts?
>
> [1]
> https://lists.apache.org/thread.html/r0de71d98d98b213dd1d0c45c1f5642135116f25def5637a5f41c8d29%40%3Cuser.beam.apache.org%3E
>
> On Tue, Jun 16, 2020 at 11:50 AM Ahmet Altay  wrote:
>
>>
>>
>> On Tue, Jun 16, 2020 at 11:38 AM Valentyn Tymofieiev <
>> valen...@google.com> wrote:
>>
>>> I have reached out to user@ for feedback on Python 3 migration[1].
>>>
>>
>> Maybe also ask on slack? There are quite a bit of users there as well.
>>
>>
>>>
>>> Could somebody from PMC please help with Twitter poll?
>>>
>>
>> I can try to do this. What question would you like to ask? I do not
>> know much about twitter polls but I assume they have character limits
>> similar to regular tweets.
>>
>>
>>>
>>> Technically, we can proceed with the change between 2.23.0 and
>>> 2.24.0, so that's after 2.23.0 is cut and we give sufficient time for 
>>> users
>>> to respond.
>>>
>>> [1]
>>> https://lists.apache.org/thread.html/r0de71d98d98b213dd1d0c45c1f5642135116f25def5637a5f41c8d29%40%3Cuser.beam.apache.org%3E
>>> On Tue, Jun 16, 2020 at 9:22 AM Ismaël Mejía 
>>> wrote:
>>>
 Yes we need to poll this outside as Robert proposed.

 The proposed last support version corresponds with the next release
 that will be
 cut in two weeks. Sounds a bit short if we count the time to poll
 people on this
 subject but still could be.
>>>
>>> Technically, we can proceed with the change between 2.23.0 and
>>> 2.24.0, so that's after 2.23.0 is cut and we give sufficient time for 
>>> users
>>> to respond.
>>>
>>>
 I remember Chad mentioned in this thread the impossibility to get
 support for
 python 2 in his industry until the end of the year, Maybe things
 have improved.
 Have they?




 On Tue, Jun 16, 2020 at 6:10 PM Robert Bradshaw <
 rober...@google.com> wrote:
 >
 > I like that 

Making reporting bugs/feature request easier

[Griselda Cuevas]

Hi folks,

I recently made a few Jira boards [1][2] to help triage and organize Beam's
backlog.


Something that came to my mind is that reporting bugs and feature requests
using Jira might be imposing a high barrier for users who don't have an
account. This process might also make it difficult to ask follow-up
questions to reporters who don't monitor Jira's notifications.


I want to gather consensus on updating the website to give the option to
report bugs and feature requests by sending an email to users@b.a.o and
adding a tag to the subject line ([bug] OR [New Feature])


There are other more sustainable solutions, like looking into using GitHub
issues, but they will have other costs, like migrating current tickets and
systems, pointing them out here in case we want to consider.


Let me know what you think,

G


[1]
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335922#

[2]
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335923#

[3] https://beam.apache.org/contribute/

[4] https://beam.apache.org/community/contact-us/

Re: Chronically flaky tests

[Kenneth Knowles]

Adding https://testautonation.com/analyse-test-results-deflake-flaky-tests/ to
the list which seems a more powerful test history tool.

On Fri, Jul 24, 2020 at 1:51 PM Kenneth Knowles  wrote:

> Had some off-list chats to brainstorm and I wanted to bring ideas back to
> the dev@ list for consideration. A lot can be combined. I would really
> like to have a section in the release notes. I like the idea of banishing
> flakes from pre-commit (since you can't tell easily if it was a real
> failure caused by the PR) and auto-retrying in post-commit (so we can
> gather data on exactly what is flaking without a lot of manual
> investigation).
>
> *Include ignored or quarantined tests in the release notes*
> Pro:
>  - Users are aware of what is not being tested so may be silently broken
>  - It forces discussion of ignored tests to be part of our community
> processes
> Con:
>  - It may look bad if the list is large (this is actually also a Pro
> because if it looks bad, it is bad)
>
> *Run flaky tests only in postcommit*
> Pro:
>  - isolates the bad signal so pre-commit is not affected
>  - saves pointless re-runs in pre-commit
>  - keeps a signal in post-commit that we can watch, instead of losing it
> completely when we disable a test
>  - maybe keeps the flaky tests in job related to what they are testing
> Con:
>  - we have to really watch post-commit or flakes can turn into failures
>
> *Separate flaky tests into quarantine job*
> Pro:
>  - gain signal for healthy tests, as with disabling or running in
> post-commit
>  - also saves pointless re-runs
> Con:
>  - may collect bad tests so that we never look at it so it is the same as
> disabling the test
>  - lots of unrelated tests grouped into signal instead of focused on
> health of a particular component
>
> *Add Gradle or Jenkins plugin to retry flaky tests*
> https://blog.gradle.org/gradle-flaky-test-retry-plugin
> https://plugins.jenkins.io/flaky-test-handler/
> Pro:
>  - easier than Jiras with human pasting links; works with moving flakes to
> post-commit
>  - get a somewhat automated view of flakiness, whether in pre-commit or
> post-commit
>  - don't get stopped by flakiness
> Con:
>  - maybe too easy to ignore flakes; we should add all flakes (not just
> disabled or quarantined) to the release notes
>  - sometimes flakes are actual bugs (like concurrency) so treating this as
> OK is not desirable
>  - without Jiras, no automated release notes
>  - Jenkins: retry only will work at job level because it needs Maven to
> retry only failed (I think)
>  - Jenkins: some of our jobs may have duplicate test names (but might
> already be fixed)
>
> *Consider Gradle Enterprise*
> Pro:
>  - get Gradle scan granularity of flake data (and other stuff)
>  - also gives module-level health which we do not have today
> Con:
>  - cost and administrative burden unknown
>  - we probably have to do some small work to make our jobs compatible with
> their history tracking
>
> *Require link to Jira to rerun a test*
> Instead of saying "Run Java PreCommit" you have to link to the bug
> relating to the failure.
> Pro:
>  - forces investigation
>  - helps others find out about issues
> Con:
>  - adds a lot of manual work, or requires automation (which will probably
> be ad hoc and fragile)
>
> Kenn
>
> On Mon, Jul 20, 2020 at 11:59 AM Brian Hulette 
> wrote:
>
>> > I think we are missing a way for checking that we are making progress
>> on P1 issues. For example, P0 issues block releases and this obviously
>> results in fixing/triaging/addressing P0 issues at least every 6 weeks. We
>> do not have a similar process for flaky tests. I do not know what would be
>> a good policy. One suggestion is to ping (email/slack) assignees of issues.
>> I recently missed a flaky issue that was assigned to me. A ping like that
>> would have reminded me. And if an assignee cannot help/does not have the
>> time, we can try to find a new assignee.
>>
>> Yeah I think this is something we should address. With the new jira
>> automation at least assignees should get an email notification after 30
>> days because of a jira comment like [1], but that's too long to let a test
>> continue to flake. Could Beam Jira Bot ping every N days for P1s that
>> aren't making progress?
>>
>> That wouldn't help us with P1s that have no assignee, or are assigned to
>> overloaded people. It seems we'd need some kind of dashboard or report to
>> capture those.
>>
>> [1]
>> https://issues.apache.org/jira/browse/BEAM-8101?focusedCommentId=17121918=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17121918
>>
>> On Fri, Jul 17, 2020 at 1:09 PM Ahmet Altay  wrote:
>>
>>> Another idea, could we change our "Retest X" phrases with "Retest X
>>> (Reason)" phrases? With this change a PR author will have to look at failed
>>> test logs. They could catch new flakiness introduced by their PR, file a
>>> JIRA for a flakiness that was not noted before, or ping an existing JIRA
>>> issue/raise its 

Re: Chronically flaky tests

[Kenneth Knowles]

Had some off-list chats to brainstorm and I wanted to bring ideas back to
the dev@ list for consideration. A lot can be combined. I would really like
to have a section in the release notes. I like the idea of banishing flakes
from pre-commit (since you can't tell easily if it was a real failure
caused by the PR) and auto-retrying in post-commit (so we can gather data
on exactly what is flaking without a lot of manual investigation).

*Include ignored or quarantined tests in the release notes*
Pro:
 - Users are aware of what is not being tested so may be silently broken
 - It forces discussion of ignored tests to be part of our community
processes
Con:
 - It may look bad if the list is large (this is actually also a Pro
because if it looks bad, it is bad)

*Run flaky tests only in postcommit*
Pro:
 - isolates the bad signal so pre-commit is not affected
 - saves pointless re-runs in pre-commit
 - keeps a signal in post-commit that we can watch, instead of losing it
completely when we disable a test
 - maybe keeps the flaky tests in job related to what they are testing
Con:
 - we have to really watch post-commit or flakes can turn into failures

*Separate flaky tests into quarantine job*
Pro:
 - gain signal for healthy tests, as with disabling or running in
post-commit
 - also saves pointless re-runs
Con:
 - may collect bad tests so that we never look at it so it is the same as
disabling the test
 - lots of unrelated tests grouped into signal instead of focused on health
of a particular component

*Add Gradle or Jenkins plugin to retry flaky tests*
https://blog.gradle.org/gradle-flaky-test-retry-plugin
https://plugins.jenkins.io/flaky-test-handler/
Pro:
 - easier than Jiras with human pasting links; works with moving flakes to
post-commit
 - get a somewhat automated view of flakiness, whether in pre-commit or
post-commit
 - don't get stopped by flakiness
Con:
 - maybe too easy to ignore flakes; we should add all flakes (not just
disabled or quarantined) to the release notes
 - sometimes flakes are actual bugs (like concurrency) so treating this as
OK is not desirable
 - without Jiras, no automated release notes
 - Jenkins: retry only will work at job level because it needs Maven to
retry only failed (I think)
 - Jenkins: some of our jobs may have duplicate test names (but might
already be fixed)

*Consider Gradle Enterprise*
Pro:
 - get Gradle scan granularity of flake data (and other stuff)
 - also gives module-level health which we do not have today
Con:
 - cost and administrative burden unknown
 - we probably have to do some small work to make our jobs compatible with
their history tracking

*Require link to Jira to rerun a test*
Instead of saying "Run Java PreCommit" you have to link to the bug relating
to the failure.
Pro:
 - forces investigation
 - helps others find out about issues
Con:
 - adds a lot of manual work, or requires automation (which will probably
be ad hoc and fragile)

Kenn

On Mon, Jul 20, 2020 at 11:59 AM Brian Hulette  wrote:

> > I think we are missing a way for checking that we are making progress on
> P1 issues. For example, P0 issues block releases and this obviously results
> in fixing/triaging/addressing P0 issues at least every 6 weeks. We do not
> have a similar process for flaky tests. I do not know what would be a good
> policy. One suggestion is to ping (email/slack) assignees of issues. I
> recently missed a flaky issue that was assigned to me. A ping like that
> would have reminded me. And if an assignee cannot help/does not have the
> time, we can try to find a new assignee.
>
> Yeah I think this is something we should address. With the new jira
> automation at least assignees should get an email notification after 30
> days because of a jira comment like [1], but that's too long to let a test
> continue to flake. Could Beam Jira Bot ping every N days for P1s that
> aren't making progress?
>
> That wouldn't help us with P1s that have no assignee, or are assigned to
> overloaded people. It seems we'd need some kind of dashboard or report to
> capture those.
>
> [1]
> https://issues.apache.org/jira/browse/BEAM-8101?focusedCommentId=17121918=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17121918
>
> On Fri, Jul 17, 2020 at 1:09 PM Ahmet Altay  wrote:
>
>> Another idea, could we change our "Retest X" phrases with "Retest X
>> (Reason)" phrases? With this change a PR author will have to look at failed
>> test logs. They could catch new flakiness introduced by their PR, file a
>> JIRA for a flakiness that was not noted before, or ping an existing JIRA
>> issue/raise its severity. On the downside this will require PR authors to
>> do more.
>>
>> On Fri, Jul 17, 2020 at 6:46 AM Tyson Hamilton 
>> wrote:
>>
>>> Adding retries can be beneficial in two ways, unblocking a PR, and
>>> collecting metrics about the flakes.
>>>
>>
>> Makes sense. I think we will still need to have a plan to remove retries
>> similar to re-enabling disabled tests.
>>
>>
>>>

Re: [VOTE] Make Apache Beam 2.24.0 the final release supporting Python 2.

[Udi Meiri]

+1

On Fri, Jul 24, 2020 at 10:47 AM Maximilian Michels  wrote:

> +1
>
> On 24.07.20 18:54, Pablo Estrada wrote:
> > +1 - thank you Valentyn!
> > -P.
> >
> > On Thu, Jul 23, 2020 at 1:29 PM Chamikara Jayalath  > > wrote:
> >
> > +1
> >
> > On Thu, Jul 23, 2020 at 1:15 PM Brian Hulette  > > wrote:
> >
> > +1
> >
> > On Thu, Jul 23, 2020 at 1:05 PM Robert Bradshaw
> > mailto:rober...@google.com>> wrote:
> >
> > [X] +1: Remove Python 2 support in Apache Beam 2.25.0.
> >
> > According to our six-week release cadence, 2.24.0 (the last
> > release to support Python 2) will be cut mid-August, and the
> > first release not supporting Python 2 would be expected to
> > land sometime in October. This seems a reasonable timeline
> > to me.
> >
> >
> > On Thu, Jul 23, 2020 at 12:53 PM Valentyn Tymofieiev
> > mailto:valen...@google.com>> wrote:
> >
> > Hi everyone,
> >
> > Please vote whether to make Apache Beam 2.24.0 the final
> > release supporting Python 2 as follows.
> >
> > [ ] +1: Remove Python 2 support in Apache Beam 2.25.0.
> > [ ] -1: Continue to support Python 2 in Apache Beam, and
> > reconsider at a later date.
> >
> > The Beam community has pledged to sunset Python 2
> > support at some point in 2020[1,2]. A recent
> > discussion[3] on dev@  proposes to outline a specific
> > version after which Beam developers no longer have to
> > maintain Py2 support, which is a motivation for this
> vote.
> >
> > If this vote is approved we will announce Apache Beam
> > 2.24.0 as our final release to support Python 2 and
> > discontinue Python 2 support starting from 2.25.0
> > (inclusive).
> >
> > This is a procedural vote [4] that will follow the
> > majority approval rules and will be open for at least 72
> > hours.
> >
> > Thanks,
> > Valentyn
> >
> > [1]
> >
> https://lists.apache.org/thread.html/634f7346b607e779622d0437ed0eca783f474dea8976adf41556845b%40%3Cdev.beam.apache.org%3E
> > [2] https://python3statement.org/
> > [3]
> >
> https://lists.apache.org/thread.html/r0d5c309a7e3107854f4892ccfeb1a17c0cec25dfce188678ab8df072%40%3Cdev.beam.apache.org%3E
> > [4] https://www.apache.org/foundation/voting.html
> > 
> >
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Jenkins trigger phrase "run seed job" not working?

[Udi Meiri]

I made my membership public and now the phrase works. (page:
https://github.com/orgs/apache/people?query=udim)

On Fri, Jul 24, 2020 at 1:04 PM Kenneth Knowles  wrote:

>
>
> On Thu, Jul 23, 2020 at 1:11 PM Damian Gadomski <
> damian.gadom...@polidea.com> wrote:
>
>> Yes, I thought that whitelisting apache organization will do the trick,
>> but apparently, it doesn't. Actually, it makes sense as we want to allow
>> only beam committers and not all apache committers. I don't know the
>> implications of membership in the apache github organization, but you for
>> instance are not there :) Neither is Ahmet.
>>
>
> This may have to do with registering alternative email addresses and
> GitHub accounts via whimsy.apache.org. If you are able to commit, then
> you are set up via gitbox.apache.org.
>
> Kenn
>
>
>> Therefore there's nothing wrong with the Ghprb plugin, it correctly
>> forbade triggering. From my investigation, the "beam-committers" GitHub
>> team (which is under the apache org) is the list of people that should be
>> allowed. But firstly, you cant whitelist a team with Ghprb. There's a
>> ticket for that, open for 5 years
>> . I could
>> implement that but, secondly, the team is secret. I can't even see it. Even
>> asfbot doesn't have permission to see it.
>>
>> You may ask, how it worked before, because on the builds.apache.org
>> somehow only committers were allowed to trigger PR builds. It appeared that
>> Infra created a webhook relay. It's configured here
>> 
>>  and
>> it filters out all the non-committers events. I wish I had known that
>> before as it was also the reason for different issues during the migration.
>> Anyway, it would be hard to use that mechanism in our case as we want to
>> configure it depending on the job.
>>
>>
>> There's a publicly available source of committers list - it's LDAP. I've
>> tested it and it allows anonymous connection and provides the list of the
>> committers as well as the github usernames. My current idea is to read this
>> from LDAP as a part of the seed job and configure the jobs with the apache
>> committers present on the ghprb whitelist.
>>
>>
>> Hope that I didn't miss anything ;) It isn't that easy to investigate
>> that kind of issues with my poor privileges ;)
>>
>>
>> Regards,
>>
>> Damian
>>
>>
>> On Thu, Jul 23, 2020 at 6:52 PM Udi Meiri  wrote:
>>
>>> Thanks Damian! I saw that the config also has this:
>>>   orgWhitelist(['apache'])
>>> Shouldn't that be enough to allow all Apache committers?
>>>
>>> I traced the code for the membership check here:
>>>
>>> https://github.com/jenkinsci/ghprb-plugin/blob/4e86ed47a96a01eeaa51a479ff604252109635f6/src/main/java/org/jenkinsci/plugins/ghprb/GhprbGitHub.java#L27
>>> Is there a way to see these logs?
>>>
>>>
>>> On Thu, Jul 23, 2020 at 7:08 AM Damian Gadomski <
>>> damian.gadom...@polidea.com> wrote:
>>>
 Hi,

 You are right, the current behavior is wrong, I'm currently working to
 fix it asap. Our intention was to disable that only for non-committers.

 As a workaround, as a committer, you could manually add yourself (your
 GitHub username) to the whitelist of the SeedJob configuration:
 https://ci-beam.apache.org/job/beam_SeedJob/configure
 Then, your comment "Run Seed Job" will trigger the build. I've already
 manually triggered it for you that way.

 Of course, it will only work until the seed job gets executed - it will
 then override the whitelist with an empty one.

 [image: Selection_408.png]

 As a target solution, I'm planning to fetch the list of beam committers
 from LDAP and automatically add them to the whitelist above as a part of
 the seed job. I'll keep you updated about the progress.

 Regards,
 Damian


 On Wed, Jul 22, 2020 at 11:03 PM Ahmet Altay  wrote:

> +Damian Gadomski , it might be related
> to this change: https://github.com/apache/beam/pull/12319.
>
> /cc +Tyson Hamilton 
>
> On Wed, Jul 22, 2020 at 1:17 PM Udi Meiri  wrote:
>
>> HI,
>> I'm trying to test a groovy change but I can't seem to trigger the
>> seed job. It worked yesterday so I'm not sure what changed.
>>
>> https://github.com/apache/beam/pull/12326
>>
>>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: No space left on device - beam-jenkins 1 and 7

[Ahmet Altay]

Tests may not be doing docker cleanup. Inventory job runs a docker prune
every 12 hours for images older than 24 hrs [1]. Randomly looking at one of
the recent runs [2], it cleaned up a long list of containers consuming
30+GB space. That should be just 12 hours worth of containers.

[1]
https://github.com/apache/beam/blob/master/.test-infra/jenkins/job_Inventory.groovy#L69
[2]
https://ci-beam.apache.org/job/beam_Inventory_apache-beam-jenkins-14/501/console

On Fri, Jul 24, 2020 at 1:07 PM Tyson Hamilton  wrote:

> Yes, these are on the same volume in the /var/lib/docker directory. I'm
> unsure if they clean up leftover images.
>
> On Fri, Jul 24, 2020 at 12:52 PM Udi Meiri  wrote:
>
>> I forgot Docker images:
>>
>> ehudm@apache-ci-beam-jenkins-3:~$ sudo docker system df
>> TYPETOTAL   ACTIVE  SIZE
>>RECLAIMABLE
>> Images  88  9   125.4GB
>>   124.2GB (99%)
>> Containers  40  4   7.927GB
>>   7.871GB (99%)
>> Local Volumes   47  0   3.165GB
>>   3.165GB (100%)
>> Build Cache 0   0   0B
>>0B
>>
>> There are about 90 images on that machine, with all but 1 less than 48
>> hours old.
>> I think the docker test jobs need to try harder at cleaning up their
>> leftover images. (assuming they're already doing it?)
>>
>> On Fri, Jul 24, 2020 at 12:31 PM Udi Meiri  wrote:
>>
>>> The additional slots (@3 directories) take up even more space now than
>>> before.
>>>
>>> I'm testing out https://github.com/apache/beam/pull/12326 which could
>>> help by cleaning up workspaces after a run (just started a seed job).
>>>
>>> On Fri, Jul 24, 2020 at 12:13 PM Tyson Hamilton 
>>> wrote:
>>>
 664Mbeam_PreCommit_JavaPortabilityApi_Commit
 656Mbeam_PreCommit_JavaPortabilityApi_Commit@2
 611Mbeam_PreCommit_JavaPortabilityApi_Cron
 616Mbeam_PreCommit_JavaPortabilityApiJava11_Commit
 598Mbeam_PreCommit_JavaPortabilityApiJava11_Commit@2
 662Mbeam_PreCommit_JavaPortabilityApiJava11_Cron
 2.9Gbeam_PreCommit_Portable_Python_Commit
 2.9Gbeam_PreCommit_Portable_Python_Commit@2
 1.7Gbeam_PreCommit_Portable_Python_Commit@3
 3.4Gbeam_PreCommit_Portable_Python_Cron
 1.9Gbeam_PreCommit_Python2_PVR_Flink_Commit
 1.4Gbeam_PreCommit_Python2_PVR_Flink_Cron
 1.3Gbeam_PreCommit_Python2_PVR_Flink_Phrase
 6.2Gbeam_PreCommit_Python_Commit
 7.5Gbeam_PreCommit_Python_Commit@2
 7.5Gbeam_PreCommit_Python_Cron
 1012M   beam_PreCommit_PythonDocker_Commit
 1011M   beam_PreCommit_PythonDocker_Commit@2
 1011M   beam_PreCommit_PythonDocker_Commit@3
 1002M   beam_PreCommit_PythonDocker_Cron
 877Mbeam_PreCommit_PythonFormatter_Commit
 988Mbeam_PreCommit_PythonFormatter_Cron
 986Mbeam_PreCommit_PythonFormatter_Phrase
 1.7Gbeam_PreCommit_PythonLint_Commit
 2.1Gbeam_PreCommit_PythonLint_Cron
 7.5Gbeam_PreCommit_Python_Phrase
 346Mbeam_PreCommit_RAT_Commit
 341Mbeam_PreCommit_RAT_Cron
 338Mbeam_PreCommit_Spotless_Commit
 339Mbeam_PreCommit_Spotless_Cron
 5.5Gbeam_PreCommit_SQL_Commit
 5.5Gbeam_PreCommit_SQL_Cron
 5.5Gbeam_PreCommit_SQL_Java11_Commit
 750Mbeam_PreCommit_Website_Commit
 750Mbeam_PreCommit_Website_Commit@2
 750Mbeam_PreCommit_Website_Cron
 764Mbeam_PreCommit_Website_Stage_GCS_Commit
 771Mbeam_PreCommit_Website_Stage_GCS_Cron
 336Mbeam_Prober_CommunityMetrics
 693Mbeam_python_mongoio_load_test
 339Mbeam_SeedJob
 333Mbeam_SeedJob_Standalone
 334Mbeam_sonarqube_report
 556Mbeam_SQLBigQueryIO_Batch_Performance_Test_Java
 175Gtotal

 On Fri, Jul 24, 2020 at 12:04 PM Tyson Hamilton 
 wrote:

> Ya looks like something in the workspaces is taking up room:
>
> @apache-ci-beam-jenkins-8:/home/jenkins$ sudo du -shc .
> 191G.
> 191Gtotal
>
>
> On Fri, Jul 24, 2020 at 11:44 AM Tyson Hamilton 
> wrote:
>
>> Node 8 is also full. The partition that /tmp is on is here:
>>
>> Filesystem  Size  Used Avail Use% Mounted on
>> /dev/sda1   485G  482G  2.9G 100% /
>>
>> however after cleaning up tmp with the crontab command, there is only
>> 8G usage yet it still remains 100% full:
>>
>> @apache-ci-beam-jenkins-8:/tmp$ sudo du -shc /tmp
>> 8.0G/tmp
>> 8.0Gtotal
>>
>> The workspaces are in the /home/jenkins/jenkins-slave/workspace
>> directory. When I run a du on that, it takes really long. I'll let it 
>> keep
>> running for a while to see if it ever returns a result but so far this
>> seems suspect.
>>
>>
>>
>>
>>
>> On Fri, Jul 24, 2020 at 11:19 

Re: No space left on device - beam-jenkins 1 and 7

[Tyson Hamilton]

Yes, these are on the same volume in the /var/lib/docker directory. I'm
unsure if they clean up leftover images.

On Fri, Jul 24, 2020 at 12:52 PM Udi Meiri  wrote:

> I forgot Docker images:
>
> ehudm@apache-ci-beam-jenkins-3:~$ sudo docker system df
> TYPETOTAL   ACTIVE  SIZE
>  RECLAIMABLE
> Images  88  9   125.4GB
>   124.2GB (99%)
> Containers  40  4   7.927GB
>   7.871GB (99%)
> Local Volumes   47  0   3.165GB
>   3.165GB (100%)
> Build Cache 0   0   0B
>  0B
>
> There are about 90 images on that machine, with all but 1 less than 48
> hours old.
> I think the docker test jobs need to try harder at cleaning up their
> leftover images. (assuming they're already doing it?)
>
> On Fri, Jul 24, 2020 at 12:31 PM Udi Meiri  wrote:
>
>> The additional slots (@3 directories) take up even more space now than
>> before.
>>
>> I'm testing out https://github.com/apache/beam/pull/12326 which could
>> help by cleaning up workspaces after a run (just started a seed job).
>>
>> On Fri, Jul 24, 2020 at 12:13 PM Tyson Hamilton 
>> wrote:
>>
>>> 664Mbeam_PreCommit_JavaPortabilityApi_Commit
>>> 656Mbeam_PreCommit_JavaPortabilityApi_Commit@2
>>> 611Mbeam_PreCommit_JavaPortabilityApi_Cron
>>> 616Mbeam_PreCommit_JavaPortabilityApiJava11_Commit
>>> 598Mbeam_PreCommit_JavaPortabilityApiJava11_Commit@2
>>> 662Mbeam_PreCommit_JavaPortabilityApiJava11_Cron
>>> 2.9Gbeam_PreCommit_Portable_Python_Commit
>>> 2.9Gbeam_PreCommit_Portable_Python_Commit@2
>>> 1.7Gbeam_PreCommit_Portable_Python_Commit@3
>>> 3.4Gbeam_PreCommit_Portable_Python_Cron
>>> 1.9Gbeam_PreCommit_Python2_PVR_Flink_Commit
>>> 1.4Gbeam_PreCommit_Python2_PVR_Flink_Cron
>>> 1.3Gbeam_PreCommit_Python2_PVR_Flink_Phrase
>>> 6.2Gbeam_PreCommit_Python_Commit
>>> 7.5Gbeam_PreCommit_Python_Commit@2
>>> 7.5Gbeam_PreCommit_Python_Cron
>>> 1012M   beam_PreCommit_PythonDocker_Commit
>>> 1011M   beam_PreCommit_PythonDocker_Commit@2
>>> 1011M   beam_PreCommit_PythonDocker_Commit@3
>>> 1002M   beam_PreCommit_PythonDocker_Cron
>>> 877Mbeam_PreCommit_PythonFormatter_Commit
>>> 988Mbeam_PreCommit_PythonFormatter_Cron
>>> 986Mbeam_PreCommit_PythonFormatter_Phrase
>>> 1.7Gbeam_PreCommit_PythonLint_Commit
>>> 2.1Gbeam_PreCommit_PythonLint_Cron
>>> 7.5Gbeam_PreCommit_Python_Phrase
>>> 346Mbeam_PreCommit_RAT_Commit
>>> 341Mbeam_PreCommit_RAT_Cron
>>> 338Mbeam_PreCommit_Spotless_Commit
>>> 339Mbeam_PreCommit_Spotless_Cron
>>> 5.5Gbeam_PreCommit_SQL_Commit
>>> 5.5Gbeam_PreCommit_SQL_Cron
>>> 5.5Gbeam_PreCommit_SQL_Java11_Commit
>>> 750Mbeam_PreCommit_Website_Commit
>>> 750Mbeam_PreCommit_Website_Commit@2
>>> 750Mbeam_PreCommit_Website_Cron
>>> 764Mbeam_PreCommit_Website_Stage_GCS_Commit
>>> 771Mbeam_PreCommit_Website_Stage_GCS_Cron
>>> 336Mbeam_Prober_CommunityMetrics
>>> 693Mbeam_python_mongoio_load_test
>>> 339Mbeam_SeedJob
>>> 333Mbeam_SeedJob_Standalone
>>> 334Mbeam_sonarqube_report
>>> 556Mbeam_SQLBigQueryIO_Batch_Performance_Test_Java
>>> 175Gtotal
>>>
>>> On Fri, Jul 24, 2020 at 12:04 PM Tyson Hamilton 
>>> wrote:
>>>
 Ya looks like something in the workspaces is taking up room:

 @apache-ci-beam-jenkins-8:/home/jenkins$ sudo du -shc .
 191G.
 191Gtotal


 On Fri, Jul 24, 2020 at 11:44 AM Tyson Hamilton 
 wrote:

> Node 8 is also full. The partition that /tmp is on is here:
>
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/sda1   485G  482G  2.9G 100% /
>
> however after cleaning up tmp with the crontab command, there is only
> 8G usage yet it still remains 100% full:
>
> @apache-ci-beam-jenkins-8:/tmp$ sudo du -shc /tmp
> 8.0G/tmp
> 8.0Gtotal
>
> The workspaces are in the /home/jenkins/jenkins-slave/workspace
> directory. When I run a du on that, it takes really long. I'll let it keep
> running for a while to see if it ever returns a result but so far this
> seems suspect.
>
>
>
>
>
> On Fri, Jul 24, 2020 at 11:19 AM Tyson Hamilton 
> wrote:
>
>> Everything I've been looking at is in the /tmp dir. Where are the
>> workspaces, or what are the named?
>>
>>
>>
>>
>> On Fri, Jul 24, 2020 at 11:03 AM Udi Meiri  wrote:
>>
>>> I'm curious to what you find. Was it /tmp or the workspaces using up
>>> the space?
>>>
>>> On Fri, Jul 24, 2020 at 10:57 AM Tyson Hamilton 
>>> wrote:
>>>
 Bleck. I just realized that it is 'offline' so that won't work.
 I'll clean up manually on the machine using the cron command.

 On Fri, Jul 24, 2020 at 10:56 AM Tyson Hamilton 
 

Re: Jenkins trigger phrase "run seed job" not working?

[Kenneth Knowles]

On Thu, Jul 23, 2020 at 1:11 PM Damian Gadomski 
wrote:

> Yes, I thought that whitelisting apache organization will do the trick,
> but apparently, it doesn't. Actually, it makes sense as we want to allow
> only beam committers and not all apache committers. I don't know the
> implications of membership in the apache github organization, but you for
> instance are not there :) Neither is Ahmet.
>

This may have to do with registering alternative email addresses and GitHub
accounts via whimsy.apache.org. If you are able to commit, then you are set
up via gitbox.apache.org.

Kenn


> Therefore there's nothing wrong with the Ghprb plugin, it correctly
> forbade triggering. From my investigation, the "beam-committers" GitHub
> team (which is under the apache org) is the list of people that should be
> allowed. But firstly, you cant whitelist a team with Ghprb. There's a
> ticket for that, open for 5 years
> . I could implement
> that but, secondly, the team is secret. I can't even see it. Even asfbot
> doesn't have permission to see it.
>
> You may ask, how it worked before, because on the builds.apache.org
> somehow only committers were allowed to trigger PR builds. It appeared that
> Infra created a webhook relay. It's configured here
> 
>  and
> it filters out all the non-committers events. I wish I had known that
> before as it was also the reason for different issues during the migration.
> Anyway, it would be hard to use that mechanism in our case as we want to
> configure it depending on the job.
>
>
> There's a publicly available source of committers list - it's LDAP. I've
> tested it and it allows anonymous connection and provides the list of the
> committers as well as the github usernames. My current idea is to read this
> from LDAP as a part of the seed job and configure the jobs with the apache
> committers present on the ghprb whitelist.
>
>
> Hope that I didn't miss anything ;) It isn't that easy to investigate that
> kind of issues with my poor privileges ;)
>
>
> Regards,
>
> Damian
>
>
> On Thu, Jul 23, 2020 at 6:52 PM Udi Meiri  wrote:
>
>> Thanks Damian! I saw that the config also has this:
>>   orgWhitelist(['apache'])
>> Shouldn't that be enough to allow all Apache committers?
>>
>> I traced the code for the membership check here:
>>
>> https://github.com/jenkinsci/ghprb-plugin/blob/4e86ed47a96a01eeaa51a479ff604252109635f6/src/main/java/org/jenkinsci/plugins/ghprb/GhprbGitHub.java#L27
>> Is there a way to see these logs?
>>
>>
>> On Thu, Jul 23, 2020 at 7:08 AM Damian Gadomski <
>> damian.gadom...@polidea.com> wrote:
>>
>>> Hi,
>>>
>>> You are right, the current behavior is wrong, I'm currently working to
>>> fix it asap. Our intention was to disable that only for non-committers.
>>>
>>> As a workaround, as a committer, you could manually add yourself (your
>>> GitHub username) to the whitelist of the SeedJob configuration:
>>> https://ci-beam.apache.org/job/beam_SeedJob/configure
>>> Then, your comment "Run Seed Job" will trigger the build. I've already
>>> manually triggered it for you that way.
>>>
>>> Of course, it will only work until the seed job gets executed - it will
>>> then override the whitelist with an empty one.
>>>
>>> [image: Selection_408.png]
>>>
>>> As a target solution, I'm planning to fetch the list of beam committers
>>> from LDAP and automatically add them to the whitelist above as a part of
>>> the seed job. I'll keep you updated about the progress.
>>>
>>> Regards,
>>> Damian
>>>
>>>
>>> On Wed, Jul 22, 2020 at 11:03 PM Ahmet Altay  wrote:
>>>
 +Damian Gadomski , it might be related to
 this change: https://github.com/apache/beam/pull/12319.

 /cc +Tyson Hamilton 

 On Wed, Jul 22, 2020 at 1:17 PM Udi Meiri  wrote:

> HI,
> I'm trying to test a groovy change but I can't seem to trigger the
> seed job. It worked yesterday so I'm not sure what changed.
>
> https://github.com/apache/beam/pull/12326
>
>

Re: No space left on device - beam-jenkins 1 and 7

[Udi Meiri]

I forgot Docker images:

ehudm@apache-ci-beam-jenkins-3:~$ sudo docker system df
TYPETOTAL   ACTIVE  SIZE
 RECLAIMABLE
Images  88  9   125.4GB
124.2GB (99%)
Containers  40  4   7.927GB
7.871GB (99%)
Local Volumes   47  0   3.165GB
3.165GB (100%)
Build Cache 0   0   0B
 0B

There are about 90 images on that machine, with all but 1 less than 48
hours old.
I think the docker test jobs need to try harder at cleaning up their
leftover images. (assuming they're already doing it?)

On Fri, Jul 24, 2020 at 12:31 PM Udi Meiri  wrote:

> The additional slots (@3 directories) take up even more space now than
> before.
>
> I'm testing out https://github.com/apache/beam/pull/12326 which could
> help by cleaning up workspaces after a run (just started a seed job).
>
> On Fri, Jul 24, 2020 at 12:13 PM Tyson Hamilton 
> wrote:
>
>> 664Mbeam_PreCommit_JavaPortabilityApi_Commit
>> 656Mbeam_PreCommit_JavaPortabilityApi_Commit@2
>> 611Mbeam_PreCommit_JavaPortabilityApi_Cron
>> 616Mbeam_PreCommit_JavaPortabilityApiJava11_Commit
>> 598Mbeam_PreCommit_JavaPortabilityApiJava11_Commit@2
>> 662Mbeam_PreCommit_JavaPortabilityApiJava11_Cron
>> 2.9Gbeam_PreCommit_Portable_Python_Commit
>> 2.9Gbeam_PreCommit_Portable_Python_Commit@2
>> 1.7Gbeam_PreCommit_Portable_Python_Commit@3
>> 3.4Gbeam_PreCommit_Portable_Python_Cron
>> 1.9Gbeam_PreCommit_Python2_PVR_Flink_Commit
>> 1.4Gbeam_PreCommit_Python2_PVR_Flink_Cron
>> 1.3Gbeam_PreCommit_Python2_PVR_Flink_Phrase
>> 6.2Gbeam_PreCommit_Python_Commit
>> 7.5Gbeam_PreCommit_Python_Commit@2
>> 7.5Gbeam_PreCommit_Python_Cron
>> 1012M   beam_PreCommit_PythonDocker_Commit
>> 1011M   beam_PreCommit_PythonDocker_Commit@2
>> 1011M   beam_PreCommit_PythonDocker_Commit@3
>> 1002M   beam_PreCommit_PythonDocker_Cron
>> 877Mbeam_PreCommit_PythonFormatter_Commit
>> 988Mbeam_PreCommit_PythonFormatter_Cron
>> 986Mbeam_PreCommit_PythonFormatter_Phrase
>> 1.7Gbeam_PreCommit_PythonLint_Commit
>> 2.1Gbeam_PreCommit_PythonLint_Cron
>> 7.5Gbeam_PreCommit_Python_Phrase
>> 346Mbeam_PreCommit_RAT_Commit
>> 341Mbeam_PreCommit_RAT_Cron
>> 338Mbeam_PreCommit_Spotless_Commit
>> 339Mbeam_PreCommit_Spotless_Cron
>> 5.5Gbeam_PreCommit_SQL_Commit
>> 5.5Gbeam_PreCommit_SQL_Cron
>> 5.5Gbeam_PreCommit_SQL_Java11_Commit
>> 750Mbeam_PreCommit_Website_Commit
>> 750Mbeam_PreCommit_Website_Commit@2
>> 750Mbeam_PreCommit_Website_Cron
>> 764Mbeam_PreCommit_Website_Stage_GCS_Commit
>> 771Mbeam_PreCommit_Website_Stage_GCS_Cron
>> 336Mbeam_Prober_CommunityMetrics
>> 693Mbeam_python_mongoio_load_test
>> 339Mbeam_SeedJob
>> 333Mbeam_SeedJob_Standalone
>> 334Mbeam_sonarqube_report
>> 556Mbeam_SQLBigQueryIO_Batch_Performance_Test_Java
>> 175Gtotal
>>
>> On Fri, Jul 24, 2020 at 12:04 PM Tyson Hamilton 
>> wrote:
>>
>>> Ya looks like something in the workspaces is taking up room:
>>>
>>> @apache-ci-beam-jenkins-8:/home/jenkins$ sudo du -shc .
>>> 191G.
>>> 191Gtotal
>>>
>>>
>>> On Fri, Jul 24, 2020 at 11:44 AM Tyson Hamilton 
>>> wrote:
>>>
 Node 8 is also full. The partition that /tmp is on is here:

 Filesystem  Size  Used Avail Use% Mounted on
 /dev/sda1   485G  482G  2.9G 100% /

 however after cleaning up tmp with the crontab command, there is only
 8G usage yet it still remains 100% full:

 @apache-ci-beam-jenkins-8:/tmp$ sudo du -shc /tmp
 8.0G/tmp
 8.0Gtotal

 The workspaces are in the /home/jenkins/jenkins-slave/workspace
 directory. When I run a du on that, it takes really long. I'll let it keep
 running for a while to see if it ever returns a result but so far this
 seems suspect.





 On Fri, Jul 24, 2020 at 11:19 AM Tyson Hamilton 
 wrote:

> Everything I've been looking at is in the /tmp dir. Where are the
> workspaces, or what are the named?
>
>
>
>
> On Fri, Jul 24, 2020 at 11:03 AM Udi Meiri  wrote:
>
>> I'm curious to what you find. Was it /tmp or the workspaces using up
>> the space?
>>
>> On Fri, Jul 24, 2020 at 10:57 AM Tyson Hamilton 
>> wrote:
>>
>>> Bleck. I just realized that it is 'offline' so that won't work. I'll
>>> clean up manually on the machine using the cron command.
>>>
>>> On Fri, Jul 24, 2020 at 10:56 AM Tyson Hamilton 
>>> wrote:
>>>
 Something isn't working with the current set up because node 15
 appears to be out of space and is currently 'offline' according to 
 Jenkins.
 Can someone run the cleanup job? The machine is full,

 @apache-ci-beam-jenkins-15:/tmp$ df -h
 

Re: No space left on device - beam-jenkins 1 and 7

[Udi Meiri]

The additional slots (@3 directories) take up even more space now than
before.

I'm testing out https://github.com/apache/beam/pull/12326 which could help
by cleaning up workspaces after a run (just started a seed job).

On Fri, Jul 24, 2020 at 12:13 PM Tyson Hamilton  wrote:

> 664Mbeam_PreCommit_JavaPortabilityApi_Commit
> 656Mbeam_PreCommit_JavaPortabilityApi_Commit@2
> 611Mbeam_PreCommit_JavaPortabilityApi_Cron
> 616Mbeam_PreCommit_JavaPortabilityApiJava11_Commit
> 598Mbeam_PreCommit_JavaPortabilityApiJava11_Commit@2
> 662Mbeam_PreCommit_JavaPortabilityApiJava11_Cron
> 2.9Gbeam_PreCommit_Portable_Python_Commit
> 2.9Gbeam_PreCommit_Portable_Python_Commit@2
> 1.7Gbeam_PreCommit_Portable_Python_Commit@3
> 3.4Gbeam_PreCommit_Portable_Python_Cron
> 1.9Gbeam_PreCommit_Python2_PVR_Flink_Commit
> 1.4Gbeam_PreCommit_Python2_PVR_Flink_Cron
> 1.3Gbeam_PreCommit_Python2_PVR_Flink_Phrase
> 6.2Gbeam_PreCommit_Python_Commit
> 7.5Gbeam_PreCommit_Python_Commit@2
> 7.5Gbeam_PreCommit_Python_Cron
> 1012M   beam_PreCommit_PythonDocker_Commit
> 1011M   beam_PreCommit_PythonDocker_Commit@2
> 1011M   beam_PreCommit_PythonDocker_Commit@3
> 1002M   beam_PreCommit_PythonDocker_Cron
> 877Mbeam_PreCommit_PythonFormatter_Commit
> 988Mbeam_PreCommit_PythonFormatter_Cron
> 986Mbeam_PreCommit_PythonFormatter_Phrase
> 1.7Gbeam_PreCommit_PythonLint_Commit
> 2.1Gbeam_PreCommit_PythonLint_Cron
> 7.5Gbeam_PreCommit_Python_Phrase
> 346Mbeam_PreCommit_RAT_Commit
> 341Mbeam_PreCommit_RAT_Cron
> 338Mbeam_PreCommit_Spotless_Commit
> 339Mbeam_PreCommit_Spotless_Cron
> 5.5Gbeam_PreCommit_SQL_Commit
> 5.5Gbeam_PreCommit_SQL_Cron
> 5.5Gbeam_PreCommit_SQL_Java11_Commit
> 750Mbeam_PreCommit_Website_Commit
> 750Mbeam_PreCommit_Website_Commit@2
> 750Mbeam_PreCommit_Website_Cron
> 764Mbeam_PreCommit_Website_Stage_GCS_Commit
> 771Mbeam_PreCommit_Website_Stage_GCS_Cron
> 336Mbeam_Prober_CommunityMetrics
> 693Mbeam_python_mongoio_load_test
> 339Mbeam_SeedJob
> 333Mbeam_SeedJob_Standalone
> 334Mbeam_sonarqube_report
> 556Mbeam_SQLBigQueryIO_Batch_Performance_Test_Java
> 175Gtotal
>
> On Fri, Jul 24, 2020 at 12:04 PM Tyson Hamilton 
> wrote:
>
>> Ya looks like something in the workspaces is taking up room:
>>
>> @apache-ci-beam-jenkins-8:/home/jenkins$ sudo du -shc .
>> 191G.
>> 191Gtotal
>>
>>
>> On Fri, Jul 24, 2020 at 11:44 AM Tyson Hamilton 
>> wrote:
>>
>>> Node 8 is also full. The partition that /tmp is on is here:
>>>
>>> Filesystem  Size  Used Avail Use% Mounted on
>>> /dev/sda1   485G  482G  2.9G 100% /
>>>
>>> however after cleaning up tmp with the crontab command, there is only 8G
>>> usage yet it still remains 100% full:
>>>
>>> @apache-ci-beam-jenkins-8:/tmp$ sudo du -shc /tmp
>>> 8.0G/tmp
>>> 8.0Gtotal
>>>
>>> The workspaces are in the /home/jenkins/jenkins-slave/workspace
>>> directory. When I run a du on that, it takes really long. I'll let it keep
>>> running for a while to see if it ever returns a result but so far this
>>> seems suspect.
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jul 24, 2020 at 11:19 AM Tyson Hamilton 
>>> wrote:
>>>
 Everything I've been looking at is in the /tmp dir. Where are the
 workspaces, or what are the named?




 On Fri, Jul 24, 2020 at 11:03 AM Udi Meiri  wrote:

> I'm curious to what you find. Was it /tmp or the workspaces using up
> the space?
>
> On Fri, Jul 24, 2020 at 10:57 AM Tyson Hamilton 
> wrote:
>
>> Bleck. I just realized that it is 'offline' so that won't work. I'll
>> clean up manually on the machine using the cron command.
>>
>> On Fri, Jul 24, 2020 at 10:56 AM Tyson Hamilton 
>> wrote:
>>
>>> Something isn't working with the current set up because node 15
>>> appears to be out of space and is currently 'offline' according to 
>>> Jenkins.
>>> Can someone run the cleanup job? The machine is full,
>>>
>>> @apache-ci-beam-jenkins-15:/tmp$ df -h
>>> Filesystem  Size  Used Avail Use% Mounted on
>>> udev 52G 0   52G   0% /dev
>>> tmpfs11G  265M   10G   3% /run
>>> */dev/sda1   485G  484G  880M 100% /*
>>> tmpfs52G 0   52G   0% /dev/shm
>>> tmpfs   5.0M 0  5.0M   0% /run/lock
>>> tmpfs52G 0   52G   0% /sys/fs/cgroup
>>> tmpfs11G 0   11G   0% /run/user/1017
>>> tmpfs11G 0   11G   0% /run/user/1037
>>>
>>> apache-ci-beam-jenkins-15:/tmp$ sudo du -ah --time . | sort -rhk 1,1
>>> | head -n 20
>>> 20G 2020-07-24 17:52.
>>> 580M2020-07-22 17:31./junit1031982597110125586
>>> 517M2020-07-22 17:31
>>>  ./junit1031982597110125586/junit8739924829337821410/heap_dump.hprof
>>> 517M2020-07-22 17:31
>>>  

Re: No space left on device - beam-jenkins 1 and 7

[Tyson Hamilton]

664Mbeam_PreCommit_JavaPortabilityApi_Commit
656Mbeam_PreCommit_JavaPortabilityApi_Commit@2
611Mbeam_PreCommit_JavaPortabilityApi_Cron
616Mbeam_PreCommit_JavaPortabilityApiJava11_Commit
598Mbeam_PreCommit_JavaPortabilityApiJava11_Commit@2
662Mbeam_PreCommit_JavaPortabilityApiJava11_Cron
2.9Gbeam_PreCommit_Portable_Python_Commit
2.9Gbeam_PreCommit_Portable_Python_Commit@2
1.7Gbeam_PreCommit_Portable_Python_Commit@3
3.4Gbeam_PreCommit_Portable_Python_Cron
1.9Gbeam_PreCommit_Python2_PVR_Flink_Commit
1.4Gbeam_PreCommit_Python2_PVR_Flink_Cron
1.3Gbeam_PreCommit_Python2_PVR_Flink_Phrase
6.2Gbeam_PreCommit_Python_Commit
7.5Gbeam_PreCommit_Python_Commit@2
7.5Gbeam_PreCommit_Python_Cron
1012M   beam_PreCommit_PythonDocker_Commit
1011M   beam_PreCommit_PythonDocker_Commit@2
1011M   beam_PreCommit_PythonDocker_Commit@3
1002M   beam_PreCommit_PythonDocker_Cron
877Mbeam_PreCommit_PythonFormatter_Commit
988Mbeam_PreCommit_PythonFormatter_Cron
986Mbeam_PreCommit_PythonFormatter_Phrase
1.7Gbeam_PreCommit_PythonLint_Commit
2.1Gbeam_PreCommit_PythonLint_Cron
7.5Gbeam_PreCommit_Python_Phrase
346Mbeam_PreCommit_RAT_Commit
341Mbeam_PreCommit_RAT_Cron
338Mbeam_PreCommit_Spotless_Commit
339Mbeam_PreCommit_Spotless_Cron
5.5Gbeam_PreCommit_SQL_Commit
5.5Gbeam_PreCommit_SQL_Cron
5.5Gbeam_PreCommit_SQL_Java11_Commit
750Mbeam_PreCommit_Website_Commit
750Mbeam_PreCommit_Website_Commit@2
750Mbeam_PreCommit_Website_Cron
764Mbeam_PreCommit_Website_Stage_GCS_Commit
771Mbeam_PreCommit_Website_Stage_GCS_Cron
336Mbeam_Prober_CommunityMetrics
693Mbeam_python_mongoio_load_test
339Mbeam_SeedJob
333Mbeam_SeedJob_Standalone
334Mbeam_sonarqube_report
556Mbeam_SQLBigQueryIO_Batch_Performance_Test_Java
175Gtotal

On Fri, Jul 24, 2020 at 12:04 PM Tyson Hamilton  wrote:

> Ya looks like something in the workspaces is taking up room:
>
> @apache-ci-beam-jenkins-8:/home/jenkins$ sudo du -shc .
> 191G.
> 191Gtotal
>
>
> On Fri, Jul 24, 2020 at 11:44 AM Tyson Hamilton 
> wrote:
>
>> Node 8 is also full. The partition that /tmp is on is here:
>>
>> Filesystem  Size  Used Avail Use% Mounted on
>> /dev/sda1   485G  482G  2.9G 100% /
>>
>> however after cleaning up tmp with the crontab command, there is only 8G
>> usage yet it still remains 100% full:
>>
>> @apache-ci-beam-jenkins-8:/tmp$ sudo du -shc /tmp
>> 8.0G/tmp
>> 8.0Gtotal
>>
>> The workspaces are in the /home/jenkins/jenkins-slave/workspace
>> directory. When I run a du on that, it takes really long. I'll let it keep
>> running for a while to see if it ever returns a result but so far this
>> seems suspect.
>>
>>
>>
>>
>>
>> On Fri, Jul 24, 2020 at 11:19 AM Tyson Hamilton 
>> wrote:
>>
>>> Everything I've been looking at is in the /tmp dir. Where are the
>>> workspaces, or what are the named?
>>>
>>>
>>>
>>>
>>> On Fri, Jul 24, 2020 at 11:03 AM Udi Meiri  wrote:
>>>
 I'm curious to what you find. Was it /tmp or the workspaces using up
 the space?

 On Fri, Jul 24, 2020 at 10:57 AM Tyson Hamilton 
 wrote:

> Bleck. I just realized that it is 'offline' so that won't work. I'll
> clean up manually on the machine using the cron command.
>
> On Fri, Jul 24, 2020 at 10:56 AM Tyson Hamilton 
> wrote:
>
>> Something isn't working with the current set up because node 15
>> appears to be out of space and is currently 'offline' according to 
>> Jenkins.
>> Can someone run the cleanup job? The machine is full,
>>
>> @apache-ci-beam-jenkins-15:/tmp$ df -h
>> Filesystem  Size  Used Avail Use% Mounted on
>> udev 52G 0   52G   0% /dev
>> tmpfs11G  265M   10G   3% /run
>> */dev/sda1   485G  484G  880M 100% /*
>> tmpfs52G 0   52G   0% /dev/shm
>> tmpfs   5.0M 0  5.0M   0% /run/lock
>> tmpfs52G 0   52G   0% /sys/fs/cgroup
>> tmpfs11G 0   11G   0% /run/user/1017
>> tmpfs11G 0   11G   0% /run/user/1037
>>
>> apache-ci-beam-jenkins-15:/tmp$ sudo du -ah --time . | sort -rhk 1,1
>> | head -n 20
>> 20G 2020-07-24 17:52.
>> 580M2020-07-22 17:31./junit1031982597110125586
>> 517M2020-07-22 17:31
>>  ./junit1031982597110125586/junit8739924829337821410/heap_dump.hprof
>> 517M2020-07-22 17:31
>>  ./junit1031982597110125586/junit8739924829337821410
>> 263M2020-07-22 12:23./pip-install-2GUhO_
>> 263M2020-07-20 09:30./pip-install-sxgwqr
>> 263M2020-07-17 13:56./pip-install-bWSKIV
>> 242M2020-07-21 20:25./beam-pipeline-tempmByU6T
>> 242M2020-07-21 20:21./beam-pipeline-tempV85xeK
>> 242M2020-07-21 20:15./beam-pipeline-temp7dJROJ
>> 236M2020-07-21 20:25

Re: No space left on device - beam-jenkins 1 and 7

[Tyson Hamilton]

Ya looks like something in the workspaces is taking up room:

@apache-ci-beam-jenkins-8:/home/jenkins$ sudo du -shc .
191G.
191Gtotal


On Fri, Jul 24, 2020 at 11:44 AM Tyson Hamilton  wrote:

> Node 8 is also full. The partition that /tmp is on is here:
>
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/sda1   485G  482G  2.9G 100% /
>
> however after cleaning up tmp with the crontab command, there is only 8G
> usage yet it still remains 100% full:
>
> @apache-ci-beam-jenkins-8:/tmp$ sudo du -shc /tmp
> 8.0G/tmp
> 8.0Gtotal
>
> The workspaces are in the /home/jenkins/jenkins-slave/workspace directory.
> When I run a du on that, it takes really long. I'll let it keep running for
> a while to see if it ever returns a result but so far this seems suspect.
>
>
>
>
>
> On Fri, Jul 24, 2020 at 11:19 AM Tyson Hamilton 
> wrote:
>
>> Everything I've been looking at is in the /tmp dir. Where are the
>> workspaces, or what are the named?
>>
>>
>>
>>
>> On Fri, Jul 24, 2020 at 11:03 AM Udi Meiri  wrote:
>>
>>> I'm curious to what you find. Was it /tmp or the workspaces using up the
>>> space?
>>>
>>> On Fri, Jul 24, 2020 at 10:57 AM Tyson Hamilton 
>>> wrote:
>>>
 Bleck. I just realized that it is 'offline' so that won't work. I'll
 clean up manually on the machine using the cron command.

 On Fri, Jul 24, 2020 at 10:56 AM Tyson Hamilton 
 wrote:

> Something isn't working with the current set up because node 15
> appears to be out of space and is currently 'offline' according to 
> Jenkins.
> Can someone run the cleanup job? The machine is full,
>
> @apache-ci-beam-jenkins-15:/tmp$ df -h
> Filesystem  Size  Used Avail Use% Mounted on
> udev 52G 0   52G   0% /dev
> tmpfs11G  265M   10G   3% /run
> */dev/sda1   485G  484G  880M 100% /*
> tmpfs52G 0   52G   0% /dev/shm
> tmpfs   5.0M 0  5.0M   0% /run/lock
> tmpfs52G 0   52G   0% /sys/fs/cgroup
> tmpfs11G 0   11G   0% /run/user/1017
> tmpfs11G 0   11G   0% /run/user/1037
>
> apache-ci-beam-jenkins-15:/tmp$ sudo du -ah --time . | sort -rhk 1,1 |
> head -n 20
> 20G 2020-07-24 17:52.
> 580M2020-07-22 17:31./junit1031982597110125586
> 517M2020-07-22 17:31
>  ./junit1031982597110125586/junit8739924829337821410/heap_dump.hprof
> 517M2020-07-22 17:31
>  ./junit1031982597110125586/junit8739924829337821410
> 263M2020-07-22 12:23./pip-install-2GUhO_
> 263M2020-07-20 09:30./pip-install-sxgwqr
> 263M2020-07-17 13:56./pip-install-bWSKIV
> 242M2020-07-21 20:25./beam-pipeline-tempmByU6T
> 242M2020-07-21 20:21./beam-pipeline-tempV85xeK
> 242M2020-07-21 20:15./beam-pipeline-temp7dJROJ
> 236M2020-07-21 20:25./beam-pipeline-tempmByU6T/tmpOWj3Yr
> 236M2020-07-21 20:21./beam-pipeline-tempV85xeK/tmppbQHB3
> 236M2020-07-21 20:15./beam-pipeline-temp7dJROJ/tmpgOXPKW
> 111M2020-07-23 00:57./pip-install-1JnyNE
> 105M2020-07-23 00:17./beam-artifact1374651823280819755
> 105M2020-07-23 00:16./beam-artifact5050755582921936972
> 105M2020-07-23 00:16./beam-artifact1834064452502646289
> 105M2020-07-23 00:15./beam-artifact682561790267074916
> 105M2020-07-23 00:15./beam-artifact4691304965824489394
> 105M2020-07-23 00:14./beam-artifact4050383819822604421
>
> On Wed, Jul 22, 2020 at 12:03 PM Robert Bradshaw 
> wrote:
>
>> On Wed, Jul 22, 2020 at 11:57 AM Tyson Hamilton 
>> wrote:
>>
>>> Ah I see, thanks Kenn. I found some advice from the Apache infra
>>> wiki that also suggests using a tmpdir inside the workspace [1]:
>>>
>>> Procedures Projects can take to clean up disk space
>>>
>>> Projects can help themselves and Infra by taking some basic steps to
>>> help clean up their jobs after themselves on the build nodes.
>>>
>>>
>>>
>>>1. Use a ./tmp dir in your jobs workspace. That way it gets
>>>cleaned up when job workspaces expire.
>>>
>>>
>> Tests should be (able to be) written to use the standard temporary
>> file mechanisms, and the environment set up on Jenkins such that that 
>> falls
>> into the respective workspaces. Ideally this should be as simple as 
>> setting
>> the TMPDIR (or similar) environment variable (and making sure it 
>> exists/is
>> writable).
>>
>>>
>>>1. Configure your jobs to wipe workspaces on start or finish.
>>>2. Configure your jobs to only keep 5 or 10 previous builds.
>>>3. Configure your jobs to only keep 5 or 10 previous artifacts.
>>>
>>>
>>>
>>> [1]:
>>> 

Re: No space left on device - beam-jenkins 1 and 7

[Tyson Hamilton]

Node 8 is also full. The partition that /tmp is on is here:

Filesystem  Size  Used Avail Use% Mounted on
/dev/sda1   485G  482G  2.9G 100% /

however after cleaning up tmp with the crontab command, there is only 8G
usage yet it still remains 100% full:

@apache-ci-beam-jenkins-8:/tmp$ sudo du -shc /tmp
8.0G/tmp
8.0Gtotal

The workspaces are in the /home/jenkins/jenkins-slave/workspace directory.
When I run a du on that, it takes really long. I'll let it keep running for
a while to see if it ever returns a result but so far this seems suspect.





On Fri, Jul 24, 2020 at 11:19 AM Tyson Hamilton  wrote:

> Everything I've been looking at is in the /tmp dir. Where are the
> workspaces, or what are the named?
>
>
>
>
> On Fri, Jul 24, 2020 at 11:03 AM Udi Meiri  wrote:
>
>> I'm curious to what you find. Was it /tmp or the workspaces using up the
>> space?
>>
>> On Fri, Jul 24, 2020 at 10:57 AM Tyson Hamilton 
>> wrote:
>>
>>> Bleck. I just realized that it is 'offline' so that won't work. I'll
>>> clean up manually on the machine using the cron command.
>>>
>>> On Fri, Jul 24, 2020 at 10:56 AM Tyson Hamilton 
>>> wrote:
>>>
 Something isn't working with the current set up because node 15 appears
 to be out of space and is currently 'offline' according to Jenkins. Can
 someone run the cleanup job? The machine is full,

 @apache-ci-beam-jenkins-15:/tmp$ df -h
 Filesystem  Size  Used Avail Use% Mounted on
 udev 52G 0   52G   0% /dev
 tmpfs11G  265M   10G   3% /run
 */dev/sda1   485G  484G  880M 100% /*
 tmpfs52G 0   52G   0% /dev/shm
 tmpfs   5.0M 0  5.0M   0% /run/lock
 tmpfs52G 0   52G   0% /sys/fs/cgroup
 tmpfs11G 0   11G   0% /run/user/1017
 tmpfs11G 0   11G   0% /run/user/1037

 apache-ci-beam-jenkins-15:/tmp$ sudo du -ah --time . | sort -rhk 1,1 |
 head -n 20
 20G 2020-07-24 17:52.
 580M2020-07-22 17:31./junit1031982597110125586
 517M2020-07-22 17:31
  ./junit1031982597110125586/junit8739924829337821410/heap_dump.hprof
 517M2020-07-22 17:31
  ./junit1031982597110125586/junit8739924829337821410
 263M2020-07-22 12:23./pip-install-2GUhO_
 263M2020-07-20 09:30./pip-install-sxgwqr
 263M2020-07-17 13:56./pip-install-bWSKIV
 242M2020-07-21 20:25./beam-pipeline-tempmByU6T
 242M2020-07-21 20:21./beam-pipeline-tempV85xeK
 242M2020-07-21 20:15./beam-pipeline-temp7dJROJ
 236M2020-07-21 20:25./beam-pipeline-tempmByU6T/tmpOWj3Yr
 236M2020-07-21 20:21./beam-pipeline-tempV85xeK/tmppbQHB3
 236M2020-07-21 20:15./beam-pipeline-temp7dJROJ/tmpgOXPKW
 111M2020-07-23 00:57./pip-install-1JnyNE
 105M2020-07-23 00:17./beam-artifact1374651823280819755
 105M2020-07-23 00:16./beam-artifact5050755582921936972
 105M2020-07-23 00:16./beam-artifact1834064452502646289
 105M2020-07-23 00:15./beam-artifact682561790267074916
 105M2020-07-23 00:15./beam-artifact4691304965824489394
 105M2020-07-23 00:14./beam-artifact4050383819822604421

 On Wed, Jul 22, 2020 at 12:03 PM Robert Bradshaw 
 wrote:

> On Wed, Jul 22, 2020 at 11:57 AM Tyson Hamilton 
> wrote:
>
>> Ah I see, thanks Kenn. I found some advice from the Apache infra wiki
>> that also suggests using a tmpdir inside the workspace [1]:
>>
>> Procedures Projects can take to clean up disk space
>>
>> Projects can help themselves and Infra by taking some basic steps to
>> help clean up their jobs after themselves on the build nodes.
>>
>>
>>
>>1. Use a ./tmp dir in your jobs workspace. That way it gets
>>cleaned up when job workspaces expire.
>>
>>
> Tests should be (able to be) written to use the standard temporary
> file mechanisms, and the environment set up on Jenkins such that that 
> falls
> into the respective workspaces. Ideally this should be as simple as 
> setting
> the TMPDIR (or similar) environment variable (and making sure it exists/is
> writable).
>
>>
>>1. Configure your jobs to wipe workspaces on start or finish.
>>2. Configure your jobs to only keep 5 or 10 previous builds.
>>3. Configure your jobs to only keep 5 or 10 previous artifacts.
>>
>>
>>
>> [1]:
>> https://cwiki.apache.org/confluence/display/INFRA/Disk+Space+cleanup+of+Jenkins+nodes
>>
>> On Wed, Jul 22, 2020 at 8:06 AM Kenneth Knowles 
>> wrote:
>>
>>> Those file listings look like the result of using standard temp file
>>> APIs but with TMPDIR set to /tmp.
>>>
>>> On Mon, Jul 20, 2020 at 7:55 PM Tyson Hamilton 

Re: No space left on device - beam-jenkins 1 and 7

[Udi Meiri]

In the "jenkins" user home directory.

On Fri, Jul 24, 2020, 11:19 Tyson Hamilton  wrote:

> Everything I've been looking at is in the /tmp dir. Where are the
> workspaces, or what are the named?
>
>
>
>
> On Fri, Jul 24, 2020 at 11:03 AM Udi Meiri  wrote:
>
>> I'm curious to what you find. Was it /tmp or the workspaces using up the
>> space?
>>
>> On Fri, Jul 24, 2020 at 10:57 AM Tyson Hamilton 
>> wrote:
>>
>>> Bleck. I just realized that it is 'offline' so that won't work. I'll
>>> clean up manually on the machine using the cron command.
>>>
>>> On Fri, Jul 24, 2020 at 10:56 AM Tyson Hamilton 
>>> wrote:
>>>
 Something isn't working with the current set up because node 15 appears
 to be out of space and is currently 'offline' according to Jenkins. Can
 someone run the cleanup job? The machine is full,

 @apache-ci-beam-jenkins-15:/tmp$ df -h
 Filesystem  Size  Used Avail Use% Mounted on
 udev 52G 0   52G   0% /dev
 tmpfs11G  265M   10G   3% /run
 */dev/sda1   485G  484G  880M 100% /*
 tmpfs52G 0   52G   0% /dev/shm
 tmpfs   5.0M 0  5.0M   0% /run/lock
 tmpfs52G 0   52G   0% /sys/fs/cgroup
 tmpfs11G 0   11G   0% /run/user/1017
 tmpfs11G 0   11G   0% /run/user/1037

 apache-ci-beam-jenkins-15:/tmp$ sudo du -ah --time . | sort -rhk 1,1 |
 head -n 20
 20G 2020-07-24 17:52.
 580M2020-07-22 17:31./junit1031982597110125586
 517M2020-07-22 17:31
  ./junit1031982597110125586/junit8739924829337821410/heap_dump.hprof
 517M2020-07-22 17:31
  ./junit1031982597110125586/junit8739924829337821410
 263M2020-07-22 12:23./pip-install-2GUhO_
 263M2020-07-20 09:30./pip-install-sxgwqr
 263M2020-07-17 13:56./pip-install-bWSKIV
 242M2020-07-21 20:25./beam-pipeline-tempmByU6T
 242M2020-07-21 20:21./beam-pipeline-tempV85xeK
 242M2020-07-21 20:15./beam-pipeline-temp7dJROJ
 236M2020-07-21 20:25./beam-pipeline-tempmByU6T/tmpOWj3Yr
 236M2020-07-21 20:21./beam-pipeline-tempV85xeK/tmppbQHB3
 236M2020-07-21 20:15./beam-pipeline-temp7dJROJ/tmpgOXPKW
 111M2020-07-23 00:57./pip-install-1JnyNE
 105M2020-07-23 00:17./beam-artifact1374651823280819755
 105M2020-07-23 00:16./beam-artifact5050755582921936972
 105M2020-07-23 00:16./beam-artifact1834064452502646289
 105M2020-07-23 00:15./beam-artifact682561790267074916
 105M2020-07-23 00:15./beam-artifact4691304965824489394
 105M2020-07-23 00:14./beam-artifact4050383819822604421

 On Wed, Jul 22, 2020 at 12:03 PM Robert Bradshaw 
 wrote:

> On Wed, Jul 22, 2020 at 11:57 AM Tyson Hamilton 
> wrote:
>
>> Ah I see, thanks Kenn. I found some advice from the Apache infra wiki
>> that also suggests using a tmpdir inside the workspace [1]:
>>
>> Procedures Projects can take to clean up disk space
>>
>> Projects can help themselves and Infra by taking some basic steps to
>> help clean up their jobs after themselves on the build nodes.
>>
>>
>>
>>1. Use a ./tmp dir in your jobs workspace. That way it gets
>>cleaned up when job workspaces expire.
>>
>>
> Tests should be (able to be) written to use the standard temporary
> file mechanisms, and the environment set up on Jenkins such that that 
> falls
> into the respective workspaces. Ideally this should be as simple as 
> setting
> the TMPDIR (or similar) environment variable (and making sure it exists/is
> writable).
>
>>
>>1. Configure your jobs to wipe workspaces on start or finish.
>>2. Configure your jobs to only keep 5 or 10 previous builds.
>>3. Configure your jobs to only keep 5 or 10 previous artifacts.
>>
>>
>>
>> [1]:
>> https://cwiki.apache.org/confluence/display/INFRA/Disk+Space+cleanup+of+Jenkins+nodes
>>
>> On Wed, Jul 22, 2020 at 8:06 AM Kenneth Knowles 
>> wrote:
>>
>>> Those file listings look like the result of using standard temp file
>>> APIs but with TMPDIR set to /tmp.
>>>
>>> On Mon, Jul 20, 2020 at 7:55 PM Tyson Hamilton 
>>> wrote:
>>>
 Jobs are hermetic as far as I can tell and use unique
 subdirectories inside of /tmp. Here is a quick look into two examples:

 @apache-ci-beam-jenkins-4:/tmp$ sudo du -ah --time . | sort -rhk
 1,1 | head -n 20
 1.6G2020-07-21 02:25.
 242M2020-07-17 18:48./beam-pipeline-temp3ybuY4
 242M2020-07-17 18:46./beam-pipeline-tempuxjiPT
 242M2020-07-17 18:44./beam-pipeline-tempVpg1ME
 242M   

Re: [BROKEN] Please add "Fix Version" when resolving or closing Jiras

[Kenneth Knowles]

I've noticed that when status == Resolved and Resolution == Unresolved,
subtasks are not given the green checkmark of doneness. Just noting another
quality-of-life issue caused here.

Kenn

On Thu, Jul 23, 2020 at 4:09 PM Brian Hulette  wrote:

> +1 - I think I saw somewhere Resolved is intended for "this is fixed"
> while Closed is "the reporter/some authority has verified it's fixed".
> Doesn't seem to apply to us.
>
> On Thu, Jul 23, 2020 at 2:21 PM Kyle Weaver  wrote:
>
>> > we could simplify those to a single state and let the Resolution field
>> be the one source of truth for the nature of the resolution.
>>
>> +1
>>
>> On Thu, Jul 23, 2020 at 2:14 PM Kenneth Knowles  wrote:
>>
>>> This is unfortunate :-(
>>>
>>> Also unfortunate: I have just enough permissions to mess it up and not
>>> enough to fix it. You can follow
>>> https://issues.apache.org/jira/browse/INFRA-20563
>>>
>>> By the way, does anyone really use the difference between "Resolved" and
>>> "Closed"? Since I am talking to Infra and probably getting our workflow
>>> re-initialized manually, we could simplify those to a single state and let
>>> the Resolution field be the one source of truth for the nature of the
>>> resolution. (typically I think fixed things get "resolved" while wontfix
>>> issues get "closed" - this is not actually what the difference is supposed
>>> to be)
>>>
>>> Kenn
>>>
>>> On Thu, Jul 23, 2020 at 9:43 AM Brian Hulette 
>>> wrote:
>>>
 Yeah same for me. Not a huge deal.. I just noticed that the jira UI
 isn't rendering references to my closed tickets with a strikethrough, and
 I'd like to distinguish others as "won't fix" or "obsolete". It should be
 easy enough to backfill these once this is sorted out though.

 Brian

 On Thu, Jul 23, 2020 at 2:01 AM Maximilian Michels 
 wrote:

> I can close/resolve but it will show "Resolution: Unresolved":
>
> On 23.07.20 02:30, Brian Hulette wrote:
>
> Is setting the Resolution broken as well? I realized I've been closing
> jiras with Resolution "Unresolved" and I can't actually change it to
> "Fixed".
>
> On Tue, Jul 21, 2020 at 7:19 AM Maximilian Michels 
> wrote:
>
>> Also, a friendly reminder to always close the JIRA issue after
>> merging a
>> fix. It's easy to forget.
>>
>> On 20.07.20 21:04, Kenneth Knowles wrote:
>> > Hi all,
>> >
>> > In working on our Jira automation, I've messed up our Jira
>> workflow. It
>> > will no longer prompt you to fill in "Fix Version" when you resolve
>> or
>> > close an issue. I will be working with infra to restore this. In
>> the
>> > meantime, please try to remember to add a Fix Version to each issue
>> that
>> > you close, so that we get automated detailed release notes.
>> >
>> > Kenn
>>
>

Re: No space left on device - beam-jenkins 1 and 7

[Tyson Hamilton]

Everything I've been looking at is in the /tmp dir. Where are the
workspaces, or what are the named?




On Fri, Jul 24, 2020 at 11:03 AM Udi Meiri  wrote:

> I'm curious to what you find. Was it /tmp or the workspaces using up the
> space?
>
> On Fri, Jul 24, 2020 at 10:57 AM Tyson Hamilton 
> wrote:
>
>> Bleck. I just realized that it is 'offline' so that won't work. I'll
>> clean up manually on the machine using the cron command.
>>
>> On Fri, Jul 24, 2020 at 10:56 AM Tyson Hamilton 
>> wrote:
>>
>>> Something isn't working with the current set up because node 15 appears
>>> to be out of space and is currently 'offline' according to Jenkins. Can
>>> someone run the cleanup job? The machine is full,
>>>
>>> @apache-ci-beam-jenkins-15:/tmp$ df -h
>>> Filesystem  Size  Used Avail Use% Mounted on
>>> udev 52G 0   52G   0% /dev
>>> tmpfs11G  265M   10G   3% /run
>>> */dev/sda1   485G  484G  880M 100% /*
>>> tmpfs52G 0   52G   0% /dev/shm
>>> tmpfs   5.0M 0  5.0M   0% /run/lock
>>> tmpfs52G 0   52G   0% /sys/fs/cgroup
>>> tmpfs11G 0   11G   0% /run/user/1017
>>> tmpfs11G 0   11G   0% /run/user/1037
>>>
>>> apache-ci-beam-jenkins-15:/tmp$ sudo du -ah --time . | sort -rhk 1,1 |
>>> head -n 20
>>> 20G 2020-07-24 17:52.
>>> 580M2020-07-22 17:31./junit1031982597110125586
>>> 517M2020-07-22 17:31
>>>  ./junit1031982597110125586/junit8739924829337821410/heap_dump.hprof
>>> 517M2020-07-22 17:31
>>>  ./junit1031982597110125586/junit8739924829337821410
>>> 263M2020-07-22 12:23./pip-install-2GUhO_
>>> 263M2020-07-20 09:30./pip-install-sxgwqr
>>> 263M2020-07-17 13:56./pip-install-bWSKIV
>>> 242M2020-07-21 20:25./beam-pipeline-tempmByU6T
>>> 242M2020-07-21 20:21./beam-pipeline-tempV85xeK
>>> 242M2020-07-21 20:15./beam-pipeline-temp7dJROJ
>>> 236M2020-07-21 20:25./beam-pipeline-tempmByU6T/tmpOWj3Yr
>>> 236M2020-07-21 20:21./beam-pipeline-tempV85xeK/tmppbQHB3
>>> 236M2020-07-21 20:15./beam-pipeline-temp7dJROJ/tmpgOXPKW
>>> 111M2020-07-23 00:57./pip-install-1JnyNE
>>> 105M2020-07-23 00:17./beam-artifact1374651823280819755
>>> 105M2020-07-23 00:16./beam-artifact5050755582921936972
>>> 105M2020-07-23 00:16./beam-artifact1834064452502646289
>>> 105M2020-07-23 00:15./beam-artifact682561790267074916
>>> 105M2020-07-23 00:15./beam-artifact4691304965824489394
>>> 105M2020-07-23 00:14./beam-artifact4050383819822604421
>>>
>>> On Wed, Jul 22, 2020 at 12:03 PM Robert Bradshaw 
>>> wrote:
>>>
 On Wed, Jul 22, 2020 at 11:57 AM Tyson Hamilton 
 wrote:

> Ah I see, thanks Kenn. I found some advice from the Apache infra wiki
> that also suggests using a tmpdir inside the workspace [1]:
>
> Procedures Projects can take to clean up disk space
>
> Projects can help themselves and Infra by taking some basic steps to
> help clean up their jobs after themselves on the build nodes.
>
>
>
>1. Use a ./tmp dir in your jobs workspace. That way it gets
>cleaned up when job workspaces expire.
>
>
 Tests should be (able to be) written to use the standard temporary file
 mechanisms, and the environment set up on Jenkins such that that falls into
 the respective workspaces. Ideally this should be as simple as setting
 the TMPDIR (or similar) environment variable (and making sure it exists/is
 writable).

>
>1. Configure your jobs to wipe workspaces on start or finish.
>2. Configure your jobs to only keep 5 or 10 previous builds.
>3. Configure your jobs to only keep 5 or 10 previous artifacts.
>
>
>
> [1]:
> https://cwiki.apache.org/confluence/display/INFRA/Disk+Space+cleanup+of+Jenkins+nodes
>
> On Wed, Jul 22, 2020 at 8:06 AM Kenneth Knowles 
> wrote:
>
>> Those file listings look like the result of using standard temp file
>> APIs but with TMPDIR set to /tmp.
>>
>> On Mon, Jul 20, 2020 at 7:55 PM Tyson Hamilton 
>> wrote:
>>
>>> Jobs are hermetic as far as I can tell and use unique subdirectories
>>> inside of /tmp. Here is a quick look into two examples:
>>>
>>> @apache-ci-beam-jenkins-4:/tmp$ sudo du -ah --time . | sort -rhk 1,1
>>> | head -n 20
>>> 1.6G2020-07-21 02:25.
>>> 242M2020-07-17 18:48./beam-pipeline-temp3ybuY4
>>> 242M2020-07-17 18:46./beam-pipeline-tempuxjiPT
>>> 242M2020-07-17 18:44./beam-pipeline-tempVpg1ME
>>> 242M2020-07-17 18:42./beam-pipeline-tempJ4EpyB
>>> 242M2020-07-17 18:39./beam-pipeline-tempepea7Q
>>> 242M2020-07-17 18:35./beam-pipeline-temp79qot2
>>> 236M2020-07-17 18:48 

Re: Go error when building containers

[Brian Hulette]

I tried removing every .gogradle directory in Beam, as well
as ~/.cache/go-build and ~/.gradle/go/repo but it's still happening. Maybe
there's some other cache I'm missing? I also synced past
https://github.com/apache/beam/pull/12364 in case it was related.

I thought maybe others were having the same issue but I guess this is a
problem unique to me.

On Thu, Jul 23, 2020 at 6:33 PM Daniel Oliveira 
wrote:

> It looks like the cached version of a package is stale and causing build
> errors when building beam. Chances are just deleting that
> /.gogradle directory will cause everything to rebuild from a clean state,
> so I'd try that. I think it should be /sdks/go/.gogradle
>
> On Thu, Jul 23, 2020 at 4:56 PM Ahmet Altay  wrote:
>
>> This is probably : https://issues.apache.org/jira/browse/BEAM-10567
>> 
>>
>> On Thu, Jul 23, 2020 at 4:53 PM Brian Hulette 
>> wrote:
>>
>>> Whenever I build a container locally
>>> (:sdks:java:container:docker, :sdks:python:container:py37:docker, ..) I get
>>> a Go error (log at the end of this message).
>>>
>>> I've discovered I can just comment
>>> out resolveBuildDependencies.dependsOn ":sdks:go:goBuild" in the relevant
>>> build.gradle file [1] whenever this happens, but it's getting old and I'm
>>> wondering if there's a better way. Is there something wrong with my
>>> environment that's causing these errors (It must not be an actual breakage
>>> in the Go SDK)? Can we remove or modify this statement to fix this?
>>>
>>> Thanks,
>>> Brian
>>>
>>> [1]
>>> https://github.com/apache/beam/blob/59b7200c8621b81804d53ded771fd3aa525fbb47/sdks/java/container/build.gradle#L32
>>>
>>> # github.com/apache/beam/sdks/go/test/integration/synthetic
>>> .gogradle/project_gopath/src/
>>> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:31:31:
>>> cannot use s (type "
>>> github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
>>> as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument to
>>> synthetic.SourceSingle
>>> .gogradle/project_gopath/src/
>>> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:33:24:
>>> cannot use s (type "
>>> github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
>>> as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument to
>>> synthetic.Step
>>> .gogradle/project_gopath/src/
>>> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:34:2:
>>> undefined: passert.Count
>>> .gogradle/project_gopath/src/
>>> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:51:25:
>>> cannot use s (type "
>>> github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
>>> as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument to
>>> synthetic.Source
>>> .gogradle/project_gopath/src/
>>> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:51:25:
>>> cannot use configs (type "
>>> github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".PCollection)
>>> as type "github.com/apache/beam/sdks/go/pkg/beam".PCollection in
>>> argument to synthetic.Source
>>> .gogradle/project_gopath/src/
>>> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:52:24:
>>> cannot use s (type "
>>> github.com/apache/beam/sdks/go/test/vendor/github.com/apache/beam/sdks/go/pkg/beam".Scope)
>>> as type "github.com/apache/beam/sdks/go/pkg/beam".Scope in argument to
>>> synthetic.Step
>>> .gogradle/project_gopath/src/
>>> github.com/apache/beam/sdks/go/test/integration/synthetic/synthetic.go:61:2:
>>> undefined: passert.Count
>>>
>>> > Task :sdks:go:buildLinuxAmd64 FAILED
>>>
>>

Re: No space left on device - beam-jenkins 1 and 7

[Udi Meiri]

I'm curious to what you find. Was it /tmp or the workspaces using up the
space?

On Fri, Jul 24, 2020 at 10:57 AM Tyson Hamilton  wrote:

> Bleck. I just realized that it is 'offline' so that won't work. I'll clean
> up manually on the machine using the cron command.
>
> On Fri, Jul 24, 2020 at 10:56 AM Tyson Hamilton 
> wrote:
>
>> Something isn't working with the current set up because node 15 appears
>> to be out of space and is currently 'offline' according to Jenkins. Can
>> someone run the cleanup job? The machine is full,
>>
>> @apache-ci-beam-jenkins-15:/tmp$ df -h
>> Filesystem  Size  Used Avail Use% Mounted on
>> udev 52G 0   52G   0% /dev
>> tmpfs11G  265M   10G   3% /run
>> */dev/sda1   485G  484G  880M 100% /*
>> tmpfs52G 0   52G   0% /dev/shm
>> tmpfs   5.0M 0  5.0M   0% /run/lock
>> tmpfs52G 0   52G   0% /sys/fs/cgroup
>> tmpfs11G 0   11G   0% /run/user/1017
>> tmpfs11G 0   11G   0% /run/user/1037
>>
>> apache-ci-beam-jenkins-15:/tmp$ sudo du -ah --time . | sort -rhk 1,1 |
>> head -n 20
>> 20G 2020-07-24 17:52.
>> 580M2020-07-22 17:31./junit1031982597110125586
>> 517M2020-07-22 17:31
>>  ./junit1031982597110125586/junit8739924829337821410/heap_dump.hprof
>> 517M2020-07-22 17:31
>>  ./junit1031982597110125586/junit8739924829337821410
>> 263M2020-07-22 12:23./pip-install-2GUhO_
>> 263M2020-07-20 09:30./pip-install-sxgwqr
>> 263M2020-07-17 13:56./pip-install-bWSKIV
>> 242M2020-07-21 20:25./beam-pipeline-tempmByU6T
>> 242M2020-07-21 20:21./beam-pipeline-tempV85xeK
>> 242M2020-07-21 20:15./beam-pipeline-temp7dJROJ
>> 236M2020-07-21 20:25./beam-pipeline-tempmByU6T/tmpOWj3Yr
>> 236M2020-07-21 20:21./beam-pipeline-tempV85xeK/tmppbQHB3
>> 236M2020-07-21 20:15./beam-pipeline-temp7dJROJ/tmpgOXPKW
>> 111M2020-07-23 00:57./pip-install-1JnyNE
>> 105M2020-07-23 00:17./beam-artifact1374651823280819755
>> 105M2020-07-23 00:16./beam-artifact5050755582921936972
>> 105M2020-07-23 00:16./beam-artifact1834064452502646289
>> 105M2020-07-23 00:15./beam-artifact682561790267074916
>> 105M2020-07-23 00:15./beam-artifact4691304965824489394
>> 105M2020-07-23 00:14./beam-artifact4050383819822604421
>>
>> On Wed, Jul 22, 2020 at 12:03 PM Robert Bradshaw 
>> wrote:
>>
>>> On Wed, Jul 22, 2020 at 11:57 AM Tyson Hamilton 
>>> wrote:
>>>
 Ah I see, thanks Kenn. I found some advice from the Apache infra wiki
 that also suggests using a tmpdir inside the workspace [1]:

 Procedures Projects can take to clean up disk space

 Projects can help themselves and Infra by taking some basic steps to
 help clean up their jobs after themselves on the build nodes.



1. Use a ./tmp dir in your jobs workspace. That way it gets cleaned
up when job workspaces expire.


>>> Tests should be (able to be) written to use the standard temporary file
>>> mechanisms, and the environment set up on Jenkins such that that falls into
>>> the respective workspaces. Ideally this should be as simple as setting
>>> the TMPDIR (or similar) environment variable (and making sure it exists/is
>>> writable).
>>>

1. Configure your jobs to wipe workspaces on start or finish.
2. Configure your jobs to only keep 5 or 10 previous builds.
3. Configure your jobs to only keep 5 or 10 previous artifacts.



 [1]:
 https://cwiki.apache.org/confluence/display/INFRA/Disk+Space+cleanup+of+Jenkins+nodes

 On Wed, Jul 22, 2020 at 8:06 AM Kenneth Knowles 
 wrote:

> Those file listings look like the result of using standard temp file
> APIs but with TMPDIR set to /tmp.
>
> On Mon, Jul 20, 2020 at 7:55 PM Tyson Hamilton 
> wrote:
>
>> Jobs are hermetic as far as I can tell and use unique subdirectories
>> inside of /tmp. Here is a quick look into two examples:
>>
>> @apache-ci-beam-jenkins-4:/tmp$ sudo du -ah --time . | sort -rhk 1,1
>> | head -n 20
>> 1.6G2020-07-21 02:25.
>> 242M2020-07-17 18:48./beam-pipeline-temp3ybuY4
>> 242M2020-07-17 18:46./beam-pipeline-tempuxjiPT
>> 242M2020-07-17 18:44./beam-pipeline-tempVpg1ME
>> 242M2020-07-17 18:42./beam-pipeline-tempJ4EpyB
>> 242M2020-07-17 18:39./beam-pipeline-tempepea7Q
>> 242M2020-07-17 18:35./beam-pipeline-temp79qot2
>> 236M2020-07-17 18:48./beam-pipeline-temp3ybuY4/tmpy_Ytzz
>> 236M2020-07-17 18:46./beam-pipeline-tempuxjiPT/tmpN5_UfJ
>> 236M2020-07-17 18:44./beam-pipeline-tempVpg1ME/tmpxSm8pX
>> 236M2020-07-17 18:42./beam-pipeline-tempJ4EpyB/tmpMZJU76

Use concrete instances of ExternalTransformBuilder in ExternalTransformRegistrar?

[Brian Hulette]

Hi all,
I've been working with +Scott Lukas  on using the new
schema io interfaces [1] in cross-language. This means adding a
general-purpose ExternalTransformRegistrar [2,3] that will register all
SchemaIOProvider implementations via ServiceLoader.

We've run into an issue though - ExternalTransformRegistrar is supposed to
return a `Map>`. This
makes it very challenging (impossible?) for us to create a general-purpose
ExternalTransformBuilder that defers to SchemaIOProvider. Ideally we would
instead return a Map (i.e. a concrete
instance rather than a class object), so that we could just register
different instances of a class like:

class SchemaIOBuilder extends ExternalTransformBuilder {
  private SchemaIOProvider provider;

  PTransform buildExternal(ConfigT configuration) {
// Use provider to create PTransform
  }
}

I think it would be possible to change the ExternalTransformRegistrar
interface so it has a single method, Map
knownBuilders(). It could even be done in a backwards-compatible way if we
keep the old method and provide a default implementation of the new method
that builds instances.

However, I'm curious if there's some strong reason for using Class as the return type for knownBuilders that
I'm missing. Does anyone know why we chose that?

Thanks,
Brian

[1] https://s.apache.org/beam-schema-io
[2]
https://github.com/apache/beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/transforms/ExternalTransformRegistrar.java
[3]
https://github.com/apache/beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/transforms/ExternalTransformBuilder.java

Re: No space left on device - beam-jenkins 1 and 7

[Tyson Hamilton]

Bleck. I just realized that it is 'offline' so that won't work. I'll clean
up manually on the machine using the cron command.

On Fri, Jul 24, 2020 at 10:56 AM Tyson Hamilton  wrote:

> Something isn't working with the current set up because node 15 appears to
> be out of space and is currently 'offline' according to Jenkins. Can
> someone run the cleanup job? The machine is full,
>
> @apache-ci-beam-jenkins-15:/tmp$ df -h
> Filesystem  Size  Used Avail Use% Mounted on
> udev 52G 0   52G   0% /dev
> tmpfs11G  265M   10G   3% /run
> */dev/sda1   485G  484G  880M 100% /*
> tmpfs52G 0   52G   0% /dev/shm
> tmpfs   5.0M 0  5.0M   0% /run/lock
> tmpfs52G 0   52G   0% /sys/fs/cgroup
> tmpfs11G 0   11G   0% /run/user/1017
> tmpfs11G 0   11G   0% /run/user/1037
>
> apache-ci-beam-jenkins-15:/tmp$ sudo du -ah --time . | sort -rhk 1,1 |
> head -n 20
> 20G 2020-07-24 17:52.
> 580M2020-07-22 17:31./junit1031982597110125586
> 517M2020-07-22 17:31
>  ./junit1031982597110125586/junit8739924829337821410/heap_dump.hprof
> 517M2020-07-22 17:31
>  ./junit1031982597110125586/junit8739924829337821410
> 263M2020-07-22 12:23./pip-install-2GUhO_
> 263M2020-07-20 09:30./pip-install-sxgwqr
> 263M2020-07-17 13:56./pip-install-bWSKIV
> 242M2020-07-21 20:25./beam-pipeline-tempmByU6T
> 242M2020-07-21 20:21./beam-pipeline-tempV85xeK
> 242M2020-07-21 20:15./beam-pipeline-temp7dJROJ
> 236M2020-07-21 20:25./beam-pipeline-tempmByU6T/tmpOWj3Yr
> 236M2020-07-21 20:21./beam-pipeline-tempV85xeK/tmppbQHB3
> 236M2020-07-21 20:15./beam-pipeline-temp7dJROJ/tmpgOXPKW
> 111M2020-07-23 00:57./pip-install-1JnyNE
> 105M2020-07-23 00:17./beam-artifact1374651823280819755
> 105M2020-07-23 00:16./beam-artifact5050755582921936972
> 105M2020-07-23 00:16./beam-artifact1834064452502646289
> 105M2020-07-23 00:15./beam-artifact682561790267074916
> 105M2020-07-23 00:15./beam-artifact4691304965824489394
> 105M2020-07-23 00:14./beam-artifact4050383819822604421
>
> On Wed, Jul 22, 2020 at 12:03 PM Robert Bradshaw 
> wrote:
>
>> On Wed, Jul 22, 2020 at 11:57 AM Tyson Hamilton 
>> wrote:
>>
>>> Ah I see, thanks Kenn. I found some advice from the Apache infra wiki
>>> that also suggests using a tmpdir inside the workspace [1]:
>>>
>>> Procedures Projects can take to clean up disk space
>>>
>>> Projects can help themselves and Infra by taking some basic steps to
>>> help clean up their jobs after themselves on the build nodes.
>>>
>>>
>>>
>>>1. Use a ./tmp dir in your jobs workspace. That way it gets cleaned
>>>up when job workspaces expire.
>>>
>>>
>> Tests should be (able to be) written to use the standard temporary file
>> mechanisms, and the environment set up on Jenkins such that that falls into
>> the respective workspaces. Ideally this should be as simple as setting
>> the TMPDIR (or similar) environment variable (and making sure it exists/is
>> writable).
>>
>>>
>>>1. Configure your jobs to wipe workspaces on start or finish.
>>>2. Configure your jobs to only keep 5 or 10 previous builds.
>>>3. Configure your jobs to only keep 5 or 10 previous artifacts.
>>>
>>>
>>>
>>> [1]:
>>> https://cwiki.apache.org/confluence/display/INFRA/Disk+Space+cleanup+of+Jenkins+nodes
>>>
>>> On Wed, Jul 22, 2020 at 8:06 AM Kenneth Knowles  wrote:
>>>
 Those file listings look like the result of using standard temp file
 APIs but with TMPDIR set to /tmp.

 On Mon, Jul 20, 2020 at 7:55 PM Tyson Hamilton 
 wrote:

> Jobs are hermetic as far as I can tell and use unique subdirectories
> inside of /tmp. Here is a quick look into two examples:
>
> @apache-ci-beam-jenkins-4:/tmp$ sudo du -ah --time . | sort -rhk 1,1 |
> head -n 20
> 1.6G2020-07-21 02:25.
> 242M2020-07-17 18:48./beam-pipeline-temp3ybuY4
> 242M2020-07-17 18:46./beam-pipeline-tempuxjiPT
> 242M2020-07-17 18:44./beam-pipeline-tempVpg1ME
> 242M2020-07-17 18:42./beam-pipeline-tempJ4EpyB
> 242M2020-07-17 18:39./beam-pipeline-tempepea7Q
> 242M2020-07-17 18:35./beam-pipeline-temp79qot2
> 236M2020-07-17 18:48./beam-pipeline-temp3ybuY4/tmpy_Ytzz
> 236M2020-07-17 18:46./beam-pipeline-tempuxjiPT/tmpN5_UfJ
> 236M2020-07-17 18:44./beam-pipeline-tempVpg1ME/tmpxSm8pX
> 236M2020-07-17 18:42./beam-pipeline-tempJ4EpyB/tmpMZJU76
> 236M2020-07-17 18:39./beam-pipeline-tempepea7Q/tmpWy1vWX
> 236M2020-07-17 18:35./beam-pipeline-temp79qot2/tmpvN7vWA
> 3.7M2020-07-17 18:48./beam-pipeline-temp3ybuY4/tmprlh_di
> 3.7M2020-07-17 18:46 

Re: No space left on device - beam-jenkins 1 and 7

[Tyson Hamilton]

Something isn't working with the current set up because node 15 appears to
be out of space and is currently 'offline' according to Jenkins. Can
someone run the cleanup job? The machine is full,

@apache-ci-beam-jenkins-15:/tmp$ df -h
Filesystem  Size  Used Avail Use% Mounted on
udev 52G 0   52G   0% /dev
tmpfs11G  265M   10G   3% /run
*/dev/sda1   485G  484G  880M 100% /*
tmpfs52G 0   52G   0% /dev/shm
tmpfs   5.0M 0  5.0M   0% /run/lock
tmpfs52G 0   52G   0% /sys/fs/cgroup
tmpfs11G 0   11G   0% /run/user/1017
tmpfs11G 0   11G   0% /run/user/1037

apache-ci-beam-jenkins-15:/tmp$ sudo du -ah --time . | sort -rhk 1,1 | head
-n 20
20G 2020-07-24 17:52.
580M2020-07-22 17:31./junit1031982597110125586
517M2020-07-22 17:31
 ./junit1031982597110125586/junit8739924829337821410/heap_dump.hprof
517M2020-07-22 17:31
 ./junit1031982597110125586/junit8739924829337821410
263M2020-07-22 12:23./pip-install-2GUhO_
263M2020-07-20 09:30./pip-install-sxgwqr
263M2020-07-17 13:56./pip-install-bWSKIV
242M2020-07-21 20:25./beam-pipeline-tempmByU6T
242M2020-07-21 20:21./beam-pipeline-tempV85xeK
242M2020-07-21 20:15./beam-pipeline-temp7dJROJ
236M2020-07-21 20:25./beam-pipeline-tempmByU6T/tmpOWj3Yr
236M2020-07-21 20:21./beam-pipeline-tempV85xeK/tmppbQHB3
236M2020-07-21 20:15./beam-pipeline-temp7dJROJ/tmpgOXPKW
111M2020-07-23 00:57./pip-install-1JnyNE
105M2020-07-23 00:17./beam-artifact1374651823280819755
105M2020-07-23 00:16./beam-artifact5050755582921936972
105M2020-07-23 00:16./beam-artifact1834064452502646289
105M2020-07-23 00:15./beam-artifact682561790267074916
105M2020-07-23 00:15./beam-artifact4691304965824489394
105M2020-07-23 00:14./beam-artifact4050383819822604421

On Wed, Jul 22, 2020 at 12:03 PM Robert Bradshaw 
wrote:

> On Wed, Jul 22, 2020 at 11:57 AM Tyson Hamilton 
> wrote:
>
>> Ah I see, thanks Kenn. I found some advice from the Apache infra wiki
>> that also suggests using a tmpdir inside the workspace [1]:
>>
>> Procedures Projects can take to clean up disk space
>>
>> Projects can help themselves and Infra by taking some basic steps to help
>> clean up their jobs after themselves on the build nodes.
>>
>>
>>
>>1. Use a ./tmp dir in your jobs workspace. That way it gets cleaned
>>up when job workspaces expire.
>>
>>
> Tests should be (able to be) written to use the standard temporary file
> mechanisms, and the environment set up on Jenkins such that that falls into
> the respective workspaces. Ideally this should be as simple as setting
> the TMPDIR (or similar) environment variable (and making sure it exists/is
> writable).
>
>>
>>1. Configure your jobs to wipe workspaces on start or finish.
>>2. Configure your jobs to only keep 5 or 10 previous builds.
>>3. Configure your jobs to only keep 5 or 10 previous artifacts.
>>
>>
>>
>> [1]:
>> https://cwiki.apache.org/confluence/display/INFRA/Disk+Space+cleanup+of+Jenkins+nodes
>>
>> On Wed, Jul 22, 2020 at 8:06 AM Kenneth Knowles  wrote:
>>
>>> Those file listings look like the result of using standard temp file
>>> APIs but with TMPDIR set to /tmp.
>>>
>>> On Mon, Jul 20, 2020 at 7:55 PM Tyson Hamilton 
>>> wrote:
>>>
 Jobs are hermetic as far as I can tell and use unique subdirectories
 inside of /tmp. Here is a quick look into two examples:

 @apache-ci-beam-jenkins-4:/tmp$ sudo du -ah --time . | sort -rhk 1,1 |
 head -n 20
 1.6G2020-07-21 02:25.
 242M2020-07-17 18:48./beam-pipeline-temp3ybuY4
 242M2020-07-17 18:46./beam-pipeline-tempuxjiPT
 242M2020-07-17 18:44./beam-pipeline-tempVpg1ME
 242M2020-07-17 18:42./beam-pipeline-tempJ4EpyB
 242M2020-07-17 18:39./beam-pipeline-tempepea7Q
 242M2020-07-17 18:35./beam-pipeline-temp79qot2
 236M2020-07-17 18:48./beam-pipeline-temp3ybuY4/tmpy_Ytzz
 236M2020-07-17 18:46./beam-pipeline-tempuxjiPT/tmpN5_UfJ
 236M2020-07-17 18:44./beam-pipeline-tempVpg1ME/tmpxSm8pX
 236M2020-07-17 18:42./beam-pipeline-tempJ4EpyB/tmpMZJU76
 236M2020-07-17 18:39./beam-pipeline-tempepea7Q/tmpWy1vWX
 236M2020-07-17 18:35./beam-pipeline-temp79qot2/tmpvN7vWA
 3.7M2020-07-17 18:48./beam-pipeline-temp3ybuY4/tmprlh_di
 3.7M2020-07-17 18:46./beam-pipeline-tempuxjiPT/tmpLmVWfe
 3.7M2020-07-17 18:44./beam-pipeline-tempVpg1ME/tmpvrxbY7
 3.7M2020-07-17 18:42./beam-pipeline-tempJ4EpyB/tmpLTb6Mj
 3.7M2020-07-17 18:39./beam-pipeline-tempepea7Q/tmptYF1v1
 3.7M2020-07-17 18:35

Re: [VOTE] Make Apache Beam 2.24.0 the final release supporting Python 2.

[Maximilian Michels]

+1

On 24.07.20 18:54, Pablo Estrada wrote:

+1 - thank you Valentyn!
-P.

On Thu, Jul 23, 2020 at 1:29 PM Chamikara Jayalath > wrote:


+1

On Thu, Jul 23, 2020 at 1:15 PM Brian Hulette mailto:bhule...@google.com>> wrote:

+1

On Thu, Jul 23, 2020 at 1:05 PM Robert Bradshaw
mailto:rober...@google.com>> wrote:

[X] +1: Remove Python 2 support in Apache Beam 2.25.0.

According to our six-week release cadence, 2.24.0 (the last
release to support Python 2) will be cut mid-August, and the
first release not supporting Python 2 would be expected to
land sometime in October. This seems a reasonable timeline
to me.


On Thu, Jul 23, 2020 at 12:53 PM Valentyn Tymofieiev
mailto:valen...@google.com>> wrote:

Hi everyone,

Please vote whether to make Apache Beam 2.24.0 the final
release supporting Python 2 as follows.

[ ] +1: Remove Python 2 support in Apache Beam 2.25.0.
[ ] -1: Continue to support Python 2 in Apache Beam, and
reconsider at a later date.

The Beam community has pledged to sunset Python 2
support at some point in 2020[1,2]. A recent
discussion[3] on dev@  proposes to outline a specific
version after which Beam developers no longer have to
maintain Py2 support, which is a motivation for this vote.

If this vote is approved we will announce Apache Beam
2.24.0 as our final release to support Python 2 and
discontinue Python 2 support starting from 2.25.0
(inclusive).

This is a procedural vote [4] that will follow the
majority approval rules and will be open for at least 72
hours.

Thanks,
Valentyn

[1]

https://lists.apache.org/thread.html/634f7346b607e779622d0437ed0eca783f474dea8976adf41556845b%40%3Cdev.beam.apache.org%3E
[2] https://python3statement.org/
[3]

https://lists.apache.org/thread.html/r0d5c309a7e3107854f4892ccfeb1a17c0cec25dfce188678ab8df072%40%3Cdev.beam.apache.org%3E
[4] https://www.apache.org/foundation/voting.html

Re: [VOTE] Make Apache Beam 2.24.0 the final release supporting Python 2.

[Pablo Estrada]

+1 - thank you Valentyn!
-P.

On Thu, Jul 23, 2020 at 1:29 PM Chamikara Jayalath 
wrote:

> +1
>
> On Thu, Jul 23, 2020 at 1:15 PM Brian Hulette  wrote:
>
>> +1
>>
>> On Thu, Jul 23, 2020 at 1:05 PM Robert Bradshaw 
>> wrote:
>>
>>> [X] +1: Remove Python 2 support in Apache Beam 2.25.0.
>>>
>>> According to our six-week release cadence, 2.24.0 (the last release to
>>> support Python 2) will be cut mid-August, and the first release not
>>> supporting Python 2 would be expected to land sometime in October. This
>>> seems a reasonable timeline to me.
>>>
>>>
>>> On Thu, Jul 23, 2020 at 12:53 PM Valentyn Tymofieiev <
>>> valen...@google.com> wrote:
>>>
 Hi everyone,

 Please vote whether to make Apache Beam 2.24.0 the final release
 supporting Python 2 as follows.

 [ ] +1: Remove Python 2 support in Apache Beam 2.25.0.
 [ ] -1: Continue to support Python 2 in Apache Beam, and reconsider at
 a later date.

 The Beam community has pledged to sunset Python 2 support at some point
 in 2020[1,2]. A recent discussion[3] on dev@  proposes to outline a
 specific version after which Beam developers no longer have to maintain Py2
 support, which is a motivation for this vote.

 If this vote is approved we will announce Apache Beam 2.24.0 as our
 final release to support Python 2 and discontinue Python 2 support starting
 from 2.25.0 (inclusive).

 This is a procedural vote [4] that will follow the majority approval
 rules and will be open for at least 72 hours.

 Thanks,
 Valentyn

 [1]
 https://lists.apache.org/thread.html/634f7346b607e779622d0437ed0eca783f474dea8976adf41556845b%40%3Cdev.beam.apache.org%3E
 [2] https://python3statement.org/
 [3]
 https://lists.apache.org/thread.html/r0d5c309a7e3107854f4892ccfeb1a17c0cec25dfce188678ab8df072%40%3Cdev.beam.apache.org%3E
 [4] https://www.apache.org/foundation/voting.html

Re: Contributor permission for Beam Jira tickets

[Alexey Romanenko]

Hi Varun,

I added you to Contributors list. 
Thanks for contribution and welcome!

Regards,
Alexey

> On 23 Jul 2020, at 20:40, Varun Sharma  wrote:
> 
> Hi,
> 
> This is Varun from THG. I have created a couple of tickets related to 
> improvements in Beam Java SDK. Could someone add me as a contributor for 
> Beam's Jira issue tracker? I would like to assign tickets for my work.
> 
> My JIRA id- varun.sharma
> 
> 
> Regards
> Varun Sharma