feat: add gRPC public API

[t3hmrman]

What problem are we solving?

This PR aims to solve multiple problems at the same time:

1. Add a public gRPC API implementation
2. Provide a public HTTP(S) OpenAPI schema

How are we solving the problem?

The idea is to create a public gRPC API, and use protoc-gen-openapi, which supports OpenAPI v3 to generate YAML spec documents.

See discussion in #4306 -- though we didn't discuss this particular solution, it seems like a good way to actually get both things done at the same time.

How is the PR tested?

There are no tests for the PR just yet, but what the API should look like is nailed down, tests should be added.

Checks

• I have added unit tests if possible.
• I will add related wiki document changes and link to this PR after merging.

[t3hmrman]

Hey @chrislusf would love some feedback on this -- started with a very small example, but it should outline the approach.

[chrislusf]

This is good. But need to be split into smaller PRs with one change at a time.

[t3hmrman]

Yeah, this is actually very close to the first PR I'd like to submit for this feature. The real addition here is public.proto and the rest are generated additions/required by Google gRPC feature usage.

The approach I wanted to take was to introduce exactly one new API (see public.proto) and then build out the API (and discuss as we go) from there.

I haven't actually written the implementation for the info endpoint I'm proposing (would love any help/pointers in that direction though, what you'd expect it to return, etc).

[kmlebedev]

I don’t understand what is the value of having a grpc documentation generator in OpenApi?

Is it true that someone will use these and make a lot of their own integrations and external components?

So far it looks like a bunch of extra code that needs to be maintained for no one knows.

[t3hmrman]

Hi @kmlebedev would you mind explaining something about the documentation generator comment you made? My intent was to add an API to enable access to currently CLI-only commands that are available.

The documentation-related notes/comments that are in the proto files are due to my (re)using Google shared proto schemas -- that's not strictly necessary but I thought it would be good to reuse.

Is it true that someone will use these and make a lot of their own integrations and external components?

The intent here was for controlling weed from outside it, without using the CLI. Not necessarily building an external component that interacts with weed internals.

Administration via CLI is fine for installations that are manually managed, but it is unnecessarily hard to automate, I think.

So far it looks like a bunch of extra code that needs to be maintained for no one knows.

If there's a different way to perform the administration tasks I wanted to lay out that I missed I'd appreciate a pointer! If CLI is intended to the be the only way to administer seaweed for the forseeable future then that's fine as well.

I'm also open to how you think this should be structured, based on the goal of being able to administer weed via API/non-CLI means.

[kmlebedev]

@t3hmrman I understand the idea and it will probably be useful, but I would like it to be the code used. Can you share your case of using this API in place of the cli?
What specific problem are you solving in your case?

[t3hmrman]

but I would like it to be the code used.

Would you mind explaining this bit? I'm not sure I understand.

Can you share your case of using this API in place of the cli?
What specific problem are you solving in your case?

It's a bit wide-ranging, but I'd like to be able to perform all the CLI operations via API if possible -- right now I basically do this by scripting a sidecar container that runs CLI commands, but ideally I could trigger the actions directly.