Tigera operator (post-migration) fails to work if some pods have ips not in cluster pod CIDR about operator HOT 5 OPEN

As a work around for you right now you should be able to set the CIDRs in the Installation resource to match the kubeadm configuration. This will be fine because the operator currently does not reconcile the IPPools defined in the Installation resource with the existing IPPools, so since the default IPPools are already created, it will not try to change/add/update the existing IPPools.
You should make sure the IPPools you define in the Installation resource do match the existing IPPools fields encapsulation and natOutgoing fields.

from operator.

This will be more important long term as well. Kubernetes is adding the ability to have multiple cluster CIDRs in the near future, so we'll need to keep our logic insync with that.

Might be worth converting this to a warning sooner rather than later, and stop blocking the operator from doing its work. I don't think we have a great mechanism to implement that right now, but it would be useful.

from operator.

I'm not sure where we could put a warning that the user would see. Is this a use case for adding another "tigerastatus" column/field that would report this issue but nothing would be blocked on it?
I feel like this wouldn't be noticed then unless there was some other issue, but maybe that would be good enough to give the user a pointer to what might be wrong in the case of something else being broken.

from operator.

from operator.

What issues does it actually cause?

The issues that would happen is that traffic may get NAT'ed when it shouldn't be which would cause problems with policy not applying correctly (block traffic that should be allowed but since it is coming from an unexpected IP it is blocked).

from operator.