[
https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195851#comment-17195851
]
Ishan Chattopadhyaya edited comment on SOLR-14789 at 9/15/20, 3:55 AM:
-----------------------------------------------------------------------
bq. There isn't discussion on this ticket, but that doesn't mean that there
wasn't discussion happening. Discussion happened on JIRA, the dev list, slack
and obviously the github PR. I think that covers the bases pretty well.
I see. It seems this JIRA is a victim of poor JIRA management practices that
confused me. The JIRA should've linked to the older JIRA (particularly to the
comments where it was reasoned that this code should be in lucene-solr), dev
list discussion etc.
bq. I'm also not sure how this was a code dump.
This is a code dump from Martijn that we absorbed in lucene-solr project.
There's nothing particularly wrong about it, but I would've appreciated
discussion around design choices made in this area. 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.
bq. I very much believe that the code that generates the solr docker image
should live in the same repo as Solr, and I'm happy to discuss that further.
One of my concerns with having this code in lucene-solr is a potential flurry
of JIRAs and PRs against our main repository that are non-essential to Solr's
core. Can this entire codebase be in a separate repository which is a git
sub-module of lucene-solr, so that it can be used to build Solr images, yet
stay out of the way sufficiently reasonably when it comes to code changes?
was (Author: ichattopadhyaya):
bq. There isn't discussion on this ticket, but that doesn't mean that there
wasn't discussion happening. Discussion happened on JIRA, the dev list, slack
and obviously the github PR. I think that covers the bases pretty well.
I see. It seems this JIRA is a victim of poor JIRA management practices that
confused me. The JIRA should've linked to the older JIRA, dev list discussion
etc.
bq. I'm also not sure how this was a code dump.
This is a code dump from Martijn that we absorbed in lucene-solr project.
There's nothing particularly wrong about it, but I would've appreciated
discussion around design choices made in this area. 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.
bq. I very much believe that the code that generates the solr docker image
should live in the same repo as Solr, and I'm happy to discuss that further.
One of my concerns with having this code in lucene-solr is a potential flurry
of JIRAs and PRs against our main repository that are non-essential to Solr's
core. Can this entire codebase be in a separate repository which is a git
sub-module of lucene-solr, so that it can be used to build Solr images, yet
stay out of the way sufficiently reasonably when it comes to code changes?
> 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: [email protected]
For additional commands, e-mail: [email protected]
