Agree with Willem, it sounds good to providing a user story to show a whole picture.
Best Regards, --- Zen Lin [email protected] Focused on Micro Service and Apache ServiceComb Willem Jiang <[email protected]> 于2018年7月16日周一 上午10:20写道： > Hi, Lance, > > I think you provide a tool that can convert the old ServiceComb > configuration into Istio related setting files, am I right? > > It could save some time of user if they want to migrate to Istio. But I'd > like to see a user story to show us a whole picture. > You can take a look at this[1] as an example. > > [1] > > https://developer.okta.com/blog/2018/07/11/ci-cd-spring-boot-jenkins-x-kubernetes > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, Jul 13, 2018 at 3:44 PM, Lance Ju <[email protected]> wrote: > > > Hi, gang! > > > > I'm thinking about handling configs of both ServiceComb and other > > frameworks(like Istio), then provide a unified solution for config > > management, to support the hybrid solution scenario(like, user use > > ServiceComb and Istio at the same time). > > > > So the first thing to do is to make sure that the chassis configs > have > > an equivalent mapping of other frameworks. Currently, I'm testing the > rate > > limit configs between ServiceComb and Istio, it's working. I write a demo > > about this at https://github.com/crystaldust/configcomb, receive a > > chassis.yaml, read the Flowcontrol field, then convert it to Istio rate > > limit rules and apply the rules in a kubernetes cluster. It should also > > work the opposite way. > > > > By doing so, it is possible to provide a unified solution for config > > management, any ideas? > > >
