take advantage of k8s native staetfulset spec instead of defining a custom one in the form of PodOptions in custom_types.go

[swarupdonepudi]

Is your feature request related to a problem? Please describe. current version of the operator uses a custom type for podspec - https://github.com/bloomberg/solr-operator/blob/master/api/v1beta1/common_types.go#L49. This requires us to update this whenever we would like to add something to the solrcloud pod that is already supported by a k8s pod spec - https://github.com/kubernetes/api/blob/master/core/v1/types.go#L2842

Describe the solution you'd like Use k8s native podspec api for defining the pod spec in solrcloud statefulset podspec - https://github.com/kubernetes/api/blob/master/core/v1/types.go#L2842 should be used instead of https://github.com/bloomberg/solr-operator/blob/master/api/v1beta1/solrcloud_types.go#L102

Describe alternatives you've considered Continue with the current structure and rollout a new version of operator everytime we want to add support for something that is already supported by k8s pod spec but not defined in our custom spec

Additional context and this is applicable for all the other resources not just podspec.

the current spec for solrcloud custom resource looks like this after removing all the comments and stuff

type SolrCloudSpec struct {
	Replicas              *int32
	ZookeeperRef          *ZookeeperRef
	SolrImage             *ContainerImage
	SolrPod               SolrPodPolicy
	DataPvcSpec           *corev1.PersistentVolumeClaimSpec
	BackupRestoreVolume   *corev1.VolumeSource
	CustomSolrKubeOptions CustomSolrKubeOptions
	BusyBoxImage          *ContainerImage
	SolrJavaMem           string
	SolrOpts              string
	SolrLogLevel          string
	SolrGCTune            string
}

this is how I think it should be

type SolrCloudSpec struct {
        Solr     StatefuleSetSpec(k8s)
	Zookeeper ZookeeperSpec
}

type ZookeeperSpec {
       Replicas int
}

the above structure is only a rough sketch but that kind of gives the idea. The native k8s StatefuleSetSpec will enable the users to use whatever is already supported by k8s native statefulset spec in solrcloud spec.

[swarupdonepudi]

if @HoustonPutman and other parties involved agree to this proposal I can start working on it.

[HoustonPutman]

Sorry @swarupdonepudi don't know how I missed this. I definitely think that we can cleanup the SolrCloud spec, like grouping all of the Solr paramteres (GC, Log, Opts, Mem, etc) under a common parent.

I'm not sure I agree that the solr properties should be replaced by a statefulSet specification... I think one of the main purposes of having the SolrCloud CRD is to abstract out the underlying kubernetes resources that are being created by the operator. So someone could come and use Solr on kube knowing very little about Kubernetes itself. Beyond that, the operator creates Services, Ingresses, etc. that wouldn't be encompassed by the StatefulSetSpec.

Could you give me an example of defining an example SolrCloud with your proposed CRD?