* [BUG][install.sh] fix the install Error "Command not found rmr" & support ZooKeeper (3.4.6+)
* [BUG][install.sh] fix the install Error "Command not found rmr" & support ZooKeeper (3.4.6+)
* [BUG][install.sh] fix the install Error "Command not found rmr" & support ZooKeeper (3.4.6+)
* [docs] add documentation for building with different ZK versions
* support both 3.4 and 3.8
* [docs] add documentation for building with different ZK versions
* support both 3.4 and 3.8
* [improvement][install.sh] fix the install Error "Command not found rmr" & support ZooKeeper (3.4.6+)
* update known-dependencies.txt
* [improvement][install.sh] fix the install Error "Command not found rmr"
* support ZooKeeper (3.4.6+) by activating zk-3.4 profile
* make zk-3.8 as default option in pom.xml
* update defalut ZK version in docs
* update known-dependencies.txt
Co-authored-by: wangxx <wangxx@kcwl.com>
Currently, our Python API code is a module in apache/dolphinscheduler codebase,
each time users change Python API code, they need to run all requests CI check
for dolphinscheduler and Python API, But if the user does only change Python
code, it could be merged if Python API CI pass and do not dependent on others CI.
Besides, we release Python API as the same version of dolphinscheduler. It is
easy for user to match Python API version. But when Python API does not change
any code, but dolphinscheduler release a bugfix version, Python API has to
release the new version to match dolphinscheduler. This happened when we
released Python API 2.0.6 and 2.0.7. 2.0.6 and 2.0.7 is bugfix version, and
Python API does not change any code, so the PyPI package is the same.
Separate Python API also makes our code more sense, we will have more
distinguished code in dolphinscheduler and Python API new repository.
Have separate issue tracker and changelog for information to users.
ref PR in other repository: apache/dolphinscheduler-sdk-python#1
see more detail in mail thread: https://lists.apache.org/thread/4z7l5l54c4d81smjlk1n8nq380p9f0oo
* [Feature-6586][Server]add some ds process definition demo when init
1.add some ds process definition demo when init, to display what task type can run and make user easy to
use ds.
2.need configure the JVM parameters (-Ddemo=true) to turn on the StandaloneServer service
3.need modify the tenant information in it
* Provide aop way as an optional way to collect yarn job's applicationId, and import new module `dolphinscheduler-aop` to place the aop code.
* Add user property `appId.collect` for user to decide how to collect applicationId.
* Add new environment configuration for each type of yarn tasks to support aop in `dolphinscheduler_env.sh`
* Update docs to declare how to use aop way.
* Update `LogUtils` to support fetch applicationId in different ways based on the user property.
Co-authored-by: gabrywu <gabrywu@apache.com>
v-wx-v
Kerwin
Donald Yang
lenian
Jay Chung
Aaron Wang
陈家名
Amy0104
Tq
Wenjun Ruan
Eric Gao
JieguangZhou
lifeng
longtb
旺阳
rickchengx
insist777
John Bampton
Assert
xuhhui
baihongbin
kezhenxu94
amao