[FORWARD-PORT] Add NODE_AWARE metadata support #281
Conversation
* Add NODE_AWARE metadata support With 3.12.11 IMDG release, new metadata introduced to define partition group based on Kubernetes node that Hazelcast cluster runs on.The discovery plugin should pass name of the node to the core SPI via using discoverLocalMetadata method like zone info. This method passes both zone and node name metadata. User can not enable tow group types at the same time so cluster will decide which metadata will be used based on cluster config.
hasancelik
requested review from
alparslanavci
and removed request for
a team and
alparslanavci
pom.xml
Outdated
| <findbugs.annotations.version>3.0.1u2</findbugs.annotations.version> | ||
|
|
||
| <hazelcast.version>4.1</hazelcast.version> | ||
| <hazelcast.version>4.1.1-SNAPSHOT</hazelcast.version> |
There was a problem hiding this comment.
Using constant does not feel right actually 🙂 we do not need to concern about backward compatibility at master branch, right? Also we have released plugin with IMDG snapshot dependency before:
https://github.com/hazelcast/hazelcast-kubernetes/blob/v2.1/pom.xml#L42
Putting constant again and release 2.2.1 with 4.1 dependency is ok for me as well btw. After IMDG 4.1.1 release, we can upgrade IMDG dependency to 4.1.1 and start use PartitionGroupMetaData.PARTITION_GROUP_NODE.
There was a problem hiding this comment.
I think we still should care about the backward-compatibility because not all users use hazelcast-all. Now, for example, if they use hazelcast:4.1 with hazelcast-kubernetes:2.2. And the see that hazelcast-kubernetes:2.2.1 was released, they may want to update. But it'll crash their app.
It's not actually about releasing from snapshot (because the dependency is provided), but about the code compatibility.
We don't always have to keep backward-compatibility and we describe compatibilities here, but this change is actually so small that I'd favor keeping backward compatibility than reusing this one constant.
There was a problem hiding this comment.
I think we still should care about the backward-compatibility because not all users use hazelcast-all. Now, for example, if they use hazelcast:4.1 with hazelcast-kubernetes:2.2. And the see that hazelcast-kubernetes:2.2.1 was released, they may want to update. But it'll crash their app.
I see, I totally missed out this scenario. I have reverted last commit 👍
2 participants
New metadata/group type introduced to define partition group based on Kubernetes node that Hazelcast cluster runs on. The discovery plugin should pass name of the node to the core SPI via using
discoverLocalMetadatamethod like zone info. This method passes bothzoneandnode namemetadata. User can not enable two group types at the same time so cluster will decide which metadata will be used based on cluster config:Here is the related PRD.
(cherry-picked from commit 9f70794)
forward-port of #278