Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blue-green strategy does not keep existing service bindings #74

Open
calle2010 opened this issue Dec 8, 2022 · 3 comments
Open

blue-green strategy does not keep existing service bindings #74

calle2010 opened this issue Dec 8, 2022 · 3 comments

Comments

@calle2010
Copy link

Hello,

I tried blue-green deployment strategy with

modules:
  - name: myName
    parameters:
      keep-existing:
        service-bindings: true

but service bindings were not transferred to the new "-idle" instance of the app.

When I try the same without "blue-green" strategy the existing, manually created service bindings are unbound and rebound as expected.

@boyan-velinov
Copy link
Contributor

Hello,

It is expected that keep-existing service-bindings to not work in blue-green deployment.
It is because that blue-green creates new app versions with new bindings to each service instance.

Keep-exisitng bings makes sense and it is designed for standard deployment where one app has bindings to services inside and outside of the MTA, and these bindings are not touched at all.

Best Regards,
Boyan

@calle2010
Copy link
Author

Hello Boyan, thanks for your reply.
I have to say that I'm not convinced about this design decision:

a) The purpose of blue-green deployment with idle start is to be able to test a complete environment. Without the manually bound services the environment is not complete; hence testing is not possible.

b) When I do blue-green deployment with --skip-idle-start my expectation is a zero-downtime deployment. But with manually bound services I find myself in a situation with a broken system. This goes against the principle of least surprise.

c) During standard deployment, the manually created service bindings are also removed and added again to the application, so the deployer is technically aware of them. This means there can't be a technical problem.

d) Existing documentation doesn't mention such a limitation. In fact it warns "Live and idle applications are bound to the same service instances."

@calle2010
Copy link
Author

According to "whats new" for "Multitarget Applications for Cloud Foundry" September 7, 2023:

"You can now preserve app environment after blue-green deployment with MTA Module parameter keep-existing and its option env. For more information see CF-MTA-ExamplesInformation published on non-SAP site."

This means environment variables are now preserved, but service bindings aren't. I think that is inconsistent and should be extended to manual service bindings, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants