DS images management and processing during an upgrade to 8.5 RU4
search cancel

DS images management and processing during an upgrade to 8.5 RU4

book

Article ID: 206726

calendar_today

Updated On:

Products

Deployment Solution

Issue/Introduction

Question:
What is the current behavior regarding DS images management for images created by the Deployment Solution pre-8.5 RU4 DS version?

Environment

DS 8.5 RU4

Resolution

This is how we handle legacy images (under images we mean personality data also) prior to DS 8.5 RU4:

  1. Ghost images for deployment: Image resources are created per each execution along with associated packages. The schema does not differ from what we have in DS 8.5 RU4.
  2. Backup images: Packages are not created. The Agent just creates a folder on SMP or PS package share and writes images in this location. In the case of “tokenized” task image resource and dedicated folder is created per each agent. On sequential executions, the existing image resource gets located by image name (in “tokenized” case it is agent name) and image files' location is reused. In case when image name is specified in the task, the behavior is chaotic and leads to unpredictable results. So on the first run, different resources will be created with different locations with the same image name (actually depends on task execution timing, the mess can happen already on the first run). On sequential runs, since lookup is performed by name, the first resource will be retrieved and re-used. It means that all the agent will try to do is to write backup images in the same location with the same file name. 
  3. Personality packages. No packages get created. Here we have also two branches. In the “tokenized” case path on PS\SMP for personality data, it will be created using agent resource GUID as a subfolder name. On each execution, data gets overwritten in this location. Since the agent does not pass the image resource GUID back to the server, on each execution separate personality resource gets created. The User ends up with a bunch of resources that actually point to on same folder and file. In the “distribute personality” task, they are all available for selection but makes not much sense. In case when personality name is specified in tasks – on each execution separate folder gets created along with a separate personality resource item. It is coded in such a way that no overwrites are possible. Since the name is taken from the task – named “capture task” execution on different agents leads to the generation of personality resources with the same names. Assume that it is not possible to use the “distribute personality” task in such scenario.

All these backup\personality “approaches” are discontinued with the DS 8.5 RU4 release. As for Ghost imaging resource\package pair gets created in all cases. Images are linked to agents they were collected from etc. All images are visible in SMP Console, packages can be edited\deleted – basic management was implemented.

With DS 8.5 RU4 release, the following was done for backup and personality images that we collected by prior DS versions:

  1. We leave backup\personality resources as-is during the upgrade and allow users to convert them later from SMP console on the image management page. There we notify the user that the image is not linked to the package and in case of deletion image data will not be removed from Package Servers. This “upgrade” does not happen immediately. PS must receive the policy, process it, and report the created package codebases back to SMP. Only after that image will be fully manageable.
    This approach allows the flexibility for customers to run the conversion when they want.  
  2. In the case of images that are created on the web (you can select some web server to upload created images to. KB 154365), we still do not implement the deletion process.
    If you try to delete such an image from the SMP Console, it will warn you about manual deletion requirements for image data.

Regarding the duplicated personality resources that link the same data package, the code around this portion that creates duplicates is fixed.