k8s-openapi
openzfs
Our great sponsors
k8s-openapi | openzfs | |
---|---|---|
7 | 25 | |
360 | 360 | |
- | 8.1% | |
8.3 | 9.7 | |
12 days ago | 5 days ago | |
Rust | C | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
k8s-openapi
-
WinBtrfs – an open-source btrfs driver for Windows
It's called sans-io in Python land, which is where I heard it first.
https://sans-io.readthedocs.io/
I did it for one of my projects back in 2018 https://github.com/Arnavion/k8s-openapi/commit/9a4fbb718b119...
-
The bane of my existence: Supporting both async and sync code in Rust
Another option is to implement your API in a sans-io form. Since k8s-openapi was mentioned (albeit for a different reason), I'll point out that its API gave you a request value that you could send using whatever sync or async HTTP client you want to use. It also gave you a corresponding function to parse the response, that you would call with the response bytes however you got them from your client.
https://github.com/Arnavion/k8s-openapi/blob/v0.19.0/README....
(Past tense because I removed all the API features from k8s-openapi after that release, for unrelated reasons.)
-
Welcome to Comprehensive Rust
Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. This is because debug builds compile proc macros in debug mode too, so while the macro itself compiles quickly (because it's a debug build), it ends up running slowly (because it's a debug build).
I know this from observing this on a mostly auto-generated crate that had a couple of thousand types with `#[derive(serde::)]` on each. [1]
This doesn't affect most users, because first-party macros like `#[derive(Debug)]` etc are not slow because they're part of rustc and are thus optimized regardless of the profile, and even with third-party macros it is unlikely that they have thousands of invocations. Even if it is* a problem, users can opt in to compiling just the proc macros in release mode. [2]
[1]: https://github.com/Arnavion/k8s-openapi/issues/4
[2]: https://github.com/rust-lang/cargo/issues/5622
-
OpenAPI Generator allows generation of API client libraries from OpenAPI Specs
>OpenAPI Generator allows generation of API client libraries from OpenAPI Specs
It does, but the generated code can be very shitty for some combinations of spec and output language. I maintain Rust bindings for the Kubernetes API server's API, and I chose to write my own code generator instead. The README at https://github.com/Arnavion/k8s-openapi has more details.
-
Any good toy Rust project for k8s application?
k8s_openapi - https://github.com/Arnavion/k8s-openapi
-
Approaches for Chaining Access to Deeply Nested Optional Structs
For example: I have a routine that checks the value of (from k8s-openapi): Ingress -> IngressStatus -> LoadBalancerStatus -> Vec[0] -> String
-
Writing a Kubernetes CRD Controller in Rust
As the maintainer of the Rust bindings that the library used in the article (kube) is backed by, I can confirm that Kubernetes' openapi spec requires a lot of Kubernetes-specific handling to generate a good client than generic openapi generators do not provide.
See https://github.com/Arnavion/k8s-openapi/blob/master/README.m... for a full description.
I also confirm that I keep it up-to-date with Kubernetes releases and have been doing so for the ~3 years that it's been around. Not just the minor ones every few months, but even the point ones; these days the latter usually only involves updating the test cases instead of code changes and they're done within a few hours of the upstream release.
openzfs
-
WinBtrfs – an open-source btrfs driver for Windows
Heads up, installing both WinBTRFS and OpenZFS on Windows may have problems:
"Win OpenZFS driver and WinBtrfs driver dont play well with each other"
https://github.com/openzfsonwindows/openzfs/issues/364
-
OpenZFS 2.2: Block Cloning, Linux Containers, BLAKE3
I tried it a few months ago and ReFS ate my data. No indication of why in event logs or SMART data. It had IsPowerProtected set because I have a UPS and I had a unclean restart, I would expect it to lose data, but not to corrupt the filesystem metadata. I had a backup of the data but wanted some recent changes. Refsutil (the official Microsoft tool) didn't help because it has not been updated for the newest ReFS version. I couldn't read most files because I had integrity enable and files failed the check. Hetman's Data Recovery was able to recover most of the data. In later testing I found out that IsPowerProtected is just very unsafe. I have since put some time into testing and sometimes fixing https://github.com/openzfsonwindows/openzfs , it is not ready for use yet, but it is making great progress.
-
Is there a mount backup vdev Windows tutorial
Windows lacks support in the same sense that Linux lacks support; there are external projects implementing it for both, though I believe the Windows port is less polished. (Some people are running it in production, though...)
-
Windows on Btrfs
This is really cool and speaks to the modularity of the Windows file system stack. I love projects that customize Windows (working against its closed-source nature).
There’s an OpenZFA port to Windows[0]. I wonder if my hopes of having ZFS on Windows (including the boot drive, because I would love to be able to snapshot and rollback) would actually be possible.
[0] https://github.com/openzfsonwindows/openzfs
-
External Harddrive from NAS to Windows?
*cough* it can, but... no idea how well it works but it seems a bit hacky.
-
External Harddrive from Truenas to Windows?
If you have not used it, maybe the native ZFS port for windows could be an easier solution.
-
Problem with a NVMe device: it drops off the bus on intense IO, so I can't scrub or zfs send
Theoretically ZFS is ported to windows, but I heard that it is not really stable yet.
- windows) IO error and suspended
-
ZFS on Windows: Mapping \*nix UID/GID ⇹ Windows UUID?
I did use the packages provided here: https://github.com/openzfsonwindows/openzfs/releases/tag/zfswin-2.1.6rc2
- Anyone using openzfs on Windows on a daily basis? Can ZVOLs be used to back WSL?
What are some alternatives?
kube - Rust Kubernetes client and controller runtime
zfs - OpenZFS on Linux and FreeBSD
fusionauth-openapi - FusionAuth OpenAPI client
ZFSin - OpenZFS on Windows port
go - The Go programming language
btrfs - WinBtrfs - an open-source btrfs driver for Windows
spectrum - OpenAPI Spec SDK and Converter for OpenAPI 3.0 and 2.0 Specs to Postman 2.0 Collections. Example RingCentral spec included.
openzfs - OpenZFS on Linux and FreeBSD, and, macOS. This is where development for macOS happens.
smithy - Smithy is a protocol-agnostic interface definition language and set of tools for generating clients, servers, and documentation for any programming language.
snapper - Manage filesystem snapshots and allow undo of system modifications
tokio - A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
windows-driver-docs - The official Windows Driver Kit documentation sources