While trying to diagnose a LTSC2019-observed failure in containerd/containerd#4419 that I cannot reproduce with hcsshim directly, I noticed that the GUID generated for parent layers by CreateScratchLayer, ExportLayer, ImportLayer, and PrepareLayer is based on the base of the path to the layer (i.e. filepath.Base), not the full path.
This means that, for example, the same GUID is generated for the following unrelated layers which may all be in use in different ways at the same time:
- "C:\Users\ADMINI~1\AppData\Local\Temp\2\test879379962\4"
- "C:\Users\ADMINI~1\AppData\Local\Temp\2\test306434375\4"
- "C:\Users\ADMINI~1\AppData\Local\Temp\2\snapshot-suite-Windows-338921673\root\snapshots\4"
- "C:\Users\ADMINI~1\AppData\Local\Temp\2\snapshot-suite-Windows-494252515\root\snapshots\4"
(The GUID for these four layers is bd9c3ef9-f239-59b5-a27e-15c523b1d149.)
I noticed this is true in both the existing RS1 APIs I mentioned above, and also is done this way in generateShimLayersStruct in the test suite, which is the one place I could find that uses Layer.Id from the RS5 APIs. I note that the RS5 APIs don't actually include a way to generate this GUID, that integration test is using the RS1 API to generate the GUID.
The RS5 documentation doesn't indicate any context for the GUID or expectation that it will be generated using that API, so if I was naively implementing containerd/containerd#4419 using RS5's computestorage instead, there's a good chance I'd have ended up generating a GUID and storing it in the snapshot data. Would that work, or does HCS/vmcompute have some internal systems that depend on matching the GUID provided with an internally-generated GUID?
Annoyingly, changing this to use the full path didn't turn out to fix my issue in containerd, so I'm not clear what the GUID is used for, since both RS1 and RS5 APIs also get the full path, but it still seems weird to to handle the GUID so... non-uniquely. More details on this at containerd/containerd#4419 (comment). This is also where #1071 came from.
I'm assuming this is a legacy of the DriverInfo structure from the RS1 API, although none of the current hcsshim codebase does anything interesting with it (everything deals with full paths internally anyway, and nothing uses GraphDriverType), so perhaps this behaviour can be changed safely now.
While trying to diagnose a LTSC2019-observed failure in containerd/containerd#4419 that I cannot reproduce with hcsshim directly, I noticed that the GUID generated for parent layers by
CreateScratchLayer,ExportLayer,ImportLayer, andPrepareLayeris based on the base of the path to the layer (i.e.filepath.Base), not the full path.This means that, for example, the same GUID is generated for the following unrelated layers which may all be in use in different ways at the same time:
(The GUID for these four layers is
bd9c3ef9-f239-59b5-a27e-15c523b1d149.)I noticed this is true in both the existing RS1 APIs I mentioned above, and also is done this way in
generateShimLayersStructin the test suite, which is the one place I could find that usesLayer.Idfrom the RS5 APIs. I note that the RS5 APIs don't actually include a way to generate this GUID, that integration test is using the RS1 API to generate the GUID.The RS5 documentation doesn't indicate any context for the GUID or expectation that it will be generated using that API, so if I was naively implementing containerd/containerd#4419 using RS5's
computestorageinstead, there's a good chance I'd have ended up generating a GUID and storing it in the snapshot data. Would that work, or does HCS/vmcompute have some internal systems that depend on matching the GUID provided with an internally-generated GUID?Annoyingly, changing this to use the full path didn't turn out to fix my issue in containerd, so I'm not clear what the GUID is used for, since both RS1 and RS5 APIs also get the full path, but it still seems weird to to handle the GUID so... non-uniquely. More details on this at containerd/containerd#4419 (comment). This is also where #1071 came from.
I'm assuming this is a legacy of the
DriverInfostructure from the RS1 API, although none of the current hcsshim codebase does anything interesting with it (everything deals with full paths internally anyway, and nothing usesGraphDriverType), so perhaps this behaviour can be changed safely now.