Github user sachingoel0101 commented on the pull request:
https://github.com/apache/flink/pull/1214#issuecomment-155385085
>>> You're probably right. It may just seem odd to the user that code gets
executed even though the job won't be submitted. We might fix that in the
future if users don't like it.
I think most people will be aware that Flink executes lazily, and just
because the program goes right till the end printing whatever it does, it
doesn't guarantee a true submission. But there is no point debating on this. We
can adapt to whatever people prefer. This'll likely go through a major change
before 1.0 to support truly detached mode anyways.
>>>Looks like your recent changes broke the YARN tests?
Yes. It's also kind of hard to debug them. I can't seem to run them on my
VM, and travis build takes a full one and a half hour to produce anything
useful, and even then, I can't access the complete logs. It probably requires
AWS keys or something. I'm not sure.
Do you know of any change I can make to travis conf so all modules are
built but only Yarn tests get executed?
I have one more concern:
There are four types of Yarn runs we can perform:
1. Yarn session in detached mode: Equivalent to `bin/start-cluster.sh`
2. Yarn session: Doesn't have a counterpart in standalone mode
3. Per job yarn in detached mode: No counterpart in standalone mode, even
after we add this PR.
4. Per job yarn: No counterpart in standalone mode.
Now, when `bin/flink -d` is run, user will expect there to be a single
semantics; that a cluster will be brought up, job will be submitted and the
cluster will be terminated. However, there doesn't seem to be any way of
achieving this in standalone mode. Will this create any confusion?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
