AZ AOSM Extension Refactor

src/aosm/HISTORY.rst

@@ -3,6 +3,39 @@
 Release History
 ===============
 
+2.0.0b1
+++++++++
+* Renamed nfdvName to nfdv in CGVs
+* Added useful comments to input files
+* Added 1:1 mapping between NFVIsFromSite and NF RETs
+* Added expose_all parameter in input file to expose all parameters in deployParameters and CGS
+* Removed multiple_instances and depends_on from input file
+* Added: mutating webhook for injectArtifactStoreDetails
+* Added: Users can specify multiple image sources from all types of registries (not just ACRs). General improvements in how CNF image sources are handled. 
+* Fixed: Namespace appeared twice in the `artifacts.json` file, leading to errors in the publish step of the CLI.
+* Changed configurationType for NF Resources from Secret to Open
+* Removed imageName from deployParameters
+* Removed image name parameter from input file
+* Fixed camel casing of VHD Parameters
+* Fixed blob sas url bug
+* Edited comment in input file to reflect RGs are created if they do not exist
+* Added creating RG if it does not exist
+* Removed use of permanent temp file for helm package
+* Fixed: helm charts not uploading correctly
+* Added creation of resource groups if does not exist
+* Fixed: Manifest name built from ACR name, so clashes
+* Fixed: Nexus image version must be semver
+* Fixed: Sensible error when no type given in helm chart schema
+* Fixed: customLocation missing from Nexus
+* Fixed: helm charts not uploading correctly
+* Added: Nexus support
+* Add `publisher` command group for management of publisher resources.
+* Changed the name of the `path_to_mappings` parameter in the CNF input file to `default_values`
+* Added a `helm template` validation step to the `az aosm nfd build` command for the `cnf` definition type
+* Added validation of the values file for helm charts when using the `az aosm nfd build` command for the `cnf` definition type
+* Fixed helm chart image parsing in the `az aosm nfd build` command for the `cnf` definition type. This means that the images can now be extracted correctly from the helm chart.
+* Fixed: infinite loop bug when retrying failed artifact uploads to the ACR
+
 1.0.0b4
 ++++++++
 * Fixed: Remove check for Allow-2023-09-01 feature flag that is no longer required (Bug #1063964)

src/aosm/README.md

@@ -49,12 +49,10 @@ For CNFs you must have these packages installed on the machine you are running t
 -  `docker` installed only in some circumstances, those being if the source image is in your local docker repository, or you do not have subscription-wide permissions required to push charts and images. See the remainder of this section for further details. Docker provides packages that easily configure docker on [Windows](https://docs.docker.com/docker-for-windows/), or [Linux](https://docs.docker.com/engine/install/#supported-platforms) systems.
 
 For CNFs, you must provide:
-* helm packages with an associated schema. These files must be on your disk and will be referenced in the `input.json` config file. 
-* images for your CNF.  For these you have the following options:
-  - a reference to an existing Azure Container Registry which contains the images for your CNF. Currently, only one ACR and namespace is supported per CNF. The images to be copied from this ACR are populated automatically based on the helm package schema. You must have Reader/AcrPull permissions on this ACR. To use this option, fill in `source_registry` and optionally `source_registry_namespace` in the input.json file.
-  - or, the image name of the source docker image from local machine. This is for a limited use case where the CNF only requires a single docker image which exists in the local docker repository. To use this option, fill in `source_local_docker_image` in the input.json file. This requires docker to be installed.
-* optionally, you can provide a file (on disk) path_to_mappings which is a copy of values.yaml with your chosen values replaced by deployment parameters, thus exposing them as parameters to the CNF. You can get this file auto-generated by leaving the value as a blank string, either having every value as a deployment parameter, or using `--interactive` to interactively choose.
-When filling in the input.json file, you must list helm packages in the order they are to be deployed. For example, if A must be deployed before B, your input.json should look something like this:
+* Helm packages with an associated schema. These files must be on your disk and will be referenced in the `cnf-input.jsonc` config file. 
+* A reference to an existing Azure Container Registry which contains the images for your CNF. Currently, only one ACR and namespace is supported per CNF. The images to be copied from this ACR are populated automatically based on the helm package schema. You must have Reader/AcrPull permissions on this ACR. To use this, fill in `source_registry` and optionally `source_registry_namespace` in the cnf-input.jsonc file.
+* Optionally, you can provide a file (on disk) path_to_mappings which is a copy of values.yaml with your chosen values replaced by deployment parameters, thus exposing them as parameters to the CNF.
+* When filling in the cnf-input.jsonc file, you must list helm packages in the order they are to be deployed. For example, if A must be deployed before B, your cnf-input.jsonc should look something like this:
 
         "helm_packages": [
             {
@@ -106,35 +104,17 @@ Create an example config file for building a definition
 
 `az aosm nfd generate-config`
 
-This will output a file called `input.json` which must be filled in. 
+This will output a file called `cnf-input.jsonc` which must be filled in. 
 Once the config file has been filled in the following commands can be run.
 
 Build an nfd definition locally
 
-`az aosm nfd build --config-file input.json`
-
-More options on building an nfd definition locally:
-
-Choose which of the VNF ARM template parameters you want to expose as NFD deploymentParameters, with the option of interactively choosing each one.
-
-`az aosm nfd build --config-file input.json --definition_type vnf --order_params`
-`az aosm nfd build --config-file input.json --definition_type vnf --order_params --interactive`
-
-Choose which of the CNF Helm values parameters you want to expose as NFD deploymentParameters.
-
-`az aosm nfd build --config-file input.json --definition_type cnf [--interactive]`
+`az aosm nfd build --config-file cnf-input.jsonc`
 
 Publish a pre-built definition
 
-`az aosm nfd publish --config-file input.json`
-
-Delete a published definition
+`az aosm nfd publish --build-output-folder cnf-cli-output`
 
-`az aosm nfd delete --config-file input.json`
-
-Delete a published definition and the publisher, artifact stores and NFD group
-
-`az aosm nfd delete --config-file input.json --clean`
 
 #### NSDs
 
@@ -149,24 +129,17 @@ Create an example config file for building a definition
 
 `az aosm nsd generate-config`
 
-This will output a file called `input.json` which must be filled in. 
+This will output a file called `nsd-input.jsonc` which must be filled in. 
 Once the config file has been filled in the following commands can be run.
 
 Build an nsd locally
 
-`az aosm nsd build --config-file input.json`
+`az aosm nsd build --config-file nsd-input.jsonc`
 
 Publish a pre-built design
 
-`az aosm nsd publish --config-file input.json`
-
-Delete a published design
-
-`az aosm nsd delete --config-file input.json`
-
-Delete a published design and the publisher, artifact stores and NSD group
+`az aosm nsd publish --build-output-folder nsd-cli-output`
 
-`az aosm nsd delete --config-file input.json --clean`
 
 ## Bug Reporting
 
@@ -200,4 +173,4 @@ az config set logging.enable_log_file=false
 ```
 
 ## Development
-Information about setting up and maintaining a development environment for this extension can be found [here](./development.md).
+Information about setting up and maintaining a development environment for this extension can be found [here](https://eng.ms/docs/strategic-missions-and-technologies/strategic-missions-and-technologies-organization/azure-for-operators/aiops/aiops-orchestration/aosm-product-docs/processes/cli_contributing).

src/aosm/azext_aosm/__init__.py

@@ -16,8 +16,17 @@ def __init__(self, cli_ctx=None):
         super().__init__(cli_ctx=cli_ctx, custom_command_type=aosm_custom)
 
     def load_command_table(self, args):
+        from azure.cli.core.aaz import load_aaz_command_table
+
         from azext_aosm.commands import load_command_table
 
+        try:
+            from . import aaz
+        except ImportError:
+            aaz = None
+        if aaz:
+            load_aaz_command_table(loader=self, aaz_pkg_name=aaz.__name__, args=args)
+
         load_command_table(self, args)
         return self.command_table
 

src/aosm/azext_aosm/_client_factory.py

@@ -14,7 +14,9 @@ def cf_aosm(cli_ctx, *_) -> HybridNetworkManagementClient:
     # By default, get_mgmt_service_client() sets a parameter called 'base_url' when creating
     # the client. For us, doing so results in a key error. Setting base_url_bound=False prevents
     # that from happening
-    return get_mgmt_service_client(cli_ctx, HybridNetworkManagementClient, base_url_bound=False)
+    return get_mgmt_service_client(
+        cli_ctx, HybridNetworkManagementClient, base_url_bound=False
+    )
 
 
 def cf_resources(cli_ctx, subscription_id=None):