Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0
+1 binding check the source and binary release is OK run demos is OK Sukesh A C 于2018年11月28日周三 下午12:19写道： > +1 binding. > > Checks done: > - verified signatures and hashes > - LICENSE is ok > - run demos > > Thanks, > Sukesh. > > -Original Message- > From: Mohammad Asif Siddiqui [mailto:asifdxtr...@apache.org] > Sent: 27 November 2018 11:38 > To: dev@servicecomb.apache.org > Subject: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0 > > Hello All, > > This is a call for a Vote to release Apache ServiceComb Java-Chassis > version 1.1.0 > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12343569 > > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.1.0/rc-01/ > > > Staging Repo : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1352 > > > Release Tag : > https://github.com/apache/servicecomb-java-chassis/releases/tag/1.1.0 > > Release CommitID : 1fa24999399f5d2f8e7dc7bc0972e3f3458f0374 > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Tuesday, 27th November, 2018) and will remain open > for at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 1.1.0 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > Mohammad Asif Siddiqui >
RE: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0
+1 binding. Checks done: - verified signatures and hashes - LICENSE is ok - run demos Thanks, Sukesh. -Original Message- From: Mohammad Asif Siddiqui [mailto:asifdxtr...@apache.org] Sent: 27 November 2018 11:38 To: dev@servicecomb.apache.org Subject: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0 Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 1.1.0 Release Notes : https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12343569 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.1.0/rc-01/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1352 Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/1.1.0 Release CommitID : 1fa24999399f5d2f8e7dc7bc0972e3f3458f0374 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Tuesday, 27th November, 2018) and will remain open for at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 1.1.0 [ ] +0 No Opinion [ ] -1 Do not release this package because On the behalf of ServiceComb Team Mohammad Asif Siddiqui
Re: [Discuss]Adding Etcd as a config center for Java-Chassis
@bismy Do you mean the config-center opensource? Yes I can do that. On Wed, Nov 28, 2018 at 11:07 AM bismy wrote: > @Yang Bo > > > Can you start working on service center opensource? I think it's time for > this task. And there maybe some tasks need to do, like code clean up, > licences and others staffs. I can find one to help you with these works if > needed. > > > I agree with you that servicecomb now seems to be a "lackluster system", > but we are in a quite progressive way to build more, and we are creating > great components. I am preparing a glossary what we are going to build. > > > > > -- 原始邮件 -- > 发件人: "Xiaoliang Tian"; > 发送时间: 2018年11月28日(星期三) 上午10:45 > 收件人: "dev"; > > 主题: Re: [Discuss]Adding Etcd as a config center for Java-Chassis > > > > etcd used by service center is not allowed to expose directly to any > client, this etcd only exposed service center. unless you setup isolated > etcd cluster for config management > > Yang Bo 于2018年11月28日周三 上午10:08写道： > > > @Sure > > Yes we can use consul. I choose etcd just because service-center already > > uses it. Actually, if we go with consul, we can even drop service-center, > > as consul provides service registry/discovery and configuration store. We > > can keep the schema data as configuration. > > > > I've been suggesting to opensource the CC and it's frontend since > May/June. > > But here we are, there are still no timeline when this will be done. > > And without this 2 component, the opensource version(servicecomb) feels > > like a lackluster system. > > > > On Wed, Nov 28, 2018 at 9:11 AM Willem Jiang > > wrote: > > > > > If we have plan to open source the config center and governance, > > > it's could be better we start a discussion here to make a road map. > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Wed, Nov 28, 2018 at 8:34 AM wjm wjm wrote: > > > > > > > > it's better to make huawei config center opensource > > > > after governance opensource, can work with huawei config center > > directly > > > > > > > > Yang Bo 于2018年11月27日周二 下午2:21写道： > > > > > > > > > Etcd in itself is good enough to be used as a config center. I > don't > > > see > > > > > the need for an extra layer, it reduces performance and adds > > > complexity. > > > > > > > > > > For example, if we use Etcd directly, the watch mechanism is > > naturally > > > > > supported by grpc which uses http2, there's no need for using > > websocket > > > > > which might have problems under some firewall rules. > > > > > > > > > > I checked the CC(CSE) client implementation in java-chassis, it > uses > > > vert.x > > > > > and http to talk to the server and use websocket for watching when > > > > > possible. > > > > > > > > > > It have implemented tenant, environment separation and we can > achieve > > > this > > > > > by using proper key prefixes in Etcd(v3). I don't see a particular > > > feature > > > > > impossible to implement using Etcd only. > > > > > > > > > > Besides, it takes a lot of time and effort to opensource the > > > Config-Center. > > > > > > > > > > There is one minor issue for Etcd though. The official Etcd client > > for > > > java > > > > > jetcd is not published to central maven repository yet. They are > > > preparing > > > > > an official 0.3.0 release but does not have a timeline for it. > > > > > > > > > > On Tue, Nov 27, 2018 at 9:50 AM bismy wrote: > > > > > > > > > > > Do you have any evaluation document by using etcd as config > center? > > > Now > > > > > > config-cc supports using Huawei Config Center as the backend. And > > > this > > > > > > implementation is based on ectd with an extra abstraction like > > > service > > > > > > center. I am not quite sure if using etcd itself can fitful for > > > users use > > > > > > cases and if it is a good solution or just a workable solution. > > > > > > > > > > > > > > > > > > Maybe we can make Huawei Config Center opensource and distribute > it > > > like > > > > > > service center which is quite simple too. > > > > > > > > > > > > > > > > > > -- 原始邮件 -- > > > > > > 发件人: "Yang Bo"; > > > > > > 发送时间: 2018年11月26日(星期一) 晚上7:30 > > > > > > 收件人: "dev"; > > > > > > > > > > > > 主题: [Discuss]Adding Etcd as a config center for Java-Chassis > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > The ServiceComb project does not have a usable config-center and > > many > > > > > users > > > > > > have shown concerns about it. (Apollo is too complex to setup and > > > have > > > > > high > > > > > > learning cure in using/maintaining). > > > > > > > > > > > > I tried to build a config-center around Etcd for Java-Chassis, > it's > > > quite > > > > > > simple. Most of the features from the CC(CSE) can be achieved. > > > > > > > > > > > > From my point of view, using Etcd is good for small projects, > show > > > cases > > > > > > and in development, because we already have an Etcd inst
?????? [Discuss]Adding Etcd as a config center for Java-Chassis
@Yang Bo Can you start working on service center opensource? I think it's time for this task. And there maybe some tasks need to do, like code clean up, licences and others staffs. I can find one to help you with these works if needed. I agree with you that servicecomb now seems to be a "lackluster system", but we are in a quite progressive way to build more, and we are creating great components. I am preparing a glossary what we are going to build. -- -- ??: "Xiaoliang Tian"; : 2018??11??28??(??) 10:45 ??: "dev"; : Re: [Discuss]Adding Etcd as a config center for Java-Chassis etcd used by service center is not allowed to expose directly to any client, this etcd only exposed service center. unless you setup isolated etcd cluster for config management Yang Bo ??2018??11??28?? 10:08?? > @Sure > Yes we can use consul. I choose etcd just because service-center already > uses it. Actually, if we go with consul, we can even drop service-center, > as consul provides service registry/discovery and configuration store. We > can keep the schema data as configuration. > > I've been suggesting to opensource the CC and it's frontend since May/June. > But here we are, there are still no timeline when this will be done. > And without this 2 component, the opensource version(servicecomb) feels > like a lackluster system. > > On Wed, Nov 28, 2018 at 9:11 AM Willem Jiang > wrote: > > > If we have plan to open source the config center and governance, > > it's could be better we start a discussion here to make a road map. > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: willem > > > > On Wed, Nov 28, 2018 at 8:34 AM wjm wjm wrote: > > > > > > it's better to make huawei config center opensource > > > after governance opensource, can work with huawei config center > directly > > > > > > Yang Bo ??2018??11??27?? 2:21?? > > > > > > > Etcd in itself is good enough to be used as a config center. I don't > > see > > > > the need for an extra layer, it reduces performance and adds > > complexity. > > > > > > > > For example, if we use Etcd directly, the watch mechanism is > naturally > > > > supported by grpc which uses http2, there's no need for using > websocket > > > > which might have problems under some firewall rules. > > > > > > > > I checked the CC(CSE) client implementation in java-chassis, it uses > > vert.x > > > > and http to talk to the server and use websocket for watching when > > > > possible. > > > > > > > > It have implemented tenant, environment separation and we can achieve > > this > > > > by using proper key prefixes in Etcd(v3). I don't see a particular > > feature > > > > impossible to implement using Etcd only. > > > > > > > > Besides, it takes a lot of time and effort to opensource the > > Config-Center. > > > > > > > > There is one minor issue for Etcd though. The official Etcd client > for > > java > > > > jetcd is not published to central maven repository yet. They are > > preparing > > > > an official 0.3.0 release but does not have a timeline for it. > > > > > > > > On Tue, Nov 27, 2018 at 9:50 AM bismy wrote: > > > > > > > > > Do you have any evaluation document by using etcd as config center? > > Now > > > > > config-cc supports using Huawei Config Center as the backend. And > > this > > > > > implementation is based on ectd with an extra abstraction like > > service > > > > > center. I am not quite sure if using etcd itself can fitful for > > users use > > > > > cases and if it is a good solution or just a workable solution. > > > > > > > > > > > > > > > Maybe we can make Huawei Config Center opensource and distribute it > > like > > > > > service center which is quite simple too. > > > > > > > > > > > > > > > -- -- > > > > > ??: "Yang Bo"; > > > > > : 2018??11??26??(??) 7:30 > > > > > ??: "dev"; > > > > > > > > > > : [Discuss]Adding Etcd as a config center for Java-Chassis > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > The ServiceComb project does not have a usable config-center and > many > > > > users > > > > > have shown concerns about it. (Apollo is too complex to setup and > > have > > > > high > > > > > learning cure in using/maintaining). > > > > > > > > > > I tried to build a config-center around Etcd for Java-Chassis, it's > > quite > > > > > simple. Most of the features from the CC(CSE) can be achieved. > > > > > > > > > > From my point of view, using Etcd is good for small projects, show > > cases > > > > > and in development, because we already have an Etcd instance > > > > > running(service-center needs it). > > > > > > > > > > The code is here(it's just a demonstration, needs improvement): > > > > > https://github.com/yangbor/servicecomb-java-chassis/tree/cc-etcd > > > > > > > > > > Any thoughts? > > > > > > > > > > -- > > > > > Best Regards, > > > > > Yang. > > > > > >
?????? [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0
+1 binding Checks done 1. RN is OK 2. check the source and binary release is OK 3. Checkout the released source and integrate to our integration tests and all tests passed -- -- ??: "Sure"; : 2018??11??28??(??) 10:40 ??: "dev"; : Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0 +1 I checked: 1. license is ok 2. demos is work -- Original -- From: Willem Jiang Date: Wed,Nov 28,2018 10:37 AM To: dev Subject: Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0 +1. I checked: - signatures and hashes correct - LICENSE is fine - NOTICE is OK - no unexpected binary files - source files have headers checked with RAT - can build the kit from source without any error - can run the demoes with the staging kit Willem Jiang Twitter: willemjiang Weibo: willem On Tue, Nov 27, 2018 at 2:08 PM Mohammad Asif Siddiqui wrote: >> Hello All, > > This is a call for a Vote to release Apache ServiceComb Java-Chassis version > 1.1.0 > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12343569 > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.1.0/rc-01/ > > Staging Repo : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1352 > > Release Tag : > https://github.com/apache/servicecomb-java-chassis/releases/tag/1.1.0 > > Release CommitID : 1fa24999399f5d2f8e7dc7bc0972e3f3458f0374 > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Tuesday, 27th November, 2018) and will remain open > for at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 1.1.0 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > Mohammad Asif Siddiqui
Re: [Discuss]Adding Etcd as a config center for Java-Chassis
etcd used by service center is not allowed to expose directly to any client, this etcd only exposed service center. unless you setup isolated etcd cluster for config management Yang Bo 于2018年11月28日周三 上午10:08写道： > @Sure > Yes we can use consul. I choose etcd just because service-center already > uses it. Actually, if we go with consul, we can even drop service-center, > as consul provides service registry/discovery and configuration store. We > can keep the schema data as configuration. > > I've been suggesting to opensource the CC and it's frontend since May/June. > But here we are, there are still no timeline when this will be done. > And without this 2 component, the opensource version(servicecomb) feels > like a lackluster system. > > On Wed, Nov 28, 2018 at 9:11 AM Willem Jiang > wrote: > > > If we have plan to open source the config center and governance, > > it's could be better we start a discussion here to make a road map. > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Wed, Nov 28, 2018 at 8:34 AM wjm wjm wrote: > > > > > > it's better to make huawei config center opensource > > > after governance opensource, can work with huawei config center > directly > > > > > > Yang Bo 于2018年11月27日周二 下午2:21写道： > > > > > > > Etcd in itself is good enough to be used as a config center. I don't > > see > > > > the need for an extra layer, it reduces performance and adds > > complexity. > > > > > > > > For example, if we use Etcd directly, the watch mechanism is > naturally > > > > supported by grpc which uses http2, there's no need for using > websocket > > > > which might have problems under some firewall rules. > > > > > > > > I checked the CC(CSE) client implementation in java-chassis, it uses > > vert.x > > > > and http to talk to the server and use websocket for watching when > > > > possible. > > > > > > > > It have implemented tenant, environment separation and we can achieve > > this > > > > by using proper key prefixes in Etcd(v3). I don't see a particular > > feature > > > > impossible to implement using Etcd only. > > > > > > > > Besides, it takes a lot of time and effort to opensource the > > Config-Center. > > > > > > > > There is one minor issue for Etcd though. The official Etcd client > for > > java > > > > jetcd is not published to central maven repository yet. They are > > preparing > > > > an official 0.3.0 release but does not have a timeline for it. > > > > > > > > On Tue, Nov 27, 2018 at 9:50 AM bismy wrote: > > > > > > > > > Do you have any evaluation document by using etcd as config center? > > Now > > > > > config-cc supports using Huawei Config Center as the backend. And > > this > > > > > implementation is based on ectd with an extra abstraction like > > service > > > > > center. I am not quite sure if using etcd itself can fitful for > > users use > > > > > cases and if it is a good solution or just a workable solution. > > > > > > > > > > > > > > > Maybe we can make Huawei Config Center opensource and distribute it > > like > > > > > service center which is quite simple too. > > > > > > > > > > > > > > > -- 原始邮件 -- > > > > > 发件人: "Yang Bo"; > > > > > 发送时间: 2018年11月26日(星期一) 晚上7:30 > > > > > 收件人: "dev"; > > > > > > > > > > 主题: [Discuss]Adding Etcd as a config center for Java-Chassis > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > The ServiceComb project does not have a usable config-center and > many > > > > users > > > > > have shown concerns about it. (Apollo is too complex to setup and > > have > > > > high > > > > > learning cure in using/maintaining). > > > > > > > > > > I tried to build a config-center around Etcd for Java-Chassis, it's > > quite > > > > > simple. Most of the features from the CC(CSE) can be achieved. > > > > > > > > > > From my point of view, using Etcd is good for small projects, show > > cases > > > > > and in development, because we already have an Etcd instance > > > > > running(service-center needs it). > > > > > > > > > > The code is here(it's just a demonstration, needs improvement): > > > > > https://github.com/yangbor/servicecomb-java-chassis/tree/cc-etcd > > > > > > > > > > Any thoughts? > > > > > > > > > > -- > > > > > Best Regards, > > > > > Yang. > > > > > > > > > > > > > > > > -- > > > > Best Regards, > > > > Yang. > > > > > > > > > -- > Best Regards, > Yang. >
Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0
+1 I checked: 1. license is ok 2. demos is work -- Original -- From: Willem Jiang Date: Wed,Nov 28,2018 10:37 AM To: dev Subject: Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0 +1. I checked: - signatures and hashes correct - LICENSE is fine - NOTICE is OK - no unexpected binary files - source files have headers checked with RAT - can build the kit from source without any error - can run the demoes with the staging kit Willem Jiang Twitter: willemjiang Weibo: willem On Tue, Nov 27, 2018 at 2:08 PM Mohammad Asif Siddiqui wrote: >> Hello All, > > This is a call for a Vote to release Apache ServiceComb Java-Chassis version > 1.1.0 > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12343569 > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.1.0/rc-01/ > > Staging Repo : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1352 > > Release Tag : > https://github.com/apache/servicecomb-java-chassis/releases/tag/1.1.0 > > Release CommitID : 1fa24999399f5d2f8e7dc7bc0972e3f3458f0374 > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Tuesday, 27th November, 2018) and will remain open > for at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 1.1.0 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > Mohammad Asif Siddiqui
Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0
+1. I checked: - signatures and hashes correct - LICENSE is fine - NOTICE is OK - no unexpected binary files - source files have headers checked with RAT - can build the kit from source without any error - can run the demoes with the staging kit Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, Nov 27, 2018 at 2:08 PM Mohammad Asif Siddiqui wrote: >> Hello All, > > This is a call for a Vote to release Apache ServiceComb Java-Chassis version > 1.1.0 > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626&version=12343569 > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.1.0/rc-01/ > > Staging Repo : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1352 > > Release Tag : > https://github.com/apache/servicecomb-java-chassis/releases/tag/1.1.0 > > Release CommitID : 1fa24999399f5d2f8e7dc7bc0972e3f3458f0374 > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Tuesday, 27th November, 2018) and will remain open > for at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 1.1.0 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > Mohammad Asif Siddiqui
Re: [Discuss]Adding Etcd as a config center for Java-Chassis
@Sure Yes we can use consul. I choose etcd just because service-center already uses it. Actually, if we go with consul, we can even drop service-center, as consul provides service registry/discovery and configuration store. We can keep the schema data as configuration. I've been suggesting to opensource the CC and it's frontend since May/June. But here we are, there are still no timeline when this will be done. And without this 2 component, the opensource version(servicecomb) feels like a lackluster system. On Wed, Nov 28, 2018 at 9:11 AM Willem Jiang wrote: > If we have plan to open source the config center and governance, > it's could be better we start a discussion here to make a road map. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Nov 28, 2018 at 8:34 AM wjm wjm wrote: > > > > it's better to make huawei config center opensource > > after governance opensource, can work with huawei config center directly > > > > Yang Bo 于2018年11月27日周二 下午2:21写道： > > > > > Etcd in itself is good enough to be used as a config center. I don't > see > > > the need for an extra layer, it reduces performance and adds > complexity. > > > > > > For example, if we use Etcd directly, the watch mechanism is naturally > > > supported by grpc which uses http2, there's no need for using websocket > > > which might have problems under some firewall rules. > > > > > > I checked the CC(CSE) client implementation in java-chassis, it uses > vert.x > > > and http to talk to the server and use websocket for watching when > > > possible. > > > > > > It have implemented tenant, environment separation and we can achieve > this > > > by using proper key prefixes in Etcd(v3). I don't see a particular > feature > > > impossible to implement using Etcd only. > > > > > > Besides, it takes a lot of time and effort to opensource the > Config-Center. > > > > > > There is one minor issue for Etcd though. The official Etcd client for > java > > > jetcd is not published to central maven repository yet. They are > preparing > > > an official 0.3.0 release but does not have a timeline for it. > > > > > > On Tue, Nov 27, 2018 at 9:50 AM bismy wrote: > > > > > > > Do you have any evaluation document by using etcd as config center? > Now > > > > config-cc supports using Huawei Config Center as the backend. And > this > > > > implementation is based on ectd with an extra abstraction like > service > > > > center. I am not quite sure if using etcd itself can fitful for > users use > > > > cases and if it is a good solution or just a workable solution. > > > > > > > > > > > > Maybe we can make Huawei Config Center opensource and distribute it > like > > > > service center which is quite simple too. > > > > > > > > > > > > -- 原始邮件 -- > > > > 发件人: "Yang Bo"; > > > > 发送时间: 2018年11月26日(星期一) 晚上7:30 > > > > 收件人: "dev"; > > > > > > > > 主题: [Discuss]Adding Etcd as a config center for Java-Chassis > > > > > > > > > > > > > > > > Hi, > > > > > > > > The ServiceComb project does not have a usable config-center and many > > > users > > > > have shown concerns about it. (Apollo is too complex to setup and > have > > > high > > > > learning cure in using/maintaining). > > > > > > > > I tried to build a config-center around Etcd for Java-Chassis, it's > quite > > > > simple. Most of the features from the CC(CSE) can be achieved. > > > > > > > > From my point of view, using Etcd is good for small projects, show > cases > > > > and in development, because we already have an Etcd instance > > > > running(service-center needs it). > > > > > > > > The code is here(it's just a demonstration, needs improvement): > > > > https://github.com/yangbor/servicecomb-java-chassis/tree/cc-etcd > > > > > > > > Any thoughts? > > > > > > > > -- > > > > Best Regards, > > > > Yang. > > > > > > > > > > > > -- > > > Best Regards, > > > Yang. > > > > -- Best Regards, Yang.
Re: [Discuss]Adding Etcd as a config center for Java-Chassis
If we have plan to open source the config center and governance, it's could be better we start a discussion here to make a road map. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Wed, Nov 28, 2018 at 8:34 AM wjm wjm wrote: > > it's better to make huawei config center opensource > after governance opensource, can work with huawei config center directly > > Yang Bo 于2018年11月27日周二 下午2:21写道： > > > Etcd in itself is good enough to be used as a config center. I don't see > > the need for an extra layer, it reduces performance and adds complexity. > > > > For example, if we use Etcd directly, the watch mechanism is naturally > > supported by grpc which uses http2, there's no need for using websocket > > which might have problems under some firewall rules. > > > > I checked the CC(CSE) client implementation in java-chassis, it uses vert.x > > and http to talk to the server and use websocket for watching when > > possible. > > > > It have implemented tenant, environment separation and we can achieve this > > by using proper key prefixes in Etcd(v3). I don't see a particular feature > > impossible to implement using Etcd only. > > > > Besides, it takes a lot of time and effort to opensource the Config-Center. > > > > There is one minor issue for Etcd though. The official Etcd client for java > > jetcd is not published to central maven repository yet. They are preparing > > an official 0.3.0 release but does not have a timeline for it. > > > > On Tue, Nov 27, 2018 at 9:50 AM bismy wrote: > > > > > Do you have any evaluation document by using etcd as config center? Now > > > config-cc supports using Huawei Config Center as the backend. And this > > > implementation is based on ectd with an extra abstraction like service > > > center. I am not quite sure if using etcd itself can fitful for users use > > > cases and if it is a good solution or just a workable solution. > > > > > > > > > Maybe we can make Huawei Config Center opensource and distribute it like > > > service center which is quite simple too. > > > > > > > > > -- 原始邮件 -- > > > 发件人: "Yang Bo"; > > > 发送时间: 2018年11月26日(星期一) 晚上7:30 > > > 收件人: "dev"; > > > > > > 主题: [Discuss]Adding Etcd as a config center for Java-Chassis > > > > > > > > > > > > Hi, > > > > > > The ServiceComb project does not have a usable config-center and many > > users > > > have shown concerns about it. (Apollo is too complex to setup and have > > high > > > learning cure in using/maintaining). > > > > > > I tried to build a config-center around Etcd for Java-Chassis, it's quite > > > simple. Most of the features from the CC(CSE) can be achieved. > > > > > > From my point of view, using Etcd is good for small projects, show cases > > > and in development, because we already have an Etcd instance > > > running(service-center needs it). > > > > > > The code is here(it's just a demonstration, needs improvement): > > > https://github.com/yangbor/servicecomb-java-chassis/tree/cc-etcd > > > > > > Any thoughts? > > > > > > -- > > > Best Regards, > > > Yang. > > > > > > > > -- > > Best Regards, > > Yang. > >
Re: [Discuss]Adding Etcd as a config center for Java-Chassis
Why not use consul? There are more advantages then etcd, for example multiple dc. -- Original -- From: wjm wjm Date: Wed,Nov 28,2018 8:34 AM To: dev Subject: Re: [Discuss]Adding Etcd as a config center for Java-Chassis it's better to make huawei config center opensource after governance opensource, can work with huawei config center directly Yang Bo ??2018??11??27?? 2:21?? > Etcd in itself is good enough to be used as a config center. I don't see > the need for an extra layer, it reduces performance and adds complexity. > > For example, if we use Etcd directly, the watch mechanism is naturally > supported by grpc which uses http2, there's no need for using websocket > which might have problems under some firewall rules. > > I checked the CC(CSE) client implementation in java-chassis, it uses vert.x > and http to talk to the server and use websocket for watching when > possible. > > It have implemented tenant, environment separation and we can achieve this > by using proper key prefixes in Etcd(v3). I don't see a particular feature > impossible to implement using Etcd only. > > Besides, it takes a lot of time and effort to opensource the Config-Center. > > There is one minor issue for Etcd though. The official Etcd client for java > jetcd is not published to central maven repository yet. They are preparing > an official 0.3.0 release but does not have a timeline for it. > > On Tue, Nov 27, 2018 at 9:50 AM bismy wrote: > > > Do you have any evaluation document by using etcd as config center? Now > > config-cc supports using Huawei Config Center as the backend. And this > > implementation is based on ectd with an extra abstraction like service > > center. I am not quite sure if using etcd itself can fitful for users use > > cases and if it is a good solution or just a workable solution. > > > > > > Maybe we can make Huawei Config Center opensource and distribute it like > > service center which is quite simple too. > > > > > > -- -- > > ??: "Yang Bo"; > > : 2018??11??26??(??) 7:30 > > ??: "dev"; > > > > : [Discuss]Adding Etcd as a config center for Java-Chassis > > > > > > > > Hi, > > > > The ServiceComb project does not have a usable config-center and many > users > > have shown concerns about it. (Apollo is too complex to setup and have > high > > learning cure in using/maintaining). > > > > I tried to build a config-center around Etcd for Java-Chassis, it's quite > > simple. Most of the features from the CC(CSE) can be achieved. > > > > From my point of view, using Etcd is good for small projects, show cases > > and in development, because we already have an Etcd instance > > running(service-center needs it). > > > > The code is here(it's just a demonstration, needs improvement): > > https://github.com/yangbor/servicecomb-java-chassis/tree/cc-etcd > > > > Any thoughts? > > > > -- > > Best Regards, > > Yang. > > > > -- > Best Regards, > Yang. >
Re: [Discuss]Adding Etcd as a config center for Java-Chassis
it's better to make huawei config center opensource after governance opensource, can work with huawei config center directly Yang Bo 于2018年11月27日周二 下午2:21写道： > Etcd in itself is good enough to be used as a config center. I don't see > the need for an extra layer, it reduces performance and adds complexity. > > For example, if we use Etcd directly, the watch mechanism is naturally > supported by grpc which uses http2, there's no need for using websocket > which might have problems under some firewall rules. > > I checked the CC(CSE) client implementation in java-chassis, it uses vert.x > and http to talk to the server and use websocket for watching when > possible. > > It have implemented tenant, environment separation and we can achieve this > by using proper key prefixes in Etcd(v3). I don't see a particular feature > impossible to implement using Etcd only. > > Besides, it takes a lot of time and effort to opensource the Config-Center. > > There is one minor issue for Etcd though. The official Etcd client for java > jetcd is not published to central maven repository yet. They are preparing > an official 0.3.0 release but does not have a timeline for it. > > On Tue, Nov 27, 2018 at 9:50 AM bismy wrote: > > > Do you have any evaluation document by using etcd as config center? Now > > config-cc supports using Huawei Config Center as the backend. And this > > implementation is based on ectd with an extra abstraction like service > > center. I am not quite sure if using etcd itself can fitful for users use > > cases and if it is a good solution or just a workable solution. > > > > > > Maybe we can make Huawei Config Center opensource and distribute it like > > service center which is quite simple too. > > > > > > -- 原始邮件 -- > > 发件人: "Yang Bo"; > > 发送时间: 2018年11月26日(星期一) 晚上7:30 > > 收件人: "dev"; > > > > 主题: [Discuss]Adding Etcd as a config center for Java-Chassis > > > > > > > > Hi, > > > > The ServiceComb project does not have a usable config-center and many > users > > have shown concerns about it. (Apollo is too complex to setup and have > high > > learning cure in using/maintaining). > > > > I tried to build a config-center around Etcd for Java-Chassis, it's quite > > simple. Most of the features from the CC(CSE) can be achieved. > > > > From my point of view, using Etcd is good for small projects, show cases > > and in development, because we already have an Etcd instance > > running(service-center needs it). > > > > The code is here(it's just a demonstration, needs improvement): > > https://github.com/yangbor/servicecomb-java-chassis/tree/cc-etcd > > > > Any thoughts? > > > > -- > > Best Regards, > > Yang. > > > > -- > Best Regards, > Yang. >
