Skip to content
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

Handle Wasm Images with wasm media types #147

Merged
merged 2 commits into from
Oct 25, 2023

Conversation

jsturtevant
Copy link
Contributor

@jsturtevant jsturtevant commented Jun 16, 2023

fixes: #108 (requires changes in containerd)

This adds the ability to handle oci artifacts as described in the proposal in https://docs.google.com/document/d/11shgC3l6gplBjWF1VJCWvN_9do51otscAm0hBDGSSAc.

Containerd doesn't currently support passing the annotations for the OCI artifact format and needs the following PR: containerd/containerd#8699

This pr relies on containerd/containerd#9142 which has been merged upstream

@jsturtevant
Copy link
Contributor Author

This should likely go in after #142, will need some refactoring to support the executor. But wanted to get some eyes on the general direction.

@jsturtevant jsturtevant force-pushed the handle-oci-artifacts branch 5 times, most recently from fbf9af5 to dbf29de Compare July 21, 2023 18:22
@jsturtevant
Copy link
Contributor Author

This no longer works after #131 since the entrypoint points to the wasm module which is no longer in the container image. Will need to re-think how to handle that scenario. Similar situation to #194

@jsturtevant
Copy link
Contributor Author

not sure why the kind-oci test is failing, I ran into #362 when trying locally and will revisit tomorrow now that it is fixed

Comment on lines 126 to 131
let arch = manifest
.config()
.platform()
.as_ref()
.ok_or_else(|| ShimError::Others("failed to extract platform".to_string()))?
.architecture();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great to expose the platform in the WasiContext.
We could use the os part (wasip1/wasip2) to choose between modules or components, and os_features might be useful to know what components we need.

Also, that could also be used to choose between wasm container vs native container, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like this idea of passing OS and Arch to the wasicontext. For features, my understanding is we have some flexibility and we should follow up on how we decide to hand those.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear, I'm not implying we should start using os_features right now.
The details on that would need wider concensus and review.
But if we expose the Platform object (instead of just the OS / Arch strings), we open the door to that option.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've passed this on to the WasiContext, but not sure I like it the current way I did it. input welcome

@jsturtevant jsturtevant force-pushed the handle-oci-artifacts branch 2 times, most recently from a06068a to eda04b0 Compare October 23, 2023 17:15
Mossaka
Mossaka previously approved these changes Oct 23, 2023
Copy link
Member

@Mossaka Mossaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm! Thanks for this awesome work!

@jprendes
Copy link
Collaborator

jprendes commented Oct 23, 2023

CI is failling with

[ERROR] failed to initialize container process: wasmedge executor can't handle spec

which indicates we are hitting this line.

Copy link
Collaborator

@jprendes jprendes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jsturtevant !
I left some minor comments.

Comment on lines +162 to +171
MediaType::ImageLayer
| MediaType::ImageLayerGzip
| MediaType::ImageLayerNonDistributable
| MediaType::ImageLayerNonDistributableGzip
| MediaType::ImageLayerNonDistributableZstd
| MediaType::ImageLayerZstd => true,
MediaType::Other(s)
if s.as_str()
.starts_with("application/vnd.docker.image.rootfs.") =>
{
true
}
_ => false,
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not a big fan of this. We would have to keep maintaining this every time the spec is updated.
Moreover, we are only interested in Wasm layers, why not probe for wasm layers only?
IIUC, this would let things like MediaType::ImageIndex, MediaType::ImageManifest, MediaType::ArtifactManifest to get through.

Could we use something like this instead?

.filter_map(|config| match config.media_type() {
    MediaType::Other(s) if s.starts_with("application/vnd.bytecodealliance.wasm.") => {
        Some(self.read_content(config.digest()).map(|module| WasmLayer {
            config: config.clone(),
            layer: module,
        }))
    }
    _ => None,
})

I can also imagine evolving WasmLayer into an enum that can tell apart different types of wasm layers (modules, components, etc), but not for this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I didn't do just wasm layer types is because runtimes like spin/slight (probably others) will need to pass there configuration files. By leaving this more open ended, initially, we allow for those other types. In the case of spin they also have a media type for a module that doesn't match the application/vnd.bytecodealliance.wasm format.

I would like to tighten this up in the future once we get to the point where "everything is component" approach. The extra config files, static files, etc would just be component that the runtime knows how to use. But feels to early to be restrictive here.

I am not too concerned about this logic change all that often. It is a borrowed, idea from containerd's IsLayerType and that hasn't had a change in 4 years.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could add in the Instance trait a method to declare what layers it cares about (with a reasonable default impl).

Something like:

fn supported_layers_types() -> &'static [&'static str] {
    &["application/vnd.bytecodealliance.wasm.component.layer.v0+wasm"]
}

or maybe something like:

fn supports_layer_type(ty: MediaType) -> bool {
    match ty {
        MediaType::Other(s) => s.starts_with("application/vnd.bytecodealliance.wasm."),
        _ => false,
    }
}

If you think the current approach is better I'm happy with that as well, I don't want to block it over this :-)

crates/containerd-shim-wasm/src/sandbox/containerd.rs Outdated Show resolved Hide resolved
Mossaka
Mossaka previously approved these changes Oct 24, 2023
Copy link
Member

@Mossaka Mossaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@jsturtevant
Copy link
Contributor Author

jsturtevant commented Oct 24, 2023

heads up this has the commit from #362

@jsturtevant jsturtevant changed the title Handle oci artifacts Handle Wasm Images with wasm media types Oct 25, 2023
@jsturtevant
Copy link
Contributor Author

heads up this has the commit from #362

I dropped it, as it shouldn't be needed.

Signed-off-by: James Sturtevant <jstur@microsoft.com>
Signed-off-by: James Sturtevant <jstur@microsoft.com>
Copy link
Collaborator

@jprendes jprendes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Distribute using OCI artifacts / allow shim to pull artifact
4 participants