I updated my test system, edited bootresources.yaml to import Trusty under "releases" (and with the "release" label), and re-ran the import script. This failed with:
Traceback (most recent call last):
File "/usr/sbin/maas-import-pxe-files", line 30, in <module>
main(args)
File "/usr/lib/python2.7/dist-packages/provisioningserver/import_images/boot_resources.py", line 515, in main
snapshot_path, meta_file_content, targets_conf, targets_conf_content)
File "/usr/lib/python2.7/dist-packages/provisioningserver/import_images/boot_resources.py", line 469, in write_snapshot_metadata
atomic_write(meta_file_content, meta_file, mode=0644)
File "/usr/lib/python2.7/dist-packages/provisioningserver/utils/__init__.py", line 306, in atomic_write
temp_file = _write_temp_file(content, filename)
File "/usr/lib/python2.7/dist-packages/provisioningserver/utils/__init__.py", line 272, in _write_temp_file
dir=directory, suffix=suffix, prefix=prefix)
File "/usr/lib/python2.7/tempfile.py", line 308, in mkstemp
return _mkstemp_inner(dir, prefix, suffix, flags)
File "/usr/lib/python2.7/tempfile.py", line 239, in _mkstemp_inner
fd = _os.open(file, flags, 0600)
OSError: [Errno 2] No such file or directory: '/var/lib/maas/boot-resources/snapshot-20140410-173132/.maas.meta.VfgRWu.tmp'
Got it!
The snapshot directory is created on the fly, as new files are downloaded from the repository. The import code also generates a JSON dump of the snapshot's metadata in memory. Then, it compares the JSON dump to what's in the current snapshot's maas.meta.
If the two are identical, there are no changes and further steps can be skipped. But if the two differ, the metadata has (probably) changed. In that case, the code writes the JSON dump to a new maas.meta file in the new snapshot, and promotes the snapshot to the current one.
The problem comes when the metadata has changed, but there are no new downloads. The code attempts to write maas.meta, but the snapshot directory does not exist!