[
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: [email protected]
For additional commands, e-mail: [email protected]
