Formalize the ability of a deployer to modify its resources

[dsyer]

We may need to formalize or otherwise bless the ability of a deployer to mutate its apps. Platforms allow that, and indeed it might be awkward to implement a sensible deployer for some platforms without the ability to modify existing apps. For instance, in Cloud Foundry, it is perfectly normal to push new version of an app without first deleting the old one. The existing API sort of allows you to implement deploy() as you wish, but the javadocs imply that you should throw an exception if the app is already deployed. There are going to be complications in the implementation because of race conditions if isn't allowed to work with the underlying platform. For instance, the mapped routes in Cloud Foundry are a headache (do you delete them when you delete an app or not - if you do then there is a race condition where someone else might claim the route in between deleting it and pushing the new app?). Ditto the app name (within a space), if two people are trying to create it at the same time. Also, at the end of the day, deleting an app and re-pushing it is a violent thing to do, and requires messy, error-prone code to poll for the state of the app in between, whereas the platform is quite happy to add env vars or update the bytes for you non-destructively

[markfisher]

should this be an added update() method?... perhaps with an AppUpdateRequest instead of the AppDeploymentRequest that is expected by deploy()

[dsyer]

Yeah, maybe. I think I'm going to stop using the AppDeployer until it supports this fetaure anyway.

[markfisher]

Our goal with the deployer project is for it to be a common library for anyone needing to deploy applications (especially boot applications) across multiple platforms via a common abstraction. That's the reason we extracted this from Spring Cloud Data Flow. The first milestone was completely driven by making this work as a dependency of the Data Flow Servers, and so the current features represent the bare minimum we needed to make that work. That said, we hope that it can evolve into something more broadly useful. Your feature requirement is a perfect example. So, please consider contributing to spring-cloud-deployer and/or the various implementations so we can extend the reach and share the enhancements (even spring-cloud-dataflow has update requirements on its roadmap, e.g. scaling the number of instances of a deployed application as well as rolling upgrades).