You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dolphinscheduler.apache.org by chendapao <fe...@163.com> on 2020/02/16 14:06:14 UTC

回复:Re: [SUGGESTION] merging these already exists properties files into big one

-1


I think a merger is a good thing. which simplifies the configuration. 
But not to merge or delete configuration.
It should be a simplified, prioritized configuration that guides the user.


For this, I think there are the following questions:
1.The cost of more upgrades.
2.Cost of more development,adjustments to development methods.
3.Not decoupling enough.
4.This approach is not a good idea to simplify deployment.


If it's to simplify deployment. I think it's time to yibasuo or ambari or document.








--

 

chendapao

feloxx@163.com




At 2020-02-16 21:35:46, "nauu" <bo...@qq.com> wrote:
>I think it’s a little strange. 
>
>first,  it is not like the way of modular design. Usually, each module should have there own configs. In this way, each module can be more easily maintained.
>
>second, now we base on Spring, and the config has priority in Spring. When in developing mode we can set configs in each module,  and when in deploying mode we should only use one merged config, it will overwrite the default value.
>
>
>
>boness@qq.com
>zhukai/nauu ygsoft
>
>
>
>
>> On Feb 16, 2020, at 9:00 PM, lidong dai <da...@gmail.com> wrote:
>> 
>> hi,
>>  for now there are too many properties configuration file in src/resource
>> dir, we maybe forget the detail location of some properties file. usually
>> developer must go to the resource directory under each module to see if the
>> configuration in this directory, I think this situation needs to be
>> changed.
>> 
>> I suggest that  merging these already exists properties files (includes
>> alert.properties, application.properties, application-api.properties,
>> quartz.properties, common.properties) into one big properties file ?  Do
>> you have any idea.
>> 
>> By the way, I will delete the unnecessary configuration items to simplify
>> the configuration. The unnecessary configuration items will be placed in
>> the official website tuning document.
>> 
>> 
>> 
>> 
>> Best Regards
>> ---------------
>> DolphinScheduler(Incubator) PPMC
>> Lidong Dai 代立冬
>> dailidong66@gmail.com
>> ---------------
>

回复: [SUGGESTION] merging these already exists properties files into big one

Posted by qiao zhanwei <qi...@outlook.com>.
-1

In theory each server needs its own configuration file and loback,Otherwise it will be messy

suggest :
1,each server has its own configuration file
2,configuration items in the file can be appropriately merged
3,no necessary items for startup, the program can have default values, and configuration items can be commented

Thx

―――――――――――――
DolphinScheduler(Incubator)  PPMC
Zhanwei Qiao 乔占卫

qiaozhanwei@outlook.com

发件人: chendapao<ma...@163.com>
发送时间: 2020-02-16 22:06
收件人: dev@dolphinscheduler.apache.org<ma...@dolphinscheduler.apache.org>
主题: 回复:Re: [SUGGESTION] merging these already exists properties files into big one
-1


I think a merger is a good thing. which simplifies the configuration.
But not to merge or delete configuration.
It should be a simplified, prioritized configuration that guides the user.


For this, I think there are the following questions:
1.The cost of more upgrades.
2.Cost of more development,adjustments to development methods.
3.Not decoupling enough.
4.This approach is not a good idea to simplify deployment.


If it's to simplify deployment. I think it's time to yibasuo or ambari or document.








--


chendapao

feloxx@163.com




At 2020-02-16 21:35:46, "nauu" <bo...@qq.com> wrote:
>I think it’s a little strange.
>
>first,  it is not like the way of modular design. Usually, each module should have there own configs. In this way, each module can be more easily maintained.
>
>second, now we base on Spring, and the config has priority in Spring. When in developing mode we can set configs in each module,  and when in deploying mode we should only use one merged config, it will overwrite the default value.
>
>
>
>boness@qq.com
>zhukai/nauu ygsoft
>
>
>
>
>> On Feb 16, 2020, at 9:00 PM, lidong dai <da...@gmail.com> wrote:
>>
>> hi,
>>  for now there are too many properties configuration file in src/resource
>> dir, we maybe forget the detail location of some properties file. usually
>> developer must go to the resource directory under each module to see if the
>> configuration in this directory, I think this situation needs to be
>> changed.
>>
>> I suggest that  merging these already exists properties files (includes
>> alert.properties, application.properties, application-api.properties,
>> quartz.properties, common.properties) into one big properties file ?  Do
>> you have any idea.
>>
>> By the way, I will delete the unnecessary configuration items to simplify
>> the configuration. The unnecessary configuration items will be placed in
>> the official website tuning document.
>>
>>
>>
>>
>> Best Regards
>> ---------------
>> DolphinScheduler(Incubator) PPMC
>> Lidong Dai 代立冬
>> dailidong66@gmail.com
>> ---------------
>

Re: Re: [SUGGESTION] merging these already exists properties files into big one

Posted by lidong dai <da...@gmail.com>.
hi,
   does we still keep common.properties and application.properties , at the
same time , we don't delete the configuration items , just comment out
these configuration items , users can uncomment them if they want to use
them. I think this can ease the pressure on new users. After all, there are
so many configuration items.  what do you think?


Best Regards
---------------
DolphinScheduler(Incubator) PPMC
Lidong Dai 代立冬
dailidong66@gmail.com
---------------


chendapao <fe...@163.com> 于2020年2月16日周日 下午10:06写道:

> -1
>
>
> I think a merger is a good thing. which simplifies the configuration.
> But not to merge or delete configuration.
> It should be a simplified, prioritized configuration that guides the user.
>
>
> For this, I think there are the following questions:
> 1.The cost of more upgrades.
> 2.Cost of more development,adjustments to development methods.
> 3.Not decoupling enough.
> 4.This approach is not a good idea to simplify deployment.
>
>
> If it's to simplify deployment. I think it's time to yibasuo or ambari or
> document.
>
>
>
>
>
>
>
>
> --
>
>
>
> chendapao
>
> feloxx@163.com
>
>
>
>
> At 2020-02-16 21:35:46, "nauu" <bo...@qq.com> wrote:
> >I think it’s a little strange.
> >
> >first,  it is not like the way of modular design. Usually, each module
> should have there own configs. In this way, each module can be more easily
> maintained.
> >
> >second, now we base on Spring, and the config has priority in Spring.
> When in developing mode we can set configs in each module,  and when in
> deploying mode we should only use one merged config, it will overwrite the
> default value.
> >
> >
> >
> >boness@qq.com
> >zhukai/nauu ygsoft
> >
> >
> >
> >
> >> On Feb 16, 2020, at 9:00 PM, lidong dai <da...@gmail.com> wrote:
> >>
> >> hi,
> >>  for now there are too many properties configuration file in
> src/resource
> >> dir, we maybe forget the detail location of some properties file.
> usually
> >> developer must go to the resource directory under each module to see if
> the
> >> configuration in this directory, I think this situation needs to be
> >> changed.
> >>
> >> I suggest that  merging these already exists properties files (includes
> >> alert.properties, application.properties, application-api.properties,
> >> quartz.properties, common.properties) into one big properties file ?  Do
> >> you have any idea.
> >>
> >> By the way, I will delete the unnecessary configuration items to
> simplify
> >> the configuration. The unnecessary configuration items will be placed in
> >> the official website tuning document.
> >>
> >>
> >>
> >>
> >> Best Regards
> >> ---------------
> >> DolphinScheduler(Incubator) PPMC
> >> Lidong Dai 代立冬
> >> dailidong66@gmail.com
> >> ---------------
> >
>