Skip to content

Tagging and versioning scheme #6

Description

@ChristianHinge

We should settle on a versioning scheme for the docker images and git commits. Things to consider:

  • In a production environment, there are three types of nodes/clients that have their own rh-node installation. Each of these must be able to communicate with one another. They are: the device using RHJob to submit a job, the manager in the cluster, and the particular ml tool packaged in rh-node. We should strive to rarely change the parts of rh-node code responsible for these dependencies. For instance, changing the URL endpoint for starting a job from "/job/start" to "/job/submit" would require one to update both the node, and the rh-node package on the client.
  • For each major version of rhnode, we could have a corresponding manager image; rhnode version 1.0.0 -> rhnode/manager:1.0.0
  • Each rhnode docker image contains two "versions" of interest - the rhnode version, and the version of the particular tool it encapsulates. HD-BET node tags could be: rhnode/hdbet:x1.x2.x3_y1.y2.y3, where x1.x2.x3 is the rhnode version and y1.y2.y3 is the tool version.
  • Docker image tags are not immutable like git commits. For instance, one could accidently push and overwrite an existing version of rhnode/hdbet:1.0.0 on dockerhub, simply by forgetting to update the tag in the compose file and doing docker compose push. Possible solution could be to have the "push" step run exclusively as a CI/CD tool on Github or similar.
  • An alternative solution could be to strictly write the git commit tags in Dockerfiles at each RUN git pull.... Then one could check this repository for older versions of the Dockerfiles in case of accidently overwriting a docker image.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions