由于更新了错误的应用配置导致应用状态变为失败，且无法再次修改配置，提示：can not upgrade application now

yuenwah

这就没有能解决的办法吗？

Feynman

这个问题方便描述清晰一点吗？哪个版本？如何复现？

sekfung

Feynman 我在v3.1.1 v3.2.0 都遇到过。

只要在控制台 value 配置写错，更新应用就会失败，且一直为失败状态，无法再次更新。但是在本地执行helm upgrade是可以的。

sekfung

Feynman 有没有什么途径可以更改控制台上应用的状态？一直显示失败，又不能删除应用，看着别扭

Feynman

sekfung 听起来是 KubeSphere 的一个 Bug，方便在 GitHub issue 记录一下这个问题吗？

sigboom

Feynman sekfung

我查阅了代码（tag:v3.2.1）发现是 pkg\models\openpitrix\release.go 函数 UpgradeApplication 的 oldRls.Status.State 变量判断存在不足，当状态是 fail 的时候，从后台将无法更新

下面是修复方法：

需要修改 HelmRelease 的 status 可以参考下：http://kuring.me/post/update-cr-status/

有几点需要注意下

文章中的 obj_file 文件不需要其他部分信息，只需要 status 的信息
HelmRelease 资源没有命名空间

下面是我提供的参考代码：

#!/bin/bash

obj_file=$1
kind=helmreleases
APISERVER=https://127.0.0.1:6443
TOKEN=eyJhbGciOiJSUzI1NXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
obj=rls-8myv4kr2n6ovkw

echo "begin to patch $obj the file "${obj_file}
curl -XPATCH -H "Accept: application/json" -H  "Content-Type: application/merge-patch+json" --header "Authorization: Bearer $TOKEN" --insecure -d  @${obj_file} $APISERVER/apis/application.kubesphere.io/v1alpha1/${kind}/$obj/status

sigboom

后续是否有修复呢？我也遇到了相同的问题

weitingwei

sbin xuanyuanaosheng

由于更新应用接口仅处理 status为"active"、“creating”、"upgraded"的 helm release 数据，导致 “failed” 状态的 helm release无法更新升级，我们规划在后续版本中完善更新应用接口处理逻辑。

目前，可以参考 sigboom 提供的方式修改helmreleases的status后，再使用控制台配置value更新应用

wanghongyjy

sigboom 需要更改状态的helmrelease是harbor应用，应用是TLS访问模式。

使用这个方法执行脚本后，显示

“message”: "Error: UPGRADE FAILED: execution error at (harbor/templates/nginx/secret.yaml:3:12): The “expose.tls.auto.commonName” is required!\n",
“state”: “failed”,

请问如何处理？

sbin

现在依旧有这个问题。

Harbor更新后，就不能再更新了，一样的表现。

xuanyuanaosheng

当部署完毕的应用的状态为失败，就无法在升级或者修改配置了

xuanyuanaosheng

weitingwei @sigboom 怎样获取对应的obj 以及怎样构建：obj_file？

我使用下面的方法，但是不对。

获取obj
obj_file 如下：

{
  "status": {
    "phase": "Running"
  }
}

weitingwei

xuanyuanaosheng

解决状态为失败的应用无法升级的问题，需要修改kubectl get helmreleases.application.kubesphere.io gitlab-sre 的 Status 为"active"、“creating” 或"upgraded" ，http://kuring.me/post/update-cr-status/ 该文档仅提供了修改参考，你可以参考其他类似指导文档，直到成功修改helmrelease gitlab-sre cr的status即可

sigboom

wanghongyjy 这个属于 helm 的报错，可以先在本地运行测试成功后再上线部署

helm template –debug <Charts 路径>

openxxs

v3.3.1 版本问题依旧没有修复。同时通过文中提供的方法，将对应的 helmreleases.application.kubesphere.io 修改status，修改后查看资源状态，status 又被改回了 failed，初步判断是有控制器在校准status，因此patch改status的方法也失效了。patch的内容如下：

{
    "status": {
        "state": "active"
    }
}

openxxs

查看了kubesphere源码，在每次进行应用更新操作时，不仅校验helmreleases.application.kubesphere.io资源的状态，还会通过Helm Chart中的状态进行校准：

func (c *helmWrapper) Upgrade(chartName, chartData, values string) error {
	sts, err := c.Status()
	if err != nil {
		return err
	}

	if sts.Info.Status == "deployed" {
		return c.writeAction(chartName, chartData, values, true)
	} else {
		err = errors.New("cannot upgrade release %s/%s, current state is %s", c.Namespace, c.ReleaseName, sts.Info.Status)
		return err
	}
}

因此需要先将Helm Chart 对应的 release 修改正确，具体方式为：

找到应用对应helm的最新部署secret，类似 sh.helm.release.v1.应用名.v应用版本号。
编辑 secrets，将 metadata.labels.status 由 failed 改为 deployed。
取出 data.release 的值，进行 base64 –decode，再对结果进行 gzip -d，得到 release 的完整信息，将信息中的 status 由 failed 改为 deployed。修改后，再通过 gzip 和 base64 生成新的 data.release 值，变更到 secrets 中。

按照上文 sigboom 的方法修改helmreleases.application.kubesphere.io资源的状态，obj_file 类似于：

{
  "status": {
    "deployStatus": [
    ],
    "state": "active",
    "version": 这里写helm中的version值
  }
}

回到应用页面，看到状态变更为了 Running，且会按照你最后一次操作更新的配置（最后一次点击了但显示can not upgrade application now时的目标配置）自动进行更新部署。

恢复方式比较trick且繁琐，希望官方能够尽快提供rollingback等功能。