[
https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196202#comment-17196202
]
Houston Putman commented on SOLR-14789:
---------------------------------------
{quote}victim of poor JIRA management
{quote}
That's fair. I was trying to clean up the JIRA and break it up into logical
tasks, but I can see how that obfuscated the discussion. I'll update the ticket
to include links to relevant discussions.
{quote}Do we agree that we should use Alpine? Do we agree that we should
support something like "pre-create" collections? Have we done a security audit
of the merged code and are we sure that the containers are production ready and
secure? These are questions I'd have appreciated if we discussed before diving
straight into a code merge.
{quote}
So I think that these questions are much more easily addressed now. The
consensus from the various discussions on the topic was that the code should be
migrated to lucene-solr. Now that the (peer-reviewed) code lives in
lucene-solr, all of these implementation questions are relatively independent,
and can be addressed without blocking each other. If you look at the parent
issue, SOLR-14168, there are many tasks that are on the roadmap. The work on
these items can be done in manageable chunks. That PR was never meant to be a
"final product". This was to get us started so that we can more easily improve
it for the 9.0 release.
There are really good ideas around reducing the footprint of
{{/solr/docker/include/scripts}} (formerly {{docker-solr/scripts}}), but
working on and testing these ideas will be much easier having all of the code
in one place. For example, you can take functionality from docker/scripts and
add it to solr/bin, or solr itself, and have a one step build and test.
I think a security audit would be great, but wouldn't that also be necessary
when bringing it in as a separate repo? I honestly think that would be a very
valuable thing to add as a gradle task in this module. Can you create a Jira
under the parent ticket to get a security audit created? I'm by no means a
security expert, so while I'm happy to help with the work I should probably not
be defining the problem.
Side note, we don't use alpine for anything. Mike brought up this concern in
the PR and it was replaced with {{scratch}}.
{quote}non-essential to Solr's core
{quote}
I don't necessarily agree with this. It is clear that much of the world is
moving to containerized/serverless deployments. Using Solr in a container
should be a fully supported paradigm, just as we support unix and windows
systems through {{solr/bin}}. Also having the image as a part of the official
project will help us move Solr in the direction of being more docker
friendly/cloud native.
As for the increase in PRs/JIRA issues. I would hope that a lot of the
questions move to the mailing lists, which I have seen used already. There are
less than 15 PRs from docker-solr over the last year that are actually relevant
to it's current form in {{lucene-solr}}, so I don't think it's going to be a
large burden to deal with. If there are a large number of PRs, then that's even
better. We'll have an even greater docker image for the future!
> Absorb and maintain docker-solr functionality for Solr 9.0+
> -----------------------------------------------------------
>
> Key: SOLR-14789
> URL: https://issues.apache.org/jira/browse/SOLR-14789
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
> Affects Versions: master (9.0)
> Reporter: Houston Putman
> Assignee: Houston Putman
> Priority: Blocker
> Fix For: master (9.0)
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Migrate the docker image building and testing from the
> [https://github.com/docker-solr/docker-solr] repo into Solr. This is only
> applicable for 9.0+. Backporting Docker functionality to Solr 8x will be
> handled separately.
>
> This is meant to be a first pass migration and not solve all issues. The goal
> is:
> * Docker images be built in a flexible way that will allow for release and
> local builds to share the same business logic
> * Building and testing should be integrated with the gradle build
> * Maintain current usage documentation in their current form, but
> documentation on building images should go in the ref-guide. The usage
> documentation will be migrated separately.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
