[jira] [Resolved] (KAFKA-14586) Move StreamsResetter to tools

2023-04-03 Thread Sagar Rao (Jira) 


 [ 
https://issues.apache.org/jira/browse/KAFKA-14586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sagar Rao resolved KAFKA-14586.
---
Resolution: Fixed

> Move StreamsResetter to tools
> -
>
> Key: KAFKA-14586
> URL: https://issues.apache.org/jira/browse/KAFKA-14586
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: Mickael Maison
>Assignee: Sagar Rao
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-14864) Memory leak in KStreamWindowAggregate with ON_WINDOW_CLOSE emit strategy

2023-04-03 Thread Matthias J. Sax (Jira) 


 [ 
https://issues.apache.org/jira/browse/KAFKA-14864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias J. Sax resolved KAFKA-14864.
-
Fix Version/s: 3.4.1
   3.3.3
   Resolution: Fixed

> Memory leak in KStreamWindowAggregate with ON_WINDOW_CLOSE emit strategy
> 
>
> Key: KAFKA-14864
> URL: https://issues.apache.org/jira/browse/KAFKA-14864
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 3.4.0, 3.3.2
>Reporter: Victoria Xia
>Assignee: Victoria Xia
>Priority: Major
> Fix For: 3.5.0, 3.4.1, 3.3.3
>
>
> The Streams DSL processor implementation for the ON_WINDOW_CLOSE emit 
> strategy during KStream windowed aggregations opens a key-value iterator but 
> does not call `close()` on it 
> ([link|https://github.com/apache/kafka/blob/5afedd9ac37c4d740f47867cfd31eaed15dc542f/streams/src/main/java/org/apache/kafka/streams/kstream/internals/AbstractKStreamTimeWindowAggregateProcessor.java#L203]),
>  despite the Javadocs for the iterator making clear that users must do so in 
> order to release resources 
> ([link|https://github.com/apache/kafka/blob/5afedd9ac37c4d740f47867cfd31eaed15dc542f/streams/src/main/java/org/apache/kafka/streams/state/KeyValueIterator.java#L27]).
>   
> I discovered this bug while running load testing benchmarks and noticed that 
> some runs were sporadically hitting OOMs, so it is definitely possible to hit 
> this in practice.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #1731

2023-04-03 Thread Apache Jenkins Server 
See 


Changes:


--
[...truncated 546660 lines...]
[2023-04-04T00:28:46.476Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > TopicIdWithOldInterBrokerProtocolTest > 
testMetadataTopicIdsWithOldIBP() STARTED
[2023-04-04T00:28:48.821Z] 
[2023-04-04T00:28:48.821Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > TopicIdWithOldInterBrokerProtocolTest > 
testMetadataTopicIdsWithOldIBP() PASSED
[2023-04-04T00:28:48.821Z] 
[2023-04-04T00:28:48.821Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > TopicIdWithOldInterBrokerProtocolTest > 
testDeleteTopicsWithOldIBPUsingIDs() STARTED
[2023-04-04T00:28:50.449Z] 
[2023-04-04T00:28:50.449Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > TopicIdWithOldInterBrokerProtocolTest > 
testDeleteTopicsWithOldIBPUsingIDs() PASSED
[2023-04-04T00:28:50.449Z] 
[2023-04-04T00:28:50.449Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
shouldSurviveFastLeaderChange() STARTED
[2023-04-04T00:29:11.441Z] 
[2023-04-04T00:29:11.441Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
shouldSurviveFastLeaderChange() PASSED
[2023-04-04T00:29:11.441Z] 
[2023-04-04T00:29:11.441Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
offsetsShouldNotGoBackwards() STARTED
[2023-04-04T00:30:23.941Z] 
[2023-04-04T00:30:23.941Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
offsetsShouldNotGoBackwards() PASSED
[2023-04-04T00:30:23.941Z] 
[2023-04-04T00:30:23.941Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
shouldFollowLeaderEpochBasicWorkflow() STARTED
[2023-04-04T00:30:23.941Z] 
[2023-04-04T00:30:23.941Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
shouldFollowLeaderEpochBasicWorkflow() PASSED
[2023-04-04T00:30:23.941Z] 
[2023-04-04T00:30:23.941Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
shouldNotAllowDivergentLogs() STARTED
[2023-04-04T00:30:31.243Z] 
[2023-04-04T00:30:31.243Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
shouldNotAllowDivergentLogs() PASSED
[2023-04-04T00:30:31.243Z] 
[2023-04-04T00:30:31.243Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
logsShouldNotDivergeOnUncleanLeaderElections() STARTED
[2023-04-04T00:30:44.472Z] 
[2023-04-04T00:30:44.472Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
logsShouldNotDivergeOnUncleanLeaderElections() PASSED
[2023-04-04T00:30:44.472Z] 
[2023-04-04T00:30:44.472Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > ReplicationUtilsTest > testUpdateLeaderAndIsr() STARTED
[2023-04-04T00:30:44.472Z] 
[2023-04-04T00:30:44.472Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > ReplicationUtilsTest > testUpdateLeaderAndIsr() PASSED
[2023-04-04T00:30:44.472Z] 
[2023-04-04T00:30:44.472Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > ZooKeeperClientTest > testZNodeChangeHandlerForDataChange() 
STARTED
[2023-04-04T00:30:44.472Z] 
[2023-04-04T00:30:44.472Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > ZooKeeperClientTest > testZNodeChangeHandlerForDataChange() 
PASSED
[2023-04-04T00:30:44.472Z] 
[2023-04-04T00:30:44.472Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > ZooKeeperClientTest > testZooKeeperSessionStateMetric() STARTED
[2023-04-04T00:30:45.971Z] 
[2023-04-04T00:30:45.971Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > ZooKeeperClientTest > testZooKeeperSessionStateMetric() PASSED
[2023-04-04T00:30:45.971Z] 
[2023-04-04T00:30:45.971Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > ZooKeeperClientTest > testExceptionInBeforeInitializingSession() 
STARTED
[2023-04-04T00:30:45.971Z] 
[2023-04-04T00:30:45.971Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > ZooKeeperClientTest > testExceptionInBeforeInitializingSession() 
PASSED
[2023-04-04T00:30:45.971Z] 
[2023-04-04T00:30:45.971Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 174 > ZooKeeperClientTest > testGetChildrenExistingZNode() STARTED
[2023-04-04T00:30:45.971Z] 
[2023-04-04T00:30:45.971Z] Gradle Test Run :core:integrationTest > Gradle Test

[jira] [Resolved] (KAFKA-6007) Connect can't validate against transforms in plugins.path

2023-04-03 Thread Greg Harris (Jira) 


 [ 
https://issues.apache.org/jira/browse/KAFKA-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Harris resolved KAFKA-6007.

  Assignee: Greg Harris  (was: Konstantine Karantasis)
Resolution: Fixed

> Connect can't validate against transforms in plugins.path
> -
>
> Key: KAFKA-6007
> URL: https://issues.apache.org/jira/browse/KAFKA-6007
> Project: Kafka
>  Issue Type: Bug
>  Components: KafkaConnect
>Affects Versions: 0.11.0.0, 0.11.0.1, 1.0.0
>Reporter: Stephane Maarek
>Assignee: Greg Harris
>Priority: Major
> Fix For: 1.0.3, 1.1.2, 2.0.2, 2.1.2, 2.3.2, 2.5.0, 2.4.0, 2.2.2
>
>
> Kafka Connect can't validate a custom transformation if placed in plugins 
> path.
> Here's the output I get on the validate call:
> {code:java}
> Invalid value com.mycorp.kafka.transforms.impl.FlattenSinkRecord for 
> configuration transforms.Flat.type: Class 
> com.mycorp.kafka.transforms.impl.FlattenSinkRecord could not be found.
> Invalid value null for configuration transforms.Flat.type: Not a 
> Transformation
> "recommended_values": [   
> "com.mycorp.kafka.transforms.Flatten$Key",
> "com.mycorp.kafka.transforms.Flatten$Value",
> "com.mycorp.kafka.transforms.impl.FlattenSinkRecord",
> "org.apache.kafka.connect.transforms.Cast$Key",
> "org.apache.kafka.connect.transforms.Cast$Value",
> "org.apache.kafka.connect.transforms.ExtractField$Key",
> "org.apache.kafka.connect.transforms.ExtractField$Value",
> "org.apache.kafka.connect.transforms.Flatten$Key",
> "org.apache.kafka.connect.transforms.Flatten$Value",
> "org.apache.kafka.connect.transforms.HoistField$Key",
> "org.apache.kafka.connect.transforms.HoistField$Value",
> "org.apache.kafka.connect.transforms.InsertField$Key",
> "org.apache.kafka.connect.transforms.InsertField$Value",
> "org.apache.kafka.connect.transforms.MaskField$Key",
> "org.apache.kafka.connect.transforms.MaskField$Value",
> "org.apache.kafka.connect.transforms.RegexRouter",
> "org.apache.kafka.connect.transforms.ReplaceField$Key",
> "org.apache.kafka.connect.transforms.ReplaceField$Value",
> "org.apache.kafka.connect.transforms.SetSchemaMetadata$Key",
> "org.apache.kafka.connect.transforms.SetSchemaMetadata$Value",
> "org.apache.kafka.connect.transforms.TimestampConverter$Key",
> "org.apache.kafka.connect.transforms.TimestampConverter$Value",
> "org.apache.kafka.connect.transforms.TimestampRouter",
> "org.apache.kafka.connect.transforms.ValueToKey"],
> {code}
> As you can see the class appear in the recommended values (!) but can't be 
> picked up on the validate call. 
> I believe it's because the recommender implements class discovery using 
> plugins:
> https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L194
> But the class inference itself doesn't:
> https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L199
> (I'm not an expert in class loading though, just a guess... Unsure how to fix)
> A quick fix is to add the transformations in the ClassPath itself, but that 
> defeats the point a bit. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-14871) Kafka Connect - TTL not respected for Config Provider-provided connector configurations

2023-04-03 Thread Dave Sloan (Jira) 


 [ 
https://issues.apache.org/jira/browse/KAFKA-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Sloan resolved KAFKA-14871.

Resolution: Abandoned

After discussing with my colleagues, we have come to the conclusion that 
although the behaviour is incorrect there's not actually a good reason for 
defining the secret providers inside the connector configuration.  For security 
reasons it is better to define inside the environment (worker properties).

> Kafka Connect - TTL not respected for Config Provider-provided connector 
> configurations
> ---
>
> Key: KAFKA-14871
> URL: https://issues.apache.org/jira/browse/KAFKA-14871
> Project: Kafka
>  Issue Type: Bug
>  Components: KafkaConnect
>Affects Versions: 3.3.2
>Reporter: Dave Sloan
>Priority: Major
>
> When defining a configuration provider using environment variables (eg via 
> Docker), then a reload is scheduled according to the TTL of the returned 
> configuration.
>  
> Here is an example:
>  
> |Environment Variable|Value|
> |CONNECT_CONFIG_PROVIDERS_VAULT_PARAM_VAULT_ENGINE_VERSION|2|
> |CONNECT_CONFIG_PROVIDERS_VAULT_PARAM_VAULT_TOKEN|9c08104f-98b7-4bce-ab86-4a6c63897ec4|
> |CONNECT_CONFIG_PROVIDERS|vault|
> |CONNECT_CONFIG_PROVIDERS_VAULT_PARAM_DEFAULT_TTL|3|
> |CONNECT_CONFIG_PROVIDERS_VAULT_PARAM_VAULT_ADDR|http://vault:8200|
> |CONNECT_CONFIG_PROVIDERS_VAULT_PARAM_VAULT_AUTH_METHOD|token|
> |CONNECT_CONFIG_PROVIDERS_VAULT_PARAM_FILE_WRITE|false|
> |CONNECT_CONFIG_PROVIDERS_VAULT_CLASS|io.lenses.connect.secrets.providers.VaultSecretProvider|
>  
>  
> {code:java}
> {
>     "name": "testSink",
>     "config": {
>         "topics": "vaultTest",
>         "name": "testSink",
>         "key.converter": "org.apache.kafka.connect.storage.StringConverter",
>         "test.sink.secret.value": 
> "${vault:rotate-test/myVaultSecretPath:myVaultSecretKey}",
>         "value.converter": "org.apache.kafka.connect.storage.StringConverter",
>         "tasks.max": 1,
>     }
> }{code}
> And this is what we see in the logs:
> {code:java}
> STDOUT: [2023-03-30 07:46:43,204] INFO Scheduling a restart of connector 
> testSink in 4908 ms 
> (org.apache.kafka.connect.runtime.WorkerConfigTransformer){code}
> However when we try and achieve the same via connector properties, no restart 
> is scheduled
>  
>  
>  
> {code:java}
> {
>     "name": "testSink",
>     "config": {
>         "topics": "vaultTest",
>         "name": "testSink",
>         "key.converter": "org.apache.kafka.connect.storage.StringConverter",
>         "value.converter": "org.apache.kafka.connect.storage.StringConverter",
>         "tasks.max": 1,
>         "connector.class": "io.lenses.connect.secrets.test.TestSinkConnector",
>         "test.sink.secret.value": 
> "${vault:rotate-test/myVaultSecretPath:myVaultSecretKey}",
>         "config.providers": "vault",
>         "config.providers.vault.class": 
> "io.lenses.connect.secrets.providers.VaultSecretProvider",
>         "config.providers.vault.param.vault.engineversion": 2,
>         "config.providers.vault.param.vault.token": 
> "9c08104f-98b7-4bce-ab86-4a6c63897ec4",
>         "config.providers.vault.param.default.ttl": 3,
>         "config.providers.vault.param.vault.addr": "http://vault:8200";,
>         "config.providers.vault.param.vault.auth.method": "token",
>         "config.providers.vault.param.file.write": false
>     }
> }{code}
>  
>  
> Upon looking deeper into the code I can see that on line 239 of AbstractConfig
> [https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/config/AbstractConfig.java#L539]
>  
> {code:java}
> ConfigTransformerResult result = 
> configTransformer.transform(indirectVariables);{code}
> The result contains the TTLs.  However these are not used.
>  
> Expectation:
> TTLs should be used to schedule a restart of the connector so that the 
> behaviour is the same as if using environment properties.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #1730

2023-04-03 Thread Apache Jenkins Server 
See 


Changes:


--
[...truncated 367396 lines...]
[2023-04-03T13:43:40.326Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldFailWithIllegalArgumentExceptionWhenIQPartitionerReturnsMultiplePartitions()
 STARTED
[2023-04-03T13:43:40.326Z] 
[2023-04-03T13:43:40.326Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldFailWithIllegalArgumentExceptionWhenIQPartitionerReturnsMultiplePartitions()
 PASSED
[2023-04-03T13:43:40.326Z] 
[2023-04-03T13:43:40.326Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQueryAllStalePartitionStores() STARTED
[2023-04-03T13:43:43.550Z] 
[2023-04-03T13:43:43.550Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQueryAllStalePartitionStores() PASSED
[2023-04-03T13:43:43.550Z] 
[2023-04-03T13:43:43.550Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQuerySpecificStalePartitionStoresMultiStreamThreads() STARTED
[2023-04-03T13:43:49.784Z] 
[2023-04-03T13:43:49.784Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQuerySpecificStalePartitionStoresMultiStreamThreads() PASSED
[2023-04-03T13:43:49.784Z] 
[2023-04-03T13:43:49.784Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQuerySpecificStalePartitionStores() STARTED
[2023-04-03T13:43:53.480Z] 
[2023-04-03T13:43:53.480Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQuerySpecificStalePartitionStores() PASSED
[2023-04-03T13:43:53.480Z] 
[2023-04-03T13:43:53.480Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQueryOnlyActivePartitionStoresByDefault() STARTED
[2023-04-03T13:43:56.512Z] 
[2023-04-03T13:43:56.512Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQueryOnlyActivePartitionStoresByDefault() PASSED
[2023-04-03T13:43:56.512Z] 
[2023-04-03T13:43:56.512Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQueryStoresAfterAddingAndRemovingStreamThread() STARTED
[2023-04-03T13:44:05.406Z] 
[2023-04-03T13:44:05.406Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQueryStoresAfterAddingAndRemovingStreamThread() PASSED
[2023-04-03T13:44:05.406Z] 
[2023-04-03T13:44:05.406Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQuerySpecificStalePartitionStoresMultiStreamThreadsNamedTopology() STARTED
[2023-04-03T13:44:08.580Z] 
[2023-04-03T13:44:08.580Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 179 > StoreQueryIntegrationTest > 
shouldQuerySpecificStalePartitionStoresMultiStreamThreadsNamedTopology() PASSED
[2023-04-03T13:44:32.382Z] 
[2023-04-03T13:44:32.382Z] > Task :core:integrationTest
[2023-04-03T13:44:32.382Z] 
[2023-04-03T13:44:32.382Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 176 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
offsetsShouldNotGoBackwards() PASSED
[2023-04-03T13:44:32.382Z] 
[2023-04-03T13:44:32.382Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 176 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
shouldFollowLeaderEpochBasicWorkflow() STARTED
[2023-04-03T13:44:36.780Z] 
[2023-04-03T13:44:36.780Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 176 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
shouldFollowLeaderEpochBasicWorkflow() PASSED
[2023-04-03T13:44:36.780Z] 
[2023-04-03T13:44:36.780Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 176 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
shouldNotAllowDivergentLogs() STARTED
[2023-04-03T13:44:45.200Z] 
[2023-04-03T13:44:45.200Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 176 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
shouldNotAllowDivergentLogs() PASSED
[2023-04-03T13:44:45.200Z] 
[2023-04-03T13:44:45.200Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 176 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
logsShouldNotDivergeOnUncleanLeaderElections() STARTED
[2023-04-03T13:44:56.078Z] 
[2023-04-03T13:44:56.078Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 176 > EpochDrivenReplicationProtocolAcceptanceWithIbp26Test > 
logsShouldNotDivergeOnUncleanLeaderElections() PASSED
[2023-04-03T13:44:56.078Z] 
[2023-04-03T13:44:56.078Z] Gradle Test Run :core:integrationTest > Gradle Test 
Executor 176 > R

[jira] [Created] (KAFKA-14877) refactor

2023-04-03 Thread Luke Chen (Jira) 
Luke Chen created KAFKA-14877:
-

 Summary: refactor 
 Key: KAFKA-14877
 URL: https://issues.apache.org/jira/browse/KAFKA-14877
 Project: Kafka
  Issue Type: Sub-task
Reporter: Luke Chen


follow up with this comment: 
https://github.com/apache/kafka/pull/13456#discussion_r1154306477



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [kafka-site] showuon commented on pull request #499: Use ASF self service portal to get JIRA account

2023-04-03 Thread via GitHub 


showuon commented on PR #499:
URL: https://github.com/apache/kafka-site/pull/499#issuecomment-1494172397

   > IMO, the committer/PMC approving the self-service request should follow-up 
with changing the permissions. 
   
   That's what I usually did. After approving the request, add the user into 
the contributor list. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #1729

2023-04-03 Thread Apache Jenkins Server 
See

[GitHub] [kafka-site] divijvaidya commented on pull request #499: Use ASF self service portal to get JIRA account

2023-04-03 Thread via GitHub 


divijvaidya commented on PR #499:
URL: https://github.com/apache/kafka-site/pull/499#issuecomment-1494118309

   > In the past when people created accounts on their own, they could only 
create new tickets. We needed to assign contributor permissions so they could 
self assign tickets.
   
   @mimaison You are right. See: 
https://issues.apache.org/jira/browse/INFRA-24423 
   
   IMO, the committer/PMC approving the self-service request should follow-up 
with changing the permissions. Do we have a wiki/documentation for instructions 
to committers on how to do this? (similar to 
[this](https://tinkerpop.apache.org/docs/current/dev/developer/#_for_committers))
   
   An alternate is to ask the user to send an email requesting for permissions 
but that just adds another step in the process and another set item of work for 
committers.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] mimaison commented on pull request #499: Use ASF self service portal to get JIRA account

2023-04-03 Thread via GitHub 


mimaison commented on PR #499:
URL: https://github.com/apache/kafka-site/pull/499#issuecomment-1494083987

   In the past when people created accounts on their own, they could only 
create new tickets. We needed to assign contributor permissions so they could 
self assign tickets. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] divijvaidya commented on pull request #499: Use ASF self service portal to get JIRA account

2023-04-03 Thread via GitHub 


divijvaidya commented on PR #499:
URL: https://github.com/apache/kafka-site/pull/499#issuecomment-1494071977

   > Don't people still need to ask for contributor permissions to self assign 
tickets?
   
   Correct me if I am wrong but once you have a Apache JIRA account, you can 
self assign tickets. The ASF self serve workflows does not distinguish between 
user/contributor role.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] mimaison commented on pull request #499: Use ASF self service portal to get JIRA account

2023-04-03 Thread via GitHub 


mimaison commented on PR #499:
URL: https://github.com/apache/kafka-site/pull/499#issuecomment-1493914940

   Don't people still need to ask for contributor permissions to self assign 
tickets?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Resolved] (KAFKA-14450) Rack-aware partition assignment for consumers (KIP-881)

2023-04-03 Thread Rajini Sivaram (Jira) 


 [ 
https://issues.apache.org/jira/browse/KAFKA-14450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajini Sivaram resolved KAFKA-14450.

Resolution: Fixed

> Rack-aware partition assignment for consumers (KIP-881)
> ---
>
> Key: KAFKA-14450
> URL: https://issues.apache.org/jira/browse/KAFKA-14450
> Project: Kafka
>  Issue Type: New Feature
>  Components: consumer
>Reporter: Rajini Sivaram
>Assignee: Rajini Sivaram
>Priority: Major
>
> Top-level ticket for KIP-881 since we are splitting the PR into 3.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-14452) Make sticky assignors rack-aware if consumer racks are configured.

2023-04-03 Thread Rajini Sivaram (Jira) 


 [ 
https://issues.apache.org/jira/browse/KAFKA-14452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajini Sivaram resolved KAFKA-14452.

Fix Version/s: 3.5.0
 Reviewer: David Jacot
   Resolution: Fixed

> Make sticky assignors rack-aware if consumer racks are configured.
> --
>
> Key: KAFKA-14452
> URL: https://issues.apache.org/jira/browse/KAFKA-14452
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: Rajini Sivaram
>Assignee: Rajini Sivaram
>Priority: Major
> Fix For: 3.5.0
>
>
> See KIP-881 for details



--
This message was sent by Atlassian Jira
(v8.20.10#820010)