Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[rfe] define shared message bus keys #134

Open
jtaleric opened this issue Feb 3, 2020 · 4 comments
Open

[rfe] define shared message bus keys #134

jtaleric opened this issue Feb 3, 2020 · 4 comments

Comments

@jtaleric
Copy link
Member

jtaleric commented Feb 3, 2020

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.

@aakarshg
Copy link
Contributor

aakarshg commented Feb 3, 2020

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.

@jtaleric
Copy link
Member Author

jtaleric commented Feb 3, 2020

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

@aakarshg
Copy link
Contributor

aakarshg commented Feb 4, 2020

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..

@jtaleric
Copy link
Member Author

jtaleric commented Feb 4, 2020

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..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants