@ambarve - Could you inspect this. Basically anywhere that assumes "amd64" replace with runtime.GOARCH

@ambarve - PTAL

@ambarve - PTAL

@ambarve - PTAL

@ambarve - PTAL

@kevpar - PTAL

@kevpar - PTAL

@kevpar - ptal

@kevpar - FYI

@kevpar / @jstarks - PTAL

@kevpar - FYI

No if you have made any project specific settings/debug/etc it will be in .vscode. Its a pretty standard practice to .gitignore the .vscode folder

Can we leave this?

@galvesribeiro is working on a release here now that we are part of the foundation. Thanks

I actually have never written VB.net :). If you have any though I would be happy to merge a change to showing this

Ok great. That is what @galvesribeiro is working on to get the signing requirements using the foundations key. Thanks

Hello folks!

We are in process of move Docker.Dotnet to .Net Foundation and as many of you may have noticed, the repo was already been moved to dotnet/ GitHub organization.

Microsoft has donated the project to the Foundation as we requested!

What does that mean for us? Well, to start, we get:

1. We can have our own release cadence. While under Microsoft/ org, even as an OSS project, we had to follow their release cadence and we were struggling to get a release out since the packages weren't meeting internal requirements;
2. We now are free to explore new .Net Core/Standard APIs since we are not obligated to maintain back compat with old and unsupported .Net Framework releases.

So, I just would like to thanks @jterry75 and the other MSFT folks along to the contributors of the project up to Today! Many projects are using this library and we're looking forward to provide more capabilities to the package and enhance it even more!

So, what now?

As we are in process of migrate things over to the new project structure/governance under the foundation, we still need a few things to get set up before we can launch a new release like for example, CI/CD pipeline, package signing, and NuGet publish.

Once we have those last things settled, we're going to release a package version with the current codebase.

After this package is pushed out, we will start designing the new versions and the revamp of the codebase using modern things provided Today by .Net Core and .Net Standard libraries like Span/Memory, replace the current golang based code generator with one based on Roslyn, etc.

I can't wait to start on the new life of this package.

Again thank you all from the community and contributors, lets revamp this package again!

I'll keep you all posted.

Cheers!

Thanks @galvesribeiro. Lets close this one out since it was transferred and then when you get the signing updated we can close out the others.

Has anyone looked at how the golang client handles this case?

@tfenster - The transfer was completed. Are you looking for something specific?

https://github.com/dotnet/Docker.DotNet/blob/master/src/Docker.DotNet/Models/RestartPolicyKind.cs#L17

This should be serializing as a string value. Are you saying that we are sending the integer value 3 instead?

@kevpar - PTAL - Looks like they added options.Root to the Cleanup api. We will want to rev hcsshim to the new proto format here.

@kevpar - Looks like one of the unit tests broke. Need to update the assumption there or else fix the code not sure didnt look into it. But good point, can you add a unit test for this in the same file as well for npipe on windows

@kevpar - Since it looks like this is going to be a fifo approach for windows, we will likely need the shim on Windows to re-log the panic.log file in the task's dir. This will need a follow up pr from the Windows side

I'm totally ok with that as well, however I should point out that currently ListImages, ImageStatus, RemoveImage and ImageFsInfo are not currently namespaced. Its only PullImage that supports this and so namespaces might require a change to CRI as well.

@mikebrow - The reason why you need to always Pull, and the Inspect/Pull workflow does not work is because of the following:

if (!InspectImage(name))
{
    PullImage(name, auth1) // -> OnDisk
}

2nd pod

if (!InspectImage(name))
{
    PullImage(name, auth2)
}

The 2nd pod referencing that image could have different auth, and in that case the inspect would succeed because its already local, and we would call CreateContainer without inspecting the auth of the 2nd container referenced to that registry.

I think thats why my workflow above to Derek is the better approach? What do you think?

@dmcgowan - Mike is sort of convincing me (by accident :) ) that its only safe to do that if the digest on disk was resolved with no auth. IE:

Scenario 1:

PullImage (name, auth) // -> digest auth:true
PullImage(name, null) //  -> Real registry call because the on disk is attributed as auth:true

Scenario 2:

PullImage(name, null) // -> digest auth:false
PullImage(name, null) // -> No registry call because digest is local with attribute auth:false so we know this is also safe.

Scenario 3:

PullImage(name, auth) // -> digest auth:true
Pullimage(name, null) // -> Real registry, but if succeeds we can "upgrade" local digest to auth:false since this one worked.
PullImage(name, null) // -> No registry call, again because manifest is now auth:false

Since you are the expert, I will refer to you here but what do you think about the above expectation?

@mikebrow - I agree with all above. Just one more question, why is it not safe to make PullImage idempotent? IE:

PullImage docker.io/library/busybox@sha256:1c35c441208254cb7c3844ba95a96485388cef9ccc0646d562c7fc026e04c807

PullImage docker.io/library/busybox@sha256:1c35c441208254cb7c3844ba95a96485388cef9ccc0646d562c7fc026e04c807

First one actually pulls. 2nd one doesnt. The reason why is because in full async, there is no ability to lock CRI for the duration of "inspect/pull" and further "inspect" does not take into account the proper credential

Also, the default for crictl create now "pulls" all the time. You have to explicitly pass --no-pull which is horribly annoying experience because you have to know the state of the images before calling the cmd

@mikebrow - It seems to be a common pattern to do this:

1. RunPodSandbox
2. PullImage (for containers 1 - N)
3. CreateContainer (1 -N)
4. StartContainer (1 -N)

2/3/4 are done async usually.

@kevpar - PTAL

@kevpar - We should make our shim adhere to what happens here. We currently write out a file but that file is in the task's dir that gets auto cleaned up. Likely the containerd side needs to look for this file from a shim and return it as an error before cleaning the task dir but lets just make sure we do the same.

What are you trying to set here? Container create opts / shim opts? The runtime handler opts as they are today are really about shim opts

Agree! @kevpar - You may want to get the WCOW changes PR'd or wait to do against containerd post this.