It is relatively easy to describe the justification for this change without
getting into the weeds and hairsplitting words.

A DAG is built not only to launch an application but also to let a user
visualize and configure it. Currently "populateDAG" is the only method we
require application writers to implement and they implement it with the
goal of running the application. So it can use properties, configuration
and code that is really only needed if you want to "run" the DAG.

As mentioned above a perfectly valid use case is that a platform allows a
user to construct a DAG, visualize it and then attach configuration values
to various components in the DAG, save these values as some kind of a
"configuration package" and then at a future date run the DAG with this
setup. This is consistent with the view that construction of a pipeline and
execution of the pipeline are 2 separate phases and should be delineated as
such.

If you understand and agree with the justification we can work on improving
the original proposal.

Sanjay
On Thu, Dec 21, 2017 at 8:27 AM, Vlad Rozov <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB