server_id not truly unique

[Morgan Jones]

During instance creation, a "unique" server_id is generated for each trove instance. The server_id is derived from the instance id modulo 65535, which of course is not truly unique. This has not been an issue to date, but the replication feature relies on the server_ids being unique. Eventually, a non-unique server_id will be generated within a master/slave set and replication will fail.

We need to come up with a better way of assigning server_ids.

See trove/common/template.py:_calculate_unique_id()

[Amrith Kumar (amrith)]

Why is the importance of this "Low"?

Morgan, what are the consequences of not having a unique server id?

[Denis M. (dmakogon)]

The importance is 'Low' since this bug only affects specific replication set.
The probability of ID's collision is 1/2^16 -1
And as i can see, nobody does replication deployment with 2^16-1 slaves. This is why it's LOW.

[Denis M. (dmakogon)]

But i do agree that it should be fixed.

[Morgan Jones (6-morgan)]

Replication will not work if the server ids are not unique.

It is not necessary for someone to have 2^16 slaves to run into this problem, it could happen to anyone at any time. However, I don't disagree with this being classified LOW, though it should be fixed in Kilo.

[Amrith Kumar (amrith)]

Why Kilo? What about Juno?

[Nikhil Manchanda (slicknik)]

Spoke to Morgan regarding this, and we're good with moving it out to Kilo since it's not critical for Juno.