The parameters named "out" here are not "output parameters" in the way you seem to be thinking. They are "input parameters" named "out", because they are the buffer or pipe you want the data written to.
84 karma · joined October 19, 2016
ahmed.taahir@gmail
Yes (perhaps not etcd, but the combination of kube-apiserver and etcd)
Substrate does not use CRDs for anything on the hot path of actor scheduling or resumption.
This is going to be decomposed. I believe the plan is to offer resumption with disk state only as well (and the RAM snapshots will need to be discarded from time to time, if you update the underlying code of the agent, or switch CPU types).
By the way, the RAM snapshots are not kept in RAM, they are serialized to disk, or uploaded to object storage.
* More efficient usage of compute by timeslicing agents (Substrate Actors), which requires fast suspend and resume (using gVisor or cloud-hypervisor snapshots), as well as keeping the K8s control plane out of the critical path (so agents can't be stored as resources in the K8s database).
* Deep inspection of outgoing requests using an egress gateway
* Minimizing the exposure of credentials to unpredictable agent control (so they can't upload access tokens to pastebin).
Achieving those goals ultimately required a significantly different design from Agent Sandbox.
(This is work in flight, but it will land within a few weeks)
If you sell them immediately, then you don't pay any additional capital gains tax, because there were no capital gains from the moment you got them to the moment you sold them.
If you hold on to them, you will eventually pay capital gains on any increase in value from the moment they vested until the moment you sell them.
Perhaps, once they are vested, you could take loans against them, to get some cash while avoiding selling them.
But no matter what, they are taxed at the moment you receive them, and again at the moment they leave your possession.
In practice, it is easy to pick out the situations in which there is "practical" universal jurisdiction, vs "theoretical" universal jurisdiction.
A Colorado company selling locally in Colorado falls in the "theoretical" bucket.
(This is basically how Let's Encrypt / ACME accounts work)
Kubernetes is such a huge project that there are few reviewers who would feel comfortable signing off an an arbitrary PR in a part of the codebase they are not very familiar with.
It's more like Linux, where you need to find the working group (Kubernetes SIG) who would be a good sponsor for a patch, and they can then assign a good reviewer.
(This is true even if you work for Google or Red Hat)
* https://github.com/grpc/grpc-java/blob/master/documentation/...
* https://grpc.io/docs/guides/reflection/
You can then use generic tools like grpc_cli or grpcurl to list available services and methods, and call them.
Take a look at https://github.com/kubernetes/enhancements/tree/master/keps/..., which is hopefully landing as alpha in Kubernetes 1.34. It lets you run a controller that issues certificates, and the certificates get automatically plumbed down into pod filesystems, and refresh is handled automatically.
Together with ClusterTrustBundles (KEP 3257), these are all the pieces that are needed for someone to put together a controller that distributes certificates and trust anchors to every pod in the cluster.
> If the Pool holds the only reference when this happens, the item might be deallocated.
Conceptually, the pool is holding a weak pointer to the items inside it. The GC is free to clean them up if it wants to, when it gets triggered.
I think you need to flip a flag on the cluster object to enable the Gateway controller.
If you salt and hash the password on the client side, how is the server going to verify the password. Everything I can think of either requires the server to store the plaintext password (bad) or basically makes the hashed bytes become the plaintext password (pointless).
There are password-based solutions that work like this --- PAKEs like Secure Remote Passwords: https://www.ietf.org/rfc/rfc2945.txt
They have low uptake because they don't really offer any security beyond just sending the plaintext password over a properly-functioning TLS channel.
Obviously, though, if you almost hit a pedestrian then you aren't properly yielding.
My impression is that Anthos is probably not what you need if your use case is deployment of a managed product into customer GCP projects (or AWS accounts).
Instead, copy the P4SA architecture that GCP uses for managing its own services in your project. Create one service account per customer, and have the customer grant that service account whatever permissions your control plane needs to manage the resources deployed into the customer project.
You can package those permissions into a Role for easier use.
You can see how this works by looking at Google's existing P4SA permissions in one of your cloud projects. They show up in your cloud IAM console if you remove the filter for "Google-Managed Grants".
The GKE equivalent of EKS IRSA is GKE Workload Identity.
It's pretty much the same user experience:
* Enable Workload Identity on your cluster
* Create a GCP service account
* Grant your Kubernetes service account permission to act as the GCP service account.
It's a bit more seamless because you don't need to upgrade your client libraries. Instead there is an on-node metadata server that provides access tokens to workloads.
Disclosure: I work on this