Improve relation between SID and Hashes

proposal
#1

After a conversation with @Anthony about the relation between SID and Hashes that we would like to have, we decided a few things.

Relation between SID and Hashes

The relation between SID and Hashes should keep track of all hashes referenced by the SID and preserve the order of addition. So basically, in the database, SID should reference an array of hash.

Service Deployment

Deploying a service with an existing SID will not delete existing services but only append the new service’s hash to the associated SID array of hashes. Like this, it keeps existing services with the order of deployment.

Return a service from a SID

When a service needs to be returned from a SID, the most recent deployed service will be returned.

Prevent concurrent run of services with same ID

Because of volumes, services with the same SID cannot run at the same time. The function service start have to prevent this behavior and fail with a explicit error for the user.

Delete a SID

When users want to delete a service with a hash, the hash is removed from the SID’s array of hashes as well as the corresponding service.
When users want to delete a service with a SID, the last deployed service’s hash is removed from the SID’s array of hashes as well as the corresponding service.

In both case, if there is no more element in the SID’s array of hashes, then the SID’s array of hashes must be remove from the database.

@krhubert @ilgooz @Anthony what do you think about this? do you have feedback?

#2

  • Start & Stop service APIs should reply with the hash to indicate which version of the service started or stopped otherwise it’s ambiguous. (we can also return the sid, can be useful when start/stop made with the hash.)

  • Running a service with different hashes at the same is needed in real world apps. Think about blue/green deployments where you still need to run the service with the previous version until all reaming tasks complete. (volume issue is an another topic, it shouldn’t limit running a service’s multiple versions at the same time.)

  • [feature idea]: introduce a lock file to workflows to lock versions of services.

other than these lgtm. :+1:

Introducing Workflow Files
#3

Ok for me but still need some discussion about:

Prevent concurrent run of services with same ID

Not sure this is really necessary, again responsibility of the developer.
Agree with @ilgooz, we can return the list of service ids/hash that are running like that when the developer run a new service (s)he can then see the list of similar services that are running and if (s)he don’t want to run to (s)he can stop it.
Let’s not enforce anything here but just provide the informations to revert if needed.

Delete a SID

I’m not really agree with the part “When users want to delete a service with a SID, the last deployed service’s hash is removed”. If I compare with shared pointers, has_many relationships in a database or any linked resources. When an attached resource is delete then fine but when the resource that attach everything is deleted then everything is deleted.
So here when the sid is deleted all the attached hash should be deleted. This is a “risky” operation and that’s the responsibility of the developer. If they do mistakes they can re-deploy it.

Other than that it’s good

#4

Note from a conversation on the Chat:

SID is also used for generating the name of the volume.
Maybe it’s not the best solution and makes things more complicated (like what happen if 2 services with the same SID runs at the same time with the same volumes?).

@ilgooz suggested to add a developer defined key to the volumes. Eg:

volumes:
  - very-unique-volume:/var/lib