OpenKruise里，请问这种场景下，kruise-rollout要这么做呢？
"请问这种场景下，kruise-rollout要这么做呢 初始状态：发布计划三批(replicas=1,2,5)，v2版本发完了第二批(状态: v1.replicas=3,v2.replicas=2) 动作：v2出问题了，有一个hotfix版本v3，发布计划要改成一批5个全部发完 结果：更改发布计划之后，v2.replicas=5，发布v3后,v3.replicas=5，这部分代码我读到了，我觉得https://github.com/openkruise/rollouts/blob/master/pkg/controller/rollout/rollout_progressing.go#L237这里的代码改成v1alpha1.CanaryStepStatePaused更好一点，另外既然计划都已经改了，直接从第一步开始不就好了，能不能给我们增加一个文档。。就是上面场景应该如何做？ 估计很多用户都有你们一样的问题，现在正常发布啥的没啥问题，这种 bugfix 或者 回滚啥的，很多用户估计不知道咋办。。。https://openkruise.io/rollouts/introduction如果他们想要赌或者自爆，作为三方平台也只能执行；但在执行的过程中，不要有预期外的工作负载版本调整就好，尤其有些人真的会做没有留后路的数据迁移，这种时候会有人选择头铁 hotfix 的，总之都是比较头疼、实质上是安全生产问题但没法约束三方使用者的场景"
写回答
-
"要不也写个 issue 吧，提供下复现步骤给社区，方便他们进一步复现，现在的场景可能是这样的： 1. 直接修改 rollout：等于临时改计划，还是要接着按照原来的 partition ceiling 把 v2 发下去 2. 涉及到一个 v3 的情况：先改 rollout 肯定会走 1 的逻辑，所以要看下 v3 之后 rollout 的反应，想要彻底搞定这个问题，得搞个 Rollout 和 RolloutRun 这样的设计，一次版本变更不允许变更 RolloutRun，暴力排一个 pause 进去，这种我理解也要区分看，灰度发布不符合预期，可能是新版本的pod直接crash没起来，也有可能是running了但是业务逻辑有问题导致没有达到预期；如果是前者，那平台可以感知到并拦住用户的后续过激操作，及时提醒客户应该赶快回滚啦；如果是后者，那平台确实感知不到，只能依赖客户的业务素养了，是选择继续梭哈还是安全回滚，平台还是会提供对应的能力，当然，对于没有回头路的发布，只能硬着头皮继续v3了，如果你们平台方会把配置存DB么？如果存的话，用户修改 rollout 计划的修改是不会立刻生效，还是改的 DB 吧？具体生效是不是还是得等用户点 发布 的时候再一块 apply，此回答整理自钉群“OpenKruise 社区交流群(答疑@机器人)”"
2023-06-20 16:04:14赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
