Jason Song

RepositoryChangeListener 应该没法实现这个需求吧，可行的方式可以参考 com.ctrip.framework.apollo.config.data.internals.PureApolloConfigFactory，通过 ApolloInjectorCustomizer 来自定义一个 Config 类实现出来

@qxo 通过 onRepositoryChange 应该无法实现诸如`敏感信息（如密码）的解密处理`，这里传入的 properties 对象虽然目前是可写的，但是从语义上而言只能当作是 readonly 的，所以如果要解密的话，还是需要通过自定义 Config 类来实现的，或者在 fireRepositoryChange 中增加一个新的 spi，专门用于对 properties 进行加工处理

我加了 discussion 标签，开放一段时间看看大家的想法吧~

很好的建议

I think we could have the 3rd grayscale rule to support the percentage scenario, but the implementation details need more discussion, e.g. how to keep the container fetch the grayscale...

If the instance list is static, the percentage grayscale rule is easy to implement. However, if the instance list is changing, which is quite common considering deployment/rebooting/scaling scenarios, then it's...

Does it mean we need to re-calculate the grayscale instance list every time when the instance lists change(step 2)? This will make the implementation complicated. However, I have a suggestion...

Thanks for the clarification, the `grayscale amount` is an interesting idea. However, I still have some concerns about the dynamic grayscale lists, but I'm open to discussions. BTW, I think...

> it may have something to do with the apollo design which defines instances 2 minutes from now are active the current active instance definition is 25 hours, see https://github.com/apolloconfig/apollo/blob/5ad5b410f0ff43111855d7bd76e047d08ab477b4/apollo-biz/src/main/java/com/ctrip/framework/apollo/biz/service/InstanceService.java#L155-L164

> Yes, but when gray configs are changed, the grayscale label rules need user to reboot k8s deployment I suppose the grayscale period should be temporary. So we may always...