-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add ACL protocol and admin methods #1646
Conversation
This looks great! I'm in the middle of cleaning up some of the core sending methods (#1639, #1640, and #1641) and I'd like to land those first because it'll help keep things consistent... I suspect it will make your life easier as well because of the clear pattern for error handling / raising. Unfortunately, it will require a rebase, but hopefully we can get this in within the next few days... |
@ulrikjohansson I just finished merging all my changes, so can you rebase and then I'll review? You'll probably want to look through these recent commits for examples of various ways to handle things by leveraging other pieces of the library... for example error handling, retries (not sure if you need those) properly sending to coordinator / controller / nodes, etc. I know @dpkp would like to cut a new release early this coming week and it'd be nice to get these in as well since they add nice functionality... If you can rebase today, I'll try to review tonight or tomorrow morning. |
I'll have a look today, but can't promise I'll have time for more than the
rebase.
We'll start there and see what I can manage 😀
Btw, there were lots of failing stuff in the travis build, was that all
stuff I introduced?
|
bedaef0
to
94fc746
Compare
I've done the refactoring I could clearly see needed fixed. If there are other things that need some attention before this can be merged, please point me in the right direction. |
Thanks, I'll review right now.
No, that was because Fixing it requires redoing the |
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.
A few comments... the capitalization of the ACL
classes + more extensive docstrings for the public methods are the two changes I'd like to see before merging.
except ImportError: | ||
# vendored backport module | ||
from kafka.vendor.enum34 import IntEnum | ||
|
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.
style nit: pep8 suggests 2 blank lines between imports and code
kafka/admin/kafka.py
Outdated
# describe_acls protocol not yet implemented | ||
# Note: send the request to the least_loaded_node() | ||
def describe_acls(self, acl_resource): | ||
"""Describe a set of ACLs |
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.
Can you expand this docstring to describe the input param?
It matters because the docstring is what shows up in https://kafka-python.readthedocs.io/en/master/apidoc/KafkaAdmin.html and is what many users will be referring to for how to use this method, for example what to pass in as an acl_resource
...
So specify what the input params are, what return value is (which is currently just the response struct, so the user will need to do their own error-checking), and anything a user needs to be careful about or be aware of when using the method.
This is true of all the public methods, including the create/delete methods as well.
kafka/admin/acl_resource.py
Outdated
pattern_type=AclResourcePatternType.LITERAL | ||
): | ||
if not isinstance(resource_type, AclResourceType): | ||
resource_type = AclResourceType[str(resource_type).upper()] # pylint: disable-msg=unsubscriptable-object |
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.
IIUC, you are accepting both strings and AclResourceType
s...
But I don't see much (any?) error checking, so could this result in a user thinking they were successful but they actually weren't?
IE, would it be better to just require folks to always pass in AclResourceType objects?
I don't know the answer, as I haven't ever worked with Kafka ACLs, so I don't know the complexity of the types... but wanted to better understand the tradeoffs here...
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.
To be honest, I've pretty much just copied how it was done for the ConfigResource
. That essentially goes for this whole PR. I tried to just keep to the same patterns that were already there.
I do not have extensive experience/knowledge of how ACLs are implemented in the Java client either, this PR is driven by a need for a more flexible and workable solution to administrate ACLs than the shell/java-combination that ships with kafka.
I think that the above is just a convenience thing what was built into the ConfigResource, and perhaps it's better to not do that to start with. It doesn't really require much more effort, since they are simple enums. I'll go with that for now.
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.
Agree, for now let's go with the more strongly-typed approach, as its far easier to relax the constraints later rather than the other way around.
kafka/admin/kafka.py
Outdated
) | ||
|
||
def create_acls(self, acl_resources): | ||
"""Create a set of ACLs""" |
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.
Needs more extensive documentation, see: #1646 (comment)
kafka/admin/kafka.py
Outdated
) | ||
|
||
def delete_acls(self, acl_resources): | ||
"""Delete a set of ACLSs""" |
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.
Needs more extensive documentation, see: #1646 (comment)
The more I look at the ACL methods in Perhaps it would be a better idea to split this PR up into 2 parts instead: What are your thoughts on this? (It's getting late over here. I'm calling it quits for today, but will check in again in the morning) |
I think that sounds wise. Good suggestion to pull in the protocol stuff immediately, that will let you start forging ahead with playing with this... I double-checked the definitions, and it all looks correct to me. So I just cherry-picked your protocol commit onto master to make sure it lands in the 1.4.4 release. But the rest of this I absolutely agree it makes sense to discuss/research w/o as much time pressure. If you can continue to lead the charge here, I would really appreciate it, as Kafka ACLs aren't something that I have any experience with yet... I expect we'll start implementing them at work in the next 6-18 months depending on various things, and then I'll know more. But it'd be nice to have this land sooner than that, plus you are already aware of edge cases, etc. |
I'll keep working on it =) |
7a8f837
to
6f40051
Compare
Any update on this? |
Haven't worked much on ACL stuff at work lately, so it's kind of been put on the back burner. |
I opened a new PR, since the stuff is on a different local branch now, see #1833 |
I haven't been able to run the test suite locally for some reason, just small parts in isolation, like running the new test case with
pytest /test/test_admin.py
I've tested this to some extent manually, both with a simple docker kafka setup (kafka v2.0), as well as with a more serious cluster secured with SSL/ACLs already (kafka v 1.1). Describing, Creating and Deleting ALCs seem to work with both v0 and v1 versions of the protocol.
Fixes #1638
This change is