@worldofgeese it's not exactly the same. Katenary creates a helm chart with several values that you can change, it also creates init containers to wait services and I'm currently developing the dependency management.
There a many bugs I fixed.
Next release will be fully documented and production ready. The company where I work is testing it a lot.

@worldofgeese short answer is "katenary does more things" but kompose is a good tool. Not made for the same goal. Kompose builds an asset to deploy, katenary creates a distributable chart.

@metal3d first time I've heard of it but I think I'll take it for a test drive for an article I wrote (and will re-write) on migrating from Compose to K8s!

@worldofgeese I don't communicate a lot for now because I'm fixing many things following issues reported by my teammates. I think that a new release will be done before the end of the week 😉

@metal3d please let me know! I'll be excited to give it a go.

@metal3d you can see the article I wrote for garden.io on migrating from Compose to K8s at https://garden.io/blog/migrating-docker-compose-to-kubernetes. If you see anything that jumps out to you that katenary would have done better than kompose feel free to reach out :-)

@worldofgeese I read when I've got time, but actually yes, there are some points that I don't agree 🙂 E.g. "You'll never scale past one machine because Compose is single node only." => Compose allow the use of Swarm for example

@worldofgeese And to answer the question, when you create your helm chart by changing values, variables, and so on... Katenary does it automatically. Actually, what you did in the article takes a few seconds with Katenary.

@metal3d this part is true yes, I will add a disclaimer that when using Compose in swarm mode, you can scale, thanks!

@metal3d I removed the statement that Compose is single node completely, cleaned up and clarified the sections, and put each section under clear headings with more headings added to help break up the article a bit.

@worldofgeese ok. There are others things that you could do to enhance the article. For example using init containers, docker entry points, and not using the default NS. But it's OK.

@metal3d init containers to replace the kubectl exec commands, right? If so, both the init containers and the namespaces will be taken care of in part 2 where I use Garden Tasks to handle early start executions and Garden's automatic namespace creation.

Can you explain what I could have improved specifically with entrypoints? Love the critique, thanks!