You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A reported getting a JSONDecodeError in the output when trying to provision a maas system. It sounds like the user had also either specified a storage configuration, or else the system just had been configured with a default storage configuration and failed to get the block device data associated with it.
This needs investigation.
The JSONDecodeError happened because it didn't get json back from the call and it was expected. It is not maas that was supposed to generate the json, it was a method in the custom storage module for the maas device connector which runs a command to retrieve disk information about the maas node and either raises an exception if the command failed, or constructs json from the output and returns it. The command succeeded, but there was no output with which to construct the json, resulting in this corner case which was unexpected.
I would like to better understand what happened here to understand if this is a normal situation that can be recovered from, or whether it's an error condition and we should raise an exception. Reproducing this in the server lab might help if possible.
Log output from the failed provision step:
*****************************************************
* Starting testflinger provision phase on jasperoid *
*****************************************************
Traceback (most recent call last):
File "/usr/local/bin/snappy-device-agent", line 8, in <module>
sys.exit(main())
File "/usr/local/lib/python3.8/dist-packages/testflinger_device_connectors/cmd.py", line 83, in main
sys.exit(func(args))
File "/usr/local/lib/python3.8/dist-packages/testflinger_device_connectors/devices/__init__.py", line 321, in wrapper
return func(*args, **kwargs)
File "/usr/local/lib/python3.8/dist-packages/testflinger_device_connectors/devices/maas2/__init__.py", line 41, in provision
device = Maas2(args.config, args.job_data)
File "/usr/local/lib/python3.8/dist-packages/testflinger_device_connectors/devices/maas2/maas2.py", line 51, in __init__
self.maas_storage = MaasStorage(self.maas_user, self.node_id)
File "/usr/local/lib/python3.8/dist-packages/testflinger_device_connectors/devices/maas2/maas_storage.py", line 40, in __init__
self.node_info = self._node_read()
File "/usr/local/lib/python3.8/dist-packages/testflinger_device_connectors/devices/maas2/maas_storage.py", line 56, in _node_read
return self.call_cmd(cmd, output_json=True)
File "/usr/local/lib/python3.8/dist-packages/testflinger_device_connectors/devices/maas2/maas_storage.py", line 84, in call_cmd
return json.loads(output)
File "/usr/lib/python3.8/json/__init__.py", line 357, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.8/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.8/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
The text was updated successfully, but these errors were encountered:
A reported getting a JSONDecodeError in the output when trying to provision a maas system. It sounds like the user had also either specified a storage configuration, or else the system just had been configured with a default storage configuration and failed to get the block device data associated with it.
This needs investigation.
The JSONDecodeError happened because it didn't get json back from the call and it was expected. It is not maas that was supposed to generate the json, it was a method in the custom storage module for the maas device connector which runs a command to retrieve disk information about the maas node and either raises an exception if the command failed, or constructs json from the output and returns it. The command succeeded, but there was no output with which to construct the json, resulting in this corner case which was unexpected.
I would like to better understand what happened here to understand if this is a normal situation that can be recovered from, or whether it's an error condition and we should raise an exception. Reproducing this in the server lab might help if possible.
Log output from the failed provision step:
The text was updated successfully, but these errors were encountered: