Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

operator/upgrade: switch from kafka to admin API for redpanda readiness #1159

Merged
merged 7 commits into from
Apr 15, 2021

Conversation

dimitriscruz
Copy link
Contributor

@dimitriscruz dimitriscruz commented Apr 14, 2021

Cover letter

  1. With the introduction of SASL, calling any Kafka listener requires credentials. Although that is possible to do from the operator, it adds complexity.
  2. It is our intention to use an upgrade-specific endpoint, which would be part of the http Admin API (not the Kafka API)

Due to the above, this PR changes the operator behavior such that it check the redpanda readiness using the Admin API. Since we don't have the ideal endpoint at the moment, we start by using v1/state/ready with the intention to develop an appropriate endpoint in the (hopefully near) future.

Copy link
Contributor

@alenkacz alenkacz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't we use readiness probe for this? The advantage of that would be that the pod would be properly in API marked as non-ready until ready which has implication for all kind of stuff like registering services etc. Also it's transparent for anyone using the kubernetes API...

@dimitriscruz
Copy link
Contributor Author

can't we use readiness probe for this? The advantage of that would be that the pod would be properly in API marked as non-ready until ready which has implication for all kind of stuff like registering services etc. Also it's transparent for anyone using the kubernetes API...

Given that this PR uses v1/state/ready, we might be able to use a readiness probe. However, the point of this PR is to prepare for an upgrade-specific endpoint, which wouldn't apply as a generic one.

alenkacz
alenkacz previously approved these changes Apr 14, 2021
Copy link
Contributor

@alenkacz alenkacz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, can you run go mod tidy though? I think the sarama dep should go away

@@ -112,6 +112,7 @@ func (r *ClusterReconciler) Reconcile(
pki.OperatorClientCert(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is getting really bad, I need to take a look at this

Copy link
Contributor Author

@dimitriscruz dimitriscruz Apr 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, maybe we could group them together in structs like "pkiInfo"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly for the services

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did go mod tidy also. No sarama dep anymore.


// TODO right now we support TLS only on one listener so if external
// connectivity is enabled, TLS is enabled only on external listener. This
// will be fixed by https://github.com/vectorizedio/redpanda/issues/1084
if !r.pandaCluster.Spec.ExternalConnectivity.Enabled && r.pandaCluster.Spec.Configuration.TLS.KafkaAPI.Enabled {
if !r.pandaCluster.Spec.ExternalConnectivity.Enabled && r.pandaCluster.Spec.Configuration.TLS.AdminAPI.Enabled {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now that we have admin api with multiple interfaces, should we update this PR too ?

maybe choose the internal IP (but keep the tls check) so that at least the traffic doesn't go out through the internet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have an external listener but do not expose it in the API yet. This check is based on the API fields. So, we have the following convention: if TLS is enabled we apply it to the external listener. If there is no external listener (external connectivity is disabled), we apply the TLS to the internal listener.

Once #1163 is merged, we'll update this line and be explicit about the listener.

Copy link
Contributor Author

@dimitriscruz dimitriscruz Apr 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But just to be clear, we are using the internal listener here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense.

@dimitriscruz dimitriscruz marked this pull request as ready for review April 15, 2021 05:26
@dimitriscruz dimitriscruz requested a review from a team as a code owner April 15, 2021 05:26
RafalKorepta
RafalKorepta previously approved these changes Apr 15, 2021
@emaxerrno emaxerrno merged commit d6f57e2 into redpanda-data:dev Apr 15, 2021
@dimitriscruz dimitriscruz deleted the image-update branch April 16, 2021 00:12
joejulian pushed a commit to joejulian/redpanda that referenced this pull request Mar 10, 2023
…-update

operator/upgrade: switch from kafka to admin API for redpanda readiness
joejulian pushed a commit to joejulian/redpanda that referenced this pull request Mar 24, 2023
…ge-update

operator/upgrade: switch from kafka to admin API for redpanda readiness
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants