Hi Beam committers,
Would you trigger the precommit checks for this PR?
https://github.com/apache/beam/pull/11586
Regards,
Tomo
Nam,
- Website looks good and looks the same as the current website. (Visually
comparing a few pages, not a deep analysis.)
- contribute.md looks good. (this is new content.)
- website/Dockerfile and website/README.md changes look good.
- I do not know what is the new version of some files, for
Done.
On Thu, Apr 30, 2020 at 7:21 PM rahul patwari
wrote:
> Hi Committers,
>
> Can you please trigger tests for
> https://github.com/apache/beam/pull/11569 and
> https://github.com/apache/beam/pull/11581
>
> Thanks,
> Rahul
>
> On Tue, 28 Apr 2020, 10:58 pm Alexey Romanenko,
> wrote:
>
>>
Hi Committers,
Can you please trigger tests for https://github.com/apache/beam/pull/11569
and https://github.com/apache/beam/pull/11581
Thanks,
Rahul
On Tue, 28 Apr 2020, 10:58 pm Alexey Romanenko,
wrote:
> Thanks Udi! I'll track for updates on this.
>
> On 28 Apr 2020, at 19:16, Udi Meiri
>
> Since we want to move forward with the PR, I would like to ask the
> community to hold off changes to the current Beam website for a week, until
> we are able to review and merge the PR. Is this acceptable to everyone?
Do we have an exact date when we can push changes to the website? I have
Exact and it is not the same because there is an extra layer, because
the PortableRunner does not deal with the same issues that the other
runners e.g. translation and execution in the target system, it feels
more proxy than the 'translating runners' in the open source case.
On Thu, Apr 30, 2020
+1 to periodic cleanups of the workers. I do not know what would be a good
frequency daily or a different one. Do we have a jira for this?
On Thu, Apr 30, 2020 at 2:22 PM Udi Meiri wrote:
> I summarized my idea here: https://issues.apache.org/jira/browse/BEAM-9865
>
+1 to this idea as well.
I summarized my idea here: https://issues.apache.org/jira/browse/BEAM-9865
On Thu, Apr 30, 2020 at 2:01 PM Maximilian Michels wrote:
> On 30.04.20 21:48, Hannah Jiang wrote:
> > --info tag was passed to docker image build commands with PythonDocker
> > Precommit to capture more logs. Without
On 30.04.20 21:48, Hannah Jiang wrote:
> --info tag was passed to docker image build commands with PythonDocker
> Precommit to capture more logs. Without the tag, errors from
> DockerFile step are not printed out to the console.
Thanks for the info (pun intended).
On 30.04.20 21:48, Hannah Jiang
Is the issue that the workspace grows over time? Couldn't we delete it
daily to ensure it does not grow too much? Always deleting it on
successful runs may be too costly because we have to recreate the
workspace every time.
Logs are stored separately. I suppose they could also add up over time.
Hey guys,
I tried my best to handle renamed files in Git. I have no clue why GitHub
doesn't show it, but finally, I made this commit [1] (thanks for your
idea @bhulette) so you guys can review changes with ease (there is no bunch
of deleted markdown files anymore :D). Also, new staged version is
Hi Darshan, I'll loop in some people for a discussion.
On 2020/04/30 04:29:13, Darshan Jani wrote:
> Thanks Luke.
>
> Thanks for pointing that out.
> I am new to Beam contribution community.
> I would appreciate if you can point me or tag someone of the contributing
> members who are working
> all runners (with perhaps the exception of the direct runner) are proxies
for actual runners
Agreed. The main difference is that this fact is more obvious for Dataflow
users, since it is "Cloud" Dataflow after all. The relationship of Beam to
its OSS runners is much less clear to new users (for
>
> Indeed, I can see the no space left on device in the following but not in
> the log above:
--info tag was passed to docker image build commands with PythonDocker
Precommit to capture more logs. Without the tag, errors from DockerFile
step are not printed out to the console.
On Thu, Apr 30,
Thank you!
On Wed, Apr 29, 2020 at 3:23 PM Kyle Weaver wrote:
> Added a comment on https://issues.apache.org/jira/browse/INFRA-19967
>
> On Wed, Apr 29, 2020 at 5:57 PM Ahmet Altay wrote:
>
>> Would it be worth filing this as an infra ticket?
>>
>> On Mon, Apr 27, 2020 at 4:29 PM Kyle Weaver
In a sense, all runners (with perhaps the exception of the direct runner)
are proxies for actual runners. In that sense, I think it makes just as
much sense to say "I want the portable runner with job endpoint X" as to
say "I want the flink runner with master Y." Saying "I want the Portable
Created https://issues.apache.org/jira/browse/BEAM-9863 to track this.
Any taker?
On Thu, Apr 30, 2020 at 5:54 PM Reuven Lax wrote:
>
> I'm not sure who added that, but it's been there for a while. Making global
> static changes like that in our module seems like poor form - I wonder if
>
Thomas has a point on the PortableRunner name, I was super confused
because of the `PortableRunner` not being a runner, I don't know if
too late but maybe it is still worth to give it a better name.
On Thu, Apr 30, 2020 at 8:41 PM Thomas Weise wrote:
>
> +1 for removing the default runner. It
+1 for removing the default runner. It has always been the Beam user
expectation that a runner needs to be selected.
"PortableRunner" isn't a runner (despite its name) - it's a proxy to a
runner that the user specifies via job_endpoint.
Thanks for cleaning this up!
On Thu, Apr 30, 2020 at 10:11
I checked node 8 and it had over 40GB space available. Does your job
require more than that?
Long term, I'm thinking we could clean up workspaces for successful jobs.
This should free up additional space (I guess at least 100GB).
https://plugins.jenkins.io/ws-cleanup/ - we already use this plugin
Changing the URLs is fine with me as long as the old urls will work too.
But do we need to change the filenames for the blog posts to accomplish
that? It's nice that the blog post markdown files start with a date so they
naturally sort chronologically. It looks like this hugo PR [1] made it
I took a look at the book - there's not really much there. Maybe he's
planning on adding more over time?
On Tue, Apr 28, 2020 at 1:48 PM Ismaël Mejía wrote:
> The tweet URL for ref in case someone wants to like/RT
>
> https://twitter.com/jaceklaskowski/status/1255046717277376512?s=19
>
> On
I'll bite :) Thanks for the feedback everyone!
On Thu, Apr 30, 2020 at 1:01 PM Robert Bradshaw wrote:
> I filed https://issues.apache.org/jira/browse/BEAM-9860. Any takers?
>
> On Thu, Apr 30, 2020 at 5:49 AM Ismaël Mejía wrote:
>
>> +1 for A there are zero reasons to have a default runner set
On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise wrote:
> For changed URLs, will previous URLs be mapped to avoid broken external
> links?
>
I believe the answer is yes from Nam's response "For now, we keep the old
URLs working in terms of redirecting them". I very much agree that this is
very
I filed https://issues.apache.org/jira/browse/BEAM-9860. Any takers?
On Thu, Apr 30, 2020 at 5:49 AM Ismaël Mejía wrote:
> +1 for A there are zero reasons to have a default runner set by
> default, being explicit is better as Robert suggests and it resolves
> the confusion that the user
For changed URLs, will previous URLs be mapped to avoid broken external
links?
On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy
wrote:
> Hi,
>
> To give a little more context regarding the URLs, the date should still
> appear on the blog post, but not on the URL.
> For example, we'd
Welcome Tyson!
On Thu, Apr 30, 2020 at 6:44 AM Connell O'Callaghan
wrote:
> Welcome Tyson!!!
>
>
>
> On Thu, Apr 30, 2020 at 6:12 AM Ismaël Mejía wrote:
>
>> Welcome!
>>
>> On Thu, Apr 30, 2020 at 12:27 AM Alan Myrvold
>> wrote:
>> >
>> > Welcome, Tyson!
>> >
>> > On Wed, Apr 29, 2020 at 3:15
Hi,
To give a little more context regarding the URLs, the date should still
appear on the blog post, but not on the URL.
For example, we'd have:
https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
become https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.
A first pass, something like:
https://druid.apache.org/druid-powered
https://spark.apache.org/powered-by.html
or even as simple as:
https://github.com/apache/airflow#who-uses-apache-airflow
Would go a long way in the sorts of very high-level conversations I'm
having around technology
Hi,
@altay: Hey hey. Yeah, I didn't expect the baseUrl of staging version is "
http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
which also includes "/11554", and Hugo considers it as a path so it breaks
the path of "static files" (like images). We made a fix. Now I'm
I'm not sure who added that, but it's been there for a while. Making global
static changes like that in our module seems like poor form - I wonder if
there's a better approach.
On Thu, Apr 30, 2020 at 8:36 AM Brian Hulette wrote:
> It seems likely this is a side effect of some static
It seems likely this is a side effect of some static initialization in
AvroUtils:
https://github.com/apache/beam/blob/763b7ccd17a420eb634d6799adcd3ecfcf33d6a7/sdks/java/core/src/main/java/org/apache/beam/sdk/schemas/utils/AvroUtils.java#L99
On Wed, Apr 29, 2020 at 9:59 PM Reuven Lax wrote:
>
Hi,
Is anyone familiar with this GRPC error? The build logs are full of it.
Also getting it on my machine when I run tests:
23:17:02 ERROR:apache_beam.runners.worker.data_plane:Failed to read inputs in
the data plane.
23:17:02 Traceback (most recent call last):
23:17:02 File
*It's working again, probably because it's running on a different
machine now.
Who can check the disk space of the Jenkins hosts?
Thanks,
Max
On 30.04.20 11:55, Maximilian Michels wrote:
> Sorry, I meant to include the Jenkins log:
>
Welcome Tyson!!!
On Thu, Apr 30, 2020 at 6:12 AM Ismaël Mejía wrote:
> Welcome!
>
> On Thu, Apr 30, 2020 at 12:27 AM Alan Myrvold wrote:
> >
> > Welcome, Tyson!
> >
> > On Wed, Apr 29, 2020 at 3:15 PM Rui Wang wrote:
> >>
> >> Welcome!
> >>
> >> -Rui
> >>
> >> On Wed, Apr 29, 2020, 3:13 PM
Welcome!
On Thu, Apr 30, 2020 at 12:27 AM Alan Myrvold wrote:
>
> Welcome, Tyson!
>
> On Wed, Apr 29, 2020 at 3:15 PM Rui Wang wrote:
>>
>> Welcome!
>>
>> -Rui
>>
>> On Wed, Apr 29, 2020, 3:13 PM Brian Hulette wrote:
>>>
>>> Welcome Tyson!
>>>
>>> On Wed, Apr 29, 2020 at 2:54 PM Ahmet Altay
+1 for A there are zero reasons to have a default runner set by
default, being explicit is better as Robert suggests and it resolves
the confusion that the user reported.
On Wed, Apr 29, 2020 at 10:05 PM Robert Bradshaw wrote:
>
> +1, I was actually thinking about this just the other day.
Sorry, I meant to include the Jenkins log:
https://builds.apache.org/job/beam_LoadTests_Python_ParDo_Flink_Streaming_PR/5/console
Thanks for investigating Hannah! Indeed, I can see the no space left on
device in the following but not in the log above:
Max, I found a link from your PR and noticed below errors. This would be
the true error.
*07:57:03* >* Task :sdks:python:container:py37:docker**07:57:03*
[91mERROR: Could not install packages due to an EnvironmentError:
[Errno 28] No space left on device*07:57:03* *07:57:03* [0m*07:57:03*
>*
39 matches
Mail list logo
