Skip to content

move cockroach-admin-client NodeId to cockroach-admin-types #8865

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

Conversation

sunshowers
Copy link
Contributor

Currently, the OpenAPI manager has a circular dependency with cockroach-admin-client and cockroach-admin-api, making it hard to make changes to the API that need to happen before the client is updated. The only dependency is NodeId, though, which can be moved to this more central location.

Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
@sunshowers sunshowers requested a review from davepacheco August 22, 2025 22:09
Copy link
Collaborator

@davepacheco davepacheco left a comment

Choose a reason for hiding this comment

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

Thanks!

Is this something that the ls-apis tool could look for?

@sunshowers
Copy link
Contributor Author

@davepacheco by "this" do you mean these kinds of circular deps? Yeah probably I think.

@sunshowers sunshowers enabled auto-merge (squash) August 22, 2025 22:52
@davepacheco
Copy link
Collaborator

Yeah. What exactly is the condition? The client crate -> API crate dependency is implicit, so if the API crate somehow depends on the client crate for real, that's the problem? It's not just an API depending on its own client...but it's also not just any API crate depending on any client crate (because I think we have that successfully and it works out as long as it's in the right direction down the API DAG).

@sunshowers
Copy link
Contributor Author

I think it would be any openapi-manager-managed API crate depending on any openapi-manager-managed API's corresponding client crate, right? Otherwise you'll run into the issue described here where you can't generate the API until the client compiles properly.

I could very well be missing something though.

@davepacheco
Copy link
Collaborator

davepacheco commented Aug 22, 2025

The cases I was thinking of were that:

  • Nexus internal API exposes types that (used to?) come from the DNS client.
  • Bootstrap agent API exposes types that (used to?) come from the sled agent client

I just checked and these both use the "-types" crate rather than the "-client" crate. Is that somehow okay?

I'm trying to resolve this with the fact that while working on stuff I'm pretty sure I've had to run cargo xtask openapi generate to generate a new spec, which alone caused another thing to need updating with cargo xtask openapi generate. This was admittedly several months ago and I could also be misremembering.

@sunshowers
Copy link
Contributor Author

sunshowers commented Aug 23, 2025

Yeah using the types crate is okay (this change does that). The types crate is meant to be shared by the client and API in this fashion.

It's possible that not everything obeys this today (bootstrap-agent-client is likely an exception to this), so we may need an allowlist that we ratchet down.

@sunshowers sunshowers disabled auto-merge August 23, 2025 02:29
@sunshowers sunshowers enabled auto-merge (squash) August 23, 2025 02:29
@sunshowers sunshowers merged commit cc96b31 into main Aug 23, 2025
17 checks passed
@sunshowers sunshowers deleted the sunshowers/spr/move-cockroach-admin-client-nodeid-to-cockroach-admin-types branch August 23, 2025 03:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants