search

dwellir-public / polkadot-operator

The Polkadot Juju operator/charm
Apache License 2.0
1 stars 1 forks source link

Revision 16 #32

Closed jonathanudd closed 8 months ago

jonathanudd commented 9 months ago
gflow33 commented 8 months ago

Some background, bifrost has a polkadot and kusama parachain, with different chain specs. Prior to deploying the bifrost polkadot parachain, we only had to worry about the kusama parachain. The changes made are to handle both cases.

jakobilobi commented 8 months ago

I'm going to want this one in here as well before we merge!

https://github.com/dwellir-public/polkadot-operator/pull/34

erik78se commented 8 months ago

We should probably/possibly use the juju feature "resource" for spec-files which allows supplying a file which is then available to tje charm. It can also be upgraded separately.

jakobilobi commented 8 months ago

We should probably/possibly use the juju feature "resource" for spec-files which allows supplying a file which is then available to tje charm. It can also be upgraded separately.

That would mean we'd have to download the file manually before supplying it to the charm?

erik78se commented 8 months ago

That would mean we'd have to download the file manually before supplying it to the charm?

Yes and no. A resource can be released together with a charm and be upgraded individually. Eg, we can have a default resource for the default deploy and if it differs it can be supplied.

Further more, we can/could have a set of chain specs built in to the charm, which will be used primarily, whereas, a supplied resource (specc file) only would be used if supplied.

Yet another approach would be that the resource is a zip archive of all our supported chains and a config parameter that controls which will be used.

There might be even more good approaches which gives determinism in what ends up in a deployment.

jakobilobi commented 8 months ago

Further more, we can/could have a set of chain specs built in to the charm, which will be used primarily, whereas, a supplied resource (specc file) only would be used if supplied.

To me, this seems like the only alternative which might be an improvement. The other ones sound like they would mean we have to do more work than what we currently have to do with Polkadot charm deployments. This alternative is basically what we have today (set of chain specs built into the charm, as hardcoded download URL:s), but with a more streamlined way of overriding the specfile if needed (today we can override it by manually adding a spec file and then point to it in the service args).