benchmark-wrapper
benchmark-wrapper copied to clipboard
[rfe] define shared message bus keys
If we have a message bus available, we should have a defined interface to interact with the bus.
Redis - As message bus
Each workload is an hash
hset uperf status "0|1|2"
0 - Complete 1 - Failed 2 - Running
By default have a status with each workload.
I agree with this, the only thing being i think the level of dict would be a bit more complicated than this so
hset uperf $UUID $thread $protocol ...
The advantage of this layer would mean that we'll be able to query redis with the status and also can deal with multiple uuids for the same run.. if it makes sense.
Does SNAFU know what test is being executed though?
Looking at UPerf specifically, we don't know what is being ran, until it is completed... If it fails, I doubt we know what failed.
https://github.com/cloud-bulldozer/snafu/blob/master/uperf-wrapper/uperf-wrapper.py#L76-L88
If we can make snafu understand what test is being executed, like in the case of fio where it reads the config file fully to figure out if its valid and what to do.... or with smallfile, where it can do a handoff with redis.
If we can accomplish the same with uperf, where we read the config file and update the redis accordingly... there'll be a single source of truth as everything will be stored in redis.. thus in the future when we implement the operator to see what test is being executed.. it can directly query the redis for state..
Open to other ideas that will also scale..
If we can make snafu understand what test is being executed, like in the case of fio where it reads the config file fully to figure out if its valid and what to do.... or with smallfile, where it can do a handoff with redis.
If we can accomplish the same with uperf, where we read the config file and update the redis accordingly... there'll be a single source of truth as everything will be stored in redis.. thus in the future when we implement the operator to see what test is being executed.. it can directly query the redis for state..
ack. My point was we do not read the config file with all workloads. What you are suggesting above would be yet another RFE, outside the scope of this one.
The idea here being, we create a single state, at which we know the workload is RUNNING|FAILED|COMPLETE, from the purview of SNAFU.
Open to other ideas that will also scale..