In the 4.x series of releases, Cloudify introduced the option of importing a plugin rather than a type file in a blueprint.  Importing a plugin implicitly imports the type file associated with the plugin.   Simultaneously, Cloudify made it much harder to pre-load type files onto Cloudify Manager so that the type files can be accessed even when Cloudify Manager is deployed into an environment with restricted network access.   Currently we rely on a script that Cloudify provided as an unsupported product, with no guarantee that it will continue to work with future releases of Cloudify Manager.

The preferred method for supporting deployments in environments with restricted network access is to upload plugins with their associated type files to Cloudify Manager and to have blueprint import the plugin rather than the type file. for example, a blueprint using the type file approach might have this:

imports:
- "https://nexus.onap.org/service/local/repositories/raw/content/org.onap.dcaegen2.platform.plugins/R5/k8splugin/1.4.13/k8splugin_types.yaml"

Using a plugin import, the blueprint would have this instead:

imports:
- plugin:k8splugin?version=1.4.13

This change will require changes to existing blueprints.  It will also require a change to the bootstrap process to install the plugins with their associated type files.  (It may make sense to move the plugin uploads from the bootstrap container to the CM container.)  It will eliminate the need for the Cloudify-provided script that runs when CM boots up.

Note that the blueprint should continue to import a Cloudify types file.

Note also that if the blueprint continues to import DCAE plugin type files rather than importing plugins, the blueprint will continue to deploy successfully in environments that have network connectivity that will allow accessing the import URL.