Time/Place 

This meeting is a Zoom conference call. Anyone is welcome to join...here's the info:

Attendees

  1. Thomas Bernhart 
  2. Andy Pfister
  3. Arran Griffith 
  4. Danny Bernstein 
  5. Ralf Claussnitzer 
  6. Dave Southard
  7. Kate Dohe 
  8. Ben Pennell 
  9. Yang Yu
  10. Rob Drew
  11. Mike Ritter
  12. Rosie Le Faive 
  13. Timothy Shearer 

Agenda

  1. Current situation
  2. Proposed solution:
    FCREPO-3849 - Getting issue details... STATUS
    FCREPO-3850 - Getting issue details... STATUS  
  3. Questions from Andy Pfister (Simplificator) and Thomas Bernhart (docuteam) to the developers/community
  4. Discussion

Notes

  1. Separate docker repository in Github. Some configuration files, etc. https://github.com/fcrepo-exts/fcrepo-docker
  2. The above repo is pulled down and when main fcrepo repository is built. These images are pushed, if the version is tagged (i.e. it is a release) then the image is appropriately tagged. Otherwise, it is just a SNAPSHOT tags for each commit on the main repository.
  3. Problems
    1. Improvements on the Docker repository do not trigger a new image. So these improvements are not immediately and do not appear in past tagged images.
    2. The base image is not regularly updated so past images do not get these fixes either.
  4. Build docker images in a new pipeline on the fcrepo-docker repository. Add some simple smoke tests to ensure the image is starting up correctly. Build some -SNAPSHOT images daily to pull in any security changes.
  5. Questions
    1. What range of Fcrepo images should we rebuild?
    2. When/how should we update the -SNAPSHOT images be built? Is daily enough?
    3. Who should be informed, when a scheduled run fails?
    4. Is it okay to replace an image if the base image has been changed? Should it be a new tag?
  6. Discussion
    1. Timestamp is not a normal Docker standard. When applications depend on configuration files they will add a application version to the configuration version to allow tying to a single point in time. For the base image (i.e. Tomcat changes) we can choose to support a couple versions of Tomcat.
    2. releases should be close to Fedora releases and use "latest" for the most current.
      1. There is two layers, so you choose 6.2.0 then you won't get 6.3.0-SNAPSHOT. But you also won't get any configuration changes to the image.
    3. If the changes to the web container are not required by Fedora, then it seems to make sense to have multiple releases (one for each version of Tomcat we want to support).
    4. Looking at some other more established repositories like https://hub.docker.com/_/tomcat/tags?page=1&name=9-
    5. For each release branches, have a tagged-LATEST (i.e. fcrepo-6.2.x-LATEST). But any docker configuration would become revisions under.
    6. The current docker image ships a set of default configuration, but you could use this image in your own Dockerfile and provide entirely different configuration files. The default configuration has some variables for the most commonly needed configurable properties.
    7. You could build your own image with any little configuration fixes based on the old image. This is about being of a benefit to the whole community.
    8. The Fedora version that is deployed and the java web container that it is running in.
    9. You can just truncate a tag and that will pull in that image with any suffix.
    10. It is possible there is a paradigm shift and users of the docker image don't actually care about the state of the container, they just care if it runs.
    11. Postgres has an example of simple tags.
    12. Proposal "fedora-<major>.<minor>.<patch>"
    13. Counter proposal "fcrepo-<major>.<minor>.<patch>-tomcat<major>" (i.e. fcrepo-6.2.0-tomcat9, fcrepo-6.2.1-tomcat9, fcrepo-6.3.0-tomcat10)
      1. This should support matches on all of fcrepo-6, fcrepo-6.2, fcrepo-6.2.0, and fcrepo-6.2.0-tomcat9
    14. No automated builds on SNAPSHOT
    15. Will make some time at the start of the Nov. 10th tech meeting to finish anymore discussion.
  • No labels

1 Comment

  1. I think my understand of docker tags was incorrect above, it now seems to me that each of version tags would be separate. So a 6.3.0 release on tomcat 9 would appear as:

    • fcrepo/fcrepo:6-tomcat9
    • fcrepo/fcrepo:6.3-tomcat9
    • fcrepo/fcrepo:6.3.0-tomcat9

    If that understanding is correct, then I'm assuming we would tag the single image with all 3 tags.

    This article shows how to do this with Docker Hub automated builds, but I think the same process can be automated in our build-and-push-to-dockerhub.sh  script