-
Notifications
You must be signed in to change notification settings - Fork 411
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
Add UpdateInstantiateConfig gov proposal #796
Add UpdateInstantiateConfig gov proposal #796
Conversation
@alpe Regarding single update vs multiple updates on a single proposal. Should it be one proposal at a time? or udpating multiple is fine? also different configs? Currently I have multiple code ids with the same AccessConfig. |
Codecov Report
@@ Coverage Diff @@
## main #796 +/- ##
==========================================
- Coverage 59.89% 58.72% -1.17%
==========================================
Files 52 52
Lines 5987 6140 +153
==========================================
+ Hits 3586 3606 +20
- Misses 2134 2266 +132
- Partials 267 268 +1
|
1564a54
to
582f435
Compare
@jhernandezb good start! You are more familiar with the concrete use case but from my perspective multiple code_ids with same AccessConfig make a lot of sense. This can be explained to the voters but also gives flexibility to address multiple code ids. |
Yes my reasoning is for example: Freeze Code ID 1,2,3,4 then you only need to apply the same config to all of them. If someone wanted different access configs then a different proposal should be made explaining the reasoning. Will complete this PR then and push updates |
582f435
to
e43b811
Compare
This will close #780 right? If so, please add that to the description |
e43b811
to
fde825b
Compare
I would either:
I have no strong opinion either way. Although I guess the second would be better to match the use case you had in mind to allow multiple code_ids |
fde825b
to
3cc80d8
Compare
If we can get this ready by (early?) next week, I would love to get it in the upcoming v0.27 release Please let us know when it is ready for another review and if that seems feasible for you. |
working on this today can have a PR ready for review tomorrow so I think its doable to have it for v0.27 |
@ethanfrey @alpe this is ready for review will be doing some manual testing. Some notes:
|
3e4619a
to
8c78632
Compare
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.
Excellent work. I am very happy with this PR.
Only some comments on rest that need be addressed before merging.
Too bad we have not dropped legacy rest support already.
Made some updates just have couple questions |
753b9c2
to
242bb3c
Compare
@alpe does this address all your concerns? I will do a review and merge this evening / tomorrow unless there is a blocker |
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.
Very nice 👍
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.
lgtm. I would love to see a manual test (as there are all kinds of codecs and middleware called in the real proposal stack), but good stuff.
I added a few comments on naming, which would be nice polish.
A CHANGELOG entry (one line pointing to this PR) would also be nice.
Happy to merge once those are done (just mention me in a comment and I will double check)
// CodeID is the reference to the stored WASM code to be updated | ||
uint64 code_id = 1 [ (gogoproto.customname) = "CodeID" ]; | ||
// InstantiatePermission to apply to the set of code ids | ||
AccessConfig instantiate_permission = 4 [ (gogoproto.nullable) = 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.
Odd that this is 4. Not wrong, just surprising, I assume this was for some backwards compatibility with another struct?
It would be good to label it if so, with something like "2 and 3 are reserved" or such
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.
it should be 2 will fix.
cmd.Flags().String(cli.FlagDeposit, "", "Deposit of proposal") | ||
cmd.Flags().String(cli.FlagProposal, "", "Proposal file path (if this path is given, other proposal flags are ignored)") | ||
// type values must match the "ProposalHandler" "routes" in cli | ||
cmd.Flags().String(flagProposalType, "", "Permission of proposal, types: store-code/instantiate/migrate/update-admin/clear-admin/text/parameter_change/software_upgrade") |
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'm a bit confused why this flag is here?
Usage is tx gov submit-proposal update-instantiate-config 1,nobody 2,everybody 3,%s1l2rsakp388kuv9k8qzq6lrm9taddae7fpx59wm
right?
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 is unrelated to this logic, but it's used by this https://github.com/cosmos/cosmos-sdk/blob/v0.45.4/x/gov/client/cli/parse.go#L13
All other proposals have it but I don't think its actually used and could be removed.
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 point, can you make a follow up (cleanup issue), so someone can look into that later.
Not blocking merge at all, but don't want to forget it
x/wasm/client/rest/gov.go
Outdated
Proposer string `json:"proposer" yaml:"proposer"` | ||
Deposit sdk.Coins `json:"deposit" yaml:"deposit"` | ||
|
||
CodeUpdates []types.CodeAccessConfigUpdate `json:"code_updates" yaml:"code_updates"` |
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 think access_config_updates
or code_access_config_updates
would work (and ideally update both in the Protobuf file as well)
@@ -749,3 +749,98 @@ func TestUnpinCodesProposal(t *testing.T) { | |||
}) | |||
} | |||
} | |||
|
|||
func TestUpdateInstantiateConfigProposal(t *testing.T) { |
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.
nice
@@ -53,6 +53,9 @@ type ContractOpsKeeper interface { | |||
|
|||
// SetContractInfoExtension updates the extension point data that is stored with the contract info | |||
SetContractInfoExtension(ctx sdk.Context, contract sdk.AccAddress, extra ContractInfoExtension) error | |||
|
|||
// SetAccessConfig updates the access config of a code id. | |||
SetAccessConfig(ctx sdk.Context, codeID uint64, config AccessConfig) error |
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 point here. If there is a simple way to keep it private and expose to the proposal handler, maybe @alpe can make a quick PR to show how. Otherwise, I would be fine to merge like this.
242bb3c
to
3ade815
Compare
@ethanfrey addressed your comments and also here is a demo |
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.
Great stuff and loving the loom video!
Thank you very much
closes #780
closes #810