network-policies when using blue/green
When a deployment using blue/green for a number of apps is complete i am often left with missing network policies to describe the routes between apps.
I define multiple policies for an app in one resource and when the app associated with any of the routes are updated then the network policies are removed. Probably because the GUID for the routes they referred to no longer exist.
The network policies are then defined like this.
resource "cloudfoundry_network_policy" "a" {
policy {
source_app = module.a.application.id
destination_app = module.b.application.id
port = "8080"
}
policy {
source_app = module.a.application.id
destination_app = module.c.application.id
port = "8080"
}
policy {
source_app = module.a.application.id
destination_app = module.d.application.id
port = "8080"
}
}
Taking a look into the code I can see that the blue/green strategy applies the route mappings but takes no account for any network policies that might be applied to that app.
It takes the route mappings directly from the app resource definition but does not have a direct link to any network policies as they are independent resources that the route has no direct link to. The deployment is mostly done by the standard provider and it does not need to know about the network policies for things to work correctly.
Im struggling to find the right approach to fix this issue.
- Do it in the blue/green provider
- Re-apply all network policies as part of the deploy
- Do we do all policies for every app? Seems a bit messy...
- This might induce downtime for an app..
- Figure out what network policies exist for an app and re-apply them in the bg/provider after the standard provider has deployed the new version.
- Will this mean downtime if the policies don't exist?
- Re-apply all network policies as part of the deploy
- Do it in the standard provider
- figure out what policies are relevant to a specific route in the blue/green provider and pass them into the standard provider for it to apply.
- adds a lot of logic to the standard provider that it currently doesn't have to care about...
- figure out what policies are relevant to a specific route in the blue/green provider and pass them into the standard provider for it to apply.
Is this a design flaw in the resources? Should the network policies be a property of a route?
Happy to take a go at fixing this myself with some guidance.
@ArthurHlt @gberche-orange
@ScottGuymer should you not be using id_bg if your apps are using blue/green?
thanks for your thoughts @ScottGuymer . id_bg could be used here yes @dwaynebailey but it is applied when the previous app which already have policies has been deleted before the new app get policies. The time should be short before re-applying the policy but some user will experiment some turbulence during this few seconds.
We actually need to work on v3 api and use the native zero downtime in cloud foundry v3, maybe it will be enough for you @ScottGuymer as it is more native and without new app creation involve ?
I was not aware of this provider feature. I did not read all the way to the bottom of the documentation.
I have now tried the id_bg and i think it fills the gap for us for the moment. We can deal with some small issues on deploys for now. But a true 0 down time would be great.
I also think it would be good to edit the docs to indicate that the id_bg features exists when using blue/green
That was actually already documented: https://registry.terraform.io/providers/cloudfoundry-community/cloudfoundry/latest/docs/resources/app#update-resource-using-blue-green-app-id
I let it open as a reminder to have a true zero-downtime for network policy. Thanks for your feedbacks @ScottGuymer
Yeah it is there but its quite easy to miss (like I did)
I think we shoud put a reference to it here https://registry.terraform.io/providers/cloudfoundry-community/cloudfoundry/latest/docs/resources/app#application-deployment-strategy-blue-green-deploy
where the blue green strategy is mentioned.
Hi, any updates on this issue? Because it's very annoying when we update application to new version and network-policy disappears. Thanks
@AndrewPentsak this should be addressed in the ongoing work on migrating to the v3 API, it's still in WIP for now.