eventhub-scaler works on new hubs where initially no storage checkpoint exists

[christle]

eventhub-scaler can scale even when no storage checkpoint exists.

To scale up without checkpoint, the first calculation based only on eventhub partition infos. The tricky part was to differentiate between a partition without messages and exactly 1 unprocessed message.

Fixes #797

[jeffhollan]

Thank you @christle - it may have been this same issue but I'd even seen issues where checkpoints exist (in that Azure Storage has partition records), but the offset was null becaues that partition had never received a message. Do you know if this will catch that case too?

[christle]

Hi @jeffhollan, as fas as i know, the scaler ignores the offset value, so this pr dont fix this issue. But i have made a similar observation for the offset and have an idea, what's the cause for this and in which case it's happening. It took's me a while to find this out.
In our project, we have some hubs in our Eventhub and everything works with keda as expected, but then we add a new hub for an Endpoint from an IOT hub and with or without messages, the scaler scales out to the maximum pod number. The offset inside the checkpoint where null. Like i said the offset is ingored by the scaler, but in this case the lastsequencenumber inside the partition stays on -1. No matter how much messages comes from the IOT hub Endpoint. With -1 the scaler runs inside the azure_eventhub_scaler.go file to this line:

unprocessedEventCountInPartition = (math.MaxInt64 - partitionInfo.LastSequenceNumber) + checkpoint.SequenceNumber

I think this should ends in an overflow Exception.The result is, the scaler returns an very high metric value (everytime the same value, no matter how much messages).

I dont know why messages, which are routed from the IOT Hub to an EventHub, don't increase the lastsequencenumber and the offset, but i think the scaler should ignore the -1 and do nothing instead of scaling up.

[SatishRanjan]

This is the redundant call to GetPartitionInformation for Partition id in GetUnprocessedEventCountInPartition, we can pass the reference of partitionInfo eventhub.HubPartitionRuntimeInformation from IsActive and GetMetrics methods where this information has already been retrieved. Other than that this change will solve the issue of "Until the an event hub processor is scaled to at least 1 manually, the keda-operator will never be able to get the checkpoint data"

[christle]

Ok thank you. I can change that. But now there are some merge conflicts. I will try to fix it.

[christle]

in isActive is no partitionInfo, only runtimeInfo but i can add it

[christle]

ok i'm done. I eliminate one call to GetPartitionInformation and fix the merge conflicts.

[ahmelsayed]

Thanks @christle for your contribution :)