Kent Dong

> > 变更冻结这种需求是否应该在源头进行限制，而不是在最终生效的地方？ > > 你上面也提到了，不管是谁重启，controller 还是 gateway，都会导致被冻结的变更在终端生效，产生预期外的配置变更。 > > 用户现场，我们总是会遇到有人(不一定是自己人)操作后台，并因此受到处罚，所以依赖"口头约定“是最不可靠的。 源头限制是一个比较好的方案，整个控制面(包括ui)都是"只能查，不能改"状态，但这涉及的面可能更广。 建议是从变更源头来限制。比如大家一般修改配置都是走UI，那么UI卡住可以满足绝大部分的需求，而且变更风险低。

> > > > 变更冻结这种需求是否应该在源头进行限制，而不是在最终生效的地方？ > > > > 你上面也提到了，不管是谁重启，controller 还是 gateway，都会导致被冻结的变更在终端生效，产生预期外的配置变更。 > > > > > > > > > 用户现场，我们总是会遇到有人(不一定是自己人)操作后台，并因此受到处罚，所以依赖"口头约定“是最不可靠的。 源头限制是一个比较好的方案，整个控制面(包括ui)都是"只能查，不能改"状态，但这涉及的面可能更广。 > > > > > > 建议是从变更源头来限制。比如大家一般修改配置都是走UI，那么UI卡住可以满足绝大部分的需求，而且变更风险低。...

> > > > > > 变更冻结这种需求是否应该在源头进行限制，而不是在最终生效的地方？ > > > > > > 你上面也提到了，不管是谁重启，controller 还是 gateway，都会导致被冻结的变更在终端生效，产生预期外的配置变更。 > > > > > > > > > > > > > >...

> > > 一些漏洞指的是重启会引起配置推送吗? 这个是预期的 如果是controller重启，默认本身就是允许推送的 如果是gateway重启，肯定要保证重启后的gateway能拉取配置并成功运行 > > > 而且正常运行过程，不应该出现两个组件重启的情况，该方案主要是为了限制正常运行过程，控制平面主动推送的场景，不管是人为操作还是程序流程。 > > > > > > 不只是重启。一般对稳定性要求高的场景，我们都要考虑横向扩容的可能性。比如在业务高峰期，我们冻结变更以保证稳定。同时，集群的容量也需要能够及时横向扩展以应对流量的上涨。很多时候，我们会使用 K8s 提供的 HPA 等技术来进行自动的集群容量调整。在这种情况下使变更生效，而且集群内各实例的配置不一致，应该不能算是预期内的吧？ > > 扩容后的影响是否可以忽略还是要看用户场景， PR中的“在需要极高稳定性的客户环境下，客户"强制"规定在某个时间范围不允许进行配置变更"的另一层面是不会对集群内进行任何变更操作，包括扩缩容，只允许在固定时间窗口内做变更操作(比如证券行业的休市时间)，所以对于我们的使用场景这点是可以忽略的。 > > 因为PR限制的是主动推送，如果希望使用了该功能+动态扩容+配置一致，那就扩容前调用 /debug/ignorePushRequest?disable=true&push=true...

> @CH3CHO @2456868764 @johnlanni > > 目前nacos相关的ci，主要是如下这个test不通过测试。 > > ``` > --- FAIL: TestHigressConformanceTests/HTTPRouteDefaultBackend (30.01s) > --- FAIL: TestHigressConformanceTests/HTTPRouteDefaultBackend/HTTPRoute_fallback_default_backend (30.00s) > ``` > > 有什么建议吗？是单独拿出来跳过还是需要做额外配置。 > > 目前的nacos-ci流程是base目录下依然是k8s client去应用配置，test目录下的yaml文件则通过nacos进行发布，然后运行test。 本地跑一下试试呢，debug看看。

`"response_flags":"NR"` 是找不到路由的意思。能提供一下PostMan的测试请求配置吗？

好的。我本地验证一下。

我本地试了一下，是可以的。  ```proto syntax = "proto3"; option java_multiple_files = true; option java_package = "com.realch3cho.grpctest.grpc"; option go_package = ".;common"; message HelloRequestType { string name = 1; } message HelloResponseType { string...

我有一个问题，8080端口是gRPC的吗？

ingress 修改成 prefix 之后的 access log 能发一下吗？还是之前的报错吗？ 你可以试试 exec 到 higress-gateway 那个 pod 里，执行 `curl -svk http://go-ping-s.default.svc.cluster.local:8080`，把输出贴一下。