Hi,
Thank you for the comments Kostas, Timo, Aljoscha. I also like the
pipeline/execution naming. I tried to apply most of your suggestions
Aljoscha.
There are a few cases when I did not. You mentioned a few options that
are already present, and I planned to reuse the existing options
(latencyTra
Hi,
In general, I’m also for “execution" compared to just “exec”. For some of these
options, though, I’m wondering whether “pipeline.” or “job.”
makes more sense. Over time, a lot of things have accumulated in
ExecutionConfig but a lot of them are not execution related, I think. For
example, a
Sounds good to me.
Thanks,
Timo
On 17.10.19 09:30, Kostas Kloudas wrote:
Hi Timo,
I agree that distinguishing between "executor" and "execution" when
scanning through a configuration file can be difficult. These names
were mainly influenced by the fact that FLIP-73 introduced the
"Executor".
Hi Timo,
I agree that distinguishing between "executor" and "execution" when
scanning through a configuration file can be difficult. These names
were mainly influenced by the fact that FLIP-73 introduced the
"Executor".
In addition, I agree that "deployment" or "deploy" sound good
alternatives. Be
Hi Kostas,
can we still discuss the naming of the properties? For me, having
"execution" and "exector" as prefixes might be confusing in the future
and difficult to identify if you scan through a list of properties.
How about `deployment` and `execution`? Or `deployer` and `exec`?
Regards,
T
Hi all,
Thanks for opening the discussion!
I like the idea, so +1 from my side and actually this is aligned with
our intensions for the FLIP-73 effort.
For the naming convention of the parameters introduced in the FLIP, my
proposal would be have the full word "execution" instead of the
shorter "
Hi Gyula,
Yes you are right, we were also considering the external configurer. The
reason we suggest the built in method is that it is more tightly coupled
with the place the options are actually set. Therefore our hope is that,
whenever somebody e.g. adds new fields to the ExecutionConfig he/she
Hi Dawid,
Sorry I misread one of the interfaces a little (Configuration instead of
ConfigurationReader), you are right.
I was referring to:
-
void StreamExecutionEnvironment.configure(ConfigurationReader)
This might be slightly orthogonal to the changes that you made here but
what I mea
Hi Gyula,
Thank you for the support on those changes.
I am not sure if I understood your idea for the "reconfiguration" logic.
The configure method on those objects would take ConfigurationReader. So
user can provide a thin wrapper around Configuration for e.g. filtering
certain logic, changing
What we could also add to make this a bit more generic and extensible is to
create some interfaces for reconfiguring the StreamExecutionEnvironment,
ExecutionConfig etc and let users specify a class the implements the
reconfiguration logic based on the flink configuration.
This could be executed a
Hi!
Huuuge +1 from me, this has been an operational pain for years.
This would also introduce a nice and simple way to extend it in the future
if we need.
Ship it!
Gyula
On Thu, Aug 29, 2019 at 5:05 PM Dawid Wysakowicz
wrote:
> Hi,
>
> I wanted to propose a new, additional way of configuring
Hi,
I wanted to propose a new, additional way of configuring execution
parameters that can currently be set only on such objects like
ExecutionConfig, CheckpointConfig and StreamExecutionEnvironment. This
poses problems such as:
* no easy way to configure those from a file
* there is no easy
12 matches
Mail list logo
