Keep Existing Autoscaler Configuration on MTA Redeploy

[bmcdonn2]

Hello everyone,

Curious if anyone has experience with the using the MTA option to keep existing service bindings. This example details what I'm talking about: Keeping existing CF app service bindings during update

This is a stripped-down version of our MTA with those concepts applied:

ID: backend
_schema-version: '3.1'
version: 1.0.0
parameters:
  enable-parallel-deployments: true
modules:
  - name: backend-v
    type: java
    parameters: 
      keep-existing:
        service-bindings: true
      disk-quota: 512M
    requires:
      - name: scaler   
  - name: backend-c
    type: java
    parameters: 
      keep-existing:
        service-bindings: true
      disk-quota: 2048M
    requires:
      - name: scaler
resources:
  - name: scaler
    type: org.cloudfoundry.existing-service

Our main goal is to make sure that the configuration of the scaling service (named scaler in this example) is maintained for applications backend-v and backend-c after fresh deployments. Unfortunately, what we're finding is that it is lost on each new deployment.

Here's an example of what we see on deployments of the MTA. You can see that the scaling service is unbound from apps backend-c and backend-v before being re-bound later. It is this action of unbinding/rebinding that causes the scaling configuration to be lost.

We've explored alternative options like trying to provide the service configuration during original binding (as outlined here: Create and Bind Scaling Service Instance) but that is suboptimal for two reasons:

1. We have different scaling configurations for different environments meaning this approach will greatly increase complexity of our deployments introducing the need for mta extension files
2. Our environment specific configurations often change as our application usage changes outside of our normal release cadence so we'd either need to capture those constant changes in our deployment configuration or risk them being overwritten by older configuration.

If anyone can provide any insight on this it is greatly appreciated.

Thanks,

Brian

**Update**

After reviewing some of the initial answers on this question I think the specific issue here might be with the autoscaler service itself rather than the mechanisms of the MTA. This might explain why the options available in the MTA parameters are insufficient to maintain the scaling configuration. In any case, I wanted to update this question to reflect this fact so I updated the title.

[sergei-u-niq]

Try removing the "requires: scaler" lines from your modules.

[bmcdonn2]

Sergei,

Thanks for the suggestion. I tried your method and it similarly re-initialized the scaler configuration.

Other things I've tried that were not successful in maintaining the scaling configuration after redeployment:

• Change the resource to type org.cloudfoundry.existing-service and include parameters to skip-service-updates
• Manually rebind the service to the applications including the scaling configuration during binding and removing all references to the scaler in the MTA

Not sure what other options remain other than working through environment specific configuration files and mta extensions. Thinking it might actually be easier to add a post-deployment hook to call the CF cli to rebind the applications with the given configuration rather than work through the mta itself.

Thanks,

Brian

[WouterLemaire]

Like you already mentioned, you can add it to the mta config. But there might be a way to get around your first reason to not do this. You can use mtaext files to configure the service for different environments:

https://help.sap.com/viewer/4505d0bdaf4948449b7f7379d24d0f0d/2.0.02/en-US/51ac525c78244282919029d8f5...

Your second reason can maybe challenged in your team to take it with the release?

[bmcdonn2]

Wouter,

Thanks for the response.

We actually already make use of mtaext files to maintain different sets of environment variables for each target environment but the specific difficulty we're having in this case is a desire to define the scaling config in different environment specific json files and then referencing those in the mtaext. Because the applications we want to scale are java applications, it isn't clear how we can ensure those json files can be included in the resulting mtar such that the mtaext will be able to establish the link during mta deployment.

It's this introduction of complexity that has us really trying to understand the keep-existing service-bindings parameter in the MTA. If it would satisfy our needs but we are just not using it correctly then a correct application would solve our problem. If the parameter was not designed to handle this situation then we have no choice but to use mtaext, we're just hoping to avoid that situation.

Thanks,

Brian

[WouterLemaire]

I guess keep-existing means that it does not create or update the service but will always unbind an rebind again. At least that’s what I understand from the documentation:

https://help.sap.com/viewer/4505d0bdaf4948449b7f7379d24d0f0d/2.0.03/en-US/4050fee4c469498ebc31b10f2a...