User stories for the machine reservation system

[lmr]

Disclaimer: I'm by no means a specialist in the fine art of writing user stories, just thought I'd write how I envision this functionality to work. My final goal is to have also more fine grained control over machine selection (hardware capabilities), but as we did not implement advanced scheduling yet, I won't include that in the couple of user stories I wrote.

1. Kayla is a Software Engineer working for FooCorp. She needs a RHEL 5.8 box for a couple of days to reproduce a problem found by a customer in one of FooCorp's products.

She wants to go to the hosts list, select one host, and tell that this host has to be provisioned with RHEL 5.8, and that she'll use it for 48 hours.

She then presses 'Reserve' and after 20 minutes, gets an email telling that her request was fullfilled and she's supposed to use the machine from now (May 15th, 2003, 15:00 GMT) to (May 17th, 2013, 15:00 GMT), with login information, and with her SSH public key (that she already registered at the autotest server on her profile page) already installed in the box, so she can log in there without having to use a password.

An email comes out 2 hours before the reservation is about to end, telling her that, and once the time has passed, the machine becomes available for new test jobs immediately.

2. Rob is a Test Automation Engineer working for BarCorp. He needs a box so he can verify whether his cgroup test suite is working properly on the linus's tree, head of the master branch.

He wants to use the command line to select one host, and tell that this host has to run a kernel compiled from linus's git repo, master branch, and that he is going to use it for an indeterminate amount of time.

He then presses 'Reserve' and after 20 minutes, gets an emaill telling that his request was fullfilled and he has a reservation on that system from now (May 15th, 2003, 15:00 GMT) and doesn't have an end time specified, with login information (user and password, since he didn't register an SSH key at the autotest server). The email states that is a bad practice to specify indefinite amounts of time, since he might forget to release the system, so it can be used efficiently among his peers, and that he has to explicitly go to the web interface (hosts tab), and select to 'release' the system, after which the machine becomes available to run jobs again.

[lmr]

@clebergnu and @juliusgawlas, this is what I had in mind. Of course, this is pretty loose, but at least it's a more concrete statement on how I think the functionality should work.

[clebergnu]

I would also like to see Autotest handling both user case scenarios.

I see two obvious piece of code/logic common to both stories:

• The periodic checking of reservation deadlines by the scheduler
• The SSH key deployment

I believe the SSH key deployment should be the first one implemented, as it is useful on its own in two different areas:

• To regular users that want to ssh into their test machines
• To default (autotest/debug_user) users when running automatic jobs, because that would remove simplify the cobbler/installation script logic

It would basically mean:

• Expanding the User database model and adding a field (or a one to many relationship) to the user key (or keys)
• Writing server side code that handles key less authentication while running ssh-copy-id (or re-implementing the same thing)

Now playing devil's advocate: how much effort should we put here once we've thought about relying on say, Beaker, for lab automation?

[juliusgawlas]

I would like to agree with Cleber and propose to separate SSH from this request; Since I am focusing on reservations I would slightly redo the user stories (same disclaimers about user stories as lmr):

1. as an autotest user I can use GUI to reserve a host for a specified period of time and the hosts will have my profile installed.

Background information: Kayla is a Software Engineer working for FooCorp. She needs a RHEL 5.8 box for a couple of days to reproduce a problem found by a customer in one of FooCorp's products. She wants to tell autotest to pick any host from the test pool, and tell that this host has to be provisioned with RHEL 5.8, and that she'll use it for 48 hours starting Mon morning. She would like to do that by using autotest GUI and receive email reminding her about the reservation once the appropriate system is reserved and 2 hours before the reservation expires.

Notes:

• no SSH, user will have to use user/password (lets do SSH as separate task)
• if no system is available within configurable time user will be notified and request abandoned
• another user should not be able to reserve the concrete system with time overlapping the other reservation (if concrete system was used)

2. as an autotest user I can use CLI to reserve a metahost for a specified period of time and the host will have specified profile installed and optionally it will run a test/kernel combination specified by me

Background: Rob is a Test Automation Engineer working for BarCorp. He needs a box so he can verify whether his cgroup test suite is working properly on the linus's tree, head of the master branch. He wants to use the command line to select one host, and tell that this host has to run on RH 5.8 with a kernel compiled from linus's git repo, master branch, and that he is going to use it for an indeterminate amount of time starting now. He then types in CLI and after 20 minutes, gets an emaill telling that his request was fullfilled and he has a reservation on that system from now (May 15th, 2003, 15:00 GMT) and doesn't have an end time specified, with login information (server, user and password). The email states that is a bad practice to specify indefinite amounts of time, since he might forget to release the system, so it can be used efficiently among his peers, and that he has to explicitly go to the web interface (hosts tab), and select to 'release' the system, after which the machine becomes available to run jobs again

Notes:

• test can be any autotest declared test