I don't think it's a niche hobby, but I really enjoy cooking. Trying out new techniques and receipts, cooking dinner for friends and family or just preparing a delicious meal in advance.
Congratulations on the 10 year anniversary. Having used Traefik for multiple years in a large Micro-Service Setup (200+ services) I must say I have made mixed experiences. If your requirements match the very opinionated way Traefik does things then it's great. But as soon as they don't you're going to have a hard time getting things to work. That's why shortly after migrating to Traefik I started to maintain an internal fork to add support for unique request ID headers which I maintained for two years until we migrated to HaProxy. The GitHub issue I opened for this in 2019 is still open.
To be fair I used Traefik back when it was still version 1.7 so maybe things have improved by now.
A bit off topic, but you might want to rethink the name. It is very close to EDEKA, the largest German supermarket chain. They have a very large IT division (https://it.edeka) and judging from the name of your project I was expecting it to be one of their projects.
Well, I had this since 2011, and in 2018 a new disease was labeled EDKA ( that is the first result you get when you google for edka). I became aware about the german supermarket few years after also. I could consider it at some point, but is very hard to find something available these days...
I used to maintain a self hosted instance of BitBucket and the user experience of it was actually very nice. We shut it down when Atlassian deprecated the self-hosted licenses. Moving to GitHub and GitHub Actions felt like a downgrade in more than a few ways
This does affect OpenBao as well. We do have a process in place for responsible disclosure but unfortunately we were not informed about those issues before they were published.
Thank you for being communicative about this and for the great work you're doing on OpenBao
I'm very disappointed to hear that the researchers didn't do their due diligence and informed the OpenBao project about this issue before publishing
I imagine this is a stressful situation for everyone involved in the project, so I hope the researchers will do some reflections on how they can avoid this situation happening in the future
We've made an effort to keep API compatibility with Vault wherever possible, also with the new namespaces implementation. Most of the tooling which works with Vault today will also work with OpenBao
It is true that most of the commits in the last 12 months were made by cipherboy, but I can assure you that the project is not a one man show. Building a community and getting traction on a project is hard work and takes time.
The organization has been slowly building trust in more committers and maintainers and so he's had to personally review many a pull request of mine in the interim. :-D
Note to clarify: I wasn’t intending to disparage the project with my original comment! I appreciate that these things take time and a lot of hard work. Just wanted to share an observation, in the knowledge that it may not hold true indefinitely :)
That actually works quite well. I once built a templating engine for Terraform files based on JQ that reads in higher level Yaml definitions of the resources that should be created and outputs valid Terraform Json config. The main reason back then was that you couldn't dynamically create Terraform provider definitions in Terraform itself.
Later on I migrated the solution to Terramate which made it a lot more maintainable because you write HCL to template Terraform config instead of JQ filters.
Make is definitely just my personal preference. If using bash scripts, Just, Taskfile or something similar works better for you then by all means use it.
The main argument I wanted to make is that it works very well to just use GitHub actions to execute your tool of choice.
reply