Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: refactor grpc gen and project structure #344

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

aryan9600
Copy link
Member

introduce a new crate lib/backends that contains the protobuf files along with the corresponding rust bindings. this allows flexible usage by both the dataplane and controlplane crates.

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Jan 23, 2025
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aryan9600

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 23, 2025
Copy link
Member

@shaneutt shaneutt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking great! A few comments, the main one being about where this lives long term.

@@ -0,0 +1,14 @@
[package]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling a crate lib is not super common in my experience. You don't find it mentioned in the standard cargo package layout, and some of our neighbor Rust projects which use workspaces like Kube-rs, Aya and Bpfman don't tend to do this.

I'm in favor of putting this under dataplane/api-server-client because I think that provides reasonable clarity about what it is, but also calling it client rather than backends leaves the door open if there ends up being more API surface we want to expose there in the future.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i took the idea from vector. i'm a bit apprehensive about putting it in the dataplane folder because the proto API is a contract between the controlplane and the dataplane.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because the proto API is a contract between the controlplane and the dataplane

The way I was kinda looking at it was that it was more a contract between the data-plane and any control-plane that wanted to drive it, if that makes sense? We have an xtask client that uses it in fact for testing... I'm suggestible here, but if you're feeling strongly would a good compromise here be to put it at the root, but just call it dataplane-client or something like that?

Copy link
Member Author

@aryan9600 aryan9600 Jan 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but just call it dataplane-client or something like that?

are you talking about the xtask grpc client here? i think that's fine where it is.

contract between the data-plane and any control-plane that wanted to drive it

i do kinda agree, but i just think its more intuitive to place it in the root of project. this makes it clear the language that both the controlplane and dataplane are speaking. i also think we might be overthinking a tad bit here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are you talking about the xtask grpc client here? i think that's fine where it is.

No, sorry I wasn't talking about that 🤔

i also think we might be overthinking a tad bit here.

With respect I disagree. Being deliberate about how you name things (and scope crates) while subtle at first, can over the lifespan of a project start having less subtle impacts and is worth a little time up front.

Moreover, building consensus with your colleagues and making sure we remain integrated in our actions on the project, however small they may feel to us individually, is worth more than any software that could be written.

i do kinda agree, but i just think its more intuitive to place it in the root of project. this makes it clear the language that both the controlplane and dataplane are speaking.

I might have misspoke: I'm in favor of putting it in the root so we might be partially on the same page here. I'm saying put it in the root, but with a more descriptive crate name that makes it clear that it's focused on the client and isn't a place for arbitrary utilities. I'm kinda open to what that is, suffice to say I'm not in favor of lib because I think that says "come put stuff here" and I'm kinda partial to dataplane-client because it says "this is only for the dataplane client code".

introduce a new crate `lib/backends` that contains the protobuf files
along with the corresponding rust bindings. this allows flexible usage
by both the dataplane and controlplane crates.

Signed-off-by: Sanskar Jaiswal <[email protected]>
Copy link
Member

@shaneutt shaneutt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want, probably fair to add some docs that say we accommodate Mac development now (and maybe a note or two about the differences from Linux).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
Status: Review
Development

Successfully merging this pull request may close these issues.

3 participants