Post-upgrade to 10.2409.0

After updating the service image to 10.2409.0, complete the migration steps to fully utilize certain enhancements.

• Migrations steps for reservation feature enhancement
  The 10.2409.0 release introduces performance enhancements to the reservation feature. To fully utilize this feature, migrate the existing reservation records from the inv_reserv_summary table to the inv_reserv_summary_v2 table. If no prior records exist, migration is not needed.
  1. Note down the time when the deployment is complete.
  2. If you wait for the expiration of existing reservation records that are created before the upgrade, then do not call the migration API. For example, if the expiration timestamp of the existing records is within the next 24 hours, then waiting for 24 hours ensures that all these records expire automatically and no data needs to be migrated into the new table. After waiting for the existing records to expire, skip step 3.
  3. If the existing records that are created before the upgrade have a longer expiration duration, waiting for them to expire may not be feasible. In such cases, call the migration API to migrate records to the new table. You can still wait for 24 hours to let most of the records to expire so that fewer records need migration.
     1. Call the migration API after 24 hours of the deployment to migrate records that are created before the upgrade, based on the database write timestamp. Set the value of modifiedBefore to the deployment completion timestamp that is noted in step 1, as shown in the following example.

        POST : https://<sip-domain>/inventory/v1/migration/reserv_summary
        {
        "tenantId": "string",
        "filters": {
        	       "modifiedBefore" : "<ReleaseDeploymentTS>" 
        	     },
        "pageSize": 5000
        }

        This API initiates a migration job and returns a job ID for tracking purposes. For more information, see the API documentation.
     2. To check the status of the migration, call the following API by using the job ID that is obtained from the step 3a. When the job status is complete, go to step 4.

        GET : https://<sip-domain>/inventory/v1/migration/reserv_summary/<Job_id>

        For more information, see the API documentation.
  4. Update all the Inventory Visibility deployments with RESERVE_SUMMARY_MIGRATION_COMPLETED environment variable to true.
     1. Define the environment variable in SIPEnvironment.

        spec:
          serverProperties:
            envVars:
             - groupName: reservation
        	propertyList:
        	   RESERVE_SUMMARY_MIGRATION_COMPLETED: 'true'

     2. Apply the group name that is defined in step 4a in IVServiceGroup.

        spec:
          property:
            envVars: reservation

        For more information, see serverProperties parameter.
  5. Update the base rule to ONLY_WRITE_NEW to disable writing to the inv_reserv_summary table by calling the PATCH operations API. To validate the updated value you can then call the GET operations API.

     PATCH https://<sip-domain>/inventory/operations/v1/configuration/settings/default
     
     {
         "migration": {
     		"reserveSummaryMigrationMode": "ONLY_WRITE_NEW",		
     	}
     }

• Delete the publisher for the productAvailability.v2 and productAvailabilitySnapshot.v2 events
  1. Get the publisher ID for the productAvailability.v2 event.

     GET : https://<sip-domain>/{tenantId}​/v1​/configuration​/events​/productAvailability.v2​/publishers

  2. Call the delete API to delete the publisher for the event. Fetch the publisher ID obtained from the step 1.

     DELETE : https:///<sip-domain>/inventory/default/v1/configuration/events/productAvailability.v2/publishers/<publishers_id>

  3. Repeat steps 1 and 2 for the productAvailabilitySnapshot.v2 event.
  4. After deleting the publishers, ensure that no subscribers for these two events are available.
     For more information, see the API documentation.
• Delete the {topicPrefix}-{environment}-prm-iv-breakup-sink-stream topic.
• Steps to help ensure effective synchronization of rules between Inventory Visibility and the Rules services. The following steps applies only when Sterling Intelligent Promising is deployed in production or flexible modes. Hence, no action is required for development mode.
  1. Add the RULES_TRIGGER_TOPIC environment variable in serverProperties in the SIPEnvironment custom resource. The value for this environment variable is read from the existing configMap. Hence, use the same configMap value that is used in the existing configMap as shown in the following example.

       serverProperties:
         envVars:
           - groupName: ruletriggertopic
             propertyRef:
               - name: RULES_TRIGGER_TOPIC
                 valueFrom:
                   configMapKeyRef:
                     key: rules-trigger-topic
                     name: iv-kafka-configs

  2. Save the changes that you configured in step 1.
  3. Set the ruletriggertopic groupName under property in IVServiceGroup and then save the custom resource. This step helps ensure the RulesTriggerConsumer backend server uses the RULES_TRIGGER_TOPIC environment variable.

     - active: true
       names:
         - 'RulesTriggerConsumer:5'
       property:
         envVars: ruletriggertopic

     The RulesTriggerConsumer pod now restarts.
  4. Verify that no errors exist in the RulesTriggerConsumer pod to proceed further.