JanMa

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

Yes this does affect OpenBao as well. We're actively working on getting a fix out as soon as possible

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.

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...

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.

Sure, here's one example: https://github.com/JanMa/nomad-driver-nspawn/blob/master/.gi...

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 :-)

Happy to hear you like the project :-)

It doesn't. The usual approach is to create new nodes with the updated OS, migrate all workloads over and then throw away the old ones

Dear friend, you should first look into using Nomad or Kamal deploy instead of K8S

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/

We had some discussions about this before removing all storage plugins except Raft, In-Memory and File storage as cipherboy pointed out in the sibling comment. If you're currently not using Raft, this should not stop you from adopting OpenBao if you first migrate to the Raft storage backend. Hashicorp has a tutorial on this which you can follow:

https://developer.hashicorp.com/vault/tutorials/raft/raft-mi...

I've personally used the Raft storage backend in production for some years and can assure you it is rock solid.

This might be a bad direct translation from the German saying "ungeteilte Aufmerksamkeit" which can also be translated as "undivided attention"

Both actually. How did they do it physically and what did they run on the phones? I found it especially interesting that 20% of the devices had to act as master or networking nodes

Does anyone have an idea how they built the cloudlets? I find the concept very fascinating but I don't have any idea how one would go about building such a large cluster of old phones

Keybase also has support for hosting Git repos: https://book.keybase.io/git

I often noticed this as well. After reading the article I wonder: Would it be feasible to write a kubernetes-shim for systemd to reduce the overlap instead of reinventing everything? This would not fix any of the valid criticism the author has of systemd but instead make it do even more things. Nevertheless I somehow find the idea very intriguing

Oh nice, that's really cool. I am pretty sure last time I checked this was not the case (~2 years ago)

How does this setup handle a maintenance of the underlying hypervisor host? As far as I know the VM will be migrated to a new hypervisor and all data on the local SSDs is lost. Can the custom RAID0 array of local SSDs handle this or does it have to be manually rebuilt on every maintenance?

Why does everyone keep thinking developers need to now about K8S? Just be glad if your infra/DevOps/platform teams abstract this away from you and you don't have to deal with this insanity.

It's a terrible, smelly, health-destroying habit, and I was right to give it up, but I think I'll always be a smoker at heart.

It's incredible how much I can relate to this. I finally managed to quit smoking after multiple attempts but I would still say I will always be a smoker at heart. I loved smoking and probably always will.