iscsi/extent RESTful API calls failing with error 'NoneType' object has no attribute 'startswith'

m87

Cadet
Joined
May 9, 2022
Messages
6
Hello,

Short story:
I'm unable to use the v2.0 RESTful API call POST to create an extent. It fails with this traceback:

"message": "'NoneType' object has no attribute 'startswith'",
"traceback": "Traceback (most recent call last):\n File \"/usr/local/lib/python3.9/site-packages/middlewared/restful.py\", line 580, in do\n result = await self.middleware.call(methodname, *method_args, **method_kwargs)\n File \"/usr/local/lib/python3.9/site-packages/middlewared/main.py\", line 1279, in call\n return await self._call(\n File \"/usr/local/lib/python3.9/site-packages/middlewared/main.py\", line 1236, in _call\n return await methodobj(*prepared_call.args)\n File \"/usr/local/lib/python3.9/site-packages/middlewared/service.py\", line 496, in create\n rv = await self.middleware._call(\n File \"/usr/local/lib/python3.9/site-packages/middlewared/main.py\", line 1236, in _call\n return await methodobj(*prepared_call.args)\n File \"/usr/local/lib/python3.9/site-packages/middlewared/schema.py\", line 975, in nf\n return await f(*args, **kwargs)\n File \"/usr/local/lib/python3.9/site-packages/middlewared/plugins/iscsi.py\", line 579, in do_create\n await self.compress(data)\n File \"/usr/local/lib/python3.9/site-packages/middlewared/plugins/iscsi.py\", line 691, in compress\n if extent_disk.startswith('zvol'):\nAttributeError: 'NoneType' object has no attribute 'startswith'\n"
}

The full gory details:
I've tried this two ways - via curl,

curl -X POST https://servername.goes.here/api/v2.0/iscsi/extent -H "Authorization: Bearer API_KEY_GOES_HERE" -H "Content-Type: application/json" -d '{"name": "herpderp", "path": "/dev/zvol/spinnersvol/herpderp_27th", "filesize": 0, "blocksize": 512, "pblocksize": true, "comment": "Whodunnit", "insecure_tpc": true, "xen": false, "rpm": "UNKNOWN", "ro": true, "enabled": true}'

and via python, using the requests library, my JSON data looks like this:
Code:
{
    "name": "herpderp",
    "path": "zvol/spinnersvol/herpderp_27th",
    "filesize": 0,
    "blocksize": 512,
    "pblocksize": True,
    "comment": "Whodunnit",
    "insecure_tpc": True,
    "xen": False,
    "rpm": "UNKNOWN",
    "ro": True,
    "enabled": True,
}


In each case, the results are the same - and yes, those are the real names, I used short names for ease of testing.
These tests all produced the error above:
- Updated to 13.0 U4
- JSON data set to only '{"name": ""}'
- fully populated JSON data - meaning all fields were present and assigned valid values
- JSON with only bare minimum fields required (non-nullable)
- JSON "path" assignment first, or last
- "path" starting with "/dev/zvol/spinnersvol....", then only "zvol/spinnersvol....", then finally only "spinnersvol...." and ultimately just ""

The only time I saw any deviation was:
- JSON data set to '{}'
- JSON data set to '{"path": ""}'
This data produced the following message:
Code:
{
 "name": [
  {
   "message": "attribute required",
   "errno": 22
  }
 ]
}


I made sure to exhaust all testing that I could think of this time, and pored over my results with a fine-toothed comb. I'm hoping someone else can fill me in on what I'm missing, because at this point it's either something truly simple/fundamental, or I'm taking crazy pills - or both, maybe.
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,194
Either way, I think you'll want to file a bug report since the API shouldn't be returning tracebacks.
 

m87

Cadet
Joined
May 9, 2022
Messages
6
I was missing something fundamental - if "type" == "DISK", then you set "disk" to "zvol/spinnersvol/etc" - and importantly, "path" is then not used. If, however, "type" == "FILE", then you set "path" to "zvol/spinnersvol/etc" and then "disk" is not used.

They didn't comment on the traceback, though, just closed the PR.
 
Top