Hi Iuliana, Thanks for the update, this sounds marvellous. Was your presentation recorded? I would love to watch it.
Just for clarity, by "the brooklyn-terraform module" I assume you mean Cloudsoft's repo of that name [1]. Of course, since this is open and Apache 2.0 licensed, anyone can contribute to it! Best regards Geoff [1] https://github.com/cloudsoft/brooklyn-terraform On Wed, 12 Oct 2022 at 10:52, Iuliana Cosmina <iuliana.cosm...@gmail.com> wrote: > > Hi team, > > This week I participated in a Java conference ( > https://2022autumn.javacro.hr/eng) and I demonstrated how Apache Brooklyn > can be used to develop applications for the cloud locally, that get > deployed to little or no change to a cloud provider. I used the > brooklyn-terraform module to deploy a three tier application to a > local Kubernetes cluster and then migrate it to EKS. > > Here are a few things a few things that we must/should do that I figured > out while preparing the demo and presenting at #javacro2022: > > 1. When we have a frontend (or anything really) depending on a cluster that > exposes some sensors the frontend needs, deleting the app causes the > dependent component to hang, because the cluster is deleted first. Not sure > if this is caused by the fact that the cluster is a software component, or > maybe we have a race condition between deleting tasks. I can reproduce it > easily, so this is a bug that we can and we should fix. > 2. We need to add custom terraform types: dbs, servers, for most used > cloud providers etc. > 3. All terraform entities under the same parent - when deployed on > Kubernetes - should be deployed under the same namespace - it helps with > cleaning. Also.. maybe in the case of an application that had only > terraform entities deployed on the same Kubernetes cluster as children, a > successful deletion of the namespace should suffice and Apache Brooklyn > should back off instead of trying to delete the entities itself and failing > to do so. We could use the power of Kubernetes when possible. > 4. At this conference there were a lot of young people just dipping their > toes in cloud development and they are interested in Apache Brooklyn for > its ability to help them get used to working on the cloud without an actual > cloud. Maybe a collaboration with Universities for workshops should be > considered. Also we could use some fresh eyes on Brooklyn to get some > feedback, use them as a testing resource and a source of ideas for things > missing in Apache Brooklyn. > 5. When terraform deploys over an unstable network, the application deploy > fails in Brooklyn. Is there anything we can do about this? Maybe a retry? > 6. One observation from a fellow speaker is that in order to get things > done, we need to write a lot of YAML. I don't particularly disagree, nor > have any idea how to fix it, unless we consider trying to enrich our > catalog with out of the box types for most recent technologies. > > That is pretty much it, if anything else comes to mind, I'll make another > list and continue this email thread. > > Observation: You might ask why I used Apache Brooklyn to drive a Terraform > deployment on a Kubernetes cluster? Because it provided me the opportunity > to try to create a CAMP blueprint agnostic towards where it got deployed. > > -- > > Best regards, > Iuliana Cosmina > > <http://rpx.kicks-ass.net>
