Add SessionAffinity and SessionAffinityConfig fields to ServiceOptions

[trevorpburke]

Attempts to address: #535

[HoustonPutman]

This is a great start!

So what you have done is make the configuration available in the CRD. So the user can now provide it, however it doesn't actually set the configuration on the underlying Services that are created for the SolrCloud/PrometheusExporter.

So we still need to:

• add the controller logic to set these fields when creating services
• make sure the fields are copied correctly when updating the services
• add tests to ensure the fields are propagated correctly
• Add helm chart options

If you want an example of a PR that does something very similar, you can look here: #350

I'm happy to contribute too, I just don't want to step on your toes! Let me know how I can help 🙂

[HoustonPutman]

Suggested change

	// +optional
	// +optional
	// +kubebuilder:default=None
	// +kubebuilder:validation:Enum=None,ClientIP

So we can actually put the default, and the enum constraints into the CRD itself using Kubebuilder CRD markers!

[trevorpburke]

Ah, neat code-gen

[HoustonPutman]

Suggested change

	SessionAffinityConfig corev1.SessionAffinityConfig `json:"sessionAffinityConfig,omitempty"`
	SessionAffinityConfig *corev1.SessionAffinityConfig `json:"sessionAffinityConfig,omitempty"`

Making this field a pointer, makes it easier for us to know whether the user provided one or not!

[trevorpburke]

Makes sense

[trevorpburke]

This is a great start!

So what you have done is make the configuration available in the CRD. So the user can now provide it, however it doesn't actually set the configuration on the underlying Services that are created for the SolrCloud/PrometheusExporter.

So we still need to:

• add the controller logic to set these fields when creating services
• make sure the fields are copied correctly when updating the services
• add tests to ensure the fields are propagated correctly
• Add helm chart options

If you want an example of a PR that does something very similar, you can look here: #350

I'm happy to contribute too, I just don't want to step on your toes! Let me know how I can help 🙂

Thanks for the feedback. I think I addressed updating the helm/ files that were changed in the PR you linked. Can you share which of those files in #350 are generated vs manually written?

AFAICT it looks like I need to also update controllers/util/solr_util.go, controllers/util/prometheus_exporter_util.go, and controllers/util/common.go.

Also, make prepare is failing for me, but guessing that's because I need to add to the controllers/util/ files and the accompanying tests

[HoustonPutman]

The changes look good so far! Just a few comments.

Now for actually implementing and testing!

There are three places to implement this logic.

In controllers/util/solr_util.go:GenerateCommonService(). That is what generates the common service for the solrCloud, so that's where we need to take these options from the SolrCloud and pass it to the Service.

In controllers/util/prometheus_exporter_util.go:GenerateSolrMetricsService(). This should be exactly (or almost exactly) the same logic as used above. We just need to support the same thing for the prometheus exporter, since it's a shared option amongst all services.

In controllers/util/common.go:CopyServiceFields(). This is where we update the existing service with what our "expected state" of the service is. So we are copying from the from service to the to service. You can basically copy and paste those if statements, using new ones for sessionAffinity and sessionAffinityConfig.

Then our last step will be testing!

[HoustonPutman]

These (the default and enum lines) were meant to be put up above with sessionAffinity, not sessionAffinityConfig.

[HoustonPutman]

Also just a thought, but we are giving users the option for the headlessService and podService, but those really don't need sessionAffinity, because they are meant to send requests to a single pod, so affinity doesn't matter. So I'm fine leaving those undocumented and unused.