Manage deployment of services for the build

[antho1404]

We have system services now and we need to make sure that these services are installed when the core is installed.

For that we have configurable variables in the configs https://github.com/mesg-foundation/core/blob/e5383ab92c854c5716fe690d6a1a442bf27c59b6/config/services.go#L10-L13

We still need on the CI to upload these services and inject the url of the tarball during the compilation of the core.

The best thing would be to actually use the Marketplace commands to manage this deployment like that we download the service directly from the marketplace and we can test the marketplace

[krhubert]

Do we have some details about how we want to do this? Adding service tars for release is easy, but how to pass url - we need to setup some server or pass file location via config, any other propositions?

[antho1404]

What I was thinking is one of the two following solutions

Tar server

• We setup a place to store the tar (s3 with public fetch for example)
• Build the tar of the services in the CI
• Upload the tar to this s3 (or equivalent)
• Inject the url of this tar like we do for the version eg: LDFLAGS="-X 'github.com/mesg-foundation/core/config.Ethwallet=$walletURL'"
• When the core is started it will fetch from the url (done already)

Using the MESG marketplace

This would be the best but requires a more work.

• We publish the service on the marketplace from the CI
• We set no offer on the marketplace (service free and accessible for anyone)
• We inject the address of the service on the marketplace eg: LDFLAGS="-X 'github.com/mesg-foundation/core/config.Ethwallet=mesg://marketplace/service/xxx
• We make sure that when the core starts it can deploy from mesg protocol (for now only the CLI does that and that should be done by the core anyway)

I would definitely go with the second option like that we use the marketplace and that's great. This can be done in 2 different dev: "support of mesg protocol in the core" and "publish service from the CI". If it's too complicated we can fallback on the s3 solution.

[krhubert]

If we have marketplace let's use it! But in that case we need working marketplace first.

[NicolasMahe]

I would go with the marketplace solution as well. EDIT how can the core deploy the marketplace service without using the marketplace service?? The marketplace service is used to resolve the service's data on ethereum (manifest source) and download the manifest using ipfs (actually just http). So how can the core do all of this work without the service that is actually doing it?? This is a chicken and egg problem again.

Solution: We could still deploy the service on the marketplace, but inject the http ipfs gateway url that contains directly the source of the service.

---

But why deploying from the CI right now? We can, for now, deploy services manually and inject the service URL to the CI using env variables. There is an UI in circleci to manage env variables.

[NicolasMahe]

• We set no offer on the marketplace (service free and accessible for anyone)

The marketplace currently requires an offer to be created for the isAuthorize function to work:

https://github.com/mesg-foundation/marketplace/blob/6f4602d150ef988a4051a329b793c769b761d1b4/contracts/Marketplace.sol#L449-L465

[antho1404]

@NicolasMahe

how can the core deploy the marketplace service without using the marketplace service??

We could run it in dev first to publish the service and then inject the result in the actual build for production.

marketplace=$(./dev-cli marketplace publish systemservice/marketplace)
wallet=$(./dev-cli marketplace publish systemservice/ethwallet)
scripts/build-cli.sh --marketplace $marketplace --wallet $wallet

Basically something similar to this but that will be quite heavy...

Another solution would be to install the previous version of mesg-core and install it the same way with

mesg-core service deploy systemservice/marketplace
mesg-core service start marketplace
mesg-core service execute marketplace --task deployService --json generatedFile.json

We don't use the CLI here but the system service should handle most of the processing, we would still need to upload the sources on ipfs manually and in that case maybe just the upload and inject the tarball as build parameter but the service will not be on the marketplace.

---

We can, for now, deploy services manually

That's a bit ugly, what happen if we want to work on 2 different versions for the marketplace or some stuff like that, it's also really risky

---

@krhubert

If we have marketplace let's use it! But in that case we need working marketplace first.

As far as i know and I tested the marketplace works well

[krhubert]

As far as i know and I tested the marketplace works well

Yes but do we have a version ready to set up on dev environment (local eth network etc...) to test this easily?

[antho1404]

To test you can just use the one deployed already on ropsten, just use the system service that is already configured for that. If you want your own marketplace then you can redeploy the smart contract and update the mesg.yml of the systemservice/marketplace

- MARKETPLACE_ADDRESS=0x94F4cB92Fe9f547574Aec617B1594B13aBd47Ad3

But just use the one already here, everything is set up and everything works. We will anyway clean up the marketplace when we launch

[antho1404]

For now we can do a simple workflow:

• We deploy with a script the service on ipfs we can use UploadSource in marketplace_provider.go
• We inject the url of ipfs gateway when we build the core
• When we download the version of the core, it fetches the services from ipfs gateway, there is no marketplace yet
• [optional] we publish the service on the marketplace

[NicolasMahe]

@krhubert can you implement this feature now please:

Todo: Create new script that should be run in the CI:

• Walk in systemservices folder, create tar (same as script dev-core).
• Upload to IPFS using MESG IPFS node (there should be some easy to use cli tool)
• Inject ipfs gateway URLs in core config (same as script dev-core).
• Done