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

Add UpdateInstantiateConfig gov proposal #796

Conversation

jhernandezb
Copy link
Contributor

@jhernandezb jhernandezb commented Apr 1, 2022

closes #780
closes #810

  • Server Side
  • Client Side
  • Testing

@jhernandezb
Copy link
Contributor Author

jhernandezb commented Apr 1, 2022

@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
Copy link

codecov bot commented Apr 1, 2022

Codecov Report

Merging #796 (22144c3) into main (5bb0673) will decrease coverage by 1.16%.
The diff coverage is 14.37%.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
x/wasm/client/cli/gov_tx.go 0.00% <0.00%> (ø)
x/wasm/client/cli/query.go 0.00% <0.00%> (ø)
x/wasm/types/proposal.go 63.12% <6.25%> (-5.93%) ⬇️
x/wasm/keeper/contract_keeper.go 92.85% <100.00%> (+0.54%) ⬆️
x/wasm/keeper/keeper.go 87.88% <100.00%> (-0.21%) ⬇️
x/wasm/keeper/proposal_handler.go 66.44% <100.00%> (+2.15%) ⬆️
x/wasm/types/codec.go 100.00% <100.00%> (ø)

@jhernandezb jhernandezb force-pushed the jhernandezb/update-instantiate-config-proposal branch from 1564a54 to 582f435 Compare April 2, 2022 01:23
@alpe
Copy link
Contributor

alpe commented Apr 4, 2022

@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.

@jhernandezb
Copy link
Contributor Author

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

@jhernandezb jhernandezb force-pushed the jhernandezb/update-instantiate-config-proposal branch from 582f435 to e43b811 Compare April 11, 2022 05:00
@ethanfrey
Copy link
Member

This will close #780 right?

If so, please add that to the description

@ethanfrey ethanfrey added this to the v0.27.0 milestone Apr 25, 2022
@ethanfrey ethanfrey added the optional Not absolutely required for the milestone label Apr 25, 2022
@jhernandezb jhernandezb force-pushed the jhernandezb/update-instantiate-config-proposal branch from e43b811 to fde825b Compare May 3, 2022 15:12
@ethanfrey
Copy link
Member

@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.

I would either:

  • One code Id, one instantiate config
  • A list of N repeated (code_id, instantiate_config) submessages

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

@jhernandezb jhernandezb force-pushed the jhernandezb/update-instantiate-config-proposal branch from fde825b to 3cc80d8 Compare May 4, 2022 18:31
@ethanfrey
Copy link
Member

ethanfrey commented May 4, 2022

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.

@jhernandezb
Copy link
Contributor Author

working on this today can have a PR ready for review tomorrow so I think its doable to have it for v0.27

@jhernandezb jhernandezb changed the title [WIP] Add UpdateInstantiateConfig gov proposal Add UpdateInstantiateConfig gov proposal May 5, 2022
@jhernandezb jhernandezb marked this pull request as ready for review May 5, 2022 19:14
@jhernandezb jhernandezb requested a review from alpe as a code owner May 5, 2022 19:14
@jhernandezb
Copy link
Contributor Author

@ethanfrey @alpe this is ready for review will be doing some manual testing.

Some notes:

  • Added a new method to the keeper SetAccessConfig
  • added testing to proposal_integration tests with different cases but let me know if it can be improved
  • Moved to A list of N repeated (code_id, instantiate_config) submessages approach
  • CLI command is a bit tricky with that approach but added examples

@jhernandezb jhernandezb force-pushed the jhernandezb/update-instantiate-config-proposal branch from 3e4619a to 8c78632 Compare May 6, 2022 03:28
Copy link
Contributor

@alpe alpe left a 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.

Makefile Show resolved Hide resolved
x/wasm/client/cli/gov_tx.go Outdated Show resolved Hide resolved
x/wasm/client/cli/gov_tx.go Show resolved Hide resolved
x/wasm/client/cli/query.go Show resolved Hide resolved
x/wasm/client/rest/gov.go Show resolved Hide resolved
x/wasm/types/proposal.go Show resolved Hide resolved
x/wasm/keeper/proposal_integration_test.go Outdated Show resolved Hide resolved
x/wasm/keeper/proposal_integration_test.go Outdated Show resolved Hide resolved
x/wasm/types/proposal.go Show resolved Hide resolved
x/wasm/keeper/proposal_integration_test.go Show resolved Hide resolved
@jhernandezb
Copy link
Contributor Author

Made some updates just have couple questions
#796 (comment)
#796 (comment)

@jhernandezb jhernandezb force-pushed the jhernandezb/update-instantiate-config-proposal branch from 753b9c2 to 242bb3c Compare May 6, 2022 15:39
@ethanfrey
Copy link
Member

@alpe does this address all your concerns?

I will do a review and merge this evening / tomorrow unless there is a blocker

Copy link
Contributor

@alpe alpe left a comment

Choose a reason for hiding this comment

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

Very nice 👍

Copy link
Member

@ethanfrey ethanfrey left a 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 ];
Copy link
Member

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

Copy link
Contributor Author

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")
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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

Proposer string `json:"proposer" yaml:"proposer"`
Deposit sdk.Coins `json:"deposit" yaml:"deposit"`

CodeUpdates []types.CodeAccessConfigUpdate `json:"code_updates" yaml:"code_updates"`
Copy link
Member

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) {
Copy link
Member

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
Copy link
Member

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.

@jhernandezb jhernandezb force-pushed the jhernandezb/update-instantiate-config-proposal branch from 242bb3c to 3ade815 Compare May 9, 2022 17:35
@jhernandezb
Copy link
Contributor Author

jhernandezb commented May 9, 2022

@ethanfrey addressed your comments and also here is a demo
https://www.loom.com/share/e99721a095d4428d80f81496daaee2ef
(ignore the print log on submit proposal, I had that as debug on my local cosmos-sdk dependency)

Copy link
Member

@ethanfrey ethanfrey left a 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

@ethanfrey ethanfrey merged commit 5233ed7 into CosmWasm:main May 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
optional Not absolutely required for the milestone
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove stray "sudo" in comment Freeze Code ID Proposal
3 participants