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.
Readit NewsJanMa commented on Show HN: Edka – Kubernetes clusters on your own Hetzner account edka.io... · Posted by u/camil
> GitHub is _easily_ the most unreliable SaaS product.
Some of us are stuck using Atlassian and BitBucket and it is by far worse in every way.
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
Even more importantly; were these vulnerabilities responsibly disclosed to the OpenBao project before they were published?*
*Assuming OpenBao has a process in place for this
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.
Yep, I have been just reading that for unrelated reasons before happening on the HN post :)
At $DAYJOB I am currently dealing with rather huge Vault Enterprise install with lots and lots of namespaces.
Honestly my biggest question is how compatible using things like kubernetes operators for Vault with OpenBao instead is - it's my main hosting platform across all projects, so very interested in integration stories there
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
OpenBao’s development seems heavily reliant on a single person, compared to multiple frequent long-term commiters to Vault. Not sure if I’d feel comfortable switching from Vault to OpenBao!
I tried linking directly to contributors for last 12 months, but you still have to select the time range manually from the dropdown :(
OpenBao: https://github.com/openbao/openbao/graphs/contributors?from=...
Vault: https://github.com/hashicorp/vault/graphs/contributors?from=...
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.
Have a look at the contributions for our latest beta release and you'll see that the amount of people involved in the project is growing: https://github.com/openbao/openbao/releases/tag/v2.3.0-beta2...
JanMa commented on Levels of configuration languages beza1e1.tuxen.de/config_l... · Posted by u/kaycebasques
I'm very surprised we don't see more people using a level 5 language to generate Terraform (as level 3 JSON) for this exact reason. It would seem to be the best of both worlds -- use the powerful language to enforce consistency and correctness while still being able to read and diff the simple output to gain understanding. In this hypothetical workflow, Terraform constructs like variables and modules would not be used; they would be replaced by their counterparts in the level 5 language.
https://developer.hashicorp.com/terraform/language/syntax/js...
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.
JanMa commented on The Pain That Is GitHub Actions feldera.com/blog/the-pain... · Posted by u/qianli_cs
In my opinion, unless if you need its ability to figure out when something should rebuild or potentially if you already use it, Make is not the right tool for the job. You should capture your pipeline jobs in scripts or similar, but Make just adds another language for developers to learn on top of everything. Make is not a simple script runner.
I maintained a Javascript project that used Make and it just turned into a mess. We simply changed all of our `make some-job` jobs into `./scripts/some-job.sh` and not only was the code much nicer, less experienced developers were suddenly more comfortable making changes to scripts. We didn't really need Make to figure out when to rebuild anything, all of our tools already had caching.
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.
JanMa commented on The Pain That Is GitHub Actions feldera.com/blog/the-pain... · Posted by u/qianli_cs
Do you have a public example of this? I'd love to see how to do this with Github Actions.
Sure, here's one example: https://github.com/JanMa/nomad-driver-nspawn/blob/master/.gi...
To be fair I used Traefik back when it was still version 1.7 so maybe things have improved by now.