...

1. Current situation
2. Proposed solution:
   

   Jira
   server Fedora JIRA serverId 1fe6d535-c432-380f-b5c0-a7d3b2940ea4 key FCREPO-3849

   
   

   Jira
   server Fedora JIRA serverId 1fe6d535-c432-380f-b5c0-a7d3b2940ea4 key FCREPO-3850

    
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.