Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: deprecating named sharding #2723

Merged
merged 13 commits into from
Jul 9, 2024
Merged

Conversation

gabrielmer
Copy link
Contributor

@gabrielmer gabrielmer commented May 23, 2024

Description

Deprecating named sharding.

We won't allow further usage of named sharding and the default pubsub topic will be replaced by each cluster's 0 shard.

Another PR will follow in which we will deprecate the --pubsub-topic CLI configuration in favor of shard

Note

This PR will be merged after having announced the deprecation of named sharding during the next two releases (it will enter to v0.31.0). However, the general approach should be reviewed from now.

Issue

closes #2772

Copy link

This PR may contain changes to configuration options of one of the apps.

If you are introducing a breaking change (i.e. the set of options in latest release would no longer be applicable) make sure the original option is preserved with a deprecation note for 2 following releases before it is actually removed.

Please also make sure the label release-notes is added to make sure any changes to the user interface are properly announced in changelog and release notes.

@gabrielmer gabrielmer added the release-notes Issue/PR needs to be evaluated for inclusion in release notes highlights or upgrade instructions label May 23, 2024
Copy link

github-actions bot commented May 23, 2024

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:2723-rln-v1

Built from cd9ac42

Copy link

github-actions bot commented May 23, 2024

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:2723-rln-v2

Built from cd9ac42

Copy link
Collaborator

@Ivansete-status Ivansete-status left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for it! 🥳
I'm not approving yet because it is in draft
Cheers

tests/testlib/wakunode.nim Show resolved Hide resolved
waku/waku_core/topics/pubsub_topic.nim Show resolved Hide resolved
waku/waku_core/topics/pubsub_topic.nim Show resolved Hide resolved
@@ -300,12 +300,13 @@ type WakuNodeConf* = object

pubsubTopics* {.
desc: "Default pubsub topic to subscribe to. Argument may be repeated.",
defaultValue: @[],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we mark this pubsubTopic config attribute as deprecated? In that case, we will need to keep it for two more versions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the idea is to deprecate it and stop creating confusion/overlap between pubsubTopic and shard.
So we will have to keep it for 2 more releases (announcing the deprecation in the release notes) and afterwards create a new PR deprecating it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps add Deprecated in the desc?

@SionoiS
Copy link
Contributor

SionoiS commented May 30, 2024

Should we take this opportunity to remove the usage of strings for pubsub topics internally?

My idea would be to replace PubsubTopic = string with a proper type that can the turned into a formatted string if needed.

WDYT?

@@ -117,10 +117,16 @@ proc setupProtocols(
## Optionally include persistent message storage.
## No protocols are started yet.

var shardCount: uint32
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this. imho pubsubTopics.len shall be always >0?

pubsubTopics will be deprecated soon and this will be eg a cli flag shard-count or network-shards. but that's for another PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True! That was done because it made everything work better when I tested not setting anything in pubsub-topic and only setting shard.

But if we currently need to use pubsub-topic to list all the topics in the network, then it makes sense to add the logic similar to this in the next PR, the one deprecating pubsub-topic

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was done because it made everything work better when I tested not setting anything in pubsub-topic and only setting shard.

mm IMHO pubsub-topic has to be always set. It could be a default value (like when using clusterid=0 or 1) but it has to be set somewhere.

@@ -96,12 +96,6 @@ proc init*(T: type Waku, conf: WakuNodeConf): Result[Waku, string] =

case confCopy.clusterId

# cluster-id=0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why removing cluster-id=0 configuration?

maybe we should keep it but with just 1 shard? for backwards compatibility? unsure though if someone is using it.

I mean, cluster-id=0 currently was a single named "shard" (default pubsub topic). From an app PoV that is equivalent to autosharding with a single shard.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that after deprecating named sharding, cluster 0 was going to stop being a "special case".

Is there's any reason why we would want to keep the configuration of cluster 0 hardcoded? Once named sharding is deprecated, there won't be backward compatibility in any case

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

im ok with removing it. you are right with cluster 0 not being a special case anymore. But think also about the "known clusters" concept. Cluster configuration is not only about topics but also bootstrap nodes, validation strategy, etc.

so the question here is. do we want cluster-id=0 to be a "known cluster" with some specific configuration that people can use, or we don't care about that? imho nope, i would care only about TWN=1

but ccing @jm-clius

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now I think we should only care about TWN=1. Everything else is (equally) undefined.

@gabrielmer
Copy link
Contributor Author

Should we take this opportunity to remove the usage of strings for pubsub topics internally?

My idea would be to replace PubsubTopic = string with a proper type that can the turned into a formatted string if needed.

WDYT?

I like the idea! I think it's better to do it in a separate PR once named sharding is deprecated so we don't mix different things and make the PR too big

Copy link
Contributor

@jm-clius jm-clius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Long overdue! Thanks.

@@ -300,12 +300,13 @@ type WakuNodeConf* = object

pubsubTopics* {.
desc: "Default pubsub topic to subscribe to. Argument may be repeated.",
defaultValue: @[],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps add Deprecated in the desc?

@gabrielmer
Copy link
Contributor Author

Perhaps add Deprecated in the desc?

How? Like this?

desc: "Deprecated. Default pubsub topic to subscribe to. Argument may be repeated.",

We can, although I will remove the pubsubTopics configuration in the next PR and both will be merged at the same time (roughly in 2 months), so the change won't really make it to master in practice. Now that I think about it, adding a default value to it also will never make it, I should probably remove that change :))

@gabrielmer gabrielmer force-pushed the chore-deprecating-named-sharding branch 3 times, most recently from 65cb4f5 to 32675a8 Compare June 10, 2024 12:32
@Ivansete-status Ivansete-status added this to the v0.31.0 milestone Jun 25, 2024
apps/chat2/config_chat2.nim Show resolved Hide resolved
apps/chat2bridge/config_chat2bridge.nim Show resolved Hide resolved
apps/liteprotocoltester/README.md Show resolved Hide resolved
apps/liteprotocoltester/README.md Show resolved Hide resolved
docs/operators/how-to/run.md Show resolved Hide resolved
examples/cbindings/waku_example.c Show resolved Hide resolved
waku/factory/external_config.nim Outdated Show resolved Hide resolved
waku/factory/waku.nim Show resolved Hide resolved
Copy link

github-actions bot commented Jul 2, 2024

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:2723

Built from 71e06e0

Copy link
Collaborator

@Ivansete-status Ivansete-status left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks! 💯

@gabrielmer gabrielmer force-pushed the chore-deprecating-named-sharding branch from 61c7815 to 4565042 Compare July 9, 2024 14:39
@gabrielmer gabrielmer merged commit e1518cf into master Jul 9, 2024
8 of 10 checks passed
@gabrielmer gabrielmer deleted the chore-deprecating-named-sharding branch July 9, 2024 15:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-notes Issue/PR needs to be evaluated for inclusion in release notes highlights or upgrade instructions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

chore: deprecate support for named sharding:
6 participants