Fixed Service ID/Name & Service Update, Create Feature

Related with #275, #558.

Currently, there is no way of updating existent services with a command like:
mesg-core update --source SERVICE_PATH SERVICE_ID

Because of this limitation, when there is a new version of a service, we required to re-deploy it and get a new service id to use. If this service has some data volumes attached to it, that volumes will also be freshly created and there will be no access to previous data. This is a totally expected behavior because service id is new so its data volumes are also should be newly created.

My suggestion is to have this new update feature to update a service’s source only and have the same service id for it. This way, other props of service will stay the same like its data volumes. This is an expected behaviour when update command is used.
Also, we may have other service props other than data volumes that we may want to keep as the same even if the source code is changed and be able to update them by using different flags with update command.

Note that, to make update work, we need to have static unique ids for services like @Anthony pointed. This means, deploying services with the same source code will result with different uuids.

Maybe we should also combine deploy & start as create. Or we can keep the deploy and use it optionally for creating a service directly from an image next to deploying from source:

// both are the same

$ mesg-core service create SERVICE_HASH
// response: 13010331-50ce-4d29-bd2b-917379a5662a

$ mesg-core service create SERVICE_SOURCE_PATH
// response: 13010331-50ce-4d29-bd2b-917379a5662a

create can also have an optional unique name to be used as alias to service uuid:

$ mesg-core service create --name hello-world SERVICE_HASH
// response: 13010331-50ce-4d29-bd2b-917379a5662a

use optionally set unique names with dev command under the hood. needed for solving issue #275:

// hello-world and randomly created 13010331-50ce-4d29-bd2b-917379a5662a can be
// used to access to services from mesg applications.

$ mesg-core service create --name hello-world SERVICE_HASH
// response: 13010331-50ce-4d29-bd2b-917379a5662a

$ mesg-core service dev --name hello-world SERVICE_SOURCE_PATH
// active logs...
// .....

@Anthony could you please give details about the bind method of yours that you mentioned in the issue #558 for solving the nonpermanent data volumes problem?

I think this is just a subset of the problem. We could also talk about the fact that every time we are using the command dev (with some updates on the service) we have a different ID so we need to update the ID in the application or any commands that we are using and this is really error prone.

For the update command I think it’s not really good I really want to have something without any update, just append only.

The way I see it is the following:

  • Each service has it’s own unique ID (defined in the mesg.yml and why not created with a service create command) eg: (ethereum-mainnet-3148feqheq or even just an UUID or similar)
  • This Id will always be the same
  • This alias will have multiple versions
  • Each version is a deployed version of what we have right now (so the different updates for the service)

We will have something like:
Alias: ethereum-mainnet-3148feqheq

  • 31urbib31rib31u4113434
  • 13ouh431uo4h13uh4314
  • 314j31bk4hbj34jhv42tjhv

This way we can access to any deployed versions of the service but we can also access to the service ID/alias that will be the latest deployed version and we can base any naming on this ID/alias (this would solve the problem with volumes, the name of the volume will be constant over time).

To summarize, this ID/alias system is a name service on top of the services and we can resolve either the alias or the version based on the hash.

This way we don’t have any update but instead only append (and delete).

For the bind option it’s an option from the container ( that use either the path on the host (if the bind option is true) or a name for the volume (based on the ID) so if we can bind these volumes we just need to store them but the we will not have any name based on the ID for the docker volume and so solve this problem of volumes deleted for every modification (because the volume is binded to the host)

I totally agree with Anthony on Alias.

I suggest that alias should not be generated but set manually by service developer in mesg.yml files.
If alias is missing, an error should be throw. This is not a retro compatible feature.

That way, we could have nice alias like ethereum-erc20.

I really like to set an alias in the mesg.yml file that app developer can use without having to update the service id all the time :+1:

About the docker’s volume topic:
I suggest that we bind all volumes to the host (like before) using the .mesg folder with combinaison of the alias.

1 Like

This start to be implemented in the PR

This proposal has been released in v0.5.