You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Chris M. Hostetter (Jira)" <ji...@apache.org> on 2021/04/09 23:26:00 UTC

[jira] [Updated] (SOLR-15322) include all docker context pre-reqs (notably docker scripts) in released solr.tgz

     [ https://issues.apache.org/jira/browse/SOLR-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris M. Hostetter updated SOLR-15322:
--------------------------------------
    Attachment: SOLR-15322.patch
        Status: Open  (was: Open)

{quote}My main concern is not to "pollute" the top level directory with too many distractions ...
{quote}
After writing this, it kept swirling around in my head, and I was thinking about the reason I felt like this top level 'docker' directory would be weird, which goes back to this earlier comment...
{noformat}
+      // nocommit: - Since we aren't including the Dockerfile in the tgz, having a top level 'docker' dir in our tgz
+      // nocommit:   release that contains a bunch of scripts w/o README or Dockerfile will be confusing to users who
{noformat}
...that assumption was based on the "chicken vs egg" problem of not being able to include our "official" Dockerfile inside the solr.tgz that had things like the SHA256 value *OF* the tgz.tgz embedded in it.

I realized that since we're already talking about needing to templatize the Dockerfile, and producing a "Dockerfile.local" (for people who want to build patched images locally) and a "Dockerfile.global" (that downloads official release tar balls and has SHA256 + GPG fingerprints hardcoded) then there isn't really any blocker to including the "Dockerfile.local" in our solr.tgz artifacts.

So why not "lean in" to the idea of drawing attention to our docker support in our solr.tgz releases? ... Do a 180 (and then another 180) and go back to what Houston had in SOLR-15129, where the TGZ file can be used directly as a docker build context. Even if we can't use that approach for "official" images, we can still make it trivially easy for people who download solr.tgz to experiment with building a docker image locally (while drawing attention to our official images)
----
The patch I'm attaching is virtually identical to Houston's patch in SOLR-15129 with a few small tweaks:
 * tweak the 'docker' directory structure in the solr.tgz file slightly:
 ** move the 'Dockerfile' into the 'docker' directory
 ** move all the scripts into a new 'docker/scripts' subdir
 * add some comments to the Dockerfile explaining what it's for and how to use it
 * eliminate the need for the VERSION.txt file (and the SOLR_VERSION build-arg)
 ** This has a confusing backstory: it started out because in SOLR-15127 I tried to simplify the Dockerfile (and the resulting image directories) by eliminating the need for the SOLR_VERSION build-arg, and using globs to match version specific paths
 ** Houston liked the idea of keeping the Dockerfile + image filesystem paths version agnostic, but was concerned about backcompat for users who might expect /opt/solr-X.Y.Z to exist...
 *** in 8.x, /opt/solr is a symlink to /opt/solr-X.Y.Z
 *** in my patch i just had /opt/solr as a 'real' directory
 ** So Houston's patch added VERSION.txt to the solr.tgz so that the logic in the Dockerfile could know what X.Y.Z to use in order to create an /opt/solr-X.Y.Z symlink to (the real) /opt/solr
 ** In this patch, I just when back to keeping it simple:
 *** using globs to copy everything into /opt/solr-X.Y.Z as the 'real' directory (just like in 8x) and adding /opt/solr as a symlink (just like in 8x)
 *** Which still doesn't need a SOLR_VERSION build-arg

----
I think this is a decent foundation to commit to main, and then move forward in other issues with templatizing the Dockerfile – this directory structure should work well for both use cases we've been talking about (w/o confusing non-docker users too much)

thoughts?

> include all docker context pre-reqs (notably docker scripts) in released solr.tgz
> ---------------------------------------------------------------------------------
>
>                 Key: SOLR-15322
>                 URL: https://issues.apache.org/jira/browse/SOLR-15322
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Chris M. Hostetter
>            Priority: Major
>         Attachments: SOLR-15322.patch
>
>
> in the 8.x docker-solr world, all of the scripts specific to the docker image lived in the 'docker-solr' repo and were completely disjoint from solr.
> in 9x, these scripts currently live in the solr/solr/docker/scripts directory of the solr.git repo, and the build.gradle file copies them into the docker context.
> we should move towards including these scripts -- and any other solr specific docker image pre-requisites -- into the "solr-X.Y.Z.tgz" release artifact, so that it contains everything necessary for building a solr docker image.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org