-
Notifications
You must be signed in to change notification settings - Fork 13
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
Refactor Client constructor options, add (m)TLS support #17
Conversation
b0aa982
to
8c355a4
Compare
2009287
to
2119bc6
Compare
@oleiade This is now ready for a proper review. The commit log is a bit messy, but it's a PITA to clean it up at this point. 😓 You can just review it as a general diff, going by file. Please take a look and let me know. |
2119bc6
to
6e17cd7
Compare
{ | ||
name: "err/object/cluster_inconsistent_option", | ||
arg: `{ | ||
cluster: { | ||
nodes: [ | ||
{ | ||
username: 'user1', | ||
password: 'pass', | ||
socket: { | ||
host: 'host1', | ||
port: 6379, | ||
}, | ||
}, | ||
{ | ||
username: 'user2', | ||
password: 'pass', | ||
socket: { | ||
host: 'host2', | ||
port: 6379, | ||
}, | ||
} | ||
] | ||
} | ||
}`, | ||
expErr: `invalid options; reason: inconsistent username option: user1 != user2`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still not sure about this behavior. redis.UniversalOptions
only allows a single username, password and many other values, even if more than one Addrs
is specified. So the point of setConsistentOptions()
is to ensure that these values are consistent across all nodes.
But I'm not sure if this is something that's also enforced by Redis, or if there can be a case where e.g. nodes within a cluster use a different username or password, or any other setting. Intuitively, I don't see why that shouldn't be allowed, in which case there would be no way for users to connect to such a cluster. But maybe this is also a Redis limitation that go-redis is compliant with, in which case this is fine.
I'm not familiar with Redis Cluster deployments, and didn't find anything specifically about this in the documentation. My hunch is that this is fine, but wanted to point it out.
Hey @imiric, it seems since you left you now need to sign the CLA 😓 Would you mind doing it, please? You mentioned we might have to split the PR, but if we don't I'd prefer to keep your contribution acknowledged 👍🏻 |
6e17cd7
to
e6404f1
Compare
Hey @oleiade! This wouldn't be an issue had this PR been reviewed in a timely manner... 😜 But GH/CLA Assistant might be confused since I deleted the Grafana email from my account, so it can't associate the commits with my account. I think the solution is as you have done by recreating the commits as yourself, and leaving me as the author. BTW, I don't think this PR should be split, as it would be a lot of work for no real gain. I'm happy to address any feedback, though I may be slow to respond. Hope all is well. Cheers! |
@imiric Touché ❤️🔥 ! That's totally fair. Sorry it took so long for me to get back to it 🙇🏻 I will proceed with recreating the commits myself, leaving you as an author, and keeping the branch as is then 🤝 All is well on this side of the Pyrenees, I hope it's the same for you 🖖🏻 |
This worked for me for the latest commit.
@oleiade You have to loop over the commits applying the command with the specific commit or use the same command as I did doing a rebase and setting all the commits with the |
@codebien Thanks for the heads-up, the issue I have is not with changing the email itself, but rather which email to use indeed 🙇🏻 At the moment, it is set to |
@oleiade you can use the mail I've posted that connects Ivan to his GitHub account. You don't need a real e-mail. |
@codebien how did you find the information as to which email to use so I know where to look next time? |
To allow passing objects similar to node-redis. See #13 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I left some nitpicks. The unique point I have is regarding the API that seems to have some overlap between the possible ways of providing the same configuration where I would prefer a single way for them, but at this point, I think it's more important to merge this and start collecting feedback.
Co-authored-by: Ivan <2103732+codebien@users.noreply.github.com>
Co-authored-by: Ivan <2103732+codebien@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍🏻 🚀
Took me some time to get all the "infrastructure" I needed to test this properly, but I'm quite happy how this whole PR, and I'm keen to merge it as is. Outstanding work 🙇🏻
redis/client.go
Outdated
k6dialer, ok := vuState.Dialer.(*netext.Dialer) | ||
if !ok { | ||
panic(fmt.Sprintf("expected *netext.Dialer, got: %T", vuState.Dialer)) | ||
} | ||
tlsDialer := &tls.Dialer{ | ||
NetDialer: &k6dialer.Dialer, | ||
Config: tlsCfg, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately I do think this completely circumvent the current tings netext.Dialer does:
- Doing the resolving of the hostnames - including over
options.hosts
- blacklisting both hostnames and ips - which likely will be a big problem in cloud
- emtting bytes read/written - which in this case might be an okay thing.
Looking at tls.Dialer though - it seems not possible to put netext.Dialer there. So maybe we should wrap it the other way aroudn 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch indeed 👍🏻 I gave a stab at addressing this concern in 3676bef, by defining a custom dialer function which relies on k6's VU (netext.Dialer
) dialer, and manually upgrades the connection to TLS (respecting the provided configuration) when TLS certificates are present.
Testing it showed that blocked hostnames were effectively taken into account.
Let me know if that addresses your point @mstoykov 🙇🏻
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did look more into this but IMO https://github.com/grafana/xk6-redis/pull/17/files#r1369707388 and it security implications are blockign this PR at this point.
I am okay if we can figure out a way to disable this functionality to merge it so that the PR doesn't stay open and continue working on the underlying problem in a separate PR. cc @oleiade
@mstoykov I'm currently looking into this indeed 👀 There's quite a bit of context involved. If I remember correctly, we wanted to do that for a specific reason (because the k6 TLS dialer is specific to HTTP), but I need to spend more time loading the context back into my brain. I will come back to this as soon as I've been able to wrap my head around it again 👍🏻 |
3676bef
to
06183eb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGMT! I would still prefer a test around blockhostnames or something like that, but looking at the code I do expect it will work.
My only other feedback is that the current options parsing has a bunch of high level issues that do not have easy fixes:
- it
export
s a goja object instead of reading directly from it - which then requires a bunch of type casting and json marshalling and unmarshalling - The above also prevents you from supporting times as both numbers and strings - which is a thing k6 generally does see Unify duration configuration values k6#1738
- Also because you do print the exported struct on error I guess you can hit stack overflow while processing a encrypt http request k6#644 (comment)
Fixes for all of those though in practice require that you do parse the config field by field from the base object which is arguably a thing we do in very few places.
So this is mostly a reminder this is not great then a let's fix it given the amount of options
06183eb
to
efd0a47
Compare
efd0a47
to
9bb7ed0
Compare
Opened #26 and #27 as a result of your comment @mstoykov. Regarding your last point, and the possibility of grafana/k6#644 (comment) being a thing, could you point me to a specific place you had in mind when mentioning "you do print the exported struct on error" please? 🙇🏻 |
Guys, sorry dont know where to report properly, but i noticed an issue in new redis client Options (k6 v50)
connection string if i provide any value in minIdleConns (default value not mentioned in Docs) connections are consumed non stop, and in a split second like (ok minute) are reaching maxClients =10k however if minIdleConns not specified, connected_clients reaches around 1353 (looks like around preallocated vus) and is properly reused, not going all the way to maxClients=10k it seems this paramater if provided causes this mishandling of connections |
Hey @mkosta, |
This is a fix/feature implementation for #13.
It refactors the
Client
constructor to accept options that are better aligned with the Node Redis API, to increase familiarity with an established JS library, and to allow specifying (m)TLS options, as proposed here. This means that these are breaking changes for users of the previous API.See the updated README and the tests for usage examples.
If you want to test this manually with a real Redis TLS server, see this gist for instructions.
What's pending:
ERR Protocol error: unauthenticated multibulk length
.I tracked it down to this issue, and this comment mentions this being some
MSET
limitation. We use regularSET
in the script, but maybe this is a general limitation of some kind(?). I'm not sure, but we'll need to look into it.According to this other comment, there's a nasty fix for this... 🙈
UPDATE 2023-08-10: I haven't been able to reproduce this again, but we should be aware that it might be an issue to look into later.
UPDATE 2023-08-10: I decided to leave it as a single PR, since the changes are closely related.