You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Ted Yu (JIRA)" <ji...@apache.org> on 2018/07/21 04:17:00 UTC

[jira] [Commented] (KAFKA-7175) Make version checking logic more flexible in streams_upgrade_test.py

    [ https://issues.apache.org/jira/browse/KAFKA-7175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16551526#comment-16551526 ] 

Ted Yu commented on KAFKA-7175:
-------------------------------

Haven't found a way for python to directly reference constant defined in Java class.

Maybe first step is to define base version, e.g. version 3 in the following:
{code}
                    leader_monitor.wait_until("Received a future (version probing) subscription (version: 4). Sending empty assignment back (with supported version 3).",
{code}
Then the other versions can be expressed as base version plus some fixed increment(s).

This way, when there is a version bump in Java, we only need to change the base version in python.

> Make version checking logic more flexible in streams_upgrade_test.py
> --------------------------------------------------------------------
>
>                 Key: KAFKA-7175
>                 URL: https://issues.apache.org/jira/browse/KAFKA-7175
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Ted Yu
>            Priority: Major
>
> During debugging of system test failure for KAFKA-5037, it was re-discovered that the version numbers inside version probing related messages are hard coded in streams_upgrade_test.py
> This is in-flexible.
> We should correlate latest version from Java class with the expected version numbers.
> Matthias made the following suggestion:
> We should also make this more generic and test upgrades from 3 -> 4, 3 -> 5 and 4 -> 5. The current code does only go from latest version to future version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)