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
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
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?