- Notes de publication d'Automation Suite sur Linux
- Notes de publication d'Automation Suite sur EKS/AKS
- Notes de publication d'Automation Suite sur OpenShift
2.2510.1
Notes de version 2.2510.1 pour Automation Suite sur OpenShift.
Date de publication : 19 décembre 2025
Prise en charge d'OpenShift Service Mesh 3.0
Automation Suite prend désormais en charge OpenShift Service Mesh (OSM) 3.0.
Pour obtenir des instructions d'installation, consultez la section Installation et configuration du service mesh.
Pour obtenir la matrice de compatibilité entre les versions OpenShift Service Mesh et Automation Suite sur les versions OpenShift, reportez-vous à la Matrice de compatibilité des composants tiers OpenShift.
Prise en charge de la désactivation de la création de classes de priorité
Vous pouvez désormais désactiver la création de classes de priorité lors du déploiement. Cette fonctionnalité est destinée aux environnements de cluster partagés où les classes de priorité ne sont pas requises. Pour l’activer, vous devez modifier le fichier de configuration input.json .
Pour de plus amples informations, consultez la section Créer une classe de priorité.
Résolution de bogues
- Erratum - ajouté le 9 février 2026 : nous avons résolu un problème où certains services de micro-services Document Understanding ne démarraient pas, notamment dans les environnements IPv4 uniquement.
- Nous avons résolu un problème qui entraînait l’échec des vérifications des prérequis lorsque Process Mining était activé. Ce problème est survenu en raison des vérifications traitant de manière incorrecte
cert-managercomme composant requis, alors que cela n’est plus nécessaire pour Process Mining. - Cette version inclut les correctifs livrés dans Automation Suite 2.2510+patch1.
Problèmes connus
Conflit de mise à l'échelle horizontale du pod Autoscaler et d'ArgoCD dans les environnements haute disponibilité
Erratum - ajouté le 10 septembre 2026: dans les environnements haute disponibilité, lorsque la charge augmente, l'outil de mise à l'échelle horizontale des pods Mise à l'échelle des charges de travail affectées met à l'échelle les charges de travail affectées tandis que le contrôleur d'application ArgoCD les réduit. Cela se produit parce qu'ArgoCD traite le nombre de répliques défini dans le graphique ou le manifeste Helm comme source de vérité, ce qui entraîne l'augmentation et la réduction des charges de travail sans cesse sans stabiliser.
Pour résoudre le problème, vous devez corriger argocd-cm ConfigMap dans l'espace de noms <argocd> afin qu'ArgoCD ignore les différences de nombre de répliques:
kubectl -n <argocd> patch configmap argocd-cm --type merge -p \
'{"data":{"resource.customizations.ignoreDifferences.argoproj.io_Rollout":"jsonPointers:\n- /spec/replicas\n"}}'
kubectl -n <argocd> patch configmap argocd-cm --type merge -p \
'{"data":{"resource.customizations.ignoreDifferences.argoproj.io_Rollout":"jsonPointers:\n- /spec/replicas\n"}}'
Réappliquez la commande après chaque resynchronisation du graphique ArgoCD ou mise à niveau d'Automation Suite, car les deux écrasent ConfigMap et suppriment le correctif.
Nous avons résolu le problème dans Automation Suite sur OpenShift 2.2510.4.
Le paramètre d’inférence du processeur de Document Understanding a été perdu lors de la mise à niveau vers la version 2.2510.2 ou ultérieure
Erratum - ajouté le 10 septembre 2026: Si vous avez activé l'inférence de processeur pour les projets modernes Document Understanding (enable_cpu_inference), le paramètre n'est pas reporté lorsque vous effectuez la mise à niveau vers 2.2510.2 ou une version ultérieure. Ce problème se produit en raison d’une modification de l’emplacement attendu du paramètre enable_cpu_inference dans input.json, à partir d’Automation Suite 2.2510.2.
Avant la mise à niveau vers Automation Suite 2.2510.2 ou une version ultérieure, déplacez le paramètre enable_cpu_inference de la racine documentunderstanding vers la section modernProjects:
// Before
"documentunderstanding": {
"enable_cpu_inference": false,
"modernProjects": {
"enabled": true
}
}
// Before
"documentunderstanding": {
"enable_cpu_inference": false,
"modernProjects": {
"enabled": true
}
}
// After (2.2510.2 or later)
"documentunderstanding": {
"modernProjects": {
"enabled": true,
"enable_cpu_inference": false
}
}
// After (2.2510.2 or later)
"documentunderstanding": {
"modernProjects": {
"enabled": true,
"enable_cpu_inference": false
}
}
Studio Desktop ne peut pas charger les connecteurs et activités Integration Service
Erratum - ajouté le 23 juillet 2026: dans Studio Desktop, le panneau Activités ne répertorie pas les connecteurs et activités Integration Service. Le problème est causé par une erreur de configuration du routage dans le service virtuel intsvcs-periodic.
Pour résoudre le problème, consultez la section Studio Desktop ne peut pas charger les connecteurs et activités Integration Service.
Nous avons résolu le problème dans Automation Suite sur OpenShift 2.2510.3.
Les vérifications des prérequis échouent lorsque les projets modernes Document Understanding sont activés et qu’AI Center est désactivé
Erratum - ajouté le 23 juillet 2026: un problème entraîne l’échec incorrect de la commande de vérification des prérequis lorsque les projets modernes Document Understanding sont activés et qu’AI Center est désactivé.
Pour résoudre le problème, consultez la section Résolution des problèmes.
Ce problème est résolu dans Automation Suite 2.2510.3.
Les pods AI Center et Document Understanding ne démarrent pas avec la vérification du certificat TLS activée
Erratum - ajouté le 15 avril 2026 : lorsque la vérification du certificat TLS de la base de données est activée, certains pods AI Center et Document Understanding peuvent rester bloqués dans Init:CrashLoopBackOff. Le conteneur d’initialisation await-migration-completion ne parvient pas à se connecter à la base de données, avec des erreurs d’établissement de liaison TLS/SSL dans les journaux.
Pour résoudre le problème, reportez-vous aux pods AI Center et Document Understanding ne démarrent pas avec la vérification du certificat TLS activée.
Nous avons résolu le problème dans Automation Suite sur OpenShift 2.2510.2.
istio-validation-deployment après prérequis ou vérifications de l’état
Erratum - ajouté le 15 avril 2026 : après avoir exécuté les vérifications des prérequis (uipathctl prereq) ou la vérification de l'état (uipathctl health check), le déploiement istio-validation-deployment créé lors de la validation du service virtuel peut ne pas être automatiquement supprimé, en utilisant des ressources de cluster inutiles.
Pour vérifier les ressources auxiliaires dans l'espace de noms UiPath, exécutez les commandes suivantes :
kubectl get deployments -n <uipath-namespace> | grep istio-validation-deployment
kubectl get jobs -n <uipath-namespace> | grep istio-validation-deployment
kubectl get deployments -n <uipath-namespace> | grep istio-validation-deployment
kubectl get jobs -n <uipath-namespace> | grep istio-validation-deployment
Si des ressources résidus sont présentes, supprimez-les en exécutant les commandes suivantes :
kubectl delete job -n <uipath-namespace> <istio-validation-job-name>
kubectl delete deployment -n <uipath-namespace> <istio-validation-deployment-name>
kubectl delete job -n <uipath-namespace> <istio-validation-job-name>
kubectl delete deployment -n <uipath-namespace> <istio-validation-deployment-name>
Nous avons résolu le problème dans Automation Suite sur OpenShift 2.2510.2.
Le nom de base de données de plate-forme personnalisé n’est pas pris en charge lors de l’installation de Process Mining
Erratum - ajouté le 26 mars 2026 : lorsque Process Mining est activé, l’utilisation d’un nom de base de données de plate-forme personnalisé entraîne l’échec de la tâche de renvoi OMS.
Pour contourner ce problème, utilisez AutomationSuite_Platform comme nom de base de données de plate-forme lors de l'installation de Process Mining.
Ce problème sera résolu dans Automation Suite 2.2510.2.
Limitations de la prise en charge de FIPS 140-2
Erratum - ajouté le 22 janvier 2026 : Insights et Integration Service ne sont pas pris en charge sur les déploiements Automation Suite qui s’exécutent sur des machines compatibles FIPS 140-2. Pour rester conforme aux exigences FIPS 140-2, vous devez désactiver ces services.
Pour de plus amples informations, consultez la section Sécurité et conformité.
Noms de bases de données personnalisés non pris en charge pour les solutions
Erratum : ajouté le 15 avril 2026 : un problème vous empêche d’utiliser un nom de base de données personnalisé pour les solutions. Si vous spécifiez un nom de base de données personnalisé, les vérifications des prérequis échouent.
Pour résoudre ce problème, vous devez utiliser AutomationSuite_AutomationSolutions comme nom de base de données Solutions.
Ce problème a été résolu dans Automation Suite 2.2510.2.
Limitations de l'authentification Kerberos
L’authentification basée sur Kerberos n’est actuellement pas prise en charge pour les produits suivants :
- Integration Service
- Autopilot for Everyone
- AI Trust Layer (Passerelle LLM, Observabilité LLM, Ancrage dans le contexte)
Nous travaillons à l’ajout de la prise en charge de Kerberos aux prochaines versions d’Automation Suite.
Pendant ce temps, vous pouvez utiliser d’autres mécanismes d’authentification tels que l’authentification de base ou l’authentification basée sur l’identité de la charge de travail.
L’ingestion de l’ancrage dans le contexte échoue dans les environnements hors ligne
Erratum - ajouté le 10 septembre 2026: dans les déploiements hors ligne (physiquement isolés), l'ingestion des documents d'ancrage dans le contexte échoue pour chaque type de fichier. L'erreur signalée indique à tort un problème avec le contenu du fichier.
Nous avons résolu le problème dans Automation Suite sur OpenShift 2.2510.4.
Chronologie de l’abandon
Nous vous recommandons de vérifier régulièrement le calendrier d'obsolescence pour toute mise à jour concernant les fonctionnalités qui seront obsolètes et supprimées.
Détails du regroupement
Versions du produit
Le tableau suivant décrit le statut de la version, la version et les notes de publication de tous les produits UiPath déployés sous Automation Suite 2.2510.1.
Légende :
✅ Nouveau : cette version d’Automation Suite comprend une nouvelle version de produit. De nouvelles notes de publication sont disponibles.
◆ Offre groupée : cette version inclut une version du produit précédemment publiée. Aucune nouvelle note de version n'est disponible.
- Prise en charge d'OpenShift Service Mesh 3.0
- Prise en charge de la désactivation de la création de classes de priorité
- Résolution de bogues
- Problèmes connus
- Conflit de mise à l'échelle horizontale du pod Autoscaler et d'ArgoCD dans les environnements haute disponibilité
- Le paramètre d’inférence du processeur de Document Understanding a été perdu lors de la mise à niveau vers la version 2.2510.2 ou ultérieure
- Studio Desktop ne peut pas charger les connecteurs et activités Integration Service
- Les vérifications des prérequis échouent lorsque les projets modernes Document Understanding sont activés et qu’AI Center est désactivé
- Les pods AI Center et Document Understanding ne démarrent pas avec la vérification du certificat TLS activée
- istio-validation-deployment après prérequis ou vérifications de l’état
- Le nom de base de données de plate-forme personnalisé n’est pas pris en charge lors de l’installation de Process Mining
- Limitations de la prise en charge de FIPS 140-2
- Noms de bases de données personnalisés non pris en charge pour les solutions
- Limitations de l'authentification Kerberos
- L’ingestion de l’ancrage dans le contexte échoue dans les environnements hors ligne
- Chronologie de l’abandon
- Détails du regroupement
- Versions du produit