We should implement the following scenarios to cover new feature of A-MQ image.

Notes:

• base amount of messages for migrations should be 1K+
• consider also test with larger numbers, e.g 10K+

#1 Scale down from 3 to 2:

• deploy A-MQ broker with 3 replicas & split volume enabled
• send unique set of messages to unique queue to replicas
• scale down to 2 replicas
• verify that one of the brokers get queue and messages from scaled pod

#2 Scaled down from 3 to 1:

• same as #1 but scale to just one replica
• verify that all messages and queues are migrated to remaining pod

#3 Failure of migration pod:

• prepare same deployment as per #1
• during migration phase periodically kill migration pod
  • `oc delete --grace-period 0` or `docker kill`
  • reconsider also node failures
• verify that even infra failures don't cause message lost

#4 Failure of drained pod:

• consider scenario in which source of messages is killed prematurely
• what is the behaviour of migration, if messages are backed by PV?

#5 Failure of migration target pod:

• repeat #3 with simulated failure on target pod

#6 Resource constrained env

• consider scoped env in which we should support migration
• what happens, if A-MQ deployment with multiple replicas is using all available quotas (CPU, Memory). Therefor user wants to scale down number of replicas to free up resources. If scale down initiates creation of drainer pod, will there be a A-MQ pod that gets killed meanwhile?