Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: PersistService.updateConfigInfo4Beta whether lost set beta_ips=? #6506

Closed
CherishCai opened this issue Jul 29, 2021 · 9 comments
Closed

Comments

@CherishCai
Copy link
Contributor

CherishCai commented Jul 29, 2021

Is your feature request related to a problem? Please describe.
我期望多次灰度时仅变更 betaIps, 目的是把灰度逐步推进到全量,例如按照灰度 10% 20% 30% 50% 100%。

I expect that only betaIps will be changed for multiple gray levels, the purpose is to gradually advance the gray level to the full amount, for example, according to gray level 10% 20% 30% 50% 100%.

But now ExternalStoragePersistServiceImpl.updateConfigInfo4Beta please see the code below. The parameter betaIps is not used.

@Override
    public void updateConfigInfo4Beta(ConfigInfo configInfo, String betaIps, String srcIp, String srcUser,
            Timestamp time, boolean notify) {
        String appNameTmp = StringUtils.isBlank(configInfo.getAppName()) ? StringUtils.EMPTY : configInfo.getAppName();
        String tenantTmp = StringUtils.isBlank(configInfo.getTenant()) ? StringUtils.EMPTY : configInfo.getTenant();
        String md5 = MD5Utils.md5Hex(configInfo.getContent(), Constants.ENCODE);
        try {
            jt.update(
                    "UPDATE config_info_beta SET content=?, md5 = ?, src_ip=?,src_user=?,gmt_modified=?,app_name=? WHERE "
                            + "data_id=? AND group_id=? AND tenant_id=?", configInfo.getContent(), md5, srcIp, srcUser,
                    time, appNameTmp, configInfo.getDataId(), configInfo.getGroup(), tenantTmp);
        } catch (CannotGetJdbcConnectionException e) {
            LogUtil.FATAL_LOG.error("[db-error] " + e.toString(), e);
            throw e;
        }
    }

Describe the solution you'd like
sql add beta_ips=?, and set betaIps.

jt.update("UPDATE config_info_beta SET content=?, md5 = ?, beta_ips=?, src_ip=?,src_user=?,gmt_modified=?,app_name=? WHERE "
                 + "data_id=? AND group_id=? AND tenant_id=?", configInfo.getContent(), md5, betaIps, srcIp,
           srcUser, time, appNameTmp, configInfo.getDataId(), configInfo.getGroup(), tenantTmp);
@realJackSun
Copy link
Collaborator

目前nacos的beta发布只支持两批次发布,即先发布一部分,线上观察没有问题再更新剩下一部分。

@CherishCai
Copy link
Contributor Author

目前nacos的beta发布只支持两批次发布,即先发布一部分,线上观察没有问题再更新剩下一部分。

目前 console 上确实仅能 beta 发布一次,然后就只能是 停止 或者 全量发布。

可以考虑灰度多次?先选一部分,然后再扩大灰度列表

@CherishCai
Copy link
Contributor Author

初步判断是要变更 上述 SQL 还有下面的 ConfigCacheService.updateBetaMd5,我先尝试下再来反馈。

image

@CherishCai
Copy link
Contributor Author

初步判断是要变更 上述 SQL 还有下面的 ConfigCacheService.updateBetaMd5,我先尝试下再来反馈。

image

以上两部分变更,支持多次灰度已内部使用一段时间,符合诉求,期望社区考虑同时寻找前端 console 支持,谢谢。
@realJackSun

@CherishCai
Copy link
Contributor Author

可以实现达到,按需灰度,充分灰度。只是需要 nacos 前端也优化一下则更好。根据这部分,我晚点提个 PR ~
image


另外提一个点,nacos 开源管控台 beta 到全量发布时,先删 beta 还是先生效发布,不知是否有这样的情况:

 /*
 * 先执行生效发布,再进行灰度清理;原因如下:
 * 1. 对于已处于灰度中的客户端,若先清理灰度,它们会回滚到旧的配置,然后再和其它客户端一同达到生效配置;
 * 2. 对于已处于灰度中的客户端,若先生效发布,因为此时灰度的 md5 和生效的 md5 一致,故灰度中的客户端,无需回滚;然后清理灰度就非常静默。
 * 总结:先生效发布,再清理灰度,会减少(处于灰度中的)客户端变更事件。
 */

@CherishCai
Copy link
Contributor Author

CherishCai commented May 6, 2022

TODO

  1. 期望社区考虑寻找前端通知 console 支持多次 betaIps 灰度;
  2. 考虑 beta 到全量发布时,先生效发布,再清理灰度,会减少(处于灰度中的)客户端变更事件。

@Cczzzz
Copy link

Cczzzz commented Mar 25, 2024

如果是减少灰度ip ,那么被删除的ip的客户端能马上收到一个正式版本的推送吗?

@CherishCai
Copy link
Contributor Author

如果是减少灰度ip ,那么被删除的ip的客户端能马上收到一个正式版本的推送吗?

@Cczzzz 会呀,那就是没有灰度,和未灰度的一致

@Cczzzz
Copy link

Cczzzz commented Mar 26, 2024

如果是减少灰度ip ,那么被删除的ip的客户端能马上收到一个正式版本的推送吗?

@Cczzzz 会呀,那就是没有灰度,和未灰度的一致
我们自己也实现了这个功能,需要把被删除的ip 也放到事件里面触发推送,才能让它触发一次拉取回到正式版。
不然删除的灰度ip 没法感觉变化去回到正式版本啊

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants