dependency volume changes when source code is changed

[ilgooz]

Problematic line. I'm working on WSS with mongodb, when I make a change on source code of WSS, mongodb's data volume also changes and I lose all the previous data.

/cc @antho1404

[antho1404]

I was thinking about this one too when I worked on the influxdb service and yes it can be annoying. In some cases it's actually a good thing to have this all automatic, but in some other cases it's really annoying so maybe it should be the responsibility of the user and have a parameter "bind" or something like that.

[antho1404]

Also the line you are pointing is really risky to remove because what happen if 2 services have the same name of dependency and same name of volume eg: db -> db that might be a big problem because data will be shared

[ilgooz]

I was thinking about this one too when I worked on the influxdb service and yes it can be annoying. In some cases it's actually a good thing to have this all automatic, but in some other cases it's really annoying so maybe it should be the responsibility of the user and have a parameter "bind" or something like that.

Updating a service's source code should never result with reseting the data volumes. This is not an expected behavior in real-world applications.

Also the line you are pointing is really risky to remove because what happen if 2 services have the same name of dependency and same name of volume eg: db -> db that might be a big problem because data will be shared

This is totally right. I have a new idea. To solve this issue we need to introduce the mesg-core service update --path SOURCE_PATH SERVICE_ID functionality. This way, devs can chose to create a new service from the updated version of source core, in this case data volumes will change like now or update an existing service and keep the data volumes as it is. We can create uuids on creation of services to make updating an existent service possible.

If you also agree with this let's create an another issue about this update feature and close this one by referencing to this new issue or forum topic.

[antho1404]

I think the update option is not really related and I think this issue will solve the problem #275 but until then I really think we could either force to bind the volume in the .mesg folder based on the name like we had before or even make an option for that.
The final solution is really to work on this "alias/ID" for service that will always be static and we can use that as identifier for the volume and this will not change anymore.

[ilgooz]

moved to https://forum.mesg.com/t/fixed-service-id-name-service-update-create-feature

[ilgooz]

@antho1404 please confirm and close this issue in favor of forum proposal.

[antho1404]

This is still a bug that can be solved by the service ID feature but it should be kept open as reminder

[NicolasMahe]

The latest messages are off-topic and the conversation continued on the PR #571

[antho1404]

this one should be solved by the PR #583 volumes will be binded to the alias and not the hash anymore so whatever the version of the service, the alias stays the same and so the volume