servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zen Lin <zenlintechnofr...@gmail.com>
Subject Re: [DISCUSSION] How to migrate configurations from cse to servicecomb prefix
Date Thu, 14 Jun 2018 00:50:06 GMT
+1 to wjm's suggestion.
I think keep two prefix in ServiceComb will confuse the users.
Anyway, CSE is just a one of the business implement from a business
company, it has nothing to do with ServiceComb in a way.
If we reserve the old prefix now, and we also have to change it in near
future to keep ServiceComb is ServiceComb.

Providing a conversion tool is a good idea which allow users easily adapt
to the new release.
Tool will be loosely coupled with the ServiecComb but Module will be part
of the core of the ServiceComb, I suggest we avoiding to keep anything
about cse in ServiceComb core.

If providing a configuration changing module that is based on the
consideration of different configuration centers in future, I think it
would be feasible, but not based on the consideration of how to deal with
cse  prefix in ServiceComb.

Also,  The idea of print error messages is good  also, but this is another
topic, something like "how to make logs friendly and usable".


Best Regards,
---
Zen Lin
zenlintechnofreak@gmail.com
Focused on Micro Service and Apache ServiceComb

2018-06-13 16:04 GMT+08:00 Yang Bo <oakyang@gmail.com>:

> +1 for wjm's idea.
> The ultimate goal is to use servicecomb.* everywhere in code and
> configurations.
> We can provide a compatible layer to read the cse.* configurations and
> merge them into servicecomb.* and use serviccomb.* elsewhere in the code.
>
> Perhaps we can also provide a tool to transform all configuration files
> from cse.* to servicecomb.* to help user migrate, this should be quite
> simple.
>
> On Wed, Jun 13, 2018 at 2:57 PM Willem Jiang <willem.jiang@gmail.com>
> wrote:
>
> > Hi,
> >
> > I  think we can borrow some idea from Spring Boot.
> > There are some configuration change between Spring Boot 2 and Spring Boot
> > 1.
> > Spring Boot provides configuration change module to the mapping thing, or
> > print error message for the changed properties.
> >
> > Any thought?
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Jun 13, 2018 at 11:08 AM, bismy <bismy@qq.com> wrote:
> >
> > > Hi,
> > >
> > >
> > > Currently we duplicate configurations for servicecomb prefix to cse
> > > prefix, and in code we can read configurations by cse prefix. That is:
> > > 1. Config file using servicecomb.x.y, can read in code with
> > > getProperty("servicecomb.x.y") and getProperty("cse.x.y")
> > > 2. Config file using cse.x.y, can read in code with
> > getProperty("cse.x.y")
> > >
> > >
> > > If we use cse prefix in code, this is the most portable way to read
> both
> > > cse.x.y and servicecomb.x.y configurations.
> > >
> > >
> > > However, this will leading us to write code always using cse, this is
> not
> > > our intention. We are asking users/developers to using servicecomb
> > > gradually.
> > >
> > >
> > > I suggest we use servicecomb prefix when adding new configuration
> items.
> > > But there maybe some axtra work users need to do. For example,
> > >
> > >
> > > One user's project using cse prefix:
> > >
> > >
> > > cse:
> > >    function:
> > >       a: false
> > >       b: false
> > >
> > >
> > > And when we add a new configuration item: servicecomb.funciton.c, users
> > > must change the configuration file to one of the following:
> > >
> > >
> > > servicecomb:
> > >   function:
> > >      a: false
> > >      b: false
> > >      c: false
> > >
> > >
> > >
> > >
> > > or
> > > cse:
> > >    function:
> > >       a: false
> > >       b: false
> > >
> > > servicecomb:
> > >   function:
> > >      c: false
> > >
> > >
> > >
> > >
> > >
> > > I think we need to encourage users using servicecomb when upgrading,
> and
> > > developers to use servicecomb  prefix when adding new configuration
> > items.
> > >
> > >
> > > Any idea?
> >
>
>
> --
> Best Regards,
> Yang.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message