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

Rebranding of code in libvalkeycluster #15

Merged
merged 7 commits into from
Jun 20, 2024
Merged

Conversation

bjosv
Copy link
Collaborator

@bjosv bjosv commented Jun 19, 2024

Presumes that libvalkey (old hiredis) is already renamed as in branch renaming.

Part of #11

@bjosv bjosv force-pushed the renaming-cluster branch from 6ce9fef to 68f10fe Compare June 19, 2024 08:35
Copy link
Contributor

@mkmkme mkmkme left a comment

Choose a reason for hiding this comment

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

Here's my 7 cents on the PR :)

libvalkeycluster/adapters/ae.h Outdated Show resolved Hide resolved
libvalkeycluster/adlist.c Outdated Show resolved Hide resolved
libvalkeycluster/adlist.c Show resolved Hide resolved
libvalkeycluster/command.c Outdated Show resolved Hide resolved
libvalkeycluster/command.c Show resolved Hide resolved
libvalkeycluster/valkeycluster.c Outdated Show resolved Hide resolved
libvalkeycluster/valkeycluster.h Outdated Show resolved Hide resolved
#define VALKEYCLUSTER_SLOTS 16384

#define VALKEY_ROLE_NULL 0
#define VALKEY_ROLE_MASTER 1
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we change the terminology?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sure, the master/slave terminology should be removed

Copy link
Collaborator

Choose a reason for hiding this comment

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

Create follow-up issue?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, separate PR

int valkeyClusterUpdateSlotmap(valkeyClusterContext *cc);

/* Internal functions */
valkeyContext *ctx_get_by_node(valkeyClusterContext *cc,
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmmm I wonder if internal functions should really be in a public header. Maybe they could/should be moved to a separate header?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In the renaming branch I renamed them, and kept them public.

It currently needs to be public to handle PUB/SUB in cluster:
Nordix/hiredis-cluster#166 (comment)
Nordix/hiredis-cluster#143 (comment)

libvalkeycluster/vkutil.h Outdated Show resolved Hide resolved
bjosv added 2 commits June 19, 2024 17:48
Signed-off-by: Björn Svensson <[email protected]>
Makefiles and tests are moved separately
@zuiderkwast
Copy link
Collaborator

The adapter .h files include

#include "../valkeycluster.h"
#include <valkey/adapters/glib.h>

I.e. they're cluster event loop adapters that depend on the corresponding non-cluster adapters. But the file name is just src/adapters/glib.h and similar. What's the idea? Merge the files with non-cluster ones or have two separate ones?

@bjosv
Copy link
Collaborator Author

bjosv commented Jun 19, 2024

`What's the idea? Merge the files with non-cluster ones or have two separate ones?

Oh, good finding. I'll need to update the includes after moving stuff to src/.
It would have been easier if libvalkey was moved first..

The plan was to have a single adapter sourcefile for each eventsystem, i.e. basically the version existing in libvalkey but with the added attach function from libvalkeycluster, like valkeyClusterGlibAttach() to start with.
This would make current tests work at least.

@bjosv
Copy link
Collaborator Author

bjosv commented Jun 19, 2024

Maybe its simpler in this stage to not rename and move the cluster adapters.
We can just move the function when the libvalkey version in in place..

@zuiderkwast
Copy link
Collaborator

Yes. What matters in the end is how they are used by users.

#include <valkey/cluster-async.h>
#include <valkey/cluster-adapters/glib.h>

Or can we make it work without cluster-specific adapters?

#include <valkey/cluster-async.h>
#include <valkey/adapters/glib.h>

Copy link
Contributor

@mkmkme mkmkme left a comment

Choose a reason for hiding this comment

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

LGTM. I am sure there's a plenty of issues still, but those are worth creating separate tickets

@bjosv
Copy link
Collaborator Author

bjosv commented Jun 20, 2024

Or can we make it work without cluster-specific adapters?

#include <valkey/cluster-async.h>
#include <valkey/adapters/glib.h>

This is the plan, and it seems to work.
Currently I have added the needed attach functions to libvalkey's adapters, but we should probably add that build flag if a user wants to include cluster support or not.

@bjosv
Copy link
Collaborator Author

bjosv commented Jun 20, 2024

Rebased and updated the includes for the moved cluster files.
The tests and examples need to be moved and their includes needs to be corrected too.
I'll merge this and then we can start creating issues.

redisClusterAsyncContext *cc =
redisClusterAsyncConnect("127.0.0.1:7000", HIRCLUSTER_FLAG_NULL);
valkeyClusterAsyncContext *cc =
valkeyClusterAsyncConnect("127.0.0.1:7000", VALKEYCLUSTER_FLAG_NULL);
Copy link
Collaborator

Choose a reason for hiding this comment

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

it's just 0? Can we rename this to VALKEYCLUSTER_FLAG_NONE or just use 0? "Null" sticks out to me.

Copy link
Collaborator Author

@bjosv bjosv Jun 20, 2024

Choose a reason for hiding this comment

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

I think it would be nice to replace the flags used in the Cluster API with a new valkeyClusterOptions,
like its done in standalone:

valkeyAsyncContext *valkeyAsyncConnectWithOptions(const valkeyOptions *options);

Then we could set any option with that API, and possibly keep the simpler one for easy usage.

valkeyClusterAsyncContext *valkeyClusterAsyncConnectWithOptions(const valkeyClusterOptions *options);
valkeyClusterAsyncContext *valkeyClusterAsyncConnect(const char *addrs);

With this change the cluster api would look the same as the standalone.

Copy link
Collaborator

@zuiderkwast zuiderkwast left a comment

Choose a reason for hiding this comment

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

You merged the adapters and made tests pass? Incredible!

@bjosv bjosv merged commit f3776bd into valkey-io:main Jun 20, 2024
1 of 42 checks passed
@bjosv bjosv deleted the renaming-cluster branch June 20, 2024 08:42
@bjosv bjosv linked an issue Jun 25, 2024 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Move cluster code to src/
4 participants