Hello Geoff, Unfortunately the conference was not recorded, and I was not prepared to do my own recording. The whole event seems to be big in Croatia, but I've found the overall organization and promotion of the event was pretty... lacking. Hopefully it will get better in the future.
The Brooklyn Terraform module is the one started from Cloudsoft, it is open-source so anybody can contribute. I used it because it provided me a way to make the Brooklyn types as generic as possible. The code and configuration for the demo, the presentation as well are in this repository, in case anybody is interested: https://github.com/cloudsoft/java-cro Best Regards, Iuliana Cosmina On Thu, Oct 13, 2022, 15:18 Geoff Macartney <geom...@apache.org> wrote: > 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> >
