[Gluster-infra] [Gluster-devel] Announcing Softserve- serve yourself a VM

Nigel Babu nigelb at redhat.com
Tue Mar 20 08:33:48 UTC 2018

Please file an issue for this:

On Tue, Mar 20, 2018 at 1:57 PM, Sanju Rakonde <srakonde at redhat.com> wrote:

> Hi Nigel,
> I have a suggestion here. It will be good if we have a option like request
> for extension of the VM duration, and the option will be automatically
> activated after 3 hours of usage of VM. If somebody is using the VM after 3
> hours and they feel like they need it for 2 more hours they will request to
> extend the duration by 1 more hour. It will save the time of engineering
> since if a machine is expired, one has to configure the machine and all
> other stuff from the beginning.
> Thanks,
> Sanju
> On Tue, Mar 13, 2018 at 12:37 PM, Nigel Babu <nigelb at redhat.com> wrote:
>> We’ve enabled certain limits for this application:
>>>>    1.
>>>>    Maximum allowance of 5 VM at a time across all the users. User have
>>>>    to wait until a slot is available for them after 5 machines allocation.
>>>>    2.
>>>>    User will get the requesting machines maximum upto 4 hours.
>>> IMHO ,max cap of 4 hours is not sufficient. Most of the times, the
>>> reason of loaning a machine is basically debug a race where we can't
>>> reproduce the failure locally what I have seen debugging such tests might
>>> take more than 4 hours. Imagine you had done some tweaking to the code and
>>> you're so close to understand the problem and then the machine expires,
>>> it's definitely not a happy feeling. What are the operational challenges if
>>> we have to make it for atleast 8 hours or max a day?
>> The 4h cap was kept so that multiple people could have a chance to debug
>> their test failures on the same day. Pushing the cap to 8h means that if
>> you don't have a machine to loan when you start work one will not be
>> available until the next day. At this point, we'll not be increasing the
>> timeout. So far, we've had one person actually hit this. I'd like to see
>> more data points before we make an application level change.
>> --
>> nigelb
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-infra/attachments/20180320/0fb5595c/attachment.html>

More information about the Gluster-infra mailing list