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

algod: Consolidate models #4714

Merged
merged 32 commits into from
Nov 14, 2022
Merged

Conversation

Eric-Warehime
Copy link
Contributor

@Eric-Warehime Eric-Warehime commented Oct 31, 2022

Summary

This PR builds on top of the oapi-codegen update

Whereas the previous PR adds a config file to do the code generation for each of the generated/routes.go, generated/types.go, generated/private/routes.go, and generated/private/types.go files, this PR moves the generated routes into a the public package, and combines both types files into a single model package.

The rest of the changes are as a result of this refactoring--changing imports.
generated=>model
generatedV2=>model
generated=>public in the case of the router

Test Plan

Existing tests provide coverage for all implemented APIs.

Updates the version of oapi-codegen which is installed via
the buildtools to our v1.11.0 prerelease. Also changes the
Makefile targets and adds config files which are the preferred
way of configuration instead of the old CLI flags.

The generated types definitions have also been updated using
the oapi-codegen commit which ensures all required Enums are generated
for enums embedded in response types.
Moves all types.go to a single model package within the v2 generated API code. Also
moves the oapi-codegen config file for each of the generated packages alongside the code
it is generating. Additionally, we've moved the generated routes.go into a public package
instead of the top level generated package.

The result of this is a large refactoring of imports. generated=>models,
generatedV2=>models, and generated=>public in the case of the router.
@codecov
Copy link

codecov bot commented Oct 31, 2022

Codecov Report

Merging #4714 (ea80a8b) into master (445b45b) will decrease coverage by 0.02%.
The diff coverage is 27.06%.

@@            Coverage Diff             @@
##           master    #4714      +/-   ##
==========================================
- Coverage   54.69%   54.67%   -0.03%     
==========================================
  Files         414      414              
  Lines       53548    53550       +2     
==========================================
- Hits        29290    29277      -13     
- Misses      21832    21844      +12     
- Partials     2426     2429       +3     
Impacted Files Coverage Δ
cmd/goal/account.go 13.76% <0.00%> (ø)
cmd/goal/accountsList.go 0.00% <ø> (ø)
cmd/goal/clerk.go 8.75% <0.00%> (ø)
cmd/goal/node.go 12.71% <ø> (ø)
cmd/tealdbg/localLedger.go 64.81% <ø> (ø)
daemon/algod/api/server/router.go 13.88% <0.00%> (-0.82%) ⬇️
daemon/algod/api/server/v2/handlers.go 0.91% <0.00%> (ø)
daemon/algod/api/server/v2/test/helpers.go 73.94% <ø> (ø)
daemon/algod/api/server/v2/utils.go 12.92% <0.00%> (ø)
libgoal/libgoal.go 2.60% <0.00%> (ø)
... and 20 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@@ -227,6 +236,10 @@
"/v2/accounts/{address}/assets/{asset-id}": {
"get": {
"description": "Given a specific account public key and asset ID, this call returns the account's asset holding and asset parameters (if either exist). Asset parameters will only be returned if the provided address is the asset's creator.",
"tags": [
"public",
"nonparticipating"
Copy link
Contributor

@shiqizng shiqizng Nov 4, 2022

Choose a reason for hiding this comment

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

are these endpoints not available when nodes are running in participation mode?

@@ -381,6 +398,10 @@
"/v2/accounts/{address}/transactions/pending": {
"get": {
"description": "Get the list of pending transactions by address, sorted by priority, in decreasing order, truncated at the end at MAX. If MAX = 0, returns all pending transactions.\n",
"tags": [
"public",
"participating"
Copy link
Contributor

Choose a reason for hiding this comment

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

similar to previous question, are these endpoints not available to nodes running non-part mode?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good question! In this PR I'm just separating APIs into groups based on potential "modes" of operation for a node, but in the routers.go file I'm registering all of them as normal.

In a followup PR the plan is to implement variations of AlgorandFullNode which have different subsets of functionality turned off/on.

Currently the list I'm working with is:

  • Participating-- runs APIs tagged with nonparticipating and participating
  • NonParticipating-- runs APIs tagged with nonparticipating
  • Data-- runs APIs tagged with nonparticipating and data

This should allow us to more easily turn on/off the APIs based on the purpose of the node, but also it will allow us to make the node more lightweight in certain cases. For example, a non participating node would no longer run the agreement service, or have a txn pool, etc.

And in the case of the data mode, we can ensure that the user has full control over what round the node is on because the agreement service won't be running to try to advance the round. That's important when implementing sync round and delta APIs in #4658

Copy link
Contributor

Choose a reason for hiding this comment

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

@Eric-Warehime Based on what I understand PR scope to be, I think we can defer a decision until a subsequent PR. My intent is to raise for light consideration because we're in the neighborhood.

I'm interested in selecting a different name for data mode.

  • Off-the-cuff, I don't have a better suggestion (NonParticipatingDeveloper?).
  • I think you suggested as much in a verbal: Perhaps we can move away from EnableDeveloperAPI towards mode instead?
    • I'm unfamiliar with the history, but perhaps it's sensible for the endpoints guarded by EnableDeveloperAPI to be non-participating only.
    • If we grouped additional routes under the data umbrella, it might motivate a different name.
  • Ultimately, if we don't have alternative names, I'm good as is. If you feel Data works well, I also won't push further.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'll echo @michaeldiamant question (and caveat that this is a good time to discuss, but out of scope for the PR). I'm not sure if "NonParticipatingDeveloper" makes sense, since dev-mode is a single-node instance it must be participating.

Additionally, I had some of the same confusion as Shiqi. I think the names "participating" and "nonparticipating" would be user settings that describe a set of feature, and the tags here might be clearer if written in terms of the feature.

  • participating - I think this is fine. There are also participation specific endpoints, so it maps well to the API.
  • non-participating - What is the difference between this and data (or ledger)

Copy link
Contributor

Choose a reason for hiding this comment

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

  • admin - probably a better name than public/private. Maybe we don't even need public.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

w/r/t public vs. private, I'm open to changing to admin for private. The reason I liked public is that made the directory structure a bit more predictable.

For the other names, the difference between a non-participating node and a data or ledger (or whatever) node is for now solely the new set of APIs being added for retrieving deltas and managing the ledger's sync round. I think if we want to we can also include things like the v2/teal/ endpoints. Also, given the work being done for new Debugger hooks, and expanding the capability of the node to provide fine grained txn tracing, it makes sense to me to put APIs exposing that data in this mode--we probably wouldn't want Txn tracers running on a normal participating or nonparticipating node.

if formatPtr != nil {
format = strings.ToLower(*formatPtr)
format = model.PendingTransactionInformationParamsFormat(*formatPtr)
Copy link
Contributor

Choose a reason for hiding this comment

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

*formatPtr doesn't need to be lowered cased anymore?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added it back in the most recent commits. It looks like it got removed when the method was changed previously, but you're right we still want to be case insensitive here.

@Eric-Warehime Eric-Warehime changed the title WIP: algod: Consolidate models algod: Consolidate models Nov 8, 2022
@Eric-Warehime Eric-Warehime marked this pull request as ready for review November 8, 2022 15:57
Comment on lines -32 to +33
generatedV2 "github.com/algorand/go-algorand/daemon/algod/api/server/v2/generated"
privateV2 "github.com/algorand/go-algorand/daemon/algod/api/server/v2/generated/private"

"github.com/algorand/go-algorand/crypto"
"github.com/algorand/go-algorand/daemon/algod/api/server/v2/generated/model"
Copy link
Contributor

Choose a reason for hiding this comment

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

🎉

package: private
generate:
echo-server: true
embedded-spec: true
Copy link
Contributor

Choose a reason for hiding this comment

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

This can be turned off in the config files.

Suggested change
embedded-spec: true
embedded-spec: false

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, we can remove it--I've left it in since it matches what we currently have.

Comment on lines -150 to +155
generated.RegisterHandlers(e, &v2Handler, apiAuthenticator)
private.RegisterHandlers(e, &v2Handler, adminAuthenticator)
nppublic.RegisterHandlers(e, &v2Handler, apiAuthenticator)
npprivate.RegisterHandlers(e, &v2Handler, adminAuthenticator)
ppublic.RegisterHandlers(e, &v2Handler, apiAuthenticator)
pprivate.RegisterHandlers(e, &v2Handler, adminAuthenticator)
Copy link
Contributor

Choose a reason for hiding this comment

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

The "real" change. 👍

winder
winder previously approved these changes Nov 9, 2022
Copy link
Contributor

@michaeldiamant michaeldiamant left a comment

Choose a reason for hiding this comment

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

@Eric-Warehime Thanks for bringing in my feedback! ☕

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants