it just happened to me again ... I need to do testing on a HP-DL1xxx machine

we have a few of them, I've chosen one which I expected to be freed soon

bad guess, it still wasn't free when I was leaving on Friday EOB

now, on Saturday, I've finished helping my parents with some garden stuff and rushed home to connect to VPN to see if I have the machine to extend the reservation time

bad luck, it is already gone

see https://beaker.engineering.redhat.com/jobs/282471

and I still do not see any possibility to set longer reservation time at https://beaker.engineering.redhat.com/reserveworkflow/


p.s. nearly the same with https://beaker.engineering.redhat.com/jobs/279136 but that hadn't relied on specific hardware

I came across this Bugzilla and I wanted to voice my opinion/opposition before some time was spent on development. I am against this request for several reasons.

1.) This request could lead to system not being available for automated testing over the weekend. I am sure in your case you would have been responsible enough to log in over the weekend and run your testing. But, unfortunatley not everyone is so responsible.

2.) We already have a solution for this problem. If you need a specific system then you can contact the owner and request a loan. That way even if your reservation times out you will still have the system.

3.) When you schedule a job in Beaker and you specify the host in your xml or pick a system via the WebUI. Then that job is scheduled with a high priority. 
So you should be aware that it has a greater chance it will run over the weekend if it was not started by EOB Friday. 

4.) You can modify your xml to send you a notification on your phone or private email so you don't have to actually log into the VPN to see if you reservation ran.
<notify>
  <cc>
    <kvolny>
  </cc>
</notify>

In my opinion this RFE will limit the amount of systems available to run automated tests over the weekends.

Bulk reassignment of issues as Bill has moved to another team.

This bugs is closed as it is either not in the current Beaker scope or we could not find sufficient data in the bug report for consideration.
Please feel free to reopen the bug with additional information and/or business cases behind it.

(In reply to comment #2)
> 1.) This request could lead to system not being available for automated
> testing over the weekend. I am sure in your case you would have been
> responsible enough to log in over the weekend and run your testing. But,
> unfortunatley not everyone is so responsible.

no, the point is that I do *not* have to log in over the weekend

> 2.) We already have a solution for this problem. If you need a specific
> system then you can contact the owner and request a loan. That way even if
> your reservation times out you will still have the system.

where is this documented?

- I cannot find a single occurence of "loan" both on http://beaker-project.org/guide/ and https://engineering.redhat.com/trac/rhat/wiki/BeakerUserGuide ...

> 3.) When you schedule a job in Beaker and you specify the host in your xml
> or pick a system via the WebUI. Then that job is scheduled with a high
> priority. 
> So you should be aware that it has a greater chance it will run over the
> weekend if it was not started by EOB Friday. 

ok, I'm aware now ... how does that help the case?

> 4.) You can modify your xml to send you a notification on your phone or
> private email so you don't have to actually log into the VPN to see if you
> reservation ran.

see 1)

> In my opinion this RFE will limit the amount of systems available to run
> automated tests over the weekends.

I don't think there's that much manual testing which meets the conditions of this RFE to have any serious impact ... this concerns only jobs started within a limited time frame; if someone gets the machine early enough before leaving for the weekend (be it on Monday ...), he runs extendtesttime and blocks the machine anyways until the testing is finished

I'd be perfectly happy to have a checkbox "don't schedule this job over weekend" (it could be even default for reservations) which would mean that once the jobs gets its turn being first in the queue, the scheduler will take a look if the date/time is a workday, and if not, it will take the next automated job in the queue, keeping the reservation job first, so it starts as soon as the weekend is over (and the automated job finishes)

this way, the amount of systems available for automated jobs won't be limited, yet still the machine should be ready reserved when the next workday starts - supposing that most of the automated tests take several hours at most

(In reply to comment #4)
> This bugs is closed as it is either not in the current Beaker scope or we
> could not find sufficient data in the bug report for consideration.
> Please feel free to reopen the bug with additional information and/or
> business cases behind it.

please specify which data are you missing?

(In reply to comment #5)
> (In reply to comment #2)
> > 1.) This request could lead to system not being available for automated
> > testing over the weekend. I am sure in your case you would have been
> > responsible enough to log in over the weekend and run your testing. But,
> > unfortunatley not everyone is so responsible.
> 
> no, the point is that I do *not* have to log in over the weekend
Well maybe I am missing your point then. From what it sounds like to me. If you put in a reserve workflow and it scheduled and runs on Friday after work, your timezone then you want to extend the reserve time through the weekend. So that when you come in monday morning that system is avaialble for you on Monday morning. If that is the case I am against it.
> 
> > 2.) We already have a solution for this problem. If you need a specific
> > system then you can contact the owner and request a loan. That way even if
> > your reservation times out you will still have the system.
> 
> where is this documented?
From the UI. On the systems page you can click "Contact Owner" Then click "Request a loan".
> 
> - I cannot find a single occurence of "loan" both on
> http://beaker-project.org/guide/ and
> https://engineering.redhat.com/trac/rhat/wiki/BeakerUserGuide ...
Agreed, Beaker documentation is lacking. There are open requests in RT for Beaker documentation, but they have remained stale for years.
> 
> > 3.) When you schedule a job in Beaker and you specify the host in your xml
> > or pick a system via the WebUI. Then that job is scheduled with a high
> > priority. 
> > So you should be aware that it has a greater chance it will run over the
> > weekend if it was not started by EOB Friday. 
> 
> ok, I'm aware now ... how does that help the case?
Not sure it does. I was just letting you know.
> 
> > 4.) You can modify your xml to send you a notification on your phone or
> > private email so you don't have to actually log into the VPN to see if you
> > reservation ran.
> 
> see 1)
In my opinion if it is truely that important for you to have this system Monday morning then it should be important enough for you to contact the owner and have it loaned to you.
> 
> > In my opinion this RFE will limit the amount of systems available to run
> > automated tests over the weekends.
> 
> I don't think there's that much manual testing which meets the conditions of
> this RFE to have any serious impact ... this concerns only jobs started
> within a limited time frame; if someone gets the machine early enough before
> leaving for the weekend (be it on Monday ...), he runs extendtesttime and
> blocks the machine anyways until the testing is finished
It still doesn't make it right. If you catch people ding that please remind them about Beaker Etiquette
https://wiki.test.redhat.com/Beaker/Etiquette
> 
> I'd be perfectly happy to have a checkbox "don't schedule this job over
> weekend" (it could be even default for reservations) which would mean that
> once the jobs gets its turn being first in the queue, the scheduler will
> take a look if the date/time is a workday, and if not, it will take the next
> automated job in the queue, keeping the reservation job first, so it starts
> as soon as the weekend is over (and the automated job finishes)
> 
> this way, the amount of systems available for automated jobs won't be
> limited, yet still the machine should be ready reserved when the next
> workday starts - supposing that most of the automated tests take several
> hours at most
> 
> (In reply to comment #4)
> > This bugs is closed as it is either not in the current Beaker scope or we
> > could not find sufficient data in the bug report for consideration.
> > Please feel free to reopen the bug with additional information and/or
> > business cases behind it.
> 
> please specify which data are you missing?
MinJung has sent an email to the Beaker users list about this 

"There are about 50 bugs or RFEs that are mass closed after bug triage activity because either they did not fit well with the current scope of Beaker or we could not find sufficient information from the bug report to include it in the future roadmap. Mass closed bugs are marked with the resolution of INSUFFICIENT_DATA and MC in the Whiteboard field."

So I think this BZ was one of those caught in the "catch all".

I think that until we have some common agreement on this BZ. Beaker developers will not invest time on this issue.

Regards,
Jeff

We are not going to implement automatic reservation extensions over the weekend, because as Jeff says it is not fair on other users.

I think your suggestion about excluding jobs from being scheduled over the weekend is a better approach, but it can't be a simple checkbox "not on the weekend" because Beaker simply cannot know what constitutes a weekend for you. (Does it start at 4pm on Friday, or 6pm? In what timezone? What if you are travelling to another timezone this week, or you feel like working late, or going home early?)

So, we could make this an RFE for specifying on a per-job basis particular times of the week where the job should not be started.

But this will be difficult to implement in the current scheduler and for what seems like a negligible gain, especially when we have other mechanisms in place (such as loans, as Jeff has pointed out). So to be honest I do not think it is likely to happen anytime soon.

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #2)
> > > 1.) This request could lead to system not being available for automated
> > > testing over the weekend. I am sure in your case you would have been
> > > responsible enough to log in over the weekend and run your testing. But,
> > > unfortunatley not everyone is so responsible.
> > 
> > no, the point is that I do *not* have to log in over the weekend
> Well maybe I am missing your point then. From what it sounds like to me. If
> you put in a reserve workflow and it scheduled and runs on Friday after
> work, your timezone then you want to extend the reserve time through the
> weekend. So that when you come in monday morning that system is avaialble
> for you on Monday morning. If that is the case I am against it.

yes, that is the case, and it is a bit incompatible with "... to log in over the weekend and run your testing ..."

...
> > if someone gets the machine early enough before
> > leaving for the weekend (be it on Monday ...), he runs extendtesttime and
> > blocks the machine anyways until the testing is finished
> It still doesn't make it right. If you catch people ding that please remind
> them about Beaker Etiquette
> https://wiki.test.redhat.com/Beaker/Etiquette

I won't

often it takes non-trivial efforts to prepare the machine for tests which you'd have to repeat if you return the machine for the weekend, not to talk about storing the temporary results etc.

I find it quite saddening if it is better (cheaper?) to waste people's time than to add some machines to the pool (usually any system would do, even some VM, not every test needs multimillion minframe ...)

...
> > please specify which data are you missing?
> MinJung has sent an email to the Beaker users list about this 
> 
> "There are about 50 bugs or RFEs that are mass closed after bug triage
> activity because either they did not fit well with the current scope of
> Beaker or we could not find sufficient information from the bug report to
> include it in the future roadmap. Mass closed bugs are marked with the
> resolution of INSUFFICIENT_DATA and MC in the Whiteboard field."
> 
> So I think this BZ was one of those caught in the "catch all".

ok, thanks for the explanation, cleaning needinfo then

(In reply to comment #7)
> We are not going to implement automatic reservation extensions over the
> weekend, because as Jeff says it is not fair on other users.

then change the subject to whatever appropriate :-)

> I think your suggestion about excluding jobs from being scheduled over the
> weekend is a better approach, but it can't be a simple checkbox "not on the
> weekend" because Beaker simply cannot know what constitutes a weekend for
> you. (Does it start at 4pm on Friday, or 6pm? In what timezone? What if you
> are travelling to another timezone this week, or you feel like working late,
> or going home early?)

I got some ipmression that Beaker already knows about user timezones ...

as for exact times, using some averages is still better than nothing

> So, we could make this an RFE for specifying on a per-job basis particular
> times of the week where the job should not be started.

I guess per-user would be better approach - are people doing that much testing when travelling?

> But this will be difficult to implement in the current scheduler and for
> what seems like a negligible gain, especially when we have other mechanisms
> in place (such as loans, as Jeff has pointed out). So to be honest I do not
> think it is likely to happen anytime soon.

if loans can assure that I won't miss the opportunity to get the machine once it is free, then it may help the case ... this RFE is from RHTS times ...

Hi Karel, lets take it to (BaseOS) QE board first and investigate if there are other possible solutions for this problem.

so, a few notes from the BaseOS QE meeting -

* this problem is not very common (at least according to the participants); only amarecek has mentioned that he needed specific machines (Core i5/i7) for testing, however his problem was not a missed reservation but inavailability due to machines being in kernel team's pool not usable by us

* an interesting possibility how to motivate people not to keep machines reserved when not actually used, with a few more benefits, would be to have a possibility to make a (LVM) snapshot, making it easy to restore the machine state, not having to configure everything manually from scratch (mmalik seemed fascinated by the idea of snapshots ...)

* unlike the web interface which defaults to 24 h reservation, the commandline allows 99 h, thus making it possible to workaround the issue (said psplicha)

* jscotka's workaround would be to schedule three same reservations in a row ... suggestions getting better, right? :-)

* a few people are aware about "loans" but there's a lot of doubt how does it work - whether it assigns the machine right after the current job finishes or what ... we really need the docs


ok, so now we know that the original issue can be avoided by multiple workarounds

but still, I think it is a good RFE material not to reserve systems for manual testing on weekends by default, so that the machine doesn't wait idle, not running the automatic jobs, while the tester who has asked for the reservation is getting drunk on a Saturday's BBQ party