remove idle suffix from bg deploy #1697

ikasarov · 2025-09-12T07:06:04Z

during blue-green deployment, move the idle application renaming before the restage (in CreateOrUpdateAppStep) - ensuring the new name is applied before the restart/restage
fix ArchiveEntryExtractorTest incorrect handling of newline leading to windows errors

See: LMCROSSITXSADEPLOY-2755

s-yonkov-yonkov · 2025-09-16T08:45:58Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java

+        public void handleApplicationName() {
+            if (!context.getVariable(Variables.KEEP_ORIGINAL_APP_NAMES_AFTER_DEPLOY)) {
+                getStepLogger().warn(
+                    Variables.KEEP_ORIGINAL_APP_NAMES_AFTER_DEPLOY + " is set to false. The application name will not be updated.");


If KEEP_ORIGINAL_APP_NAMES_AFTER_DEPLOY is false, why The application name will not be updated? I presume that if the original name should not be kept, the app name will be updated?

KEEP_ORIGINAL_APP_NAMES_AFTER_DEPLOY is a flag that determines the use of suffixes during the bg deploy - if true we use the temporary '-idle' suffix, if false we use blue and green colour suffixes and don't rename apps but rotate the names; this check needs to be extended however

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java

s-yonkov-yonkov · 2025-09-16T12:16:30Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java

+
+            String oldName = existingApp.getName();
+            String newName = BlueGreenApplicationNameSuffix.removeSuffix(oldName);
+            if (oldName.equals(newName)) {


when this check will return true?

will double-check - in general if the new app happens to have the same name (not blue-green deploy?)

if it is not the not blue green, will it even reach this condition? Maybe during retry?

CreateOrUpdateAppStep is a very generic step in the deploy app subprocess, so I think this condition will be reached if we're just updating an app's attributes/environment variables.

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java

s-yonkov-yonkov · 2025-09-16T12:19:34Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java

        }

+        @Override
+        public void handleApplicationName() {


Misleading name, except the renaming it is performing ConfigurationSubscription updates

the subscriptionas are downstream from the appName, feel like it's more important

s-yonkov-yonkov · 2025-09-16T12:20:20Z

...-process/src/main/java/org/cloudfoundry/multiapps/controller/process/steps/ScaleAppStep.java

        int currentInstances = 1; // default instances when creating an app
        if (existingApp != null) {
-            currentInstances = client.getApplicationProcess(client.getApplicationGuid(existingApp.getName()))
+            currentInstances = client.getApplicationProcess(client.getApplicationGuid(app.getName()))


why is this updated?

was a bad solution to an issue with the changed app name - now the existingApp is overwritten in the context once the app name is updated

IvanBorislavovDimitrov · 2025-10-01T13:02:12Z

multiapps-controller-api/src/main/resources/mtarest.yaml

            $ref: "#/definitions/Info"
      security:
      - oauth2: []
-  /api/v1/spaces/{spaceGuid}/files:


Do not delete this. Must be checked why always deleted after build

IvanBorislavovDimitrov · 2025-10-01T13:02:24Z

multiapps-controller-api/src/main/resources/mtarest.yaml

    flow: "password"
    scopes: {}
 definitions:
-  AsyncUploadResult:


IvanBorislavovDimitrov · 2025-10-02T08:36:56Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java

                      .shouldKeepExistingEnv() ? UpdateStrategy.MERGE : UpdateStrategy.REPLACE;
        }

+        @Override


Instead of creating a new method and flow, can you create a new ApplicationAttributeUpdater. For example, ApplicationNameApplicationAttributeUpdater and update the application name in handleApplicationAttributes (Update flow)?

Decided on in-between solution - removing the new method but not implementing an ApplicationAttributeUpdater for a specific reason - the attribute updaters are used in a stream but are all dependant on the application name which the new updater would be changing. This makes the order of the attributeUpdaters very important and would be easy to break in the future.

IvanBorislavovDimitrov · 2025-10-02T09:51:46Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java


+        @Override
+        public void handleApplicationName() {
+            boolean processIsBlueGreenWithIdleSuffix = StepsUtil.getAppSuffixDeterminer(context)


maybe rename to isBlueGreenProcessAfterResumePhase or something?

the current name seems more clear since this is only for blueGreen with idle, not with colours

Is this resolved?

IvanBorislavovDimitrov · 2025-10-02T09:52:29Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java

+
+            String oldName = existingApp.getName();
+            String newName = BlueGreenApplicationNameSuffix.removeSuffix(oldName);
+            if (oldName.equals(newName)) {


if it is not the not blue green, will it even reach this condition? Maybe during retry?

...ava/org/cloudfoundry/multiapps/controller/process/steps/RemoveNewApplicationsSuffixStep.java

IvanBorislavovDimitrov · 2025-10-02T11:14:44Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java

+            }
+
+            getStepLogger().info(Messages.RENAMING_APPLICATION_0_TO_1, oldName, newName);
+            client.rename(oldName, newName);


What will happen if the MTA operation fail in the resume phase? I mean if the restart of the rename application (now without suffix fails) and the customer executes a new deployment, will the new process detect the "-live" applications as actually live? Is it possible for the new operation to detect the wrong application as live?

I'm writing this comment because now the renaming is before the restart/restage, which is a potential point of failure.

thsi was tested with a crash at the end of the CreateOrUpdateStep - the retries handled the resume correctly

IvanBorislavovDimitrov · 2025-10-02T11:16:51Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java

+        public void handleApplicationName() {
+        }


If you agree with my other comment this method will not be needed. If you do not, add some comment why there is no implementation here

IvanBorislavovDimitrov · 2025-10-02T11:32:05Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java

+                getStepLogger().info(Messages.THE_DETECTED_APPLICATION_HAS_THE_SAME_NAME_AS_THE_NEW_ONE);
+                return;


Can a rename here make this step non-idempotent? What will happen if the step fails during the update of the configuration entries? Or for example instance get shutdown and it gets re-executed by flowable?

Is this resolved/answered?

haven't tested a failure at the point of updating the subscribers but I assume the behaviour will be unchanged - the rename + update of subscribers were handled in the same step (not this one) before my changes as well

fix unit test for win

s-yonkov-yonkov · 2026-01-05T11:00:02Z

multiapps-controller-api/src/main/resources/mtarest.yaml

-      file_url:
-        type: "string"
-        readOnly: true
  Info:


Revert the changes to this file.

s-yonkov-yonkov · 2026-01-05T11:42:13Z

.../test/java/org/cloudfoundry/multiapps/controller/core/cf/detect/AppSuffixDeterminerTest.java

    static Stream<Arguments> testAppSuffixDeterminer() {
        return Stream.of(
-        //@formatter:off
+            //@formatter:off


Is this still necessary?

no, removed

s-yonkov-yonkov · 2026-01-05T12:02:36Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java


+        @Override
+        public void handleApplicationName() {
+            boolean processIsBlueGreenWithIdleSuffix = StepsUtil.getAppSuffixDeterminer(context)


Is this resolved?

s-yonkov-yonkov · 2026-01-05T12:03:16Z

...src/main/java/org/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateAppStep.java

+                getStepLogger().info(Messages.THE_DETECTED_APPLICATION_HAS_THE_SAME_NAME_AS_THE_NEW_ONE);
+                return;


Is this resolved/answered?

s-yonkov-yonkov · 2026-01-05T14:10:53Z

.../test/java/org/cloudfoundry/multiapps/controller/process/util/ArchiveEntryExtractorTest.java

        String expectedDeploymentDescriptor = new String(getClass().getResourceAsStream("expected-mtad.yaml")
                                                                   .readAllBytes());
-        assertEquals(expectedDeploymentDescriptor, actualDeploymentDescriptor);
+        assertEquals(expectedDeploymentDescriptor.replace("\r", ""), actualDeploymentDescriptor.replace("\r", ""));


This is already added in master, please remove it

s-yonkov-yonkov · 2026-01-05T14:12:34Z

...in/java/org/cloudfoundry/multiapps/controller/web/resources/ApplicationShutdownResource.java


-import jakarta.inject.Inject;
-
 @RestController


Why is this class modified?

it looks like a formatter issue :D

s-yonkov-yonkov · 2026-01-05T14:17:53Z

...g/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateStepWithExistingAppTest.java

    private AppBoundServiceInstanceNamesGetter appServicesGetter;
+    @Mock
+    private ConfigurationSubscriptionService subscriptionService;
+    @Mock(answer = Answers.RETURNS_SELF)


Why is this(answer = Answers.RETURNS_SELF) added?

it's for mocking the configuration subscriptions update in the test - copied from the deleted test for the deleted separate step

s-yonkov-yonkov · 2026-01-05T14:19:08Z

...g/cloudfoundry/multiapps/controller/process/steps/CreateOrUpdateStepWithExistingAppTest.java

        return expectedEnvMap;
    }

+    @Test


this is the straight scenario, how about adding other scenarios, where renaming should not be applied or other?

s-yonkov-yonkov · 2026-01-05T14:21:40Z

Why is this PR made from a fork? Update/sync the fork as it is 41 commits behind master

s-yonkov-yonkov self-requested a review September 12, 2025 08:45

s-yonkov-yonkov reviewed Sep 16, 2025

View reviewed changes

ikasarov force-pushed the remove-idle-new branch from 9749112 to b9b7baa Compare October 1, 2025 13:13

IvanBorislavovDimitrov reviewed Oct 2, 2025

View reviewed changes

ikasarov added 4 commits January 5, 2026 15:38

remove idle suffix from bg deploy

697eea2

fix unit test for win

remove no longer needed RemoveNewApplicationsSuffixStep

a6ae41b

fixing comments

06091ce

removed the handleApplicationName method signature from StepFlowHandler

10c2f79

s-yonkov-yonkov requested changes Jan 5, 2026

View reviewed changes

additional review changes

2fe0804

ikasarov force-pushed the remove-idle-new branch from 3b384a8 to 2fe0804 Compare January 9, 2026 15:02

		getStepLogger().info(Messages.THE_DETECTED_APPLICATION_HAS_THE_SAME_NAME_AS_THE_NEW_ONE);
		return;

remove idle suffix from bg deploy #1697

Are you sure you want to change the base?

remove idle suffix from bg deploy #1697

Conversation

ikasarov commented Sep 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

IvanBorislavovDimitrov Oct 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

s-yonkov-yonkov Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

IvanBorislavovDimitrov Oct 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ikasarov Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

IvanBorislavovDimitrov Oct 2, 2025 •

edited

Loading

s-yonkov-yonkov Sep 16, 2025 •

edited

Loading

IvanBorislavovDimitrov Oct 2, 2025 •

edited

Loading

ikasarov Jan 9, 2026 •

edited

Loading