Skip to content

KAFKA-9027, KAFKA-9028: Convert create/delete acls requests/response to use generated protocol#7725

Merged
ijuma merged 18 commits intoapache:trunkfrom
ijuma:kafka-9027-create-acls-generated
Feb 3, 2020
Merged

KAFKA-9027, KAFKA-9028: Convert create/delete acls requests/response to use generated protocol#7725
ijuma merged 18 commits intoapache:trunkfrom
ijuma:kafka-9027-create-acls-generated

Conversation

@ijuma
Copy link
Copy Markdown
Member

@ijuma ijuma commented Nov 21, 2019

Also add support for flexible versions to both protocol types.

Co-authored-by: Rajini Sivaram rajinisivaram@googlemail.com
Co-authored-by: Jason Gustafson jason@confluent.io

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@ijuma ijuma changed the title KAFKA-9027: Convert create/delete acls requests/response to use generated protocol KAFKA-9027, KAFKA-9028: Convert create/delete acls requests/response to use generated protocol Nov 21, 2019
@ijuma ijuma force-pushed the kafka-9027-create-acls-generated branch from 30101cc to 4a14ddd Compare November 24, 2019 17:39
@hachikuji hachikuji force-pushed the kafka-9027-create-acls-generated branch 2 times, most recently from 8490c73 to 0657ddb Compare December 5, 2019 23:59
Copy link
Copy Markdown
Contributor

@cmccabe cmccabe Dec 6, 2019

Choose a reason for hiding this comment

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

Hmm. This part isn't quite right. We should be iterating over aclCreations, since that is what we actually sent out on the wire. Entries in acls may or may not have been sent out on the wire (if they were invalid, they weren't.)

I think we should remove the TODO comment about "duplicates"... since duplicates never get sent on the wire, they don't need to be handled here (if we iterate over the right collection)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I think you assumed this was complete, it's WIP as the commit message says: 755a6f2

The TODO is also a hint of the same. :)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This is another case that needs to be fixed. The simplest way would be just creating a list which contains all the AclBindingFilter objects that were sent on the wire (it seems that the incorrect decision to use filters in this PR was caused by the change in type in filterList from AclBindingFilter to DeleteAclsRequestData.DeleteAclsFilter)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Again, this was not complete and hence why there was a FIXME in it. ;)

Copy link
Copy Markdown
Contributor

@cmccabe cmccabe Dec 6, 2019

Choose a reason for hiding this comment

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

I was surprised by this when I read it, and had to think back to why we did this :) It would be good to add a comment about why we're doing this, I think. The explanation would be something like this: on older brokers, no pattern types existed except LITERAL (effectively...). So even though ANY is not directly supported on those brokers, we can get the same effect as ANY by setting LITERAL on those particular brokers.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Also, it's really ugly for "validate" to mutate the request. Can we have another function for this... 🙏

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@cmccabe Older brokers supported LITERAL and *, right?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

"*" is considered "LITERAL" for compatibility reasons

@ijuma ijuma force-pushed the kafka-9027-create-acls-generated branch from 0657ddb to c6c81e9 Compare December 9, 2019 15:16
@ijuma ijuma force-pushed the kafka-9027-create-acls-generated branch from c6c81e9 to b0f13b0 Compare January 30, 2020 15:59
@ijuma ijuma requested a review from rajinisivaram January 31, 2020 20:43
@ijuma ijuma force-pushed the kafka-9027-create-acls-generated branch from e70688f to 44bf6d1 Compare January 31, 2020 20:44
@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Jan 31, 2020

This should be ready to review once the tests complete.

@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 2, 2020

1 failure in one job and 4 in the other. All unrelated to this PR.

@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 2, 2020

retest this please

1 similar comment
@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 2, 2020

retest this please

@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 2, 2020

2 flaky failures in one job and 1 in another.

@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 2, 2020

retest this please

Copy link
Copy Markdown
Contributor

@rajinisivaram rajinisivaram left a comment

Choose a reason for hiding this comment

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

@ijuma Thanks for the PR, LGTM

@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 3, 2020

More unrelated flaky failures:

JDK 11:

kafka.admin.DescribeConsumerGroupTest.testDescribeGroupWithShortInitializationTimeout
kafka.admin.ResetConsumerGroupOffsetTest.testResetOffsetsExportImportPlan
org.apache.kafka.streams.kstream.internals.KStreamImplTest.shouldSupportTriggerMaterializedWithKTableFromKStream

JDK 8:

kafka.admin.DeleteConsumerGroupsTest.testDeleteCmdAllGroups
kafka.api.ConsumerBounceTest.testCloseDuringRebalance

@ijuma ijuma merged commit 738e14e into apache:trunk Feb 3, 2020
@ijuma ijuma deleted the kafka-9027-create-acls-generated branch February 3, 2020 15:12
@ijuma
Copy link
Copy Markdown
Member Author

ijuma commented Feb 3, 2020

I cherry-picked this to 2.5 so that describe/create/delete ACLs are all bumped at the same time.

ijuma added a commit that referenced this pull request Feb 3, 2020
…to use generated protocol (#7725)

Also add support for flexible versions to both protocol types.

Reviewers: Rajini Sivaram <rajinisivaram@googlemail.com>, Colin Patrick McCabe <cmccabe@apache.org>

Co-authored-by: Rajini Sivaram <rajinisivaram@googlemail.com>
Co-authored-by: Jason Gustafson <jason@confluent.io>
ijuma added a commit to confluentinc/kafka that referenced this pull request Feb 4, 2020
Conflicts related to version bump in AK, replaced
2.6 with 6.0:
* gradle.properties
* __init__.py
* version.py

* apache-github/trunk:
  KAFKA-9490: Fix generics for Grouped (apache#8028)
  Bump trunk to 2.6.0-SNAPSHOT (apache#8026)
  KAFKA-9027, KAFKA-9028: Convert create/delete acls requests/response to use generated protocol (apache#7725)
  MINOR: Refactor CheckpointFile to improve testability (apache#7391)
  MINOR: updated documentation where RocksDBStore was being used as the sample class for byte[] versus Bytes examples (apache#5884)
stanislavkozlovski pushed a commit to stanislavkozlovski/kafka that referenced this pull request Feb 18, 2020
…to use generated protocol (apache#7725)

Also add support for flexible versions to both protocol types.

Reviewers: Rajini Sivaram <rajinisivaram@googlemail.com>, Colin Patrick McCabe <cmccabe@apache.org>

Co-authored-by: Rajini Sivaram <rajinisivaram@googlemail.com>
Co-authored-by: Jason Gustafson <jason@confluent.io>
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.

4 participants