on 2021 Jan 06 3:58 PM
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:
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.
Try removing the "requires: scaler" lines from your modules.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
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
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:
Your second reason can maybe challenged in your team to take it with the release?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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:
User | Count |
---|---|
81 | |
11 | |
10 | |
10 | |
10 | |
8 | |
8 | |
7 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.