profile
viewpoint
Justin jterry75 @Microsoft Redmond, WA

dotnet/Docker.DotNet 1230

:whale: .NET (C#) Client Library for Docker API

microsoft/go-winio 436

Win32 IO-related utilities for Go

jterry75/Bond-ASP.NET-Core-Formatters 3

Implements the formatter collection for running ASP.NET Core applications using Microsoft Bond Serialization/Deserialization.

jterry75/kubernetes 1

Production-Grade Container Scheduling and Management

jterry75/runtime-spec 1

OCI Runtime Specification

jterry75/xrdp 1

xrdp: an open source RDP server

jterry75/cgroups 0

cgroups package for Go

jterry75/cli 0

The Docker CLI

jterry75/containerd 0

An open and reliable container runtime

jterry75/cri 0

Containerd Plugin for Kubernetes Container Runtime Interface

issue commentcontainerd/containerd

LCOW: should not hard code "amd64" architecture

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

jstarks

comment created time in 7 days

pull request commentcontainerd/containerd

Mount snapshots on Windows

@ambarve - PTAL

TBBle

comment created time in 20 days

pull request commentcontainerd/containerd

Commit writable WCOW layers as read-only parent layers

@ambarve - PTAL

TBBle

comment created time in 20 days

pull request commentcontainerd/containerd

Implement windowsDiff.Compare to allow outputting OCI images

@ambarve - PTAL

TBBle

comment created time in 20 days

pull request commentcontainerd/containerd

Use go-winio for applying tarballs

@ambarve - PTAL

TBBle

comment created time in 20 days

pull request commentcontainerd/containerd

Mount snapshots on Windows

@kevpar - PTAL

TBBle

comment created time in 20 days

pull request commentcontainerd/containerd

Commit writable WCOW layers as read-only parent layers

@kevpar - PTAL

TBBle

comment created time in 21 days

pull request commentcontainerd/containerd

Use go-winio for applying tarballs

@kevpar - ptal

TBBle

comment created time in 22 days

issue commentcontainerd/containerd

Windows (WCOW) implementation of diff.Comparer

@kevpar - FYI

TBBle

comment created time in a month

pull request commentcontainerd/containerd

Implement windowsDiff.Compare to allow outputting OCI images

@kevpar / @jstarks - PTAL

TBBle

comment created time in a month

pull request commentcontainerd/cri

Update to latest Windows SandboxImage

@kevpar - FYI

jsturtevant

comment created time in a month

Pull request review commentdotnet/Docker.DotNet

Sign build

 ## files generated by popular Visual Studio add-ons.  .vs-.vscode

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

galvesribeiro

comment created time in a month

Pull request review commentdotnet/Docker.DotNet

Sign build

 ## files generated by popular Visual Studio add-ons.  .vs-.vscode

Can we leave this?

galvesribeiro

comment created time in a month

issue commentdotnet/Docker.DotNet

Can you provide a strong name for the Nuget package?

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

sczhh

comment created time in a month

issue commentdotnet/Docker.DotNet

VB.net? Can you add just an example or two for VB.net

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

ScubaDrew

comment created time in a month

issue commentdotnet/Docker.DotNet

[Announcement] Docker.DotNet -> .Net Foundation

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

galvesribeiro

comment created time in a month

issue closeddotnet/Docker.DotNet

[Announcement] Docker.DotNet -> .Net Foundation

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!

closed time in a month

galvesribeiro

issue commentdotnet/Docker.DotNet

[Announcement] Docker.DotNet -> .Net Foundation

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.

galvesribeiro

comment created time in a month

issue commentdotnet/Docker.DotNet

Events monitoring stream does not seems to always include CR or LF character at the end of every messages

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

simardst

comment created time in a month

issue commentdotnet/Docker.DotNet

[Announcement] Docker.DotNet -> .Net Foundation

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

galvesribeiro

comment created time in a month

issue commentdotnet/Docker.DotNet

[But?] The CreateContainerParameters RestartPolicy name is a number value.

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?

treenewlyn

comment created time in a month

pull request commentcontainerd/containerd

Prepare release v1.3.5

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

AkihiroSuda

comment created time in 2 months

pull request commentcontainerd/cri

Support named pipe mounts for Windows containers

@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

comment created time in 2 months

pull request commentcontainerd/containerd

fix panic in shim is not logged

@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

milkwine

comment created time in 2 months

issue commentcontainerd/cri

PullImage with a digest should not pull the image if that digest is already in local store

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.

veerun14

comment created time in 2 months

issue commentcontainerd/cri

PullImage with a digest should not pull the image if that digest is already in local store

@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?

veerun14

comment created time in 2 months

issue commentcontainerd/cri

PullImage with a digest should not pull the image if that digest is already in local store

@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?

veerun14

comment created time in 2 months

issue commentcontainerd/cri

PullImage with a digest should not pull the image if that digest is already in local store

@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

veerun14

comment created time in 2 months

issue commentcontainerd/cri

PullImage with a digest should not pull the image if that digest is already in local store

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

veerun14

comment created time in 2 months

issue commentcontainerd/cri

PullImage with a digest should not pull the image if that digest is already in local store

@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.

veerun14

comment created time in 2 months

pull request commentcontainerd/containerd

Add windows hcsshim to release pipeline

@kevpar - PTAL

cpuguy83

comment created time in 2 months

issue commentcontainerd/containerd

panic in shim is not logged

@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.

AkihiroSuda

comment created time in 3 months

issue commentcontainerd/cri

Custom Runtime Spec Defaults

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

crosbymichael

comment created time in 3 months

issue commentcontainerd/cri

Merge CRI code into upstream containerd

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

crosbymichael

comment created time in 3 months

more