ModuleClientState info is not found in the contrail-control-nodemgr generator info

Bug #1716799 reported by Senthilnathan Murugappan
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R4.0
Fix Committed
High
Megh Bhatt
R4.1
Fix Committed
High
Megh Bhatt
Trunk
Fix Committed
High
Megh Bhatt

Bug Description

version: 4.0.1.0-56~newton
testcase: test_verify_generator_connections_to_collector_node
Cluster: 10.87.118.141 (SM) has a screen named test

ModuleClientState info is not found in the contrail-control-nodemgr generator info of one of the control node process.

root@72e8d3c1b4eb:/opt/contrail/utils# curl -H 'X-Auth-Token: 4bb99059468f4f949562e7d71b457f44' http://10.0.0.10:8081/analytics/uves/generator/server6:Control:contrail-control-nodemgr:0?flat | python -mjson.tool
{
    "ModuleServerState": {
        "generator_info": [
            {
                "gen_attr": {
                    "connect_time": 1505199602966920,
                    "connects": 1,
                    "in_clear": false,
                    "reset_time": 0,
                    "resets": 0
                },
                "hostname": "server5"
            }
        ],
        "msg_stats": [
            {
                "hostname": "server5",
                "log_level_stats": [],
                "msgtype_stats": [
                    {
                        "bytes": 3383146,
                        "last_msg_timestamp": 1505259572025694,
                        "message_type": "NodeStatusUVE",
                        "messages": 1010
                    },
                    {
                        "bytes": 5509,
                        "last_msg_timestamp": 1505199602969546,
                        "message_type": "SandeshModuleClientTrace",
                        "messages": 3
                    }
                ]
            }
        ],
        "session_rx_socket_stats": {
            "average_blocked_duration": null,
            "average_bytes": 1697.0,
            "blocked_count": 0,
            "blocked_duration": "00:00:00",
            "bytes": 3429603,
            "calls": 2020,
            "errors": 0
        },
        "session_stats": {
            "num_recv_fail": 0,
            "num_recv_msg": 0,
            "num_recv_msg_fail": 0,
            "num_send_buffer_fail": 0,
            "num_send_msg": 1,
            "num_send_msg_fail": 0,
            "num_wait_msgq_dequeue": 0,
            "num_wait_msgq_enqueue": 0,
            "num_write_ready_cb_error": 0
        },
        "session_tx_socket_stats": {
            "average_blocked_duration": null,
            "average_bytes": 979.0,
            "blocked_count": 0,
            "blocked_duration": "00:00:00",
            "bytes": 979,
            "calls": 1,
            "errors": 0
        },
        "sm_drop_level": "INVALID",
        "sm_msg_stats": {
            "aggregate_stats": {
                "bytes_received": 3390057,
                "bytes_sent": 0,
                "messages_received": 1014,
                "messages_received_dropped": 0,
                "messages_sent": 0,
                "messages_sent_dropped": 0
            },
            "type_stats": [
                {
                    "message_type": "NodeStatusUVE",
                    "stats": {
                        "bytes_received": 3383146,
                        "bytes_sent": 0,
                        "messages_received": 1010,
                        "messages_received_dropped": 0,
                        "messages_sent": 0,
                        "messages_sent_dropped": 0
                    }
                },
                {
                    "message_type": "SandeshCtrlClientToServer",
                    "stats": {
                        "bytes_received": 1402,
                        "bytes_sent": 0,
                        "messages_received": 1,
                        "messages_received_dropped": 0,
                        "messages_sent": 0,
                        "messages_sent_dropped": 0
                    }
                },
                {
                    "message_type": "SandeshModuleClientTrace",
                    "stats": {
                        "bytes_received": 5509,
                        "bytes_sent": 0,
                        "messages_received": 3,
                        "messages_received_dropped": 0,
                        "messages_sent": 0,
                        "messages_sent_dropped": 0
                    }
                }
            ]
        },
        "sm_queue_count": 0,
        "sm_stats": {
            "ev_stats": [
                {
                    "dequeue_fails": 0,
                    "dequeues": 1,
                    "enqueue_fails": 0,
                    "enqueues": 1,
                    "event": "ssm::EvSandeshCtrlMessageRecv"
                },
                {
                    "dequeue_fails": 0,
                    "dequeues": 1013,
                    "enqueue_fails": 0,
                    "enqueues": 1013,
                    "event": "ssm::EvSandeshMessageRecv"
                },
                {
                    "dequeue_fails": 0,
                    "dequeues": 1,
                    "enqueue_fails": 0,
                    "enqueues": 1,
                    "event": "ssm::EvStart"
                },
                {
                    "dequeue_fails": 0,
                    "dequeues": 1,
                    "enqueue_fails": 0,
                    "enqueues": 1,
                    "event": "ssm::EvTcpPassiveOpen"
                },
                {
                    "dequeue_fails": 0,
                    "dequeues": 1016,
                    "enqueue_fails": 0,
                    "enqueues": 1016,
                    "event": null
                }
            ],
            "last_event": "ssm::EvSandeshMessageRecv",
            "last_event_at": 1505259571985218,
            "last_state": "Established",
            "state": "Established",
            "state_since": 1505199602968197
        }
    }
}

description: updated
Revision history for this message
Megh Bhatt (meghb) wrote :

This looks like an issue in the contrail-analytics-api uvedbcache since the following API which does not go through the cache is returning the ModuleClientState"

curl -u admin:c0ntrail123 127.0.0.1:8181/analytics/uves/generator/server6:Control:contrail-control-nodemgr:0 | python -m json.tool

{
    "ModuleClientState": {
        "client_info": [
            [
                {
                    "@type": "struct",
                    "SandeshClientInfo": {
                        "collector_ip": {
                            "#text": "10.10.0.8:8086",
                            "@type": "string"
                        },
                        "collector_list": {
                            "@type": "list",
                            "list": {
                                "@size": "3",
                                "@type": "string",
                                "element": [
                                    "10.10.0.7:8086",
                                    "10.10.0.8:8086",
                                    "10.10.0.9:8086"
                                ]
                            }
                        },
                        "collector_name": {
                            "#text": "server5",
                            "@type": "string"
                        },
                        "http_port": {
                            "#text": "8101",
                            "@type": "u32"
                        },
                        "pid": {
                            "#text": "6005",
                            "@type": "u32"
                        },
                        "start_time": {
                            "#text": "1505199566571402",
                            "@type": "u64"
                        },
                        "status": {
                            "#text": "Established",
                            "@type": "string"
                        },
                        "successful_connections": {
                            "#text": "2",
                            "@type": "u32"
                        }
                    }
                },
                "server6:Control:contrail-control-nodemgr:0"
            ]
        ],
        "max_sm_queue_count": [
            [
                {
                    "#text": "3",
                    "@type": "u64"
                },
                "server6:Control:contrail-control-nodemgr:0"
            ]
        ],
        "sm_queue_count": [
            [
                {
                    "#text": "2",
                    "@type": "u64"
                },
                "server6:Control:contrail-control-nodemgr:0"
            ]
        ]
    },
    "ModuleServerState": {
        "generator_info": {
            "@aggtype": "union",
            "@type": "list",
......

Revision history for this message
Megh Bhatt (meghb) wrote :

The UVE aggregation done by contrail-alarm-gen seems to be an issue:

127.0.0.1:6381[7]> hgetall AGPARTVALUES:0:22:ObjectGeneratorInfo:server6:Control:contrail-control-nodemgr:0
1) "ModuleServerState"
2) "{\"sm_queue_count\": 0, \"sm_drop_level\": \"INVALID\", \"session_tx_socket_stats\": {\"blocked_count\": 0, \"errors\": 0, \"calls\": 1, \"bytes\": 979, \"average_bytes\": 979.0, \"blocked_duration\": \"00:00:00\", \"average_blocked_duration\": null}, \"sm_stats\": {\"last_state\": \"Established\", \"last_event_at\": 1505327615364737, \"ev_stats\": [{\"dequeue_fails\": 0, \"enqueues\": 1, \"event\": \"ssm::EvSandeshCtrlMessageRecv\", \"enqueue_fails\": 0, \"dequeues\": 1}, {\"dequeue_fails\": 0, \"enqueues\": 2147, \"event\": \"ssm::EvSandeshMessageRecv\", \"enqueue_fails\": 0, \"dequeues\": 2147}, {\"dequeue_fails\": 0, \"enqueues\": 1, \"event\": \"ssm::EvStart\", \"enqueue_fails\": 0, \"dequeues\": 1}, {\"dequeue_fails\": 0, \"enqueues\": 1, \"event\": \"ssm::EvTcpPassiveOpen\", \"enqueue_fails\": 0, \"dequeues\": 1}, {\"dequeue_fails\": 0, \"enqueues\": 2150, \"event\": null, \"enqueue_fails\": 0, \"dequeues\": 2150}], \"last_event\": \"ssm::EvSandeshMessageRecv\", \"state\": \"Established\", \"state_since\": 1505199602968197}, \"session_stats\": {\"num_recv_msg_fail\": 0, \"num_send_buffer_fail\": 0, \"num_recv_fail\": 0, \"num_write_ready_cb_error\": 0, \"num_send_msg\": 1, \"num_send_msg_fail\": 0, \"num_wait_msgq_dequeue\": 0, \"num_wait_msgq_enqueue\": 0, \"num_recv_msg\": 0}, \"sm_msg_stats\": {\"aggregate_stats\": {\"messages_sent_dropped\": 0, \"messages_sent\": 0, \"messages_received\": 2148, \"bytes_sent\": 0, \"bytes_received\": 7194738, \"messages_received_dropped\": 0}, \"type_stats\": [{\"stats\": {\"messages_sent_dropped\": 0, \"messages_sent\": 0, \"messages_received\": 2144, \"bytes_sent\": 0, \"bytes_received\": 7187827, \"messages_received_dropped\": 0}, \"message_type\": \"NodeStatusUVE\"}, {\"stats\": {\"messages_sent_dropped\": 0, \"messages_sent\": 0, \"messages_received\": 1, \"bytes_sent\": 0, \"bytes_received\": 1402, \"messages_received_dropped\": 0}, \"message_type\": \"SandeshCtrlClientToServer\"}, {\"stats\": {\"messages_sent_dropped\": 0, \"messages_sent\": 0, \"messages_received\": 3, \"bytes_sent\": 0, \"bytes_received\": 5509, \"messages_received_dropped\": 0}, \"message_type\": \"SandeshModuleClientTrace\"}]}, \"session_rx_socket_stats\": {\"blocked_count\": 0, \"errors\": 0, \"calls\": 4288, \"bytes\": 7278510, \"average_bytes\": 1697.0, \"blocked_duration\": \"00:00:00\", \"average_blocked_duration\": null}, \"msg_stats\": [{\"hostname\": \"server5\", \"log_level_stats\": [], \"msgtype_stats\": [{\"messages\": 2144, \"bytes\": 7187827, \"message_type\": \"NodeStatusUVE\", \"last_msg_timestamp\": 1505327615403952}, {\"messages\": 3, \"bytes\": 5509, \"message_type\": \"SandeshModuleClientTrace\", \"last_msg_timestamp\": 1505199602969546}]}], \"generator_info\": [{\"gen_attr\": {\"resets\": 0, \"connect_time\": 1505199602966920, \"in_clear\": false, \"connects\": 1, \"reset_time\": 0}, \"hostname\": \"server5\"}]}"

Revision history for this message
Megh Bhatt (meghb) wrote :

This is a timing issue between contrail-collector writing the UVE on to redis, publishing the relevant notification on to a kafka partition, the contrail-alarm-gen getting ownership of that partition.

From the ModuleServerState UVE we see that the last ModuleClientState message was received on the contrail-collector at 1505199602969546.

From the kafka logs, we see that the contrail-alarm-gen acquired ownership of the partition 22 on which the UVE resides at 1505199602027427.

Megh Bhatt (meghb)
tags: added: sanity
removed: sanityblocker
Revision history for this message
aswani kumar (aswanikumar90) wrote :

i am seeing same issue in mitaka build 79 ubuntu14 openstack HA
During sanity generator cases failed because of this

nodem6:10.204216.95
nodem7:10.204.216.96
nodem14:10.204.216.103

Config Nodes : [u'nodem6', u'nodem7', u'nodem14']
Control Nodes : [u'nodem6', u'nodem7', u'nodem14']
Compute Nodes : [u'nodem8', u'nodem9', u'nodem10']
Openstack Node : [u'nodem6', u'nodem7', u'nodem14']
WebUI Node : [u'nodem6', u'nodem7', u'nodem14']
Analytics Nodes : [u'nodem! 6', u'nodem7', u'nodem14']
Database Nodes : [u'nodem6', u'nodem7', u'nodem14']

contrail-control-nodemgr is not connected to any of the collectors
It doesn't seem timing issue I am seeing this even after 5hrs from bringing

nodem7:Control:contrail-control-nodemgr:0Connection Error since 3h 19m200654.11 KB
 {
name: nodem7:Control:contrail-control-nodemgr:0
value: {
ModuleServerState: { ... }
}
}

WARNING - nodem7:Control:contrail-control-nodemgr:0 is NOT connected to collector 10.204.216.95 WARNING - nodem7:Control:contrail-control-nodemgr:0 is NOT connected to collector 10.204.216.96
WARNING - nodem7:Control:contrail-control-nodemgr:0 is NOT connected to collector 10.204.216.103

Revision history for this message
Megh Bhatt (meghb) wrote :

From comment in #4 this is not same issue, please file new PR for the same

Revision history for this message
aswani kumar (aswanikumar90) wrote :

Sorry I put it in a wrong way.(contrail-node-mgr not connected to collectors)

What I saw was the same issue as senthil reported in the bug.(ModuleClientState info is not found in the contrail-control-nodemgr generator info) and you mentioned it is because of timing issue.
But I saw after few hours while debugging still ModuleClientState info is not found in the contrail-control-nodemgr generator info and testcase is failing because of that when I reran.

Thanks,
Aswani kumar

If you did not see ModuleClientState then it is same issue, what I mean by timing issue is that the root cause of this is a race between contrail-alarm-gen acquiring a partition and contrail-collector updating the partition but once this issue happens then it will remain in that state until the contrail-control-nodemgr either is restarted or connects to another collector. So then there is no need to open another PR. I will take a look at this. We are also suspecting a librdkafka change that was done recently might be causing this.

Thanks

Megh

Revision history for this message
Jeba Paulaiyan (jebap) wrote :

Happened in R4.0-65~newton also.

tags: added: sanityblocker
removed: sanity
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R4.0

Review in progress for https://review.opencontrail.org/36493
Submitter: Anish Mehta (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R4.1

Review in progress for https://review.opencontrail.org/36494
Submitter: Anish Mehta (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R4.0

Review in progress for https://review.opencontrail.org/36493
Submitter: Anish Mehta (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R4.1

Review in progress for https://review.opencontrail.org/36494
Submitter: Anish Mehta (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/36494
Committed: http://github.com/Juniper/contrail-controller/commit/b038b9488fc120ea7f0faa475011970fe95cc657
Submitter: Zuul (<email address hidden>)
Branch: R4.1

commit b038b9488fc120ea7f0faa475011970fe95cc657
Author: Anish Mehta <email address hidden>
Date: Thu Oct 12 23:05:34 2017 -0700

Added more debugging information:
In alarmgen, we print out UVE Type info during get-partition and UVE processing in the Tracebuffer.
In collector, we add a timestamp when publishing to Kafka.
In redis, we for a printout when ModuleClientState is updated.
Partial-Bug: #1716799

Change-Id: Iea8c3a58c55028d95b86667207a7d07a2dc9a70a

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/36559
Submitter: Anish Mehta (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/36493
Committed: http://github.com/Juniper/contrail-controller/commit/e527e6f715f71be66e98f1a0a88df776665dce9c
Submitter: Zuul (<email address hidden>)
Branch: R4.0

commit e527e6f715f71be66e98f1a0a88df776665dce9c
Author: Anish Mehta <email address hidden>
Date: Thu Oct 12 23:05:34 2017 -0700

Added more debugging information:
In alarmgen, we print out UVE Type info during get-partition and UVE processing in the Tracebuffer.
In collector, we add a timestamp when publishing to Kafka.
In redis, we for a printout when ModuleClientState is updated.
Partial-Bug: #1716799

Change-Id: Iea8c3a58c55028d95b86667207a7d07a2dc9a70a

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/36559
Committed: http://github.com/Juniper/contrail-controller/commit/4a5e9b70c7f96d302d3d0e42add39e15249a6fb6
Submitter: Zuul (<email address hidden>)
Branch: master

commit 4a5e9b70c7f96d302d3d0e42add39e15249a6fb6
Author: Anish Mehta <email address hidden>
Date: Thu Oct 12 23:05:34 2017 -0700

Added more debugging information:
In alarmgen, we print out UVE Type info during get-partition and UVE processing in the Tracebuffer.
In collector, we add a timestamp when publishing to Kafka.
In redis, we for a printout when ModuleClientState is updated.
Partial-Bug: #1716799

Change-Id: Iea8c3a58c55028d95b86667207a7d07a2dc9a70a

Conflicts:
 src/opserver/alarmgen.py
Change-Id: Iea8c3a58c55028d95b86667207a7d07a2dc9a70a

Revision history for this message
Megh Bhatt (meghb) wrote :

Added debugging code to help analyze this further.

Revision history for this message
Anish Mehta (amehta00) wrote :

See during redis restart systemless test:

*** contrail-analytics-api ***
2017-11-09 12:35:30,627 DEBUG send sync_uve <ubuntu-build04:Analytics:contrail-analytics-api:0: 219> in the [ObjectGeneratorInfo:SandeshModuleClientTrace] map

*** contrail-collector ***
2017-11-09 Thu 12:35:30:621.957 PST ubuntu-build04 [Thread 139723899205376, Pid 24835]: Received Ctrl Message: ubuntu-build04:Analytics:contrail-analytics-api:0 Session:127.0.0.1:39293::127.0.0.1:41105(1)
2017-11-09 Thu 12:35:30:622.763 PST ubuntu-build04 [Thread 139723899205376, Pid 24835]: Sent good Ctrl Msg: Size 0 ubuntu-build04:contrail-analytics-api:0:Analytics

*** contrail-alarm-gen ***
11/09/2017 12:35:29 PM [contrail-alarm-gen]: Newer KafkaClient -uve-3
11/09/2017 12:35:29 PM [contrail-alarm-gen]: Starting part 3 collectors ['127.0.0.1:38314']
11/09/2017 12:35:29 PM [contrail-alarm-gen]: Starting part 3 UVEs 1
11/09/2017 12:35:29 PM [contrail-alarm-gen]: Created uveQ for part 3
11/09/2017 12:35:32 PM [contrail-alarm-gen]: poll for topic -uve-3 : {TopicPartition(topic=u'-uve-3', partition=0): 2}

*** contrail-alarm-gen trace ***
11/09/2017 12:36:39 PM [contrail-alarm-gen]: 1510259729771269 UVEQTrace: get-part-127.0.0.1:38314 3 [ ('ubuntu-build04:Analytics:contrail-collector:0', "{'ObjectGeneratorInfo:ubuntu-build04:Analytics:contrail-collector:0': {'ModuleClientState': {}, 'ModuleServerState': {}}}"), ] Thursday, November 9, 2017 12:35:29.771
11/09/2017 12:36:39 PM [contrail-alarm-gen]: 1510259729771919 UVEQTrace: create 3 [ ('ObjectGeneratorInfo:ubuntu-build04:Analytics:contrail-collector:0', 'None'), ]
11/09/2017 12:36:39 PM [contrail-alarm-gen]: 1510259730442450 UVEQTrace: proc-output 3 [ ('ObjectGeneratorInfo:ubuntu-build04:Analytics:contrail-collector:0', ['ModuleClientState', 'ModuleServerState']), ]
11/09/2017 12:36:39 PM [contrail-alarm-gen]: 1510259732832850 UVEQTrace: update 3 [ ('ObjectGeneratorInfo:ubuntu-build04:Analytics:contrail-analytics-api:0', "{'ModuleServerState': {u'__T': 1510259730858868}}"), ] November 9, 2017 12:35:32.833 PM

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/37393
Submitter: Anish Mehta (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R4.1

Review in progress for https://review.opencontrail.org/37395
Submitter: Anish Mehta (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/37393
Submitter: Anish Mehta (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R4.1

Review in progress for https://review.opencontrail.org/37395
Submitter: Anish Mehta (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R4.0

Review in progress for https://review.opencontrail.org/37417
Submitter: Anish Mehta (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/37393
Committed: http://github.com/Juniper/contrail-controller/commit/b401ac5554dbf0f005d343c769d6e16eb8f0ab28
Submitter: Zuul (<email address hidden>)
Branch: master

commit b401ac5554dbf0f005d343c769d6e16eb8f0ab28
Author: Anish Mehta <email address hidden>
Date: Fri Nov 10 00:21:38 2017 -0800

When starting a KafkaConsumer, we need to call the position API to establish the next offset BEFORE reading the partition from raw redis.
This ensures that we will not miss any UVE changes that happen between the partition read and when we starting reading from kafka.

Moved mockkafka to broker version 0.9.0.1, to be compatible with the fallback kafka version used collector via librdkafka

set offsets.topic.replication.factor to 1 for kafka-broker to in mockkafka to prevent spurious errors in systemless test

Re-enabled the redis restart systemless test

Change-Id: I12c03648ab0ae6b2571f86e46ed016117fcefa18
Closes-Bug: #1716799

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/37417
Committed: http://github.com/Juniper/contrail-controller/commit/8909c87db037ee162e2d0ac14bc95b28cd194325
Submitter: Zuul (<email address hidden>)
Branch: R4.0

commit 8909c87db037ee162e2d0ac14bc95b28cd194325
Author: Anish Mehta <email address hidden>
Date: Fri Nov 10 00:21:38 2017 -0800

When starting a KafkaConsumer, we need to call the position API to establish the next offset BEFORE reading the partition from raw redis.
This ensures that we will not miss any UVE changes that happen between the partition read and when we starting reading from kafka.

Moved mockkafka to broker version 0.9.0.1, to be compatible with the fallback kafka version used collector via librdkafka

set offsets.topic.replication.factor to 1 for kafka-broker to in mockkafka to prevent spurious errors in systemless test

Re-enabled the redis restart systemless test

Closes-Bug: #1716799

Conflicts:
 src/opserver/test/test_analytics_uve.py
Change-Id: I12c03648ab0ae6b2571f86e46ed016117fcefa18

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/37395
Committed: http://github.com/Juniper/contrail-controller/commit/79feb17ec889609c06c5e3bbcf0dad5ca5a6199c
Submitter: Zuul (<email address hidden>)
Branch: R4.1

commit 79feb17ec889609c06c5e3bbcf0dad5ca5a6199c
Author: Anish Mehta <email address hidden>
Date: Fri Nov 10 00:21:38 2017 -0800

When starting a KafkaConsumer, we need to call the position API to establish the next offset BEFORE reading the partition from raw redis.
This ensures that we will not miss any UVE changes that happen between the partition read and when we starting reading from kafka.

Moved mockkafka to broker version 0.9.0.1, to be compatible with the fallback kafka version used collector via librdkafka

set offsets.topic.replication.factor to 1 for kafka-broker to in mockkafka to prevent spurious errors in systemless test

Re-enabled the redis restart systemless test

Change-Id: I12c03648ab0ae6b2571f86e46ed016117fcefa18
Closes-Bug: #1716799

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.