Does Upgrades Plugins work in a serverless environment

Support Upgrades
1

I have taken a look at the plugin.

this might not work in a serverless environment as I see it mentioning something will be stored in a .openzeppelin folder?
In fact this might also not work in an environment running on multiple instances for scaling?

the internal implementation wasn’t made very clear. So unsure if .openzeppelin folder is critical for this to succeed.

And also there isn’t any proper api documentation on the parameters explaining what they are.
This is an ongoing issue with OpenZeppelin doc.
The main doc also never mention this new plugin so as developers, really had to spend lots of time digging around.

2 Likes
2

Hi @skybach,

I am not sure if the Upgrades Plugins would currently work in an environment where there isn’t a way to write to an .openzeppelin directory: https://docs.openzeppelin.com/upgrades-plugins/1.x/network-files

If I recall correctly you are deploying programmatically in JavaScript. Can you describe a little more what your setup is?

3

This is briefly mentioned in How the plugins work:

The plugins will keep track of all the implementation contracts you have deployed in an .openzeppelin folder in the project root, as well as the proxy admin.

In more detail, the .openzeppelin directory tracks for each network: 1) the addresses of already deployed implementation contracts so they can be reused for future proxies, 2) their storage layout to verify compatibility of future upgrades, 3) the address of the ProxyAdmin contract for reuse.

While it's not a requirement to persist this directory, it would be wasteful not to reuse the things that can be reused.

In a serverless environment you can provide each instance with an already populated .openzeppelin directory. It wouldn't need persistence because the plugins will not do any additional changes. (There is one situation where the plugins will change the contents of the directory, but it's an error condition: if a contract that we assume to be deployed (e.g. one of the implementation contracts) is not found on chain, the plugins will remove the entry from the relevant network file, and then exit with an error.)

In order to create the populated .openzeppelin directory for your serverless instances, you can use prepareUpgrade locally and then commit the generated files to source control, for example. This function deploys and stores an implementation contract that can be picked up by later calls to deployProxy. However, you would also need an admin, which prepareUpgrade doesn't deploy for you, so every subsequent deployProxy would deploy their own admin. If you can confirm that this setup would work for you, we can add a new function in the API to deploy the admin by itself.

The feedback about documentation is appreciated.

I recognize that there is room for improvement but have you seen the API Reference pages? If so, what kind of documentation do you think is missing there?

I'm not sure what you mean by main doc, but last week we released updates to the site, including updated "Learn guides" such as Upgrading smart contracts which now explains how to use the upgrades plugins. They are also featured under "Tools & Libraries" in the landing page. There's also mention of the plugins in other pages that are relevant, like the documentation for Proxy contracts.

1 Like
4

the processes are running in AWS Lambda using NodeJS.

1 Like
5

@skybach Let me know if you tried any of the things I suggested above. I would love to know what your experience was and if there’s anything we should improve for a serverless environment.

1 Like
6

yes, i saw the docs after commenting here.
Guess my main gripe is from the docs navigation, it’s not very clear where to look for specific stuffs from the documentation.
Suggests having more descriptive sub menu about the topics.

7

@frangio

I have put on hold on the exploration because I am not working full time on this.

But from first impression, having a physical storage is undesirable in terms of architeturing the solution.
Creates dependency for syncing issue if things were to be scalable.
Need more thought in the app design to make it work.

1 Like
8

It’s hard for me to make recommendations without knowing more details about the problem you’re trying to solve. However, I don’t think you need persistent storage for it to work. My point above was that it’s useful and probably desirable to have a pre-populated read-only .openzeppelin directory that you provide for every serverless instance.

Feel free to come back and ask questions whenever you resume the exploration.

1 Like