Meilleures pratiques Azure Operator Service Manager pour intégrer et déployer des fonctions réseau

Microsoft a développé de nombreuses pratiques éprouvées pour la gestion des fonctions réseau (NFs) en utilisant Azure Operator Service Manager. Cet article fournit des instructions que les fournisseurs de NF, les opérateurs de télécommunications et leurs partenaires peuvent suivre pour optimiser la conception. Gardez ces pratiques à l’esprit lorsque vous intégrez et déployez vos NFs.

Considérations d’ordre général

Nous vous recommandons d’intégrer et de déployer d’abord vos NFs les plus simples (un ou deux graphiques) en utilisant les guides de démarrage rapide pour vous familiariser avec le flux global. Vous pouvez ajouter les détails de configuration nécessaires dans les itérations suivantes. À mesure que vous parcourez les guides de démarrage rapide, tenez compte des points suivants :

• Structurez vos artefacts pour qu’ils s’alignent sur l’utilisation planifiée. Envisagez de séparer les artefacts globaux des artefacts que vous souhaitez faire varier selon le site ou l’instance.
• Assurez-vous de la composition de service de plusieurs NFs avec un ensemble de paramètres qui correspond aux besoins de votre réseau. Par exemple, vous pouvez avoir un graphique qui a 1000 valeurs et vous ne personnalisez que 100 d’entre elles. Assurez-vous que, dans la couche Schéma de groupe de configuration (CGS) (couverte plus largement dans les sections qui suivent), vous n’exposez que 100.
• Réfléchissez rapidement à la façon dont vous souhaitez séparer l’infrastructure (par exemple, en clusters) ou les magasins d’artefacts et l’accès entre les fournisseurs, en particulier au sein d’un seul service. Faites correspondre votre ensemble de ressources de serveur de publication à ce modèle.
• Le site Azure Operator Service Manager est un concept logique, une représentation d’une destination de déploiement. Il s’agit par exemple d’un cluster Kubernetes pour les fonctions réseau en conteneur (Containerized Network Functions/CNF) ou d’un emplacement personnalisé étendu d’Azure Operator Nexus pour les fonctions réseau virtualisées (Virtualized Network Functions/VNF). Il ne s’agit pas d’une représentation d’un site de périphérie physique. Il existe donc des cas d’usage où plusieurs sites partagent le même emplacement physique.
• Azure Operator Service Manager fournit différentes API qui facilitent la combinaison avec ADO ou d’autres outils de pipeline.

Considérations relatives au serveur de publication

• Nous vous recommandons de créer un seul serveur de publication par fournisseur NF. Cette pratique offre une expérience optimale de support, de maintenance et de gouvernance pour tous les fournisseurs et simplifie la conception de votre service réseau lorsqu’elle est composée de plusieurs NFs de plusieurs fournisseurs.

• Une fois que l’ensemble souhaité de ressources et d’artefacts du serveur de publication Azure Operator Service Manager est testé et approuvé pour une utilisation en production, nous vous recommandons de marquer l’ensemble comme immuable pour empêcher des modifications accidentelles et garantir une expérience de déploiement cohérente. Envisagez de vous appuyer sur des fonctionnalités d’immuabilité pour distinguer les ressources et les artefacts utilisés en production et ceux utilisés à des fins de test et de développement. Vous pouvez interroger l’état des ressources du serveur de publication et les manifestes d’artefact pour déterminer ceux qui sont marqués comme immuables. Pour plus d’informations, consultez Gestion des locataires, des abonnements, des régions et de la gestion en préversion des serveurs de publication.

  Gardez à l’esprit la logique suivante :

  • Si NSDV (Network Service Design Version) est marqué comme immuable, CGS doit également être marqué comme immuable. Sinon, l’appel de déploiement échoue.
  • Si la version de conception de fonction réseau (Network Function Design Version/NFDV) est marquée comme immuable, le manifeste de l’artefact doit également être marqué comme immuable. Sinon, l’appel de déploiement échoue.
  • Si seul le manifeste d’artefact ou le CGS sont marqués comme immuable, l’appel de déploiement réussit, que la NFDV et la NSDV soient marquées comme immuables.
  • Le marquage d’un manifeste d’artefact comme immuable garantit que tous les artefacts répertoriés dans ce manifeste (généralement, les graphiques, les images et les modèles Azure Resource Manager [modèles ARM]) sont également marqués comme immuables en appliquant les autorisations nécessaires sur le magasin d’artefacts.

• Envisagez d’utiliser des conventions d’affectation de noms et des techniques de gouvernance convenus pour aider à combler toute lacune restante.

Considérations sur la version et le groupe de définition de fonction réseau

Le groupe de définition de fonction réseau (NFDG) représente le plus petit composant que vous prévoyez de réutiliser indépendamment sur plusieurs services. Toutes les parties d’un NFDG sont toujours déployées ensemble. Ces parties sont appelées networkFunctionApplications. Par exemple, il est naturel d’intégrer une seule NF composée de plusieurs graphiques et images Helm sous la forme d’un seul NFDG si vous déployez toujours ces composants ensemble. Dans les cas où plusieurs NFs sont toujours déployées ensemble, il est raisonnable d’avoir un seul NFDG pour toutes ces fonctions. Les NFDG uniques peuvent avoir plusieurs NFDV.

Pour les versions de définition de fonction réseau conteneurisée (CNF NFDV), la liste networkFunctionApplications ne peut contenir que des packages Helm. Il est raisonnable d’inclure plusieurs packages Helm s’ils sont toujours déployés et supprimés ensemble.

Pour les versions de définition de fonction réseau virtualisée (VNF NFDV), la liste networkFunctionApplications doit contenir au moins un VhdImageFile et un modèle ARM. Le modèle ARM doit déployer une seule machine virtuelle (VM). Pour déployer plusieurs VMs pour une VNF unique, veillez à utiliser des modèles ARM distincts pour chaque VM.

Le modèle ARM ne peut déployer des ressources Resource Manager provenant des fournisseurs de ressources suivants :

• Microsoft.Compute
• Microsoft.Network
• Microsoft.NetworkCloud
• Microsoft.Storage
• Microsoft.NetworkFabric
• Microsoft.Authorization
• Microsoft.ManagedIdentity

Cas d’usage courants qui déclenchent une mise à jour mineure ou majeure de la version de conception de fonction réseau

• Mise à jour du CGS/des Valeurs de groupe de configuration (Configuration Group Values/CGV) pour une version existante qui déclenche la modification du fichier deployParametersMappingRuleProfile.
• Mise à jour des valeurs codées en dur dans la NFDV.
• Marquage des composants inactifs pour les empêcher d’être déployés via applicationEnablement: Disabled.
• Nouvelle version de NF, comme des graphiques et des images.

Considérations relatives au groupe de conception et aux versions de service réseau

Network Service Design Group (NSDG) est un composite d’un ou plusieurs NFDG et de tous les composants d’infrastructure (comme les clusters et les machines virtuelles Nexus Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS]) déployés en même temps. Un service de réseau de site (SNS) fait référence à une NSDV unique. Cette conception garantit un déploiement homogène et reproductible du service réseau sur un site donné à partir d’un seul SNS PUT.

Voici un exemple de NSDG :

• NF Fonction de serveur d’authentification (AUSF)
• NF Gestion des données unifiée (UDM)
• Machine virtuelle d’administration prenant en charge AUSF/UDM
• NF Unity Cloud (UC) Session Management Function (SMF)
• Cluster NAKS, sur lequel AUSF, UDM et SMF sont déployés

Ces cinq composants forment un NSDG unique. Un NSDG unique peut avoir plusieurs NSDV.

Cas d’usage courants qui déclenchent la mise à jour mineure ou majeure de la version de la conception du service réseau

• Créer ou supprimer les CGS.
• Modifications apportées à la NF modèle ARM associée à l’une des NFs déployées.
• Modifications apportées au modèle ARM d’infrastructure, par exemple AKS/NAKS ou machine virtuelle.

Considérations relatives au schéma de groupe de configuration

Nous vous recommandons de commencer toujours avec un seul CGS pour l’ensemble de la NF. S’il existe des paramètres spécifiques au site ou à l’instance, nous vous recommandons toujours de les conserver dans un CGS unique. Nous vous recommandons de fractionner en plusieurs CGS lorsqu’il existe plusieurs composants (rarement des NFs, plus couramment, une infrastructure) ou des configurations partagées entre plusieurs NFs. Le nombre de CGS définit le nombre de CGV.

Scénario

• FluentD, Kibana et Splunk (composants tiers courants) sont toujours déployés pour toutes les NFs au sein d’une NSD. Nous vous recommandons de regrouper ces composants en un NFDG unique.
• Une NSD a plusieurs NFs qui partagent toutes quelques configurations (emplacement de déploiement, nom du serveur de publication et quelques configurations de graphique).

Dans ce scénario, nous vous recommandons d’utiliser un CGS global et unique pour exposer les configurations de composants de NF et tiers courants. Vous pouvez définir un CGS spécifique à la NF en fonction des besoins.

Choisir les paramètres à exposer

• Le CGS ne doit avoir que des paramètres utilisés par des NFs (configuration jour 0/N) ou des composants partagés.
• Les paramètres rarement configurés doivent avoir des valeurs par défaut définies.
• Si plusieurs CGS sont utilisés, nous vous recommandons peu ou pas de chevauchement entre les paramètres. Si un chevauchement est nécessaire, assurez-vous que les noms des paramètres sont clairement distinguables entre les CGS.
• Ce qui peut être défini via API (Azure Operator Nexus, Azure Operator Service Manager) doit être pris en compte pour le CGS. Par opposition à la définition de ces valeurs de configuration par le biais de fichiers CloudInit, par exemple.
• Lorsque vous n’êtes pas sûr, un bon point de départ consiste à exposer le paramètre et à avoir une valeur par défaut raisonnable spécifiée dans le CGS. L’exemple suivant montre les exemples de charges utiles CGS et CGV correspondantes.
• Une identité managée affectée par l’utilisateur unique doit être utilisée dans tous les modèles de NF ARM et doit être exposée via le CGS.

Charge utile CGS :

{ 
  "type": "object", 
  "properties": { 
    "abc": { 
    "type": "integer", 
    "default": 30
    }, 
    "xyz": { 
    "type": "integer", 
    "default": 40
    },
    "qwe": {
    "type": "integer" //doesn't have defaults
    }
  }
  "required": "qwe"
}

Charge utile CGV correspondante transmise par l’opérateur :

{
"qwe": 20
}

Charge utile CGV résultante générée par Azure Operator Service Manager :

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

Considérations relatives aux valeurs de groupe de configuration

Avant d’envoyer la création de la ressource CGV, vous pouvez vérifier que le schéma et les valeurs du fichier YAML ou JSON sous-jacent correspondent à ce que le CGS correspondant attend. Pour ce faire, une option consiste à utiliser l’extension YAML pour Visual Studio Code.

Considérations CLI

L’extension CLI Azure Operator Service Manager vous aide à publier les NFD et les NSD. Utilisez cet outil comme point de départ pour créer de nouvelles NFD et NSD. Envisagez d’utiliser l’interface CLI pour créer les fichiers initiaux. Modifiez-les ensuite pour incorporer des composants d’infrastructure avant de publier.

Considérations relatives au service de réseau de site

Nous vous recommandons d’avoir un SNS unique pour l’ensemble du site, y compris l’infrastructure. Le SNS doit déployer toute infrastructure requise (par exemple, les clusters et les machines virtuelles NAKS/AKS), puis déployer les NFs requises par-dessus. Cette conception garantit un déploiement homogène et reproductible du service réseau sur un site donné à partir d’un seul SNS PUT.

Nous vous recommandons de déployer chaque SNS avec une identité managée affectée par l’utilisateur plutôt qu’avec une identité managée affectée par le système. Cette identité managée affectée par l’utilisateur doit disposer des autorisations nécessaires pour accéder à la NFDV et doit avoir le rôle d’opérateur d’identité managée sur lui-même. Pour plus d’informations, consultez Créer et affecter une identité managée affectée par l’utilisateur.

Mappage des ressources Azure Operator Service Manager par cas d’usage

Les deux scénarios suivants illustrent le mappage des ressources Azure Operator Service Manager.

Scénario : fonction réseau unique

Une NF avec un ou deux composants d’application est déployée sur un cluster NAKS.

Répartition des ressources :

• NFDG : si les composants peuvent être utilisés indépendamment, deux NFDG, un par composant. Si les composants sont toujours déployés ensemble, un NFDG unique est déployé.
• NFDV : selon les besoins en fonction des cas d’usage mentionnés dans les sections « Cas d’usage courants » précédentes, qui déclenchent les mises à jour mineures ou principales de la NFDV.
• NSDG : unique. Combine les NFs et les définitions de cluster Kubernetes.
• NSDV : si nécessaire en fonction des cas d’usage mentionnés dans les sections précédentes « Cas d’usage courants » qui déclenchent des mises à jour mineures ou majeures de la NSDV.
• CGS : unique. Nous vous recommandons que le CGS dispose de sous-sections pour chaque composant et infrastructure déployés pour faciliter la gestion, et comprenne les versions des NFD.
• CGV : unique en fonction du nombre de CGS.
• SNS : unique par NSDV.

Scénario : plusieurs fonctions réseau

Plusieurs NFs avec certains composants partagés et indépendants sont déployés sur un cluster NAKS.

Répartition des ressources :

• NFDG :
  • NFDG pour tous les composants partagés.
  • NFDG pour chaque composant indépendant ou NF.
• NFDV : plusieurs pour chaque NFDG par cas d’usage mentionné dans les sections « Cas d’usage courants » précédentes, qui déclenchent les mises à jour mineures ou principales de la NFDV.
• NSDG : unique. Combine l’ensemble des NFs, les composants partagés et indépendants et l’infrastructure (cluster Kubernetes ou toutes les VMs le prenant en charge).
• NSDV : si nécessaire en fonction des cas d’usage mentionnés dans les sections précédentes « Cas d’usage courants » qui déclenchent des mises à jour mineures ou majeures de la NSDV.
• CGS :
  • Célibataire. Global pour tous les composants qui ont des valeurs de configuration partagées.
  • NF CGS par NF, y compris la version de la NFD.
  • Selon le nombre total de paramètres, envisagez de combiner tous les CGS en un CGS unique.
• CGV : identique au nombre de CGS.
• SNS : unique par NSDV.

Considérations relatives à la mise à niveau logicielle

En supposant que les NFs prennent en charge les mises à niveau sur place/en service, pour les CNFs :

• Si de nouveaux graphiques et images sont ajoutés, Azure Operator Service Manager installe les nouveaux graphiques.
• Si certains graphiques et images sont supprimés, Azure Operator Service Manager supprime les graphiques qui ne sont plus déclarés dans la NFDV.
• Azure Operator Service Manager vérifie que la NFDV/NSDV provient du même NFDG/NSDG, et donc du même serveur de publication. Les mises à niveau entre serveurs de publication ne sont pas prises en charge.

Pour les VNF :

• Les mises à niveau sur place ne sont actuellement pas prises en charge. Vous devez instancier une nouvelle VNF avec une image mise à jour côte à côte. Supprimez ensuite l’ancienne VNF en supprimant le SNS.
• Si une VNF est déployée en tant que paire de VMs pour la haute disponibilité, vous pouvez concevoir le service réseau de telle sorte que vous puissiez supprimer et mettre à niveau les VMs une par une. Nous vous recommandons la conception suivante pour autoriser la suppression et la mise à niveau de VMs individuelles :
  • Chaque VM est déployée en utilisant un modèle ARM dédié.
  • Depuis le modèle ARM, deux paramètres doivent être exposés via le CGS : nom de la machine virtuelle, pour autoriser l’indication de l’instance principale/secondaire, et la stratégie de déploiement, contrôlant si le déploiement de VM est autorisé ou non.
  • Dans la NFDV, deployParameters et templateParameters doivent être paramétrés de telle sorte que vous puissiez fournir les valeurs uniques à l’aide des CGV pour chacun d’eux.

Considérations relatives à la haute disponibilité et à la récupération d’urgence

Azure Operator Service Manager est un service régional déployé dans des zones de disponibilité dans les régions qui les prennent en charge. Pour savoir dans quelles régions Azure Operator Service Manager est disponible, consultez Produits Azure par région. Pour obtenir la liste des régions Azure qui ont des zones de disponibilité, consultez Choisir la région Azure qui vous convient.

Tenez compte des exigences suivantes en matière de haute disponibilité et de récupération d’urgence :

• Pour fournir une géoredondance, vérifiez que vous disposez d’un serveur de publication dans chaque région où vous envisagez de déployer des NFs. Envisagez d’utiliser des pipelines pour vous assurer que les artefacts et ressources du serveur de publication sont maintenus synchronisés entre les régions.
• Le nom du serveur de publication doit être unique par région par locataire Microsoft Entra.

resource sns 'Microsoft.HybridNetwork/sitenetworkservices@2023-09-01’ = {
 name: snsName
 location: location
 identity: {
  type: 'SystemAssigned'
 }
 properties: {
   publisherName: publisherName
   publisherScope: 'Private'
   networkServiceDesignGroupName: nsdGroup
   networkServiceDesignVersionName: nsdvName
   networkServiceDesignVersionOfferingLocation: location

Considérations sur la résolution des problèmes

Pendant l’installation et la mise à niveau par défaut, les options atomiques et d’attente sont définies sur true, et le délai d’expiration de l’opération est défini sur 27 minutes. Lors de l’intégration initiale, et uniquement pendant que vous déboguez et développez des artefacts, nous vous recommandons de définir l’indicateur atomique sur false. pour éviter une restauration helm en cas d’échec et de conserver les journaux ou erreurs susceptibles d’être perdus. La meilleure façon de le faire se trouve dans le modèle ARM de la NF.

Dans le modèle ARM, ajoutez la section suivante :

"roleOverrideValues": [
    "{\"name\":\"NF_component_name>\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"false\",\"wait\":\"true\",\"timeout\":\"100\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\"}}}}}"
]

Le nom du composant est défini dans la NFDV :

     networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'fed-crds'
          dependsOnProfile: null
          artifactProfile: {
            artifactStore: {
              id: acrArtifactStore.id
            }

Considérations relatives au nettoyage

Supprimez les ressources d’opérateur dans l’ordre suivant pour vous assurer qu’aucune ressource orpheline n’est laissée derrière :

• SNS
• Site
• CGV

Supprimez les ressources du serveur de publication dans l’ordre suivant pour vous assurer qu’aucune ressource orpheline n’est laissée derrière :

• CGS
• NSDV
• NSDG
• NFDV
• NFDG
• Manifeste d’Artéfact
• Magasin d’Artéfacts
• Éditeur

Considérations à prendre en compte si votre NF exécute cert-manager

De la version 1.0.2728-50 à la version 2.0.2777-132, AOSM utilise désormais cert-manager pour stocker et faire pivoter les certificats. Dans le cadre de cette modification, AOSM déploie un opérateur cert-manager et associe des CRD dans l’espace de noms azurehybridnetwork. Plusieurs opérateurs cert-manager, même déployés dans des espaces de noms distincts, surveillant tous les espaces de noms, un seul cert-manager peut être exécuté effectivement sur le cluster.

Tout utilisateur qui tente d’installer cert-manager sur le cluster, dans le cadre d’un déploiement de charge de travail, obtient un échec de déploiement avec une erreur indiquant que la CRD « existe et ne peut pas être importée dans la version actuelle. » Pour éviter cette erreur, il est recommandé d’ignorer l’installation de cert-manager et, à la place, de prendre dépendance sur l’opérateur de gestionnaire de certificats et la CRD déjà installés par AOSM.

Autres modifications de configuration à prendre en compte

En plus de désactiver l’application NfApp associée à l’ancien cert-manager utilisateur, d’autres modifications peuvent être nécessaires ;

1. Si une NfApp contient une installation de l’autorité de certification et du gestionnaire de certificats, ceux-ci doivent être divisés en deux NfApps pour que partenaire puisse désactiver le gestionnaire de certificats et installer l’installation de l’autorité de certification.
2. Si d’autres NfApps ont des références DependsOn à l’ancienne NfApp du cert-manager utilisateur, celles-ci doivent être supprimées.
3. Si d’autres NfApps font référence à l’ancienne valeur d’espace de noms cert-manager utilisateur, celle-ci doit être remplacée par la nouvelle valeur d’espace de noms azurehybridnetwork.

Compatibilité et gestion des versions de cert-manager

Pour l’opérateur cert-manager, notre version déployée actuelle est 1.14.5. Les utilisateurs doivent tester la compatibilité avec cette version. Les futures mises à niveau des opérateurs cert-manager seront prises en charge via le processus de mise à niveau de l’extension NFO.

Pour les ressources CRD, notre version déployée actuelle est 1.14.5. Les utilisateurs doivent tester la compatibilité avec cette version. La gestion d’une CRD de cluster commun étant généralement gérée par un administrateur de cluster, nous travaillons à activer les mises à niveau des ressources CRD via le processus de module complémentaire Nexus standard.

Comportement de classement séquentiel NfApp

Vue d’ensemble

Par défaut, les applications de fonction réseau (NfApps) conteneurisées sont installées ou mises à jour en fonction de l’ordre séquentiel dans lequel elles apparaissent dans la version de conception de fonction réseau (NFDV). Pour la suppression, les NfApps sont supprimées dans l’ordre inverse spécifié. Lorsqu’un éditeur doit définir un ordre spécifique des NfApps, différent de l’ordre par défaut, dependsOnProfile est utilisé pour définir une séquence unique pour les opérations d’installation, de mise à jour et de suppression.

Utilisation de dependsOnProfile

Un éditeur peut utiliser dependsOnProfile dans la NFDV pour contrôler la séquence d’exécutions helm pour les NfApps. Dans l’exemple suivant, lors de l’opération d’installation, les NfApps seront déployées dans l’ordre suivant : dummyApplication1, dummyApplication2, puis dummyApplication. Lors de l’opération de mise à jour, les NfApps sont mises à jour dans l’ordre suivant : dummyApplication2, dummyApplication1, puis dummyApplication. Lors de l’opération de suppression, les NfApps sont supprimées dans l’ordre suivant : dummyApplication2, dummyApplication1, puis dummyApplication.

{
    "location": "eastus",
    "properties": {
        "networkFunctionTemplate": {
            "networkFunctionApplications": [
                {
                  "dependsOnProfile": {
                        "installDependsOn": [
                            "dummyApplication1",
                            "dummyApplication2"
                        ],
                        "uninstallDependsOn": [
                            "dummyApplication1"
                        ],
                        "updateDependsOn": [
                            "dummyApplication1"
                        ]
                    },
                    "name": "dummyApplication"
                },
                {
                  "dependsOnProfile": {
                        "installDependsOn": [
                        ],
                        "uninstallDependsOn": [
                            "dummyApplication2"
                        ],
                        "updateDependsOn": [
                            "dummyApplication2"
                        ]
                    },
                    "name": "dummyApplication1"
                },
                {
                    "dependsOnProfile": null,
                    "name": "dummyApplication2"
                }
            ],
            "nfviType": "AzureArcKubernetes"
        },
        "networkFunctionType": "ContainerizedNetworkFunction"
    }
}

Erreurs courantes

À ce jour, si dependsOnProfile fourni dans la NFDV n’est pas valide, l’opération NF échoue avec une erreur de validation. Le message d’erreur de validation s’affiche dans la ressource d’état de l’opération et ressemble à l’exemple suivant.

 {
  "id": "/providers/Microsoft.HybridNetwork/locations/EASTUS2EUAP/operationStatuses/ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "name": "ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "resourceId": "/subscriptions/4a0479c0-b795-4d0f-96fd-c7edd2a2928f/resourceGroups/xinrui-publisher/providers/Microsoft.HybridNetwork/networkfunctions/testnfDependsOn02",
  "status": "Failed",
  "startTime": "2023-07-17T20:48:01.4792943Z",
  "endTime": "2023-07-17T20:48:10.0191285Z",
  "error": {
    "code": "DependenciesValidationFailed",
    "message": "CyclicDependencies: Circular dependencies detected at hellotest."
  }
}