[GitHub] [solr-operator] sda399 opened a new issue, #563: Status of the solr operator as of april 2023

["sda399 (via GitHub)" <gi...@apache.org>]

sda399 opened a new issue, #563:
URL: https://github.com/apache/solr-operator/issues/563

   Hi,
   what is the current status of Solr Operator. Is it production ready?
   
   My understaning from the readme is that Solr Operator is beta and maybe api modifications are possible in future releases.
   
   verbatim: "The project is currently in beta (v1beta1), and while we do not anticipate changing the API in backwards-incompatible ways there is no such guarantee yet."
   
   Could you please clarify and detail the sentence on the project status? runtime stable, dev api not frozen, production ok, still many bugs or code is frozen testing phase etc?
   
   regards


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org

[GitHub] [solr-operator] HoustonPutman commented on issue #563: Status of the solr operator as of april 2023

["HoustonPutman (via GitHub)" <gi...@apache.org>]

HoustonPutman commented on issue #563:
URL: https://github.com/apache/solr-operator/issues/563#issuecomment-1527750023

   Yes the Solr Operator is production ready, and has been used in production by multiple large companies. (Hard to actually get a sense for this. We hear from people as well as see people giving conference talks.)
   
   In a release or two, we will likely get a v1.0.0 release. The delay for this mostly lies in the expectations from Kubernetes in upgrading a CRD's version from `v1beta1` to `v1`. I would love for it to happen, but it requires a fair amount of code to achieve. It's much harder than just changing the version in the repo and saying "We are officially v1".
   
   And while we have contributors, there's not a lot of extra bandwidth to do a big project with minimal "impact" to actual capabilities.
   
   > while we do not anticipate changing the API in backwards-incompatible ways there is no such guarantee yet.
   
   This is somewhat true, and you can see in the version upgrade notes, that fields are moved and changed in minor versions (e.g. between `v0.6.0` and `v0.7.0`). However, if you do a rolling upgrade from `v0.5.0` to `v0.6.0` to `v0.7.0`, you will see no issues for existing resources. The Solr Operator will make sure to change/move the fields in the existing resources. You will just need to make sure that your new resources use the new CRD fields.
   
   So as long as you are ok looking at the upgrade notes before actually doing an upgrade, and upgrading one minor version at a time, you should see no issues with backwards incompatibility.
   
   > Could you please clarify and detail the sentence on the project status? runtime stable, dev api not frozen, production ok, still many bugs or code is frozen testing phase etc?
   
   Production ok for sure. There are pretty comprehensive end-to-end tests, and unit tests. It's been around for a while and has almost a million docker image downloads.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org