6.2. 修复了 Red Hat Developer Hub 1.2 的问题

Backstage 1.25 中引入的上游安全修复需要所有后端端点的身份验证令牌，包括动态插件使用的静态资产。

在这个版本中，用户可以访问动态插件 UI 元素，从而导致用户体验降低应用程序中的功能。

在本发行版本中，动态插件静态资产的安全要求已被删除，它会恢复对动态插件 UI 元素的访问。

在这个版本中，用户可以查看和与动态插件 UI 元素交互，从而提高了应用程序中的可用性和功能。

在早期版本的 Red Hat Developer Hub 中，使用策略操作定义条件策略会导致错误。

此问题导致定义条件策略比较困难，从而阻止应用程序的配置权限。

在这个版本中，您可以使用权限策略操作在 Developer Hub 中定义条件策略。

在早期版本的 Red Hat Developer Hub Operator 中，无法使用 Custom Resource 中的 spec.application.route.host 字段在 OpenShift Container Platform 上设置自定义 Route 主机。

这个限制会阻止用户配置自定义路由主机，限制他们自定义部署环境的能力。

在这个版本中，您可以使用自定义资源中的指定字段在 OpenShift Container Platform 上设置自定义路由主机。

在早期版本的 Red Hat Developer Hub Operator 中，如果该对象的名称中包含句点(.)字符，则无法引用自定义资源中的 ConfigMap 或 Secret 对象。

这个问题导致 Red Hat Developer Hub 实例无法正确启动。

在这个版本中，这个问题已被解决。

当将 Red Hat Developer Hub Operator 从版本 1.1 升级到 1.2 时，带有已在运行的 Developer Hub 实例，实例已配置为使用一个新的空本地数据库 pod 和卷。

现有数据库数据被保留，但这种错误配置会导致现有 Developer Hub 实例使用新的空本地数据库 pod 和卷，从而导致数据冗余和潜在的数据不一致问题。

在这个版本中，当 Operator 升级到更新的版本时，确保现有 Developer Hub 实例继续使用现有的本地数据库。

在早期版本的 Red Hat Developer Hub 中，因为缺少资源请求，由(product-short) Operator 创建的 Developer Hub pod 可能无法调度到某些集群中。

此问题会导致 Developer Hub 应用程序不可用，因为 pod 无法被正确调度。

在这个版本中，在 Operator 的默认配置中添加了 CPU 和内存请求，确保 Developer Hub pod 具有指定的所需资源请求。

在这个版本中，Developer Hub pod 可以在所有集群上正确调度并启动，确保 Red Hat Developer Hub 应用程序的可用性。

在早期版本的 Red Hat Developer Hub Operator 中，指定镜像 pull secret 以从存储库（如 registry.redhat.io ）拉取容器镜像不会影响数据库镜像。当 Kubernetes 集群中（如 Amazon EKS 或 Azure AKS）中部署 Developer Hub 时，这个限制会阻止从 registry.redhat.io' 使用数据库镜像。

因此，用户无法从 Kubernetes 集群中的 registry.redhat.io 部署数据库镜像，从而限制部署灵活性和兼容性。

在这个版本中，通过传播在 spec.application.imagePullSecrets Custom Resource 字段中指定的镜像 pull secret 解决了这个问题。现在，您可以将这些 secret 用于 Developer Hub 和数据库镜像。

在这个版本中，用户可以成功为 Developer Hub 和数据库镜像使用镜像 pull secret，允许从 Kubernetes 集群（如 Amazon EKS 或 Azure AKS）中的 registry.redhat.io 等存储库进行部署。这样可确保在不同环境中具有更大的灵活性和兼容性。

在 Red Hat Developer Hub 的早期版本中，当禁用 Role-Based Access Control (RBAC)插件时，RBAC 选项卡会在禁用 RBAC 插件时保持可见。

在这个版本中，确保在禁用 RBAC 插件时隐藏 RBAC 选项卡。

在这个版本中，当禁用 RBAC 插件时，RBAC 选项卡不再可见，从而导致更干净的用户界面。

在以前的版本中，当用户创建简单权限策略且稍后返回到编辑角色时，则不会显示 Configure Access 按钮。

因此，用户无法为使用简单权限策略创建的角色添加条件权限策略，从而限制更新和优化访问控制的能力。

在本发行版本中，角色表单已被更新，以显示之前为支持条件的插件和资源类型创建了简单权限策略的 Configure Access 按钮。在这个版本中，用户可以添加和保存新的条件策略。

在以前的版本中，Condition API 允许存储多个有冲突操作集的条件。

此问题可能会导致权限处理中的不一致和冲突，从而导致应用程序出现意外行为。

在这个发行版本中，Condition API 已被更新，以防止存储带有冲突操作集的多个条件。

在以前的版本中，当 admins 从配置中删除时，它们关联的管理元数据和策略不会被自动删除。

此问题会导致应用程序中过时的管理元数据和策略保留。

在本发行版本中，当管理员从应用程序配置中删除时，会移除 admin 元数据和策略。

在以前的版本中，Developer Hub Operator 升级过程存在一个问题，它会阻止 Operator 支持的 Developer Hub 实例在 Developer Hub Operator 本身升级时无缝升级。这是因为，当尝试协调现有 Developer Hub 自定义资源时，Operator 会拒绝对 Kubernetes 或 OpenShift Container Platform 限制或只读的特定字段进行补丁。

此问题会导致在升级过程中达到所需状态失败。

在这个版本中，Operator 已重构，以便在无法修补它们时，通过强制替换对象来解决这些问题。但是，作为一个已知问题，用户可能需要在升级后在由 Developer Hub Operator 管理的底层资源上重新创建任何自定义标签或注解。

在以前的版本中，OpenShift Cluster Manager (OCM)插件 Readme 文件没有有关如何在 Kubernetes 集群上配置 OCM 的信息。

由于缺少这个信息，用户无法将 OCM 插件配置为获取集群，从而导致插件无法显示集群。

在本发行版本中，Readme 文件已被更新，使其包含在 Kubernetes 集群上配置 OCM 的链接，并提供了在启用了 RBAC 权限框架时启用对 OCM 后端插件的访问的说明。

现在，用户可以正确配置 OCM 插件以在 OCM 前端中获取和显示集群，确保插件按预期运行。

最近对 Backstage 的更新需要使用服务到服务身份验证进行更新，以使用新的 httpAuth 和 auth 服务。

如果没有这些更新，RBAC 后端插件无法从其他插件查询信息。在这个版本中，修改 RBAC 后端插件，以使用新的 httpAuth 和 auth 服务进行服务到服务身份验证。

在这个版本中，RBAC 后端插件可以在不中断的情况下从其他插件成功查询信息。

在扩展 Developer Hub 实例时，角色数据会不同步，因为实例之间没有共享内存缓存。

此问题会导致不同实例之间的角色数据不一致。

在这个版本中，扩展 Developer Hub 实例不再会导致角色数据不同步。

最近对 Gitlab 插件的更新会导致同步组织供应商数据失败。

在本发行版本中，这个问题已通过包含公开 Gitlab 组织的 Gitlab 插件的打包程序来解决这个问题。

对上游 Helm Chart 的最新更改会意外阻止部署静态资源。

随着 Developer Hub 1.2.1 Helm Chart 的发布，这个问题已被解决。