Arvados

Not sure if this is the same problem, but the error I ran into was "can't update mounts when state is Final" (not exact wording) when trying to cancel a container that was in Locked state.

I'm not able to reproduce the issue, please provide a specific case.

On Pirca, trying to move https://workbench.pirca.arvadosapi.com/container_requests/pirca-xvhdp-om4zxfsae65h29f#Log into a project, I get:

//railsapi.internal/arvados/v1/container_requests/pirca-xvhdp-om4zxfsae65h29f: 422 Unprocessable Entity: Mounts cannot be modified in state 'Final' ({"/keep/bcca5ee5b64d1f30296f204be49fc050+270"=>{"kind"=>"collection", "portable_data_hash"=>"bcca5ee5b64d1f30296f204be49fc050+270"}, "/tmp"=>{"capacity"=>1073741824, "kind"=>"tmp"}, "/var/spool/cwl"=>{"capacity"=>1073741824, "kind"=>"tmp"}}, {"/keep/bcca5ee5b64d1f30296f204be49fc050+270"=>{"capacity"=>0, "commit"=>"", "content"=>nil, "device_type"=>"", "exclude_from_output"=>false, "git_url"=>"", "kind"=>"collection", "path"=>"", "portable_data_hash"=>"bcca5ee5b64d1f30296f204be49fc050+270", "repository_name"=>"", "uuid"=>"", "writable"=>false}, "/tmp"=>{"capacity"=>1073741824, "commit"=>"", "content"=>nil, "device_type"=>"", "exclude_from_output"=>false, "git_url"=>"", "kind"=>"tmp", "path"=>"", "portable_data_hash"=>"", "repository_name"=>"", "uuid"=>"", "writable"=>false}, "/var/spool/cwl"=>{"capacity"=>1073741824, "commit"=>"", "content"=>nil, "device_type"=>"", "exclude_from_output"=>false, "git_url"=>"", "kind"=>"tmp", "path"=>"", "portable_data_hash"=>"", "repository_name"=>"", "uuid"=>"", "writable"=>false}}) (req-evc322zkn8hjjscktltz)

It seems that controller is passing empty (zero-value) fields and that's why the validation fails:

Previous state¶

{
    "/keep/bcca5ee5b64d1f30296f204be49fc050+270"=>{
        "kind"=>"collection", 
        "portable_data_hash"=>"bcca5ee5b64d1f30296f204be49fc050+270" 
    }, 
    "/tmp"=>{
        "capacity"=>1073741824, 
        "kind"=>"tmp" 
    }, 
    "/var/spool/cwl"=>{
        "capacity"=>1073741824, 
        "kind"=>"tmp" 
    }
} 

New state¶

{
    "/keep/bcca5ee5b64d1f30296f204be49fc050+270"=>{
        "capacity"=>0, 
        "commit"=>"", 
        "content"=>nil, 
        "device_type"=>"", 
        "exclude_from_output"=>false, 
        "git_url"=>"", 
        "kind"=>"collection", 
        "path"=>"", 
        "portable_data_hash"=>"bcca5ee5b64d1f30296f204be49fc050+270", 
        "repository_name"=>"", 
        "uuid"=>"", 
        "writable"=>false
    }, 
    "/tmp"=>{
        "capacity"=>1073741824, 
        "commit"=>"", 
        "content"=>nil, 
        "device_type"=>"", 
        "exclude_from_output"=>false, 
        "git_url"=>"", 
        "kind"=>"tmp", 
        "path"=>"", 
        "portable_data_hash"=>"", 
        "repository_name"=>"", 
        "uuid"=>"", 
        "writable"=>false
    }, 
    "/var/spool/cwl"=>{
        "capacity"=>1073741824, 
        "commit"=>"", 
        "content"=>nil, 
        "device_type"=>"", 
        "exclude_from_output"=>false, 
        "git_url"=>"", 
        "kind"=>"tmp", 
        "path"=>"", 
        "portable_data_hash"=>"", 
        "repository_name"=>"", 
        "uuid"=>"", 
        "writable"=>false
    }
}

Update: I've kept trying to reproduce the issue and found something interesting: I was able to get the error when attempting to move a CR on pirca (v2.3.1~rc3), but when doing so on ce8i5 or tordo (both v2.4.0~dev) or even jutro (v2.2.1), they worked just fine.

Status update: While trying to reproduce the issue on local arvbox instances running different arvados versions, I realized that the failure isn't related to the version as previously thought, but the bug is triggered by some other reason. Example:

• Container request ce8i5-xvhdp-haiyk7xqphcjf4u doesn't have any issues with being moved.
• Container request ce8i5-xvhdp-pk34kuh6ghs8qvm cannot be moved, giving a similar error that the one described on this ticket.

Both CRs have a read-only collection-type mount and several temp mounts.

services/api/app/models/container_request.rb

  def check_update_whitelist
    ...
    elsif mounts_changed? && mounts_was.keys == mounts.keys
      ...

This looks like it's unintentionally sensitive to key order. Perhaps the outcome is different when, while reformatting the get/list response, controller sorts the keys differently than the program that created (or most recently updated) the record?

The ordering didn't seem to be a problem (although I think it won't hurt to .sort() the keys list for comparison), but I think I've found what's the problem: The code from check_update_whitelist doesn't take 0 (zero) as one of the zero-values.

Updates at 1f626bc34 - branch 18301-wb1-cancel-button-fix
Test run: developer-run-tests: #2831

• Adds 0 (zero) as one of the default values that needs to be ignored when validating changes on mounts.
• Adds test case.

Lucas Di Pentima wrote:

Updates at 1f626bc34 - branch 18301-wb1-cancel-button-fix
Test run: developer-run-tests: #2831

• Adds 0 (zero) as one of the default values that needs to be ignored when validating changes on mounts.
• Adds test case.

This LGTM