-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Layer refactor #2029
Layer refactor #2029
Conversation
8bb7864
to
7d729e5
Compare
388d8c0
to
67b8035
Compare
// entry in the list. | ||
scratchLayer = filepath.Join(scratchLayer, "vm") | ||
scratchVHDPath := filepath.Join(scratchLayer, "sandbox.vhdx") | ||
if err = os.MkdirAll(scratchLayer, 0777); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't seem right that we create directories or copy vhd as part of Parse function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. However, this is just for backwards compatibility so we can remove this code in the future. Plus, if we don't create these files here, we will have to pass all the layer paths to the UVM creator function (via the WCOWBootFiles
struct) which I am trying to avoid. What do you think? Let's ask @kevpar too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree having this in a function named Parse
is non-ideal, but it is work we want to get out of the way initially so we don't have to worry about it later. Maybe there is a better name for this function which conveys that it does some setup work too?
6c17a7a
to
e9720ad
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For future reference, I think it would have been better to do the CimFS UVM code deletion as a separate PR. It doesn't really relate to layer refactoring, as far as I'm aware?
// TODO(ambarve): | ||
// correctly handle cleanup of cimfs layers in case of shim process crash here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the current thinking here? Are we still evaluating with containerd if the new deletion behavior should be changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The old behavior of container was actually due to a bug, that means with 2.0 onwards we need to persist layer data for each container started within a shim and properly clean it up during shim delete
call. However, that's a medium/large change so it needs to be handled in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this change need to be backported to 0.12, or can we get it into 0.13 for containerd 2.1?
5e3ccbe
to
b914759
Compare
It was related in the sense that we didn't need the
For now we are aiming for containerd 2.1 with a 0.13 tag on hcsshim because we don't have any strong reason to backport this to 0.12, we can backport in the future if required. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM pending one change to the defer
block in storage.go.
My understanding is the following work will be done as follow-up PRs:
- Refactor the containerd mount parsing code into the containerd repo.
- Properly track mounted layers for later removal on shim
delete
call.
As we refactor the layer management code, it is easier to keep LCOW & WCOW layer management code in their own separate files. Signed-off-by: Amit Barve <ambarve@microsoft.com>
Adds a set of functions that can parse layers or rootfs mounts provided by containerd into structs that can be later used for mounting layers. Primary purpose of this change is to remove restriction of always representing layers as an array of strings. Signed-off-by: Amit Barve <ambarve@microsoft.com>
This commit uses the newly added WCOW layer parsers and the new type for representing mounted WCOW layers. LCOW functions are also moved around (and renamed) to follow similar style as that of WCOW functions. Signed-off-by: Amit Barve <ambarve@microsoft.com>
Current layer writer interface forces us to calculate the CIM path from the layer path by making assumptions about CIM storage. This isn't a very good approach, better way is to be explicit about what information the layer writer needs from containerd. This change updates the CIM layer writer to take in layer CIM & parent CIM paths as inputs. This also means a corresponding changes needs to be made in containerd. Signed-off-by: Amit Barve <ambarve@microsoft.com>
CimFS is currently not supported with HyperV isolation. However, we still have code that handles processing of UtilityVM layer during image import. After the layer refactoring change we need to update this code as well. But since this code isn't being used anywhere updating it doesn't make much sense. There are no tests for this either. This code is removed for now and we can add it back later once the plan for running HyperV isolated containers with CimFS is more solid. Signed-off-by: Amit Barve <ambarve@microsoft.com>
Currently container image layers are represented as an array of strings everywhere in the hcsshim code. This representation is good enough for WCIFS based layers, however, some other types of layers (for e.g. CimFS) can not be cleanly represented in this format. This has already made some of the layer management code hacky and adding newer types of layers is getting more difficult. We need a better way of representing different types of layers.
Current workflow is that containerd forwards the layer information via a RootFS mount to the shim. Shim parses that mount and fills the layer folders into the
spec.Windows.LayerFolders
field in the container spec. (In some cases thespec.Windows.LayerFolders
is already populated and no RootFS mount is passed). ThisLayerFolders
array is then used in multiple packages within the shim code. This refactoring makes following changes to this workflow:spec.Windows.LayerFolders
) into a Go type that represents a specific type of layers (e.g. WCIFS, CimFS etc.)With these changes adding new type of layers or making changes to exiting layer functionality is much easier.
The PR is broken into 4 commits for easier review:
Future work:
shim delete
is completely removed. The assumption thatshim delete
will be issued by containerd for every container is incorrect (Containerd doesn't issueshim delete
for containers anymore. containerd/containerd#9727) so this code wasn't doing much anyway. A new PR will be made to handle this cleanup properly.