1.13.3

New release to correct an issue with the use of mapped drives in the CastGlobalSettings.ini file on an AIP Node.

1.13.2

New release to correct an issue with the synchronization of authorizations between AIP Console and integrated dashboard when LDAP security mode is enabled.

1.13.1

 New release to correct an issue with storage path syntax in the aip-node-app.properties file preventing the AIP Node from functioning correctly.

1.13.0

New features

Known issues

Upgrade notes

When upgrading to 1.13.x from a previous release of AIP Console, you should take note of the following information:

Delivery folder split

In AIP Console 1.13.x the Delivery folder (located on each AIP Node) will be split so that each Application has its own dedicated Delivery folder (previously, the Delivery folder was global to all Applications). This process is actioned automatically during an upgrade to 1.13.x as described below.

Why will this split occur?

• To allow each Application to have dedicated (DMT) plugins and to therefore avoid a "collision" of plugins across the Applications.
• Possibility to have multiple versions of plugins running on different Applications
• Easier to backup and restore the Delivery folder for one Application

New delivery folder structure

The Delivery folder location will become the parent of all the "application delivery folders". By default the Delivery folder is located at AipNode\data\delivery on each AIP Node (this default location has not changed) and the following structure will now be used:

Inside each Application specific subfolder, you will find the exact same folder structure as used in Delivery folder before upgrade:

When is the split actioned?

The Delivery folder split will be actioned during an upgrade to AIP Console 1.13.x:

• When the installer detects that the delivery folder is in the "old" structure, the split tool will be launched automatically:

Click to enlarge

• The installation continues after the split tool has successfully executed, otherwise there will be a popup error 
• After installation of 1.13.x, in the original location, you will have the same delivery folder with the new structure and a backup of the original one:

• Existing Applications will continue to work in AIP Console as before.

Situations that require manual migration before installing AIP Console

You will need to manually execute the split tool before installation of the new release of AIP Console in the following situations:

1. Where you have multiple AIP Nodes with multiple CAST Storage Servers/PostgreSQL instances, but only one shared Delivery folder
2. Where you are using a mapped drive for  your Delivery folder such as R:\

The manual migration process is as follows:

The split tool can be found in <AIPNode>/bin/dmt-migration-tool. Configure the config.json file with the correct settings: if you have multiple multiple CAST Storage Servers/PostgreSQL instances, you need to enter each one into this file (as shown below). Run the migration.bat file to complete the split. Then proceed with the upgrade.

[
  {
    "delivery_folder_location": "R:/delivery",
    "css_servers": [
      {
        "dbname": "postgres",
        "host": "localhost",
        "port": "2282",
        "username": "operator",
        "password": "CastAIP"
      }
      {
        "dbname": "postgres",
        "host": "other_host",
        "port": "2282",
        "username": "operator",
        "password": ""
      }
    ]
  }
]

Reorganization of Architecture Model files

Introduction

This documentation applies to AIP Console users who are currently using a version < 1.13.x, have used Architecture Checker features, and have upgraded their version of AIP Console to 1.13.x or 1.14.x.

Below is described how folders containing Architecture files (models, templates, and library sets/layers) are organized before/after upgrade of AIP Console to 1.13.x, and what are the actions that will be automatically performed by the "upgrade process" during switch from the old to the new organisation of these folders.

Organization of Architecture models, templates, library sets/layers in versions ≤ 1.12.x

All AIP Console Architecture Checker related files are located only on AIP Nodes, and files of a given Node are only visible to the end-user in the context of the Applications that are hosted by that Node. Below are, per AIP Node, the folders for the various files according to their type:

• models: AipNode\data\upload\AC\models
• templates (user-defined): AipNode\data\upload\AC\templates
• library sets and layers (product/standard and user-defined): AipNode\data\upload\AC\libraries

Organization of Architecture models, templates, library sets/layers in versions ≥ 1.13.x

As of AIP Console 1.13 with the introduction of the Architecture Studio, the AIP Console Architecture Checker related files become distributed in folders hosted by:

• the 1 to many AIP Nodes where Architecture files used to exist before
• the (unique) AIP Console where Architecture models, templates, and library sets/layers are now centralized

A model that used to exist on a AIP Node in version <= 1.12 will stay there, initially in the same folder as before (namely AipNode\data\upload\AC\models), because still the full file path of the model remains stored in the CAST-MS configuration of the Application(s) to which this model has been attached thus this path should not change. Note: as of AIP Console 1.13, models that will become attached to Application(s) will be in folder AipNode\data\drive_upload\architecture\models, instead of in AipNode\data\upload\AC\models.

Below are, on the AIP Console, the folders for the various files according to their type:

• models: AipConsole\data\upload\architecture\models
• user-defined templates: AipConsole\data\upload\architecture\templates
• user-defined library sets and layers: AipConsole\data\upload\architecture\libraries
• standard templates: AipConsole\data\standard\architecture\templates
• standard library sets and layers: AipConsole\data\standard\architecture\libraries

Why and when of the migration process

Since all Architecture models, templates, and library sets/layers are now centralized on the AIP Console instead of being spread across AIP Nodes, it is necessary to also bring in all the corresponding files from the Node(s) which used to host them up until now. The Architecture Models and user-defined templates whose transfer was successful will then be presented on the Architecture Studio main page, whereas the user-defined library sets/layers whose transfer was successful will be presented in a drop-down list in the models/templates editor.

The movement of Architecture files will not happen during the upgrade of the AIP Console version by the Installer tool, but rather each time an AIP Node will become available (i.e. accessible and enabled) when:

• the whole AIP Console application is (re-)started, whether the two .bat files are launched, or the two Windows Services are (re-)started: in this case, all available AIP Nodes will have their Architecture files migrated during the initialization steps (those executed before a user can connect)
• an AIP node that was accessible but disabled becomes enabled again, typically following the below user action in the Administration Center - Nodes page:

Situations and corresponding migration messages (levels = DEBUG, INFO, WARN, ERROR)

All messages related to the Architecture files migration are sequentially logged into AipConsole\data\logs\webi.log, and unless the user observes that the expected models, etc. are not visible in the Architecture Studio main page, there is no need at all to inspect this file. If this file needs to be inspected, all messages related to Architecture files migration will be between these two lines:

[...] Performing GET request to 'http://hostname:port#/api/archichecker/models'

and:

[...] Full sync for analysis node at http://hostname:port# is finished.

If no message is visible at all, it means that no migration was necessary: either the AIP Node did not host any Architecture Checker file, or else they have all been already migrated.

Notes

Once AIP Console has started, or a formerly disabled AIP Node has become enabled again, it is necessary to wait around 30 seconds to be absolutely certain sure that synchronization of the AIP Node will have occurred since the migration of Architecture files which is a part of it. Otherwise, launching AIP Console services, logging in, and then rushing to the Architecture Studio home page will almost certainly display none of the models and templates expected to have been migrated.

The migration process is the same whichever type of Architecture file is being migrated, and every message will indicate the file type for clarity. Below are the situations and the corresponding messages and severity levels, taking the example of an Architecture model file:

• The model is migrated for the first time and no file with the same filename already exists:

> DEBUG - Copied Architecture model file 'MyModel.CASTArchitect' from AIP Node 'local node' at http://localhost:8082.

• In the Architecture Studio, there already exists a model whose filename is 'MyModel.CASTArchitect', whether this file exists because it was created from scratch by the user or else results from a previous migration: 

  • If the model has, on its AIP Node, exactly the same content (binary comparison) as the file existing on AIP Console, then nothing will happen because it serves no purpose to migrate that file:

    > INFO - Skipped retrieval of Architecture model file 'MyModel.CASTArchitect' from AIP Node 'local node' at http://localhost:8082 because it has the same content as the existing model file with the same name.

  • Otherwise (i.e. content found on the AIP Node is different), then the formerly existing AIP Console file is left untouched and the migrated file will have its base part suffixed, between parentheses, by the name of the AIP Node from which it comes from (characters '\', '/', ':', '*', '?', '"', '<', '>', '|' disallowed in Windows filenames being replaced by underscores as is the case in the example warning below):

    > WARN - Renamed the Architecture model file 'MyModel.CASTArchitect' from AIP Node '<super*fast>' at http://quantumcomputer:8086 to 'MyModel (super_fast).CASTArchitect' because it has the same file name as the existing model file but it has different content.

• The model file doesn't exist any longer on its AIP Node, or its folder cannot be accessed, or the AIP Node suddenly became unavailable (for e.g. because of a power shutdown):

  > ERROR - Error while retrieving Architecture model file 'MyModel.CASTArchitect' from AIP Node 'local node' at http://localhost:8082. org.springframework.web.client.HttpClientErrorException$NotFound: 404
  Such errors will always be followed by a full stack trace, for easing diagnosis of the error cause.

Migration report

After all Architecture files found on the AIP Node currently of interest will have been processed, one line per type of file will be logged regarding migration success or failure. Below is an example showing the only two sorts of messages that can occur:

INFO - All 5 Architecture custom_template files could be migrated from AIP Node 'local node' at http://localhost:8082.

WARN - Only 4 of 6 Architecture model files could be migrated from AIP Node 'local node' at http://localhost:8082.

WARN - Only 0 of 3 Architecture custom_layer files could be migrated from AIP Node 'local node' at http://localhost:8082.

Migration recovery

The migration process has been designed so that any AIP Node knows which of its Architecture files haven't yet been migrated. If the migration process is abruptly interrupted, then files that couldn't yet be migrated will be attempted to be processed again once their AIP Node will have been restarted or has become available again. However, in no case any Architecture model file that hasn't successfully been migrated will be deleted on the file system of its AIP Node whether it is, in the case of models, attached to any Application, or to none.

If some Architecture files have definitively become unavailable for migration (because for example they have been deleted on the file system of their AIP Node), warnings will endlessly be logged in the migration report, each time the migration process will be re-executed, until this process will have disappeared from AIP Console.

Architecture Models with identical IDs

As part of the upgrade process, Architecture Model files will be automatically moved from storage on AIP Nodes to storage on the AIP Console (see note above). Since it is possible for Architecture Models on different AIP Nodes to use identical Metric IDs, after the upgrade and when one of the Architecture Model is subsequently edited in AIP Console a warning message will be displayed when model is saved as shown below. The Metric ID field will be editable so that a new metric ID can be assigned to the model. The model cannot be saved until the duplicate metric ID issue is resolved.

Requirements

See Deployment requirements.

How to report issues and feedback

Please report and issue or feedback to the product manager, Damien Charlemagne (d.charlemagne@castsoftware.com).