Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1576817 - RFE -couple of minutes after the transfer(upload disk) was paused by the system due to inactivity upload did not stop but 2 minutes afterwards
Summary: RFE -couple of minutes after the transfer(upload disk) was paused by the syst...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RFEs
Version: 4.2.3.5
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Rob Young
QA Contact: Avihai
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-10 12:43 UTC by Avihai
Modified: 2020-04-01 14:52 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: Storage
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)
upload_with_inactivity_script (5.77 KB, text/x-python)
2018-05-10 12:43 UTC, Avihai
no flags Details
engine, vdsm , proxy , deamon logs (1.41 MB, application/x-gzip)
2018-05-10 12:53 UTC, Avihai
no flags Details

Description Avihai 2018-05-10 12:43:50 UTC
Created attachment 1434349 [details]
upload_with_inactivity_script

Description of problem:
For a couple of minutes after the transfer(upload disk) was paused by the system due to inactivity upload itself did not stop but only after 2 minutes afterward.


Daniel E. stated:
"Currently pause doesn't remove the ticket as we need to allow resume using the existing ticket. 
We could perhaps add some 'paused' flag to the ticket and handle it in the daemon accordingly. 

You can open an RFE about that and we'll decide if it's interesting enough.
"

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Script attached to simulate upload with inactivity value of 10sec and sleep of 70 sec,
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Avihai 2018-05-10 12:52:57 UTC
Engine shows pasue by system:
2018-05-10 12:19:05 -  EVENT_ID: UPLOAD_IMAGE_PAUSED_BY_SYSTEM_TIMEOUT
 
deamon log shows another write(upload) started 2 minutes later at 2018-05-10
12:21:14
2018-05-10 12:21:14,835 INFO    (Thread-5) [web] START [10.35.162.7] PUT
/images/c3db24af-70b2-45e4-9d3d-fca7872cb184
2018-05-10 12:21:14,836 INFO    (Thread-5) [images] Writing 16777216 bytes
at offset 33554432 flush True to

Comment 2 Avihai 2018-05-10 12:53:56 UTC
Created attachment 1434350 [details]
engine, vdsm , proxy , deamon logs

Comment 3 Nir Soffer 2018-06-05 17:49:50 UTC
If the transfer was paused because of inactivity, it means inactivity_timeout
seconds passed since the last client request was finished.

If the client is using code like:

   while not done:
       send PUT request
       write data
       sleep inactivity_timeout + 10

Then I think we can expect that the ticket will paused, and the next PUT request
will fail with an error like "403 Forbidden", with a json error about 
"Transfer was paused"

We don't want to remove the ticket since we will loose the ticket state, but we
can add a "paused" attribute.

To pause a transfer, engine will ask vdsm to modify the ticket:

    Host.update_image_ticket(ticket_uuid, {"paused"=true})

Vdsm will send this request to the daemon:

    PUT /tickets/ticket-uuid
    ...
    {
        "paused": true,
    }

To resume a ticket, engine will send this to vdsm:

    Host.update_image_ticket(ticket_uuid, {"paused"=false, "timeout"=300)

Vdsm will send this request to the daemon:

    PUT /tickets/ticket-uuid
    ...
    {
        "paused": false,
        "timeout": 300
    }

Host.update_image_ticket() will replace Host.extend_image_ticket()
which will be deprecated and removed in future version.

Daniel, what do you think?

Comment 4 Daniel Erez 2018-06-06 08:48:42 UTC
(In reply to Nir Soffer from comment #3)
> If the transfer was paused because of inactivity, it means inactivity_timeout
> seconds passed since the last client request was finished.
> 
> If the client is using code like:
> 
>    while not done:
>        send PUT request
>        write data
>        sleep inactivity_timeout + 10
> 
> Then I think we can expect that the ticket will paused, and the next PUT
> request
> will fail with an error like "403 Forbidden", with a json error about 
> "Transfer was paused"
> 
> We don't want to remove the ticket since we will loose the ticket state, but
> we
> can add a "paused" attribute.
> 
> To pause a transfer, engine will ask vdsm to modify the ticket:
> 
>     Host.update_image_ticket(ticket_uuid, {"paused"=true})
> 
> Vdsm will send this request to the daemon:
> 
>     PUT /tickets/ticket-uuid
>     ...
>     {
>         "paused": true,
>     }
> 
> To resume a ticket, engine will send this to vdsm:
> 
>     Host.update_image_ticket(ticket_uuid, {"paused"=false, "timeout"=300)
> 
> Vdsm will send this request to the daemon:
> 
>     PUT /tickets/ticket-uuid
>     ...
>     {
>         "paused": false,
>         "timeout": 300
>     }
> 
> Host.update_image_ticket() will replace Host.extend_image_ticket()
> which will be deprecated and removed in future version.
> 
> Daniel, what do you think?

We can just add a new api (e.g. pause_image_ticket), which could be simpler. Or do we expect any more values we might want the update in the ticket later on?

Comment 5 Nir Soffer 2018-06-14 13:28:06 UTC
(In reply to Daniel Erez from comment #4)
> We can just add a new api (e.g. pause_image_ticket), which could be simpler.
> Or do we expect any more values we might want the update in the ticket later
> on?

I don't know if we will need new ways to update the ticket, but having a generic
API means we will have to change only engine next time, and it means we need 
single update() API instead of pause() and resume().

Comment 6 Michal Skrivanek 2020-03-18 15:50:21 UTC
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 7 Michal Skrivanek 2020-03-18 15:52:56 UTC
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 8 Michal Skrivanek 2020-04-01 14:49:05 UTC
ok, closing. Please reopen if still relevant/you want to work on it.

Comment 9 Michal Skrivanek 2020-04-01 14:52:02 UTC
ok, closing. Please reopen if still relevant/you want to work on it.


Note You need to log in before you can comment on or make changes to this bug.