[
https://issues.apache.org/jira/browse/SOLR-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17340485#comment-17340485
]
Chris M. Hostetter commented on SOLR-15335:
-------------------------------------------
{quote}I actually took away the network aliases, this is using the default
networking. Just adding an entry in the etchosts file of the builder. So it's
really lightweight!
{quote}
right, sorry – i didn't mean "network alias" i ment "add-host" (ie: explicit
hostname:ip mapping)
{quote}... Otherwise it's kind of hard to understand that's where the
dockerfiles are actually built, IMO.
{quote}
Strictly speaking it's _not_ where the dockerfiles are built – it's where the
"createDockerfileFOO" *TASKS* are programmatically created using metadata, and
those tasks are then responsible for creating the dockerfiles ... but yes, by
all means: we can add a lot more comments
{quote}It'd be nice to have small section in docker/gradle-help.txt that
explains the few commands for testing/building the official image. ...
{quote}
I don't think i ever noticed that file exists before ... sure, we can add any
docs you want there.
{quote}Maybe it's after my patch, but there might be some unused imports at the
top.
{quote}
which file are we talking about? do you mean you got a warning about unused
java imports? the patch doesn't modify any java code – maybe you're seeing some
unrelated bug on main?
(Oh, hmmm i adid need to add some "import" statments to docker/build.gradle but
those are definitely necessary for the pattern matching and SHA512 calculations
... so i'm not clear what you're refering to)
{quote}I think the Dockerfile in the Solr package should be named Dockerfile,
not Dockerfile.local
{quote}
Ok ... so this is a big deal. I think it would be a huge mistake to rename
Dockerfile.local -> Dockerfile ... even if we were talking about doing that
only in the limted context of when it's copied to the solr.tgz
The reason i say that is because we really need to make sure that moving
forward we can always disambiguate what file people are talking about in any
given conversation/context/jira. When the time comes to "publish" the
"Dockerfile.official" for 9.X.Y to docker-library, via the type of process/repo
we've been talking about in SOLR-15321, at that point "Dockerfile.official" for
Solr 9.X.Y _must_ (AFAICT) be (re-)named "Dockerfile" – so we should be
prepared for people at large (ie: outside of you + me + other solr committers +
people who who look at solr.tgz or the solr.git repo) to refer to that file as
"the Solr 9.X.Y Dockerfile".
"FileX that can be used to build a docker image directly from solr.tgz or your
local git checkout" should not _also_ be known (in whatever context people see
it) as "Dockerfile" or it's going to be confusing as hell down the road when
people say things like "I ran into a problem using the solr 9.X.Y Dockerfile" –
particularly given the historical context of the "docker-solr" project, where
where people who wanted to build a customized/patched Solr *.x.y docker image
were expected to fork/modifying the "official" docker-solr/*/Dockerfile to
build using their custom compiled jars
I don't care if we call it "Dockerfile.local" or "Dockerfile.customizable" or
"Dockerfile.user-built" or "Dockerfile.whatever" ... but I really feel like
it's going to be very important that it should always (including in it's
template names, and intermediate ./docker/build/ forms, and in the final
released solr.tgz) have some name that makes it clear it's not the "official"
{{Dockerfile}} (full stop, no suffix) used to build {{_/solr:X.Y.Z}} – it's a
variant for you to build {{my/solr:X.Y.Z}}
Do you see what i mean?
----
(FYI: I'm AFK friday, may not have much time to work on this next week, and AFK
the week after that ... so if you want to go ahead and combine the patches, and
work up some additional build.gradle comments + gradle-help.txt additions
please go head .. as long as the "tests" pass feel free to commit whenever
you're happy with it even if i'm not around)
> templated (header + body) approach for building Dockerfile.local +
> Dockerfile.official w/common guts
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-15335
> URL: https://issues.apache.org/jira/browse/SOLR-15335
> Project: Solr
> Issue Type: Sub-task
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-15335-no-custom-network.patch, SOLR-15335.patch,
> SOLR-15335.patch, SOLR-15335.patch, SOLR-15335.patch, SOLR-15335.patch,
> SOLR-15335.patch
>
>
> Goals:
> * "generate" a Dockerfile.official at release time that will satisfy the
> process/tooling of docker-library for 'official' docker images
> ** use a templated approach to fill in things like version, sha512, and GPG
> fingerprint
> * ensure that the generated Dockerfile.official and the Dockerfile.local
> included in solr.tgz are identical in terms of the "operational" aspects of a
> Solr docker image (ie: what the disk layout looks like, and how it runs)
> ** they should only differ in how they get the contents of a solr.tgz into
> the docker image (and how much they trust it before unpacking it)
> * minimize the amount of overhead needed to make changes that exist in in
> both dockerfiles
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
