[prev in list] [next in list] [prev in thread] [next in thread]
List: lucene-dev
Subject: Re: [DISCUSS] Solr Operator grant to Apache Lucene
From: Houston Putman <houstonputman () gmail ! com>
Date: 2020-10-23 15:36:15
Message-ID: CAD4GwrMZ_G-vzTGEXysyUSusAb9_4VKEL-WwopVHqvRX=9SMEQ () mail ! gmail ! com
[Download RAW message or body]
I can answer a few of those!
I assume this is a donation to Solr project, so it will be an
> apache/solr-operator project, similar to how it is currently
> lucene-solr?
>
Yes, the target would be apache/solr-operator. Similar to
apache/rocketmq-operator <https://github.com/apache/rocketmq-operator>.
How does this interplay with Docker that IS in-project?
>
Currently the Dockerfile that is in-project (Solr 9+), is pretty much
identical to the one in docker-solr (Solr 8-).
There is no real difference between the two currently, therefore both are
supported by the Solr Operator.
If the solr/docker image begins to diverge, we will make sure that the
solr-operator supports it since that will be the official Solr docker image
starting in Solr 9.
Currently the Solr Operator does not have a minimum version of Solr that it
supports, as long as the Solr image is setup the same way as the official
image.
We can begin to start enforcing minimum supported Solr versions if there
are newer Solr features that we want to utilize within the operator. But
there are no current plans to do that .
- Houston
On Fri, Oct 23, 2020 at 9:38 AM Alexandre Rafalovitch <arafalov@gmail.com>
wrote:
> What would this practically look like if it is adopted/accepted? Given
> the Lucene and Solr separating as an additional wrinkle.
>
> I assume this is a donation to Solr project, so it will be an
> apache/solr-operator project, similar to how it is currently
> lucene-solr? Would the committers be the same or is it kind of a new
> set? Or more like a first-party package?
>
> How does this interplay with Docker that IS in-project?
>
> I am neither plus nor minus on this, just putting the questions that I
> feel would benefit being clarified.
>
> Regards,
> Alex.
>
> On Fri, 23 Oct 2020 at 03:32, Anshum Gupta <anshum@anshumgupta.net> wrote:
> >
> > Hi everyone,
> >
> > Recently, Bloomberg reached out to us to donate the Solr Operator[1]
> codebase to the Apache Lucene project.
> >
> > Built on the Kube Builder framework, Solr Operator would help in
> standardizing the way SolrCloud clusters are managed in Kubernetes. This
> will allow the community to converge and share best practices around
> managing SolrCloud in k8s world.
> >
> > The PMC has spent the last few weeks discussing the merits and concerns
> around the grant and intends to move forward with it unless there are
> concerns that the community has around it.
> >
> > Thanks to Tim, here's a detailed document around the design of Solr
> Operator, this should answer most questions around the technicality of the
> project -
> https://docs.google.com/document/d/1uQiJcE7kW5c6iEl9zG1Ve9MTEUGY7OHnMHX8PuTqpY8/edit?usp=sharing
> >
> > I'd also like to summarize the PMC discussions to help reduce repeating
> walking down the same path.
> >
> > Q: Why is having an operator important for the project?
> > A: In todays' world of cloud native technologies, Kubernetes is an
> essential part of most modern platforms. A Kubernetes Operator allows the
> users of Apache Solr to deploy SolrCloud clusters on k8s while allowing the
> people who understand the system, to codify our collective knowledge about
> how SolrCloud should be operated.
> >
> > Q: Do we want to maintain the Kubernetes operator as part of the Apache
> Lucene project?
> > A: Yes, the operator will become an essential part of Solr as K8s
> adoption grows. Instead of pointing users at third party documentation and
> supporting projects, it would be good to have something that is supported
> by the Solr community. Also, as a separate repository, with a release
> cadence that doesn't restrict Lucene/Solr releases, the Kubernetes Operator
> will create a lot of value for users.
> >
> > Q: Have we reviewed the design of the operator before accepting the
> grant?
> > A: The project has a lot of commits from Houston, who's an existing
> committer. Also, Tim (Timothy Potter) has gone through the code and has
> PRs. His document above also provides a lot of insight into the operator
> for the rest of us. Overall, the code seems good and the code is in
> reasonable shape to be accepted and improved.
> >
> > Q: Should we allow the Operator to be incubated as its own project
> instead? If not, why?
> > A: This was considered, but after discussing the pros and cons around
> having the operator come in via the incubator, it was decided otherwise.
> >
> > Q: This is written in a different language i.e. Go. How do we handle
> that? Can we not find something in Java instead ?
> > A: Go is the de-facto language for Kubernetes. We would not get the same
> amount of tooling and support for Kubernetes in Java as Go. As this is the
> right language to move forward with the operator, all of us running
> SolrCloud in K8s will be learning and working with it anyways. We will also
> certainly get questions around it from users, and it makes sense for us to
> lead that instead of catch up. This way we will also attract more
> contributors who know Go and Kubernetes in the future. Most importantly, a
> separate repository will allow us to keep things easy to manage.
> >
> > Q: What about the operator release cadence?
> > A: The operator and Lucene/Solr would have independent release cadence.
> >
> > We would like to give the community a week i.e. until 30th of October,
> 2020 to discuss this so the PMC can make an informed decision.
> >
> > Looking forward to a healthy discussion.
> >
> > [1] https://github.com/bloomberg/solr-operator
> >
> > --
> > Anshum Gupta
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
[Attachment #3 (text/html)]
<div dir="ltr">I can answer a few of those!<div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">I assume this is a donation to Solr project, so it \
will be an<br>apache/solr-operator project, similar to how it is \
currently<br>lucene-solr?<br></blockquote><div><br></div><div>Yes, the target would \
be apache/solr-operator. Similar to <a \
href="https://github.com/apache/rocketmq-operator">apache/rocketmq-operator</a>.</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">How does this interplay with Docker that IS \
in-project?<br></blockquote><div><br></div><div>Currently the Dockerfile that is \
in-project (Solr 9+), is pretty much identical to the one in docker-solr (Solr \
8-).</div><div>There is no real difference between the two currently, therefore both \
are supported by the Solr Operator.</div><div>If the solr/docker image begins to \
diverge, we will make sure that the solr-operator supports it since that will be the \
official Solr docker image starting in Solr 9.</div><div><br></div><div>Currently the \
Solr Operator does not have a minimum version of Solr that it supports, as long as \
the Solr image is setup the same way as the official image.</div><div>We can begin to \
start enforcing minimum supported Solr versions if there are newer Solr features that \
we want to utilize within the operator. But there are no current plans to do that \
.</div><div><br></div><div>- Houston</div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Fri, Oct 23, 2020 at 9:38 AM Alexandre Rafalovitch \
<<a href="mailto:arafalov@gmail.com">arafalov@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What would this \
practically look like if it is adopted/accepted? Given<br> the Lucene and Solr \
separating as an additional wrinkle.<br> <br>
I assume this is a donation to Solr project, so it will be an<br>
apache/solr-operator project, similar to how it is currently<br>
lucene-solr? Would the committers be the same or is it kind of a new<br>
set? Or more like a first-party package?<br>
<br>
How does this interplay with Docker that IS in-project?<br>
<br>
I am neither plus nor minus on this, just putting the questions that I<br>
feel would benefit being clarified.<br>
<br>
Regards,<br>
Alex.<br>
<br>
On Fri, 23 Oct 2020 at 03:32, Anshum Gupta <<a \
href="mailto:anshum@anshumgupta.net" target="_blank">anshum@anshumgupta.net</a>> \
wrote:<br> ><br>
> Hi everyone,<br>
><br>
> Recently, Bloomberg reached out to us to donate the Solr Operator[1] codebase to \
the Apache Lucene project.<br> ><br>
> Built on the Kube Builder framework, Solr Operator would help in standardizing \
the way SolrCloud clusters are managed in Kubernetes. This will allow the community \
to converge and share best practices around managing SolrCloud in k8s world.<br> \
><br> > The PMC has spent the last few weeks discussing the merits and concerns \
around the grant and intends to move forward with it unless there are concerns that \
the community has around it.<br> ><br>
> Thanks to Tim, here's a detailed document around the design of Solr Operator, \
this should answer most questions around the technicality of the project - <a \
href="https://docs.google.com/document/d/1uQiJcE7kW5c6iEl9zG1Ve9MTEUGY7OHnMHX8PuTqpY8/edit?usp=sharing" \
rel="noreferrer" target="_blank">https://docs.google.com/document/d/1uQiJcE7kW5c6iEl9zG1Ve9MTEUGY7OHnMHX8PuTqpY8/edit?usp=sharing</a><br>
><br>
> I'd also like to summarize the PMC discussions to help reduce repeating walking \
down the same path.<br> ><br>
> Q: Why is having an operator important for the project?<br>
> A: In todays' world of cloud native technologies, Kubernetes is an essential \
part of most modern platforms. A Kubernetes Operator allows the users of Apache Solr \
to deploy SolrCloud clusters on k8s while allowing the people who understand the \
system, to codify our collective knowledge about how SolrCloud should be \
operated.<br> ><br>
> Q: Do we want to maintain the Kubernetes operator as part of the Apache Lucene \
project?<br> > A: Yes, the operator will become an essential part of Solr as K8s \
adoption grows. Instead of pointing users at third party documentation and supporting \
projects, it would be good to have something that is supported by the Solr community. \
Also, as a separate repository, with a release cadence that doesn't restrict \
Lucene/Solr releases, the Kubernetes Operator will create a lot of value for \
users.<br> ><br>
> Q: Have we reviewed the design of the operator before accepting the grant?<br>
> A: The project has a lot of commits from Houston, who's an existing committer. \
Also, Tim (Timothy Potter) has gone through the code and has PRs. His document above \
also provides a lot of insight into the operator for the rest of us. Overall, the \
code seems good and the code is in reasonable shape to be accepted and improved.<br> \
><br> > Q: Should we allow the Operator to be incubated as its own project \
instead? If not, why?<br> > A: This was considered, but after discussing the pros \
and cons around having the operator come in via the incubator, it was decided \
otherwise.<br> ><br>
> Q: This is written in a different language i.e. Go. How do we handle that? Can \
we not find something in Java instead ?<br> > A: Go is the de-facto language for \
Kubernetes. We would not get the same amount of tooling and support for Kubernetes \
in Java as Go. As this is the right language to move forward with the operator, all \
of us running SolrCloud in K8s will be learning and working with it anyways. We will \
also certainly get questions around it from users, and it makes sense for us to lead \
that instead of catch up. This way we will also attract more contributors who know Go \
and Kubernetes in the future. Most importantly, a separate repository will allow us \
to keep things easy to manage.<br> ><br>
> Q: What about the operator release cadence?<br>
> A: The operator and Lucene/Solr would have independent release cadence.<br>
><br>
> We would like to give the community a week i.e. until 30th of October, 2020 to \
discuss this so the PMC can make an informed decision.<br> ><br>
> Looking forward to a healthy discussion.<br>
><br>
> [1] <a href="https://github.com/bloomberg/solr-operator" rel="noreferrer" \
target="_blank">https://github.com/bloomberg/solr-operator</a><br> ><br>
> --<br>
> Anshum Gupta<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe, e-mail: <a href="mailto:dev-unsubscribe@lucene.apache.org" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> For additional commands, \
e-mail: <a href="mailto:dev-help@lucene.apache.org" \
target="_blank">dev-help@lucene.apache.org</a><br> <br>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic