[Doc] Bridge integration doc

[sknot-rh]

Type of change

• Documentation

Description

Bridge integration doc. Realted to #1641

Checklist

Please go through this checklist and make sure all applicable tasks have been done

• Update/write design documentation in ./design
• Write tests
• Make sure all tests pass
• Update documentation
• Check RBAC rights for Kubernetes / OpenShift roles
• Try your changes from Pod inside your Kubernetes and OpenShift cluster, not just locally
• Reference relevant issue(s) and close them after merging
• Update CHANGELOG.md

[d-laing]

I produced a local build using AsciiDoctor but cannot see the Kafka Bridge content. It looks like you need to add the assembly-deployment-configuration-kafka-bridge.adoc file to the assembly-deployment-configuration assembly .

Are there any further parent assemblies that need updating?

[sknot-rh]

That is because this PR is dependent on #1641
There are generated some resources from the CRD.
This PR is just docs and is not working without PR mentioned above.

[d-laing]

I understand about the auto-generated content. However, I think you do need to add assembly-deployment-configuration-kafka-bridge.adoc to the assembly-deployment-configuration assembly.

[PaulRMellor]

Looks good. I've left a few suggestions. I have a couple of questions on the Healthchecks and Scheduling sections. The sections may be fine in terms of content required, but I've flagged for checking just in case.

[scholzj]

I left some comments. I think this is missing two major parts:

• Exposing the Bridge ... this should suggest to the users to create their own routes, node-ports or load-balancers if needed (and warn them about security consequences of that).
• Securing the bridge ... could for example suggest to write your own network policies to manage the access to the bridge.

I think these have to be added to this PR. (but the code needs to be finished first so that we can do RC1)

[PaulRMellor]

I left some comments. I think this is missing two major parts:

• Exposing the Bridge ... this should suggest to the users to create their own routes, node-ports or load-balancers if needed (and warn them about security consequences of that).
• Securing the bridge ... could for example suggest to write your own network policies to manage the access to the bridge.

I think these have to be added to this PR. (but the code needs to be finished first so that we can do RC1)

@laidan6000 @stanlyDoge - this new content will be picked up in another PR.

[d-laing]

Looks good from a docs POV.

[PaulRMellor]

@scholzj @ppatierno - ready to merge?

[ppatierno]

I am not sure about this section. Due to our problem with consumers which have to connect to the same bridge instance where the consumer were created, as we mentioned in the past we cannot run the bridge with multiple replicas but having just one and for HA maybe more bridge deployment with just one replica. @scholzj wdyt?

[scholzj]

Well, having multiple bridge instances with a single replica will not be HA. Because either you have one service handling them all in case you have the same issues with case you have the same issues as with single instance in multiple replicas. Or you use different services in which case you can hardly call it HA because clients will need to reconfigure to fail over.

That said, maybe this section of the docs should do more about describing the problems with multiple replicas than explain around HA.

[sknot-rh]

From examples/kafka-connect/kafka-connect.yaml

  tls:
    trustedCertificates:
      - secretName: my-cluster-cluster-ca-cert
        certificate: ca.crt

Are we sure about the indentation?

[scholzj]

Both are valid and working. This:

  tls:
    trustedCertificates:
      - secretName: my-cluster-cluster-ca-cert
        certificate: ca.crt

has the same meaning as this:

  tls:
    trustedCertificates:
    - secretName: my-cluster-cluster-ca-cert
      certificate: ca.crt

I usually prefer the first one as I find it more readable. But I think that most editors will format into the second. Either way in both case the secret reference will be in the hierarchy under the trustedCertificates.

[d-laing]

@stanlyDoge - Please can you combine the OCP and Kubernetes deployment procedures into a single procedure and apply IF statements. Please ask if you're unsure.