Arnavion/libjass 166
Renders ASS subs in the browser.
Rust bindings for the Kubernetes client API
An example of an out-of-process crash dumper
Arnavion/derive-error-chain 20
A Macros 1.1 implementation of https://crates.io/crates/error-chain
PowerShell provider for FTP sites
Temperature and fan controller for Thinkpads on Linux
Arnavion/winapi-tlb-bindgen 13
Generates Rust bindings to COM interfaces, enums and coclasses.
Arnavion/pfsense-dashboard-cli 8
The pfSense dashboard in your terminal instead of a web browser
A mod manager for Factorio.
Pure Rust implementation of a D-Bus client
issue commentArnavion/k8s-openapi
Extra operations on data types?
I don't follow what setters and builders would allow you to do that setting the fields directly does not.
They would allow writing this:
let pod_spec = PodSpec::default()
.set_restart_policy("Always")
.append_container(get_default_node_js_container_spec())
.override_with(overrides.generic_pod_overrides)
.override_with(overrides.node_js_pod_overrides);
and similar for any arbitrary resource type.
comment created time in 7 hours
issue commentArnavion/k8s-openapi
Extra operations on data types?
@Arnavion Oh, I realize they are pub. But unfortunately that doesn't make them very ergonomic. Which is not the end of the world, but is making them inconvenient to work with directly.
comment created time in 12 hours
issue openedArnavion/k8s-openapi
Extra operations on data types?
I'm [researching implementing a kind-of-helm-replacement] that would generate input for kubectl apply -f - be just executing Rust source code. In such tool I would like to reuse types generates by k8s-openapi to define all the resources. In that respect the Rust code would become somewhat of a semi-DSL.
However, the usability of the types generated by k8s-openapi is not great, since they are very bare: just the type definition. Ideally I wish they supported builder pattern and maybe things like fn override_with(&self, other: &Self) -> Self for helm-like value shadowing where useful.
To make an example of what I have in mind:
let pod_spec = PodSpec::default()
.set_restart_policy("Always")
.append_container(get_default_node_js_container_spec())
.override_with(overrides.generic_pod_overrides)
.override_with(overrides.node_js_pod_overrides);
Would that be something that could be part of this crate? Potentially behind a feature flags for all the users that don't need it?
created time in a day
startedArnavion/tpfancontrol-rs
started time in 7 days
issue openedArnavion/k8s-openapi
3rd party API Generation with k8s-api-codegen?
I have a need to generate and deploy Argo workflows in Rust. There is a full swagger 2 spec for the Argo workflows here: https://github.com/argoproj/argo/blob/master/api/openapi-spec/swagger.json
Is it a fool's errand to try to use k8s-openapi-codegen on this? If so, is there another approach you'd recommend?
Thanks.
created time in 14 days
startedArnavion/k8s-openapi
started time in 22 days
startedArnavion/k8s-openapi
started time in 23 days
startedArnavion/k8s-openapi
started time in a month
startedArnavion/k8s-openapi
started time in a month
startedArnavion/k8s-openapi
started time in a month
startedArnavion/k8s-openapi
started time in a month
startedArnavion/k8s-openapi
started time in a month
startedArnavion/k8s-openapi
started time in a month
startedArnavion/k8s-openapi
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
issue openedArnavion/k8s-openapi
Hi,
I'm testing some Kubernetes 1.19 features like Ingress as part of the network v1 API.
Can we release these changes?
Thanks 🙏
created time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
issue openedArnavion/k8s-openapi
k8s-openapi compiles very slowly. That isn't really a dig on it, it's just a big crate.
But it would be nice if we could opt in to which APIs are actually relevant.
I figure a decent first approximation would be to have a cargo feature per apiVersion, which are already used for module separation anyway.
created time in 2 months
startedArnavion/pfsense-dashboard-cli
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months
startedArnavion/k8s-openapi
started time in 2 months