Annonces relatives aux modifications de service

Modification de service : le service Oracle Cloud Infrastructure Anomaly Detection est en phase d'abandon.

Date annoncée : 7 mars 2024

Date d'application : 6 mars 2025

Détails : à compter du 6 mars 2025, le service Anomaly Detection d'Oracle Cloud Infrastructure atteint la fin de vie. Avant la date de fin de vie, nous vous recommandons d'effectuer la migration vers le service Oracle Cloud Infrastructure Data Science pour détecter les anomalies.

Cela me concerne-t-il ? Le service Anomaly Detection ne sera plus disponible pour utilisation après le 6 mars 2025. Les modèles précédemment créés continueront à fonctionner dans votre location, mais vous devez migrer immédiatement pour éviter toute interruption de service.

Que dois-je faire ? Vous pouvez utiliser l'opérateur Accelerated Data Science du service Oracle Cloud Infrastructure Data Science pour détecter les anomalies. Il prend en charge à la fois la détection d'anomalies univariées et multivariées.

Modification de service : la prise en charge du service Oracle Cloud Infrastructure API Gateway pour certains cryptages hérités est en phase d'abandon.

Date d'annonce : mars 2024

Date d'application : 1er avril 2025

Détails : à compter du 1er avril 2025, le service API Gateway ne prend plus en charge les cryptages hérités suivants :

• ECDHE-RSA-AES128-SHA256
• ECDHE-RSA-AES256-SHA384
• DHE-RSA-AES256-SHA256
• DHE-RSA-AES128-SHA256

Cela me concerne-t-il ? Après le 1er avril 2025, une passerelle d'API n'inclura plus les cryptages hérités dans la liste des cryptages pris en charge lors de l'établissement d'une connexion avec un client d'API ou avec un service back-end. Un client d'API ou un service back-end qui prend uniquement en charge les cryptages hérités ne pourra plus se connecter à une passerelle d'API.

Que dois-je faire ? Assurez-vous que les clients d'API et les services back-end qui se connectent aux passerelles d'API prennent en charge des cryptages qui continuent d'être pris en charge par le service API Gateway (reportez-vous à Versions et cryptages TLS pris en charge).

Modification de service : l'attribut requis subnetId de l'API CreateRecoveryServiceSubnet d'Oracle Cloud Infrastructure est en phase d'abandon.

L'API CreateRecoveryServiceSubnet peut utiliser l'attribut facultatif Subnets à la place, qui deviendra par la suite un attribut requis.

Date d'annonce : 2023 mai.

Date d'effet : mai 2024 mai.

Détails : avant l'application de cette modification de service, l'attribut subnetId peut être utilisé pour indiquer un seul sous-réseau à associer à un sous-réseau de service de récupération. Après l'application de cette modification de service, l'attribut subnetId sera ignoré et subnets deviendra un attribut requis. L'attribut subnets peut être utilisé pour indiquer plusieurs sous-réseaux à associer à un sous-réseau de service de récupération.

Cela me concerne-t-il ? Si vous disposez de scripts personnalisés ou de scripts Terraform référençant l'API CreateRecoveryServiceSubnet et que vous utilisez explicitement l'attribut subnetId, vous pouvez les modifier pour enlever cet attribut et utiliser subnets à la place.

Que dois-je faire ? Lorsque vous utilisez des kits SDK OCI et des outils de ligne de commande, vous devez choisir de mettre à jour vos scripts personnalisés afin d'utiliser l'attribut subnets. Après mai 2024, l'attribut subnets sera un champ requis.

Modification de service : le contrat entre Oracle et Cloudera expire le 31 janvier 2023. Par conséquent, à partir du 31 janvier, Oracle Big Data Service ne prendra plus en charge l'utilisation de la distribution Cloudera avec Apache Hadoop (CDH) pour lancer de nouveaux clusters ou ajouter des noeuds ou des coeurs aux clusters existants au-delà d'une limite définie. Cette modification n'a pas d'incidence sur la prise en charge continue des clusters Big Data Service CDH existants.

Cette modification s'applique uniquement à Big Data Service CDH. Cette modification n'a pas d'incidence sur les clients qui utilisent Oracle Big Data Appliance (BDA) ou Big Data Service sur site avec la distribution Oracle de Hadoop (ODH).

Date d'annonce : 13 décembre 2022

Date d'application : 31 janvier 2023

Détails : le 31 janvier 2023, la limite d'extension Big Data Service CDH du nombre de coeurs de calcul (OCPU) est gelée. Le nombre de coeurs de calcul dans la location d'un client au 31 janvier devient le nombre maximal de coeurs autorisé pour cette location et aucune extension supplémentaire ne sera autorisée.

Cela me concerne-t-il ? Cette modification s'applique uniquement à Big Data Service avec CDH. Big Data Service avec la distribution Oracle de Hadoop (ODH) n'est pas concerné.

Par exemple, si au 31 janvier 2023 une location comporte 2 clusters BDS CDH de 15 noeuds chacun avec 120 OCPU au total, la limite maximale d'OCPU après le 31 janvier 2023 sera définie sur 120 et ne pourra pas être augmentée au-delà de 120 après cette date. Pour les problèmes de prise en charge tels que le remplacement de noeuds en échec, de nouveaux noeuds peuvent être ajoutés jusqu'à cette limite. Les utilisateurs peuvent également réduire le nombre de coeurs et revenir ensuite à cette limite (par exemple, 120).

Etapes suivantes : Oracle recommande de planifier et d'implémenter toutes les extensions de cluster Big Data Service CDH requises avant le 31 janvier 2023. Pour les clients qui souhaitent éviter la contrainte d'extension après cette date, nous vous recommandons de migrer vers Big Data Service ODH.

A propos de Big Data Service avec ODH : en 2022, Oracle a lancé Big Data Service ODH, que nous avons développé en tant que service cloud natif pour nos clients Big Data. Oracle assure un investissement et une prise en charge continus pour ODH, sans nécessiter de licence de la part de Cloudera. ODH propose des fonctionnalités clés axées sur l'entreprise, notamment le redimensionnement automatique, Kerberos, l'intégration Active Directory, le connecteur HDFS pour Object Storage et les scripts de démarrage. Par ailleurs, il s'agit de l'un des produits Big Data les plus rentables du marché.

Big Data Service ODH dispose de plusieurs versions avec les dernières et les précédentes versions des composants Hadoop à des fins de compatibilité avec les piles d'applications plus récentes et plus anciennes. Il fonctionne également avec WANdisco Data Migrator afin de faciliter les migrations à grande échelle et utilise les services Oracle Cloud Lift afin de collaborer avec des ingénieurs Oracle pour les migrations. Pour plus d'informations sur la migration vers Big Data Service ODH, reportez-vous à la documentation.

Modification de service : les stratégies de sauvegarde définies par Oracle n'incluent plus de sauvegardes de volume complètes.

Date d'annonce : novembre 3, 2020

Date d'application : 3 novembre 2021

Détails : depuis le 3 novembre 2021, les stratégies de sauvegarde définies par Oracle n'incluent plus de sauvegardes de volume complètes. Toutes les sauvegardes de volume générées à partir des stratégies définies par Oracle sont désormais des sauvegardes incrémentielles. Cette modification s'applique aux affectations de stratégie de sauvegarde de volume existantes et aux nouvelles affectations de stratégie de sauvegarde de volume. Cette modification n'a pas d'incidence sur les stratégies définies par l'utilisateur, qui restent inchangées.

Cela me concerne-t-il ? Si vous avez affecté une stratégie définie par Oracle à des volumes d'initialisation ou à des volumes de blocs pour des sauvegardes programmées, les sauvegardes complètes ne sont plus générées depuis le 3 novembre 2021.

Que dois-je faire ? Les sauvegardes incrémentielles sont fonctionnellement identiques aux sauvegardes complètes pour la récupération des données. Pour plus d'informations, reportez-vous à Types de sauvegarde de volume. Aucune action n'est nécessaire pour les scénarios de récupération de données. Certains scénarios de conformité peuvent nécessiter des sauvegardes complètes programmées. Pour ces scénarios de conformité, remplacez l'affectation de stratégie de sauvegarde par une stratégie de sauvegarde définie par l'utilisateur avant le 1er novembre 2021. Vous pouvez créer une stratégie définie par l'utilisateur à partir d'une stratégie de sauvegarde existante. Reportez-vous à Duplication des stratégies de sauvegarde existantes.

Modification de service : fin de vie du service de migration OCI Classic à compter du 31 mars 2024.

Date d'annonce : 04 mars 2024

Date d'application : 31 mars 2024

Détails : Oracle annonce les mises à jour de fin de distribution et de fin de vie pour OCI Classic Migration Service à compter du 31 mars 2024.

Classic Migration Service (anciennement appelé Application Migration Service) simplifie la migration d'applications d'Oracle Cloud Infrastructure Classic vers Oracle Cloud Infrastructure. Classic Migration Service migre des applications telles qu'Oracle Java Cloud Service, SOA Cloud Service et Integration Classic, d'Oracle Cloud Infrastructure Classic et Oracle Cloud@Customer vers Oracle Cloud Infrastructure.

Cela me concerne-t-il ? Il ne devrait y avoir aucun impact sur les clients existants. Les versions d'application prises en charge par Classic Migrations sont obsolètes depuis un certain nombre d'années et les clients utilisent déjà des versions plus récentes.

Que dois-je faire ? Aucune action attendue de la part des clients. Si vous avez une application classique à migrer, contactez le service d'application cloud associé.

Modification de service : la classe de panne PCI-NIC pour la surveillance de l'état des instances Compute Bare Metal est en phase d'abandon.

Date d'annonce : 21 juin 202

Date d'application : 21 juin 2023

Détails : la classe de panne PCI-NIC fournit des informations sur un problème matériel concernant vos instances Bare Metal, en particulier lorsqu'une panne a été détectée dans la carte d'interface réseau de l'instance. La classe de panne PCI-NIC ne sera plus émise.

Cela me concerne-t-il ? A la fin de la prise en charge, vous ne recevrez plus de notifications de surveillance de l'état pour la classe de panne PCI-NIC. Les mesures d'état d'infrastructure ne seront plus émises pour la classe de panne PCI-NIC.

Que dois-je faire ? Migrez vers la classe de panne PCI pour obtenir des fonctionnalités similaires. Pour plus d'informations, reportez-vous à Surveillance de l'état de Compute pour les instances Bare Metal et à Mesures d'état d'infrastructure.

Modification de service : le kit SDK Java OCI version 2 est en phase d'abandon.

Date annoncée : 6 avril 2023

Date d'application : 30 juin 2023

Détails : Oracle a récemment publié le kit SDK Java Oracle Cloud Infrastructure (OCI) version 3. Le kit SDK Java OCI version 3 est une version majeure du kit SDK. Nous vous recommandons d'effectuer la mise à niveau vers cette dernière version. Nous continuerons à prendre entièrement en charge le kit SDK Java OCI version 2 jusqu'à fin juin 2023. Pendant ce temps, les versions 2 et 3 du kit SDK Java OCI recevront des mises à jour régulières pour prendre en charge les nouvelles API de service, les patches de sécurité et les corrections de bug critiques, ainsi que les modifications apportées à la documentation.

Cela me concerne-t-il ? Après le 30 juin 2023, le kit SDK Java OCI version 2 ne recevra plus de mises à jour permettant de prendre en charge de nouvelles régions, de nouveaux services ou des fonctionnalités dans les services existants, sauf indication contraire. Pour les versions antérieures du kit SDK Java OCI version 2 qui datent de moins de 12 mois, OCI rétroportera, à la demande, uniquement les problèmes de sécurité et les corrections de bug critiques.

Que dois-je faire ? Effectuez la mise à niveau vers le kit SDK Java OCI version 3.

Les API Autonomous Data Warehouse d'Oracle Cloud Infrastructure sont en phase d'abandon depuis le 15  février 2019.

Important ! La prise en charge de ces API Autonomous Database pour les analyses et l'entreposage de données prendra fin le 1er juillet 2020. Oracle vous recommande de migrer dès que possible vos charges de travail de base de données vers les API de remplacement.

Modification de service : la valeur par défaut de l'attribut isMTLSConnectionRequired passera de true à false le 1er juillet 2023 dans les API suivantes :

• CreateAutonomousDatabase
• GetAutonomousDatabase
• UpdateAutonomousDatabase

Date d'annonce : 7 février 2023.

Date d'application : 1 juillet 2023.

Détails : avant cette modification de service, la valeur par défaut de l'attribut isMTLSConnectionRequired était true. Cette option s'applique à Autonomous Database sans serveur.

Cela me concerne-t-il ? Si vous disposez de scripts personnalisés ou de scripts Terraform référençant l'API CreateAutonomousDatabase, GetAutonomousDatabase ou UpdateAutonomousDatabase, vous pouvez les modifier afin qu'ils prennent en compte la modification de la valeur par défaut de cet attribut. Toutefois, si vous choisissez de ne pas apporter de modifications à vos scripts, les appels d'API contenant cet attribut continueront à fonctionner, sauf que la valeur par défaut passera de "true" à "false".

Que dois-je faire ? Lorsque vous utilisez des outils de ligne de commande et des kits SDK OCI, vous pouvez choisir de mettre à jour vos scripts personnalisés afin de définir explicitement l'attribut isMTLSConnectionRequired sur "true".

Modification de service : les API suivantes ont fait l'objet de modifications à la suite desquelles les API ou certains champs d'API sont en phase d'abandon.

Date d'annonce : : 17 mai 2023.

Date d'effet : 17 mai 2024.

Détails : avant l'application de cette modification de service, ces API incluent les API ou les champs d'API mentionnés. Après l'application de cette modification de service, les API ou les champs d'API mentionnés seront enlevés. Cette option s'applique à Autonomous Database sans serveur.

La prise en charge de ces champs d'API Autonomous Database prendra fin le 2 mai 2024. Oracle vous recommande de migrer vos scripts afin d'arrêter d'utiliser ces champs dès que possible. Le cas échéant, basculez pour utiliser l'API ou le champ de remplacement.

Cela me concerne-t-il ? Si vous disposez de scripts personnalisés ou de scripts Terraform référençant ces API ou les champs mentionnés, vous devez les modifier pour tenir compte de ces modifications.

Que dois-je faire ? Si vous utilisez des kits SDK OCI et des outils de ligne de commande, mettez à jour vos scripts personnalisés pour enlever l'utilisation des API ou des champs en phase d'abandon, ou pour utiliser les remplacements.

Modification de service : les valeurs de retour de certaines API sont modifiées, où la valeur de 409 Incorrect State est renvoyée dans certains cas, le cas échéant, à 409 Conflict.

Date annoncée : octobre 2023.

Date d'application : octobre 2024.

Détails : avant cette modification de service, certains appels d'API échouent avec le code d'erreur 409 Incorrect State. Une fois ce service modifié, dans certains cas, selon le cas, les appels d'API échoueront avec le code d'erreur 409 Conflict.

Avant cette modification, de nombreuses API renvoient 409 Incorrect State lorsque l'instance Autonomous Database est arrêtée ou indisponible. Pour ces états, selon les directives d'API, le retour correct est 409 Conflict. Pour les autres états Autonomous Database, tels que Démarrage, Arrêt et Provisionnement, le retour en cours de 409 Incorrect State est correct et ne changera pas après cette mise à jour.

Le retour 409 Incorrect State doit être utilisé pour indiquer que les nouvelles tentatives sont correctes et que la ressource finira par atteindre l'état correct, et le retour 409 Conflict indique que la ressource n'atteindra pas l'état correct par elle-même et que les nouvelles tentatives ne doivent pas être effectuées. Cette modification de service modifie la valeur de code d'erreur dans ces API pour les cas où 409 Conflict est représentatif de l'état Autonomous Database connu.

Cette modification de service s'applique aux API suivantes :

• UpdateAutonomousDatabase
• DeleteAutonomousDatabase
• ChangeDisasterRecoveryConfiguration
• RotateAutonomousDatabaseEncryptionKey
• StartAutonomousDatabase
• RestartAutonomousDatabase
• ShrinkAutonomousDatabase
• StopAutonomousDatabase
• ConfigureAutonomousDatabaseVaultKey
• AutonomousDatabaseManualRefresh
• FailOverAutonomousDatabase
• SwitchoverAutonomousDatabase
• ChangeAutonomousDatabaseCompartment
• RegisterAutonomousDatabaseDataSafe
• DeregisterAutonomousDatabaseDataSafe
• EnableAutonomousDatabaseOperationsInsights
• DisableAutonomousDatabaseOperationsInsights

Cela m'a-t-il un impact ? : si vous disposez de scripts personnalisés ou de scripts Terraform qui gèrent le retour 409 Incorrect State à partir de ces API, vous pouvez modifier les scripts pour gérer le retour 409 Conflict, le cas échéant.

Que dois-je faire ? Lorsque vous utilisez des kits SDK OCI et des outils de ligne de commande, vous pouvez choisir de mettre à jour vos scripts personnalisés.

Modification de service : sur Autonomous Database sans serveur, la possibilité de réaliser des sauvegardes manuelles, qui ne sont pas des sauvegardes à long terme, est en phase d'abandon.

Autonomous Database sans serveur sauvegarde automatiquement la base de données jusqu'à 60 jours. En raison de cette modification, le 15 février 2025, lorsque vous appelez l'API CreateAutonomousDatabaseBackupDetails avec l'attribut isLongTermBackup, la valeur doit être définie sur true. La valeur par défaut de l'attribut isLongTermBackup sera également remplacée par true.

Date d'annonce : 15 février 2024.

Date d'application : 15 février 2025.

Détails : avant cette modification de service, la valeur par défaut de l'attribut isLongTermBackup était false. Après cette modification de service, la seule valeur valide pour l'attribut isLongTermBackup est true. Cette modification s'applique à Autonomous Database sans serveur.

Cela m'a-t-il un impact ? Si vous disposez de scripts personnalisés ou de scripts Terraform référençant l'API CreateAutonomousDatabaseBackupDetails, vous pouvez les modifier pour qu'ils prennent en compte la modification de la valeur par défaut de cet attribut. Toutefois, si vous choisissez de ne pas apporter de modifications à vos scripts, les appels d'API contenant cet attribut continueront à fonctionner, sauf que la valeur par défaut passera de false à true.

Que dois-je faire ? : lors de l'utilisation des kits SDK et des outils de ligne de commande OCI, mettez à jour vos scripts personnalisés pour définir explicitement l'attribut isLongTermBackup sur true.

Modification de service : le paramètre isShared du fichier ListAutonomousDatabaseCharacterSets d'Oracle Cloud Infrastructure est en phase d'abandon.

Date annoncée : octobre 2023.

Date d'application : octobre 2024.

Détails : avant cette modification de service, le paramètre facultatif isShared peut être utilisé. Cette modification introduit le paramètre facultatif isDedicated et le paramètre isShared sera enlevé après octobre 2024.

Cela m'a-t-il un impact ? : si vous disposez de scripts personnalisés ou de scripts Terraform référençant l'API ListAutonomousDatabaseCharacterSets à l'aide du paramètre isShared avec la valeur TRUE, modifiez les scripts pour remplacer ce paramètre par le paramètre suivant : Le paramètre isDedicated avec la valeur FALSE et, si vous référencez l'API ListAutonomousDatabaseCharacterSets à l'aide du paramètre isShared avec la valeur FALSE, modifiez les scripts pour remplacer ce paramètre par l'attribut isDedicated avec la valeur TRUE.

Que dois-je faire ? : lorsque vous utilisez des kits SDK et des outils de ligne de commande OCI, mettez à jour vos scripts personnalisés pour remplacer le paramètre isShared par le paramètre isDedicated.

Les API de système de base de données Exadata d'Oracle Cloud Infrastructure sont en phase d'abandon depuis le 15 novembre 2020.

Important : aucun nouveau système ne peut être provisionné avec l'ancien modèle de ressource ou avec d'anciennes API de système de base de données après le 15 mai 2021. La prise en charge de l'ancien modèle de ressource et des anciennes API de système de base de données prendra fin sur les systèmes existants le 15 novembre 2021. Oracle recommande de migrer dès que possible vos instances Exadata Database Service on Dedicated Infrastructure vers le nouveau modèle de ressource et les nouvelles API. La conversion vers le nouveau modèle de ressource n'implique aucun temps d'inactivité du système.

Modification de service : l'attribut facultatif dbWorkload de l'API CreateDatabase d'Oracle Cloud Infrastructure est en phase d'abandon.

Date d'annonce : novembre 2022. 202

Date d'application : novembre 2023.

Détails : tant que cette modification de service n'est pas encore appliquée, l'attribut dbWorkload peut être utilisé pour choisir entre la charge globale OLTP (traitement des transactions en ligne) ou Data Warehouse (analyse), et est utilisé en interne afin de déterminer les paramètres de mémoire en fonction de la charge globale de base de données. Une fois cette modification de service appliquée, l'attribut dbWorkload est traité comme une opération "no-op" (aucune opération), ce qui signifie que même si les appels d'API contenant l'attribut en phase d'abandon n'échouent pas, la valeur transmise est ignorée et le système utilise à la place une valeur par défaut en interne. Cela s'applique à Exadata Database Service on Dedicated Infrastructure, Exadata Database Service on Cloud@Customer et Base Database Service.

Cela me concerne-t-il ? Si vous disposez de scripts personnalisés ou de scripts Terraform référençant l'API CreateDatabase et utilisant explicitement l'attribut dbWorkload, vous pouvez les modifier pour enlever cet attribut. Toutefois, si vous choisissez de ne pas apporter de modifications à vos scripts, les appels d'API contenant cet attribut continueront à fonctionner, sauf que la valeur transmise pour l'attribut dbWorkload ne sera pas prise en compte.

Que dois-je faire ? Lorsque vous utilisez des outils de ligne de commande et des kits SDK OCI, vous pouvez choisir de mettre à jour vos scripts personnalisés afin d'exclure l'attribut dbWorkload. Après novembre 2023, si vous transmettez une valeur à l'attribut dbWorkload, elle sera ignorée.

Modification de service : la version d'API Database Migration d'Oracle Cloud Infrastructure 201210929 est en phase d'abandon à partir du 21 juin 2024.

Date d'annonce : 2 juillet 2024

Date d'application : 21 juin 2024

Détails :

À partir du 21 juin 2024, l'ancienne version de l'API Database Migration, version 201210929, est en phase d'abandon. À partir du 21 juin 2025, l'API en phase d'abandon n'est plus disponible et a été remplacée par une nouvelle version d'API 20230518 qui fournit des fonctionnalités améliorées et la prise en charge des versions futures.

Que dois-je faire ?

Si vous utilisez une ancienne version du kit SDK ou du fournisseur Terraform, vous devez prévoir de le mettre à niveau vers le nouveau kit SDK ou le fournisseur Terraform au plus tôt.

Liste des API obsolètes et de remplacement

Modification de service : les API DevOps de version 20210630 d'Oracle Cloud Infrastructure (deux API) sont en phase d'abandon depuis le 29 mars 2022.

Date d'annonce : 29 mars 2022

Date d'application : 29 mars 2023

Détails : depuis le 29 mars 2022, deux API DevOps de version 20210630 sont en phase d'abandon. A partir du 29 mars 2023, les API en phase d'abandon ne seront plus disponibles.

Modification de service : le service Event Hub est en phase d'abandon.

Date d'annonce : 29 avril 202

Date d'effet : 31 mai 2023

Détails : la fin de vie du service Oracle Event Hub sera effective au 31 mai 2023. Avant la date de fin de vie, nous vous recommandons de migrer vos flux de données d'Event Hub vers Oracle Cloud Infrastructure Streaming.

Cela me concerne-t-il ? Si vous utilisez le service Event Hub pour créer des clusters Kafka et/ou des sujets Event Hub, vous ne pourrez plus le faire après le 31 mai 2023. Les clusters précédemment créés continueront à fonctionner dans votre location sans modification.

Que dois-je faire ? Tous les clients Event Hub peuvent désormais utiliser Streaming pour déplacer des données à l'aide de ses étroites intégrations à Oracle Cloud Infrastructure (OCI), Database, GoldenGate et Integration Cloud. Le service utilise un outil Kafka Connect afin de fournir des intégrations prêtes à l'emploi pour des centaines de produits tiers dans des catégories telles que DevOps, bases de données, Big Data et applications SaaS.

Modification de service : un maximum de 100 systèmes de fichiers peuvent être attachés à une stratégie d'instantané donnée.

Date d'annonce : 5 août 2023

Date d'application : 7er août 2023

Détails : à partir du 7 août 2023, une nouvelle limite de service sera introduite pour limiter le nombre total de systèmes de fichiers attachés à une stratégie de cliché. Cette modification permet d'attacher jusqu'à 100 systèmes de fichiers par stratégie de cliché et par locataire et par domaine de disponibilité.

Cela me concerne-t-il ? Si vous prévoyez d'attacher plus de 100 systèmes de fichiers à une stratégie d'instantané donnée, vous ne pourrez plus le faire après le 7 août 2023. Tous les locataires existants auxquels plus de 100 systèmes de fichiers sont attachés par stratégie de cliché avant le 7 août 2023 recevront une exception. Aucune exception ne sera accordée après le 7 août 2023.

Que dois-je faire ? Si vous devez attacher plus de 100 systèmes de fichiers à une stratégie de cliché, créez une seconde stratégie de cliché ou utilisez toute autre stratégie de cliché existante. Vous pouvez créer 100 stratégies d'instantané par locataire et par domaine de disponibilité. Vous pouvez toujours générer des instantanés basés sur une stratégie pour les systèmes de fichiers, mais vous devrez peut-être utiliser plusieurs stratégies d'instantané.

Modification de service : les systèmes de fichiers File Storage utilisant des clés de cryptage gérées par le client nécessitent de nouvelles stratégies IAM.

Date annoncée : mai 29, 2024

Date d'effet : 29 mai 2024

Détails : le 29 mai 2024, File Storage introduit une nouvelle méthode permettant aux systèmes de fichiers d'autoriser l'utilisation de clés de cryptage personnalisées. Avant cette modification, les stratégies permettant d'accorder aux systèmes de fichiers des droits d'accès permettant d'utiliser des clés de cryptage personnalisées utilisaient l'utilisateur du service File Storage. Par exemple :

Allow service <file_storage_service_user> to use keys

Après cette modification, les ressources File Storage sont autorisées à utiliser des clés personnalisées. Pour plus d'informations, reportez-vous à la section Encrypting a File System.

Cela me concerne-t-il ? Avant le 29 mai 2024, les systèmes de fichiers File Storage utilisant des clés de cryptage Vault gérées par le client au lieu de clés gérées par Oracle utilisaient l'utilisateur du service File Storage dans les stratégies IAM requises.

L'utilisateur du service n'aura plus accès aux clés gérées par le client à l'avenir.

Que dois-je faire ? Créez des stratégies IAM qui permettent à File Storage de crypter et de décrypter des systèmes de fichiers à l'aide de principaux de ressource. Assurez-vous que les systèmes de fichiers utilisent des stratégies de principal de ressource plutôt que des stratégies de principal de service.

Pour plus d'informations, reportez-vous aux sections Encrypting a File System et Verifying Resource Principal Access to Encryption Keys.

Modification de service : le type de membre COMPUTE_INSTANCE dans DrProtectionGroupMemberType est en phase d'abandon et ne sera plus pris en charge.

Date d'annonce : 31 octobre 2023

Date d'application : 31 octobre 2024.

Migrer vers l'un des nouveaux types d'instance avant la date d'abandon d'effet.

Cela me concerne-t-il ? Si vous utilisez le type de membre COMPUTE_INSTANCE dans votre configuration de récupération après sinistre, cette modification vous affecte. Veillez à effectuer la migration vers l'un des nouveaux types d'instance avant la date d'abandon effective.

Que dois-je faire ? Pour effectuer une migration d'une instance COMPUTE_INSTANCE existante vers l'un des nouveaux types d'instance, suivez ces instructions.

Modification de service : la version 0.5.x (et versions antérieures) de l'interface de ligne de commande du projet Fn ne sera plus prise en charge.

Date d'annonce : 29 juin 2021

Date d'application : 1er août 2021

Détails : à partir du 1er août 2021, la version 0.5.x (et versions antérieures) de l'interface de ligne de commande du projet Fn ne fonctionnera plus avec OCI Functions.

Cela me concerne-t-il ? Si vous utilisez actuellement la version 0.5.x (ou versions antérieures) de l'interface de ligne de commande du projet Fn, vous devrez effectuer la mise à niveau vers la version 0.6.x (ou versions ultérieures) de l'interface de ligne de commande du projet Fn.

Que dois-je faire ? Effectuez une mise à niveau vers la version 0.6.x (ou versions ultérieures) de l'interface de ligne de commande du projet Fn en suivant les instructions fournies dans Mise à niveau de l'interface de ligne de commande du projet Fn.

Modification de service : à partir du 15 décembre 2021, les images de base de création et d'exécution de kits de développement de fonction (FDK) de projet Fn, à l'exception du FDK pour Python 3.7, sont créées sur la distribution limitée d'Oracle Linux 8. Les images de base de kit de développement de fonction Alpine/Debian sont en phase d'abandon.

Date d'annonce : novembre 15, 2021

Date d'application : 15 décembre 2021

Détails : à partir du 15 décembre 2021, la plupart des images de base de création et d'exécution de kits de développement de fonction (FDK) de projet Fn pour les différentes langues prises en charge sont créées sur la distribution mince d'Oracle Linux 8 (au lieu des distributions Alpine et Debian Linux). Les nouvelles fonctions que vous déployez utiliseront ces images de base de kit de développement de fonction Oracle Linux 8. Les seules exceptions sont les images de base de création et d'exécution de kit de développement de fonction pour Python 3.7, qui continuent d'être créées sur la distribution Debian Linux.

Les distributions Alpine/Debian Linux et la distribution légère d'Oracle Linux 8 ont différents gestionnaires de packages. Après la transition vers les images de base de kit de développement de fonction Oracle Linux 8, le fichier Docker temporaire créé par OCI Functions lors du déploiement des nouvelles fonctions contient les commandes de gestionnaire de packages Oracle Linux 8.

Cela me concerne-t-il ?

Pour les fonctions existantes déjà déployées vers OCI Functions, reportez-vous aux points suivants :

• Si OCI Functions utilise les paramètres du fichier func.yaml d'une fonction pour créer un fichier Docker temporaire contenant les instructions à partir desquelles créer l'image Docker de la fonction, la fonction est créée et déployée sans erreur. Le fichier Docker temporaire inclut les commandes de gestionnaire de packages Oracle Linux 8 correctes.
• Si vous avez créé un fichier Docker personnalisé pour une fonction (par exemple, en modifiant le fichier Docker créé par OCI Functions et en définissant runtime: docker dans le fichier func.yaml de la fonction), la fonction peut à présent être créée et déployée avec des erreurs telles que missing apt-get .... Les erreurs surviennent si le fichier Docker personnalisé inclut les commandes de gestionnaire de packages Alpine/Debian.

Que dois-je faire ? Si vous avez créé des fichiers Docker personnalisés contenant des commandes de gestionnaire de packages Alpine/Debian, remplacez ces commandes par les commandes de gestionnaire de packages Oracle Linux 8.

Si vous ne pouvez pas commencer immédiatement à utiliser les images de base de kit de développement de fonction Oracle Linux 8 car vous avez des fonctions qui nécessitent encore les distributions Alpine ou Debian Linux, il existe une solution de contournement temporaire. Jusqu'au 15 décembre 2022, les images de base de kit de développement de fonction Alpine/Debian restent disponibles mais avec des balises d'image modifiées. Vous pouvez mettre à jour les fichiers Docker personnalisés pour utiliser les images de base de kit de développement de fonction Alpine/Debian en phase d'abandon au lieu des images de base Oracle Linux 8 en spécifiant explicitement les balises d'image modifiées. Reportez-vous à Mes fonctions nécessitent toujours les distributions Alpine et Debian Linux. Existe-t-il une solution de contournement temporaire ?.

Modification de service : les API GoldenGate d'Oracle Cloud Infrastructure pour DatabaseRegistrations sont en phase d'abandon à compter du 01 novembre 2022.

Date d'annonce : novembre 01, 2022

Date d'application : novembre 01, 2023

Détails : à partir du 01 novembre 2022, les API DatabaseRegistrations sont en phase d'abandon et remplacées par les API Connections. À partir du 01 novembre 2023, les API en phase d'abandon ne seront plus disponibles.

Cela me concerne-t-il ? Oui. Les API DatabaseRegistrations ont fonctionné pour les connexions Oracle Database, tandis que les nouvelles API Connections extensibles vous permettent de vous connecter à de nombreux autres types de technologies de données.

Que dois-je faire ? Utilisez les API Connections au lieu des API DatabaseRegistrations pour vous connecter aux technologies source et cible.

Modification de service : la propriété timeUpgradeRequired des API Deployment et DeploymentSummary est en phase d'abandon à compter du 14 mars 2023.

Date d'annonce : 14 mars 2023

Date d'application : 14 mars 2024

Détails : avec les nouvelles fonctionnalités de maintenance déployées le 14 mars 2023, la propriété timeUpgradeRequired des API Deployment et DeploymentSummary est en phase d'abandon.

Cela me concerne-t-il ? La propriété timeUpgradeRequired en lecture seule a été utilisée pour vous aider à déterminer le temps nécessaire à la mise à niveau manuelle vers une nouvelle version de déploiement, mais le service n'a pas automatiquement mis à niveau votre déploiement lorsque la date limite a été dépassée. La nouvelle fonctionnalité de maintenance planifie une ou plusieurs mises à niveau et met automatiquement à niveau votre déploiement à la date indiquée. Vous pouvez trouver ces dates sur la page de détails du déploiement.

Que dois-je faire ? Vous pouvez ajuster les mises à niveau programmées selon vos besoins lorsque vous créez le déploiement ou à partir de la page de détails du déploiement.

Modification de service : la propriété adminPassword utilisée dans les objets de modèle CreateOggDeploymentDetails et UpdateOggDeploymentDetails des API CreateDeploymentDetails et UpdateDeploymentDetails était en phase d'abandon à compter du 15 août 2023.

Date annoncée : 15 août 2023

Date d'application : 15 août 2024

Détails : avec la nouvelle fonctionnalité d'authentification unique introduite le 15 août 2023, la propriété adminPassword utilisée dans les objets de modèle CreateOggDeploymentDetails et UpdateOggDeploymentDetails des API CreateDeploymentDetails et UpdateDeploymentDetails est désormais en phase d'abandon.

Cela me concerne-t-il ? Oui.

Que dois-je faire ? Les nouveaux déploiements créés à partir du 15 août 2023 nécessitent que vous sélectionniez une banque d'informations d'identification (OCI Identity and Access Management (IAM) ou GoldenGate) dans des locations où OCI IAM avec des domaines d'identité est activé. Si vous sélectionnez OCI IAM, vous pouvez vous connecter à la console de déploiement à l'aide de votre compte Oracle Cloud, tandis que GoldenGate vous demande de créer un coffre et d'ajouter une clé secrète dans laquelle stocker votre mot de passe, que vous utiliserez pour vous connecter à la console de déploiement.

Modification de service : fin de vie de GoldenGate Cloud Service Classic prenant effet le 11 avril 2024.

Date d'annonce : 22 mars 2024

Date d'entrée en vigueur : 11 avril 2024

Cela me concerne-t-il ? Oracle GoldenGate Cloud Service Classic est exécuté sur Oracle Cloud Classic Gen 1, qui est en phase d'abandon en faveur d'Oracle Cloud Infrastructure (OCI) Gen 2 Cloud. Si vous êtes un utilisateur Oracle GoldenGate Cloud Service Classic, vous pouvez migrer vos charges globales d'Oracle Cloud Classic Gen 1 vers Oracle Cloud Infrastructure GoldenGate.

Si vous êtes actuellement un utilisateur OCI GoldenGate, cette annonce de modification de service ne s'applique pas à vous.

Que dois-je faire ? Migrez les charges de travail Oracle GoldenGate Cloud Service vers Oracle Cloud Infrastructure GoldenGate, qui offre des fonctionnalités similaires. Pour connaître les étapes de migration détaillées, reportez-vous à Migration vers Oracle Cloud Infrastructure GoldenGate.

Modification de service : les API d'événements d'audit Oracle Cloud Infrastructure Identity and Access Management et certains modèles de rapports pour les API de rapports, que vous pouvez utiliser avec les domaines d'identité IAM, seront en phase d'abandon.

Date annoncée : mai 15, 2023

Date d'application : 15 décembre 2024

Détails : à compter du 15 décembre 2024, les API IAM pour AuditEvents et certains modèles de rapport dans les API Reports ne fonctionneront plus avec IAM.

Cela me concerne-t-il ? Si vous utilisez actuellement des API IAM pour AuditEvents et les API pour Reports qui reposent sur AuditEvents, vous devrez utiliser les API du service OCI Audit à la place.

Que dois-je faire ? Vous pouvez désormais utiliser les API OCI Audit. Pour en savoir plus sur l'extraction de données à partir d'OCI Audit, reportez-vous aux sections suivantes :

• Implémenter la sécurité multicloud à l'aide d'OCI Audit pour capturer des événements à partir d'OCI Identity and Access Management
• Génération de rapports Identity and Access Management à partir d'Oracle Cloud Infrastructure Audit

Modification de service : à compter du 15 juillet 2022, l'API CreateFleet nécessitera l'OCID de journal personnalisé dans la propriété inventoryLog.

Date d'annonce : 15 avril 2022

Date d'application : 15 juillet 2022

Détails : depuis le 30 mars 2022, JMS utilise le service Oracle Cloud Infrastructure Logging pour stocker les journaux d'inventaire et d'opérations. Les journaux d'inventaire sont des journaux personnalisés qui stockent l'inventaire d'exécution Java et les informations relatives à l'utilisation signalées par l'agent de gestion à partir des hôtes. Avec cette modification, l'API CreateFleet inclut une propriété supplémentaire, inventoryLog, pour indiquer le journal personnalisé à utiliser.

Que dois-je faire ? Les parcs existants doivent être migrés à l'aide de l'API UpdateFleet avant le 15 juillet 2022. Après le 15 juillet 2022, la propriété inventoryLog de l'API CreateFleet sera un paramètre requis. Pour plus d'informations, reportez-vous aux opérations CreateFleet et UpdateFleet. Les agents doivent être de version 220302.1455 ou ultérieure.

Depuis le 26 octobre 2022, les API Language Detect de la version 20221001 sont en phase d'abandon. A partir du 10 octobre 2023, les API en phase d'abandon ne seront plus disponibles.

Depuis le 26 octobre 2022, les API Language BatchDetect disposent de la nouvelle version d'API prise en charge 20221001. Avec l'introduction de la version d'API 20221001, les classes suivantes ont été enlevées et remplacées par la classe commune, com.oracle.bmc.ailanguage.model.TextDocument.

Modification de service : la période de conservation des sauvegardes du système de base de données a été réduite de 10 000 à 365 jours.

Date d'annonce : septembre 2020

Date d'application : octobre 2020

Détails : la période de conservation des sauvegardes du système de base de données a été réduite de 10 000 à 365 jours.

Cela me concerne-t-il ? Non.

Que dois-je faire ? Rien.

Modification de service : la valeur par défaut de AutomaticBackupRetention passe de DELETE à RETAIN.

Date d'annonce : 2024 janvier 2024

Date d'application : 2025 janvier 2025

Détails : avant la modification de ce service, la valeur par défaut de l'attribut AutomaticBackupRetention dans la stratégie de suppression de système de base de données était DELETE. Avec cette modification, la valeur par défaut de AutomaticBackupRetention est remplacée par RETAIN. Cette modification n'a aucune incidence sur la stratégie de suppression des systèmes de base de données existants. La modification s'applique uniquement aux systèmes de base de données créés après la date en vigueur.

Cela me concerne-t-il ? Oui, si vous utilisez des valeurs par défaut pour la stratégie de suppression.

Que dois-je faire ? Si vous préférez que la valeur par défaut soit DELETE pour AutomaticBackupRetention et que vous utilisez le kit SDK/CLI/Terraform sans que la valeur ne soit définie, vous devez définir explicitement la valeur préférée.

L'API ListNetworkLoadBalancerProtocol d'Oracle Cloud Infrastructure Network Load Balancer est en phase d'abandon à compter du 12 janvier 2022. La prise en charge de ListNetworkLoadBalancerProtocol prend fin le 1er mars 2023. Reportez-vous à ListenerDetails pour obtenir la liste actuelle des valeurs de protocole prises en charge.

Modification de service : OCI Cache restreint l'utilisation des commandes Redis CONFIG SET et ACL dans les clusters gérés par le service.

Date d'annonce : 14 juin 2024

Date d'application : 14 juillet 2024

Détails : OCI Cache empêche l'utilisation de certaines commandes Redis pour garantir les performances et la stabilité du service. Reportez-vous à Commandes Redis non prises en charge. À partir du 14 juillet 2024, les commandes CONFIG SET et ACL seront incluses dans la liste des commandes restreintes pour OCI Cache.

Cela me concerne-t-il ? Si vous utilisez actuellement ces commandes, vous ne pourrez plus les utiliser avec vos clusters OCI Cache après le 14 juillet 2024. Nous vous recommandons également de ne pas utiliser ces commandes avant qu'elles ne soient restreintes car elles peuvent entraîner des problèmes de stabilité avec les clusters gérés par OCI Cache.

Modification de service : le service Oracle OS Management est en phase d'abandon.

Date d'annonce : 23 avril 2024

Date d'application : 23 avril 2025

Détails : le 23 avril 2025, le service OS Management (OSMS) atteint la fin de vie (EOL). Désormais, le service n'est plus disponible pour vous dans les régions où vous n'utilisez pas déjà OSMS ou pour les nouveaux utilisateurs avec de nouvelles locations. Le service OS Management est remplacé par OS Management Hub, qui offre une expérience utilisateur améliorée avec de nouvelles fonctionnalités, notamment des déploiements de patches via des étapes de cycle de vie, une planification de travail améliorée et des fonctionnalités de reporting.

Cela me concerne-t-il ? Le service OS Management ne sera plus disponible pour gérer les instances Oracle Linux ou Microsoft Windows après le 23 avril 2025.

Procédure : commencez à utiliser le service OS Management Hub pour gérer les instances dans Oracle Cloud Infrastructure (OCI), les centres de données privés et les environnements cloud tiers pris en charge. Avant la date de fin de vie, nous vous recommandons de migrer vos instances gérées du service OS Management vers le service OS Management Hub.

Modification de service : les droits d'accès IAM pour les ressources réseau requises pour créer et utiliser des clusters OpenSearch passent des droits d'accès de service aux droits d'accès utilisateur.

Date d'annonce : 20 février 2024

Date d'application : 20 mars 2024

Détails : afin de créer et de gérer des clusters dans Search avec OpenSearch, vous devez créer des stratégies IAM pour votre location qui octroient des droits d'accès à des ressources réseau spécifiques. Actuellement, les droits d'accès requis sont des droits d'accès de service, avec des instructions de stratégie telles que le fragment de code suivant :

Allow service opensearch to manage <Networking_Resource>...

La recherche avec OpenSearch requiert des droits d'accès utilisateur pour accorder l'accès aux ressources Networking au lieu des droits d'accès au service. Pendant la période de transition, votre location doit disposer des deux types de stratégie.

Cela me concerne-t-il ? Toutes les locations où les utilisateurs créent et gèrent des clusters OpenSearch doivent disposer de nouvelles stratégies qui indiquent des droits d'accès utilisateur en plus des stratégies existantes avec des droits d'accès de service pour l'accès aux ressources réseau requises.

Allow group SearchOpenSearchAdmins to manage vnics in compartment <NETWORK_RESOURCES_COMPARTMENT>
Allow group SearchOpenSearchAdmins to manage vcns in compartment <NETWORK_RESOURCES_COMPARTMENT>
Allow group SearchOpenSearchAdmins to use subnets in compartment <NETWORK_RESOURCES_COMPARTMENT>
Allow group SearchOpenSearchAdmins to use network-security-groups in compartment <NETWORK_RESOURCES_COMPARTMENT>
Allow group SearchOpenSearchAdmins to manage opensearch-family in compartment <CLUSTER_RESOURCES_COMPARTMENT> 

Vous devez conserver toutes les stratégies existantes pour Search avec OpenSearch qui incluent des instructions de droits d'accès de service pour les ressources Networking jusqu'à ce que la transition vers les instructions de droits d'accès utilisateur soit terminée. Pour plus d'informations sur les droits d'accès requis pour Search avec OpenSearch, reportez-vous à Recherche avec des stratégies IAM OpenSearch.

Modification de service : les API Service Mesh d'Oracle Cloud Infrastructure de la version 20210930 sont en phase d'abandon depuis le 14 décembre 2022.

Date d'annonce : 14 décembre 202

Date d'application : 15 décembre 2023

Détails : depuis le 14 décembre 2022, les API Service Mesh de la version 20210930 sont en phase d'abandon. À partir du 15 décembre 2023, les API en phase d'abandon ne seront plus disponibles.

• Les opérations de mise à jour/de suppression/d'obtention/de liste sur toutes les ressources créées par des API en phase d'abandon seront prises en charge par les nouvelles API (version 20220615).
• Les outils de ligne de commande et les kits SDK OCI publiés avant le 14 décembre 2022 sont limités aux fonctionnalités du modèle de ressource en phase d'abandon (version 20210930).

Liste des API non prises en charge et de remplacement

Modification de service : les API d'analyse de documents d'Oracle Cloud Infrastructure Vision sont en phase d'abandon depuis le 30 janvier 2023. La fonctionnalité d'analyse de documents est désormais proposée via le service Oracle Cloud Infrastructure Document Understanding.

Date d'annonce : 30 janvier 2023

Date d'application : 31 janvier 2024

Détails :

Les API suivantes sont en phase d'abandon depuis le 10 janvier 2023 :

• AnalyzeDocument
• CreateDocumentJob
• GetDocumentJob
• CancelDocumentJob

Les données de sortie stockées dans un bucket Object Storage résultant de travaux de document précédents resteront accessibles après l'abandon de l'API de document. A partir du 31 janvier 2024, les API en phase d'abandon ne seront plus disponibles dans le service Oracle Cloud Infrastructure Vision.

Cela me concerne-t-il ? Cette modification a une incidence sur les clients qui utilisent la fonctionnalité d'analyse de documents du service Oracle Cloud Infrastructure Vision.

Que dois-je faire ? Les clients qui utilisent la fonctionnalité d'analyse de documents du service Oracle Cloud Infrastructure Vision doivent utiliser la fonctionnalité d'analyse de documents proposée via le service Oracle Cloud Infrastructure Document Understanding.