I've learned the hard way that CPU resource limits in K8S are a bad idea, as can be seen in this post. Just use CPU requests without limits so the scheduler has an estimate of your applications CPU requirements, but it can burst to use more CPU when it's available.
With memory of course you should set a limit and from experience it should be the same as your memory requests.
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.
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.
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.
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.
Whenever possible I now just use GitHub actions as a thin wrapper around a Makefile and this has improved my experience with it a lot. The Makefile takes care of installing all necessary dependencies and runs the relevant build/Test commands. This also enables me to test that stuff locally again without the long feedback loop mentioned in other comments in this thread.
I bought my first Motorola phone in 2013 and am a happy user ever since. I usually buy the current Moto G model for less than 200€ and get a solid 3-4 years of use of it. Of course you can't expect the performance of these phones to be comparable to high end models, but for my use case they are perfectly fine. Also if you drop a sub 200€ smartphone, you don't get a mini heart attack like when you drop a 1000€ iPhone :-)
There's a lot of tools you could use for this (I'd personally recommend OpenBao), but in my opinion proper SSO, permission and group management is way more important.
If you make an effort to define granular groups for every team, and role you have in your company it makes the management of access to resources (and not only secrets) a lot easier.
In the example you describe, the newly promoted hire would automatically be added to new groups which will have the right to access the needed Secrets. Similarly, whenever a person leaves your company, simply remove them from the groups they are in and they (almost) immediately loose all access.
It's not a small feat to built, maintain and reconfigure all your tools to use it, but if you do it really pays dividends
That’s also what works best for me! A single monitor and only one window on fullscreen. When I need to switch applications, I navigate to another fullscreen window. Sometimes I like to joke that my brain is single threaded :-)
On behalf of the OpenBao TSC and Development Working Group, I'm happy to announce the 2.0.0 Beta release is available now!
Major improvements include:
- Fixing compatibility with existing upstream plugins.
- Fixing migration from upstream 1.14.0 release w.r.t. SSCT token support.
- Alternative release pipeline and improvements for release distribution.
Many thanks to the community for making this release possible and all the contributions!
The GA release is currently slated for release four weeks from now on July 16th, 2024. Prior to this, the focus will be on stability of the GA release. Feel free to open issues or discussions on GitHub: https://github.com/openbao/openbao/
With memory of course you should set a limit and from experience it should be the same as your memory requests.