-
Notifications
You must be signed in to change notification settings - Fork 474
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
Conversation
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 Report
@@ 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
📣 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" |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
andparticipating
- NonParticipating-- runs APIs tagged with
nonparticipating
- Data-- runs APIs tagged with
nonparticipating
anddata
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
There was a problem hiding this comment.
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.
- I'm unfamiliar with the history, but perhaps it's sensible for the endpoints guarded by
- 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.
There was a problem hiding this comment.
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 anddata
(orledger
)
There was a problem hiding this comment.
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 needpublic
.
There was a problem hiding this comment.
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.
daemon/algod/api/server/v2/utils.go
Outdated
if formatPtr != nil { | ||
format = strings.ToLower(*formatPtr) | ||
format = model.PendingTransactionInformationParamsFormat(*formatPtr) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
daemon/algod/api/server/v2/generated/participating/private/private_routes.yml
Show resolved
Hide resolved
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" |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
embedded-spec: true | |
embedded-spec: false |
There was a problem hiding this comment.
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.
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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "real" change. 👍
There was a problem hiding this 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! ☕
Summary
This PR builds on top of the
oapi-codegen
updateWhereas 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
, andgenerated/private/types.go
files, this PR moves the generated routes into a thepublic
package, and combines both types files into a singlemodel
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 routerTest Plan
Existing tests provide coverage for all implemented APIs.