profile
viewpoint
John Howard lowenna @Microsoft UK https://docs.microsoft.com/archive/blogs/jhoward/ Mostly retired. Previously @microsoft working on Windows container related things - docker/moby/containerd

push eventlowenna/getitv

John Howard

commit sha 28ceec18fe7f138f2c6ca5ce348c32b7fcc890cc

Concurrency test working - move to real code Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 3 days

push eventlowenna/getitv

John Howard

commit sha 86f538445a523984402ec2a5e12b254f5e333ebd

Fix for single episode series Signed-off-by: John Howard <github@lowenna.com>

view details

John Howard

commit sha 8477b51d2d2739aa5286634c4fa75e8ddb2aec5a

Add framework for settings Signed-off-by: John Howard <github@lowenna.com>

view details

John Howard

commit sha baa82e7dac32f4a4a4ffda0576dc9dd44366e788

Add header Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 3 days

push eventlowenna/getitv

John Howard

commit sha 5c7ba9f95daefce5f13db4dca4a52aed48a8fc69

Remove done 'TODO:' statements Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 5 days

push eventlowenna/getitv

John Howard

commit sha e433e6f4944b516d77b548d1f25bab7ac21146b8

Locking on cache Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 5 days

PR closed rmyorston/busybox-w32

ash.c lazy loading of APIs unavailable on nanoserver

Signed-off-by: John Howard jhoward@microsoft.com

Part of the changes required for busybox 64-bit to run on nanoserver in a container on Windows.

Nanoserver does not support the full API surface of the windowsservercore images. This change updates shell/ash.c so that the functions are lazily loaded from kernel32 and do not cause busybox to quit when calling an unsupported API.

The reason for this change (there are others in the pipeline) is to support running docker CI on Windows using nanoserver as the base image. Currently the CI servers at https://github.com/docker/docker use windowsservercore. Docker makes extensive use of busybox for its integration test suite. To move to nanoserver (which dramatically improves) performance and allows the use of Hyper-V containers as well, we need a 64-bit version of busybox which doesn't fail calling Win32 APIs which aren't available in nanoserver.

+16 -4

6 comments

1 changed file

lowenna

pr closed time in 5 days

pull request commentrmyorston/busybox-w32

ash.c lazy loading of APIs unavailable on nanoserver

@jstarks - Closing this, but not sure if anyone really wants to run busybox on nanoserver any more? If so, could someone rebase and carry? Thanks :)

lowenna

comment created time in 5 days

PR closed Azure/azure-functions-docker

Compress python.Dockerfile (stretch/amd64) to a single layer

Signed-off-by: John Howard jhoward@microsoft.com

@ahmelsayed Is there any chance you can try this out and ping me offline with an image I can verify?

+4 -1

4 comments

1 changed file

lowenna

pr closed time in 5 days

pull request commentAzure/azure-functions-docker

Compress python.Dockerfile (stretch/amd64) to a single layer

Going to close this one. Feel free to carry. I have now retired from Microsoft, so will let someone else take up the baton....

lowenna

comment created time in 5 days

PR closed moby/moby

Reviewers
Windows: Add generate-swagger-api.ps1 area/testing kind/enhancement platform/windows status/2-code-review

Signed-off-by: John Howard jhoward@microsoft.com

@johnstep Adds a Windows native way of doing this without the need to run under WSL or a Linux VM.

+27 -0

12 comments

2 changed files

lowenna

pr closed time in 5 days

PR closed Azure/azure-container-networking

Move store to bbolt database

Signed-off-by: John Howard jhoward@microsoft.com

This PR is a follow on to https://github.com/Azure/azure-container-networking/pull/247

@tamilmani1989 @sharmasushant PTAL.

@patricklang, @DavidSchott @dineshgovindasamy @madhanrm @jterry75 FYI. @msuiche perhaps you are able to perform more verification on this as well?

As per https://github.com/Azure/azure-container-networking/pull/247#issuecomment-423027106, while that PR was better, it was far from perfect.

This PR replaces the store entirely and uses a bolt database to store the data. See https://github.com/Azure/azure-container-networking/pull/247#issuecomment-423027106 https://github.com/Azure/azure-container-networking/pull/247#issuecomment-423708058

Patrick gave me access to one of his Windows clusters to perform verification. While there were some errors, none appear attributed to this change.

I was able to scale from 1 to 25, back to 1 and back up again. Hopefully this is finally the end of those lock store-related errors.

It is not however the end of no-errors-at-all during scaling. I will leave that to others to investigate...

I have NOT been able to test this against a linux node - perhaps @tamilmani1989 would be able to that as per before.

In addition, this PR has a bunch of commits which fix (most) vendoring issues in this repo. There is still more to do there, but again, I will leave that for others to resolve. I had to tackle vendoring to some extent to pull in bbolt.

Finally, there are three other commits in this PR.

  • I have put in an implementation of GetLastRebootTime on Windows. As it's implementation changes the startup functionality, I have left that effectively stubbed out for someone else to follow through with.
  • I hit a SIGSEGV in testing in UpdateSendAndReport. Made that safe.
  • Remove ./store/ from circleCI

Here's the 25 pods scaling up-and-down on Patricks cluster:

NAME                        READY   STATUS    RESTARTS   AGE     IP            NODE           NOMINATED NODE
iis-1803-687cdddf9f-28vrj   1/1     Running   0          10m     10.240.0.10   13833k8s9000   <none>
iis-1803-687cdddf9f-5fjcn   1/1     Running   0          6m33s   10.240.0.30   13833k8s9000   <none>
iis-1803-687cdddf9f-6dk28   1/1     Running   0          10m     10.240.0.31   13833k8s9000   <none>
iis-1803-687cdddf9f-6j8wg   1/1     Running   0          6m33s   10.240.0.11   13833k8s9000   <none>
iis-1803-687cdddf9f-8f5kc   1/1     Running   1          6m33s   10.240.0.14   13833k8s9000   <none>
iis-1803-687cdddf9f-bkd7n   1/1     Running   0          10m     10.240.0.28   13833k8s9000   <none>
iis-1803-687cdddf9f-bth4v   1/1     Running   0          6m33s   10.240.0.23   13833k8s9000   <none>
iis-1803-687cdddf9f-csm2x   1/1     Running   0          10m     10.240.0.5    13833k8s9000   <none>
iis-1803-687cdddf9f-dtvqp   1/1     Running   1          6m33s   10.240.0.9    13833k8s9000   <none>
iis-1803-687cdddf9f-fv9rn   1/1     Running   1          6m33s   10.240.0.20   13833k8s9000   <none>
iis-1803-687cdddf9f-gmzcz   1/1     Running   1          6m33s   10.240.0.12   13833k8s9000   <none>
iis-1803-687cdddf9f-kzmcf   1/1     Running   0          10m     10.240.0.7    13833k8s9000   <none>
iis-1803-687cdddf9f-lltjr   1/1     Running   1          6m33s   10.240.0.13   13833k8s9000   <none>
iis-1803-687cdddf9f-lx2vf   1/1     Running   0          10m     10.240.0.26   13833k8s9000   <none>
iis-1803-687cdddf9f-nn9pp   1/1     Running   1          6m33s   10.240.0.21   13833k8s9000   <none>
iis-1803-687cdddf9f-pjcws   1/1     Running   1          6m33s   10.240.0.22   13833k8s9000   <none>
iis-1803-687cdddf9f-q7hsf   1/1     Running   1          6m33s   10.240.0.33   13833k8s9000   <none>
iis-1803-687cdddf9f-qn5c7   1/1     Running   0          10m     10.240.0.27   13833k8s9000   <none>
iis-1803-687cdddf9f-rt6r5   1/1     Running   1          6m33s   10.240.0.17   13833k8s9000   <none>
iis-1803-687cdddf9f-s2jsb   1/1     Running   0          10m     10.240.0.8    13833k8s9000   <none>
iis-1803-687cdddf9f-sgwb8   1/1     Running   1          6m33s   10.240.0.25   13833k8s9000   <none>
iis-1803-687cdddf9f-x9tpt   1/1     Running   0          10m     10.240.0.29   13833k8s9000   <none>
iis-1803-687cdddf9f-xf6x9   1/1     Running   0          6m33s   10.240.0.24   13833k8s9000   <none>
iis-1803-687cdddf9f-xwfxg   1/1     Running   0          10m     10.240.0.15   13833k8s9000   <none>
iis-1803-687cdddf9f-zf8kv   1/1     Running   1          6m33s   10.240.0.16   13833k8s9000   <none>
azureuser@k8s-master-13833463-0:~/john$ curl http://10.240.0.16
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>IIS Windows Server</title>
<style type="text/css">
<!--
body {
        color:#000000;
        background-color:#0072C6;
        margin:0;
}

#container {
        margin-left:auto;
        margin-right:auto;
        text-align:center;
        }

a img {
        border:none;
}

-->
</style>
</head>
<body>
<div id="container">
<a href="http://go.microsoft.com/fwlink/?linkid=66138&amp;clcid=0x409"><img src="iisstart.png" alt="IIS" width="960" height="600" /></a>
</div>
</body>
</html>

Then scaling back down:

azureuser@k8s-master-13833463-0:~/john$ kubectl scale deploy iis-1803 --replicas=1
deployment.extensions/iis-1803 scaled
azureuser@k8s-master-13833463-0:~/john$

Some time later...

azureuser@k8s-master-13833463-0:~/john$ kubectl get pod -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE
iis-1803-687cdddf9f-x9tpt   1/1     Running   0          16m   10.240.0.29   13833k8s9000   <none>

And scaling back up again

azureuser@k8s-master-13833463-0:~/john$ kubectl scale deploy iis-1803 --replicas=25
deployment.extensions/iis-1803 scaled
azureuser@k8s-master-13833463-0:~/john$

Some time later...

zureuser@k8s-master-13833463-0:~/john$ kubectl get pod -o wide
NAME                        READY   STATUS    RESTARTS   AGE    IP            NODE           NOMINATED NODE
iis-1803-687cdddf9f-26p6l   1/1     Running   0          7m     10.240.0.11   13833k8s9000   <none>
iis-1803-687cdddf9f-2ktdz   1/1     Running   0          7m     10.240.0.10   13833k8s9000   <none>
iis-1803-687cdddf9f-48ggp   1/1     Running   0          7m     10.240.0.5    13833k8s9000   <none>
iis-1803-687cdddf9f-4gtmb   1/1     Running   0          7m     10.240.0.26   13833k8s9000   <none>
iis-1803-687cdddf9f-4hd72   1/1     Running   0          7m     10.240.0.24   13833k8s9000   <none>
iis-1803-687cdddf9f-4pwsq   1/1     Running   1          7m     10.240.0.33   13833k8s9000   <none>
iis-1803-687cdddf9f-5kw22   1/1     Running   0          7m     10.240.0.9    13833k8s9000   <none>
iis-1803-687cdddf9f-664z7   1/1     Running   1          7m     10.240.0.16   13833k8s9000   <none>
iis-1803-687cdddf9f-8swz7   1/1     Running   1          7m1s   10.240.0.7    13833k8s9000   <none>
iis-1803-687cdddf9f-9h98r   1/1     Running   1          7m     10.240.0.8    13833k8s9000   <none>
iis-1803-687cdddf9f-9h9jd   1/1     Running   1          7m     10.240.0.14   13833k8s9000   <none>
iis-1803-687cdddf9f-lftd7   1/1     Running   1          7m     10.240.0.19   13833k8s9000   <none>
iis-1803-687cdddf9f-m9knq   1/1     Running   1          7m     10.240.0.31   13833k8s9000   <none>
iis-1803-687cdddf9f-mplcc   1/1     Running   1          7m     10.240.0.21   13833k8s9000   <none>
iis-1803-687cdddf9f-p7jn2   1/1     Running   0          7m     10.240.0.20   13833k8s9000   <none>
iis-1803-687cdddf9f-sml2x   1/1     Running   0          7m1s   10.240.0.13   13833k8s9000   <none>
iis-1803-687cdddf9f-tjfws   1/1     Running   0          7m     10.240.0.18   13833k8s9000   <none>
iis-1803-687cdddf9f-vxdl4   1/1     Running   0          7m     10.240.0.15   13833k8s9000   <none>
iis-1803-687cdddf9f-x26vj   1/1     Running   1          7m1s   10.240.0.30   13833k8s9000   <none>
iis-1803-687cdddf9f-x2hll   1/1     Running   1          7m     10.240.0.28   13833k8s9000   <none>
iis-1803-687cdddf9f-x9tpt   1/1     Running   0          24m    10.240.0.29   13833k8s9000   <none>
iis-1803-687cdddf9f-xg5bm   1/1     Running   1          7m     10.240.0.23   13833k8s9000   <none>
iis-1803-687cdddf9f-zkkzm   1/1     Running   1          7m     10.240.0.32   13833k8s9000   <none>
iis-1803-687cdddf9f-zqv69   1/1     Running   0          7m     10.240.0.17   13833k8s9000   <none>
iis-1803-687cdddf9f-zvzn9   1/1     Running   0          7m     10.240.0.27   13833k8s9000   <none>
azureuser@k8s-master-13833463-0:~/john$
+14666 -4596

13 comments

207 changed files

lowenna

pr closed time in 5 days

PR closed moby/moby

Reviewers
Windows: Case (in-)sensitivity for volume parser kind/experimental platform/windows status/2-code-review

Signed-off-by: John Howard jhoward@microsoft.com

Fixes https://github.com/moby/moby/issues/36613. This was kind of interesting, as removing the case-insensitivity (I think I just put it there some 3 or more years ago to make life easier and long since forgot about it as Windows at this level is generally case insensitive and way before I had thought about LCOW) found another 'bug' (I say bug, but the code was doing the right thing, just for the wrong reason) which looks to have been introduced part by me, and part by refactoring of this code a year or more back. Case caught by the unit tests.

That bug was that the reserved name check has nothing whatsoever to do with the fix for 26329, but that's where it was in the code. Was very confused trying to figure out what its purpose was in that 26329-fix block, or which it was checking destination rather than source. Anyway, moved it to the right place and all is well.

After this, you can now do something such as the following - note the target directory inside the container as the important bit - the host casing is irrelevant as Windows here is case-insensitive. Similarly in the Windows case, the target casing is irrelevant.

LCOW:

PS E:\> docker run --rm -v c:\CaSeOnHoSt:/bar/humbuG:rW alpine ls /bar
humbuG
PS E:\> docker run --rm -v c:\caseonhost:/bar/humbuG:rW alpine ls /bar
humbuG
PS E:\> docker run --rm -v C:\CaSeOnHoSt:/bar/humbug alpine ls /bar
humbug
PS E:\>

WCOW:

PS E:\> docker run --rm -v c:\CaSeOnHoSt:c:/bar/humbuG:rW microsoft/nanoserver cmd /s /c dir c:\bar
 Volume in drive C has no label.
 Volume Serial Number is 106A-BF5E

 Directory of c:\bar

09/25/2018  04:10 PM    <DIR>          .
09/25/2018  04:10 PM    <DIR>          ..
09/25/2018  04:08 PM    <DIR>          humbuG
               0 File(s)              0 bytes
               3 Dir(s)  21,299,740,672 bytes free
PS E:\> docker run --rm -v c:\caseonhost:c:/bar/humbuG:rW microsoft/nanoserver cmd /s /c dir c:\bar
 Volume in drive C has no label.
 Volume Serial Number is 106A-BF5E

 Directory of c:\bar

09/25/2018  04:11 PM    <DIR>          .
09/25/2018  04:11 PM    <DIR>          ..
09/25/2018  04:08 PM    <DIR>          humbuG
               0 File(s)              0 bytes
               3 Dir(s)  21,299,732,480 bytes free
PS E:\>

@DHowett-MSFT @dnperfors FYI

@johnstep PTAL.

Note: You cannot, at least in RS5, unfortunately do the following after this fix - mapping two directories /a and /A in LCOW located in the same folder. Need to figure out where that is, but likely a platform issue at this point in HCS. However, you couldn't do it before either haha.

docker run --rm -v c:\UPPER:/foo/A -v c:\lower:/foo/a alpine ls -l /foo
e:\go\src\github.com\docker\cli\binary\docker.exe: Error response from daemon: CreateComputeSystem b3ba52af987bff00224d5aebeb656172271c25acb9c0b54dcd1941cd765257c6: The object already exists.
(extra info: {"SystemType":"container","Name":"b3ba52af987bff00224d5aebeb656172271c25acb9c0b54dcd1941cd765257c6","Owner":"docker","LayerFolderPath":"C:\\control\\lcow\\b3ba52af987bff00224d5aebeb656172271c25acb9c0b54dcd1941cd765257c6","Layers":[{"ID":"2e2ab5f1-6ea9-557b-af6c-c401a2a3db37","Path":"C:\\control\\lcow\\fb27f0fc7fbad278718cab180f3e0dcc238fc8509560b5db3e79804b0de1ec4a\\layer.vhd"}],"MappedDirectories":[{"HostPath":"c:\\UPPER","ContainerPath":"/tmp/gcs/b3ba52af987bff00224d5aebeb656172271c25acb9c0b54dcd1941cd765257c6/binds/foo/A","ReadOnly":false,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":true,"LinuxMetadata":true},{"HostPath":"c:\\lower","ContainerPath":"/tmp/gcs/b3ba52af987bff00224d5aebeb656172271c25acb9c0b54dcd1941cd765257c6/binds/foo/a","ReadOnly":false,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":true,"LinuxMetadata":true}],"HvPartition":true,"EndpointList":["C54594FC-A983-4D70-9E37-DC73734C4885"],"HvRuntime":{"ImagePath":"C:\\Program Files\\Linux Containers","LinuxInitrdFile":"initrd.img","LinuxKernelFile":"kernel"},"AllowUnqualifiedDNSQuery":true,"ContainerType":"linux","TerminateOnLastHandleClosed":true}).
PS C:\>
+12 -14

12 comments

2 changed files

lowenna

pr closed time in 5 days

pull request commentmoby/moby

Windows: Case (in-)sensitivity for volume parser

@taylorb-microsoft - another one which if you believe important enough someone should consider finishing. Closing though.

lowenna

comment created time in 5 days

pull request commentAzure/azure-container-networking

Move store to bbolt database

Closing as I am no longer working on container related things. This is still something which needs to be addressed as the implementation is not thread/multi-process safe, but I'll leave the container networking folks to take up if they wish.

lowenna

comment created time in 5 days

PR closed moby/moby

Windows:Fix VOLUME statement area/builder kind/bugfix platform/windows status/2-code-review

Signed-off-by: John Howard jhoward@microsoft.com

This fixes an issue which was reported internally. I think the cause of it is more my mis-understanding of the VOLUME statement in a dockerfile from some 3+ years ago. While it mostly worked, there was a bug (obviously).

The issue was something such as the following was causing an error starting a Windows container using this image:

FROM microsoft/windowsservercore
RUN mkdir c:\source
VOLUME c:/source

The error was "docker: Error response from daemon: Unrecognised volume spec: file 'c:/source' cannot be mapped. Only directories can be mapped on this platform."

It was root caused that on the Windows path, it was erroneously attempting to parse the spec as a volume spec, not as a destination. In that scenario, the parse looked at the spec as it if were local (host) rather than a container path. Now in the case (such as above) that c:/source (c:\source) exists, and is a file rather than a directory, the above error would be seen.

The fix is to treat (as Linux does) the spec as a destination.

And manual verification: First WCOW:

PS E:\docker\build\volume> docker build -t wcowvolume .
Sending build context to Docker daemon  3.584kB
Step 1/4 : FROM microsoft/windowsservercore
 ---> e523d49b4b94
Step 2/4 : RUN mkdir c:\source
 ---> Using cache
 ---> ba84419e9d41
Step 3/4 : RUN copy c:\windows\system32\ntdll.dll c:\source
 ---> Using cache
 ---> 409ed22dd31a
Step 4/4 : VOLUME c:/source
 ---> Using cache
 ---> 8c56416c697f
Successfully built 8c56416c697f
Successfully tagged wcowvolume:latest
PS E:\docker\build\volume> dir c:\source

    Directory: C:\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       11/20/2018   8:45 AM            125 source

PS E:\docker\build\volume> docker run volume
Microsoft Windows [Version 10.0.17763.1]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\>
PS E:\docker\build\volume>

And an LCOW equivalent:

PS E:\docker\build\volume\Linux> type Dockerfile
FROM alpine
RUN mkdir /source
RUN cp /bin/ls /source
VOLUME /source

PS E:\docker\build\volume\Linux> docker build -t lcowvolume .
Sending build context to Docker daemon  2.048kB
Step 1/4 : FROM alpine
 ---> 196d12cf6ab1
Step 2/4 : RUN mkdir /source
 ---> Using cache
 ---> 8f2f87ba69b7
Step 3/4 : RUN cp /bin/ls /source
 ---> Using cache
 ---> 9d2cf70ecb0e
Step 4/4 : VOLUME /source
 ---> Using cache
 ---> a0ee39598ee2
Successfully built a0ee39598ee2
Successfully tagged lcowvolume:latest
PS E:\docker\build\volume\Linux> docker run lcowvolume
PS E:\docker\build\volume\Linux>
+60 -50

6 comments

1 changed file

lowenna

pr closed time in 5 days

pull request commentmoby/moby

Windows:Fix VOLUME statement

Long out-of-date. Closing as I am no longer working in this area. @taylorb-microsoft - not sure if you want to find someone to carry this?

lowenna

comment created time in 5 days

pull request commentmoby/moby

Windows: Add generate-swagger-api.ps1

Long out-of-date. Closing as I am no longer working in this area.

lowenna

comment created time in 5 days

PR closed moby/moby

LCOW (and generic): Add Supported-Platforms to _ping API endpoint area/lcow status/2-code-review

Signed-off-by: John Howard jhoward@microsoft.com

This is part of the LCOW discussion issue, specifically for https://github.com/moby/moby/issues/34617#issuecomment-324730147. It adds an HTTP header to the _ping API endpoint so that a client can determine whether the daemon is multi-platform capable, and the list of possible values. As HTTP headers can't be structured, it passes this as a string.

For a Linux daemon, it would return something like Supported-Platforms: linux/amd64. For a dual-mode LCOW/WCOW daemon on Windows, it would return Supported-Platforms: windows/amd64,linux/amd64.

@dnephin @johnstep

EDIT: Updated to use JSON encode the OCI Image-Spec platform structure instead of a comma-separated list.

+39 -1

10 comments

3 changed files

lowenna

pr closed time in 5 days

pull request commentmoby/moby

LCOW (and generic): Add Supported-Platforms to _ping API endpoint

Long out-of-date. Closing as I am no longer working in this area.

lowenna

comment created time in 5 days

push eventlowenna/getitv

John Howard

commit sha 230f763cd1fa8c52ea324f1d7ca2fe55ec2ea0de

Bit more on cache Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 5 days

push eventlowenna/getitv

John Howard

commit sha 84b54bd44ac2992439c4b76248fe458d84475599

Can fully build cache now, workaround ITV JSON stupidity Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 5 days

push eventlowenna/getitv

John Howard

commit sha 5031f952b4421659206e989968f298745f145589

Can fully build cache now, workaround ITV JSON stupidity Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 5 days

push eventlowenna/getitv

John Howard

commit sha 3c98ddec73e4a01532f13559dcd4e787d9d620f1

More cache - still early Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 7 days

push eventlowenna/getitv

John Howard

commit sha 7b3e0c92c0224831acd50fb0b1d2ca8f0c24cb20

A litle cache implementation Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 7 days

push eventlowenna/getitv

John Howard

commit sha f3463299ada92e0812131f57140efc8d51907189

Basic cache outline shell Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 7 days

push eventlowenna/getitv

John Howard

commit sha e8d4646094850945176db6b355dd5eb7a48ac5ae

TODO:Episode availability Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 7 days

push eventlowenna/getitv

John Howard

commit sha 9e49474bd3947e4bea177e6c15c14ac8f9d9f731

Add prototype cache, use types package Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 7 days

push eventlowenna/getitv

John Howard

commit sha 9fafa6a3cee1db28e87f7b0d972c23774f1518c2

Add scraper for shows Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 7 days

push eventlowenna/getitv

John Howard

commit sha b6b573adbb7ce10ecd9c04ff70e0317549d30508

Add shows sample data Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 7 days

push eventlowenna/getitv

John Howard

commit sha 163c400f2de24062802376f1e37117b1f50e193e

Minor tidy Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 7 days

push eventlowenna/getitv

John Howard

commit sha 834c9bd3b58a93c999740b9bf4e7192d68f39882

Update modules Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 7 days

delete branch lowenna/getitv

delete branch : go-metadata

delete time in 7 days

push eventlowenna/getitv

John Howard

commit sha b696187c841b47c4da28f18a855389b95a4634d6

Working on scraper Signed-off-by: John Howard <github@lowenna.com>

view details

John Howard

commit sha 9bd7c10932f956a8333d48c37142209ac57129ce

Merge pull request #1 from lowenna/go-metadata Working on scraper

view details

push time in 7 days

PR merged lowenna/getitv

Working on scraper

Signed-off-by: John Howard github@lowenna.com

+2612 -0

0 comment

9 changed files

lowenna

pr closed time in 7 days

PR opened lowenna/getitv

Working on scraper

Signed-off-by: John Howard github@lowenna.com

+2612 -0

0 comment

9 changed files

pr created time in 7 days

create barnchlowenna/getitv

branch : go-metadata

created branch time in 7 days

push eventlowenna/getitv

John Howard

commit sha 8cd8c8cc5cd9957363df78ad48b0a974e8368687

Initial commit Signed-off-by: John Howard <github@lowenna.com>

view details

push time in 10 days

create barnchlowenna/getitv

branch : master

created branch time in 10 days

created repositorylowenna/getitv

Wrapper for downloading ITV and probably more

created time in 10 days

PR opened microsoft/hcsshim

Typo: 'Sever' --> 'Server'

Signed-off-by: John Howard github@lowenna.com

Now I have an almost usable office again, albeit with Internet at the speed of two cups and a piece of string...

+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchlowenna/hcsshim

branch : typo

created branch time in 2 months

fork lowenna/hcsshim

Windows - Host Compute Service Shim

fork in 2 months

pull request commentmicrosoft/opengcs

Formally deprecate LCOW v1

Nice 😁

jterry75

comment created time in 2 months

delete branch microsoft/docker

delete branch : retire

delete time in 3 months

issue commentmoby/moby

--squash Fails in ImportLayer in Docker EE Windows Server with Process Isolation

IIRC, to support squash, it would need additional support from the platform to be able to diff two arbitrary layers which isn't supported by the filter driver. Currently when the filter driver is loaded, it's an all or nothing. I doubt a solution is high on the priority list to fix unfortunately. It has nothing directly to do with process or Hyper-V isolation though.

vikalyan

comment created time in 3 months

delete branch lowenna/moby

delete branch : jjh/username

delete time in 4 months

pull request commentmoby/moby

jhowardmsft --> lowenna

@thaJeztah Thanks, but all seems back to normal now. I'm not sure if it's because of you reaching out, or a support email I sent (no response yet).

lowenna

comment created time in 4 months

pull request commentcontainerd/project

Add Sebastiaan as reviewer

LGTM (no longer a maintainer)

dmcgowan

comment created time in 4 months

pull request commentmoby/moby

jhowardmsft --> lowenna

oh! you may want to keep your @microsoft.com email in your profile (as hidden/private e-mail address); if you remove your e-mail, you drop of the vanity contributors wall; https://github.com/moby/moby/graphs/contributors

Hmmm. I readded them but doesn't show up. Maybe just takes a while to filter through

lowenna

comment created time in 4 months

PR opened moby/moby

Reviewers
jhowardmsft --> lowenna

Signed-off-by: John Howard github@lowenna.com

I've now changed my jhowardmsft username to lowenna since today is my last day at Microsoft (retiring). Updating MAINTAINERS tp reflect the change.

Shadow, who sadly passed away last month shadow

And Painter, now living in England. painter

+6 -6

0 comment

1 changed file

pr created time in 4 months

create barnchlowenna/moby

branch : jjh/username

created branch time in 4 months

fork lowenna/moby

Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

https://mobyproject.org/

fork in 4 months

issue closedmoby/docker-ci-zap

Please add this to chocolatey

This shall be either inbox with docker or be easily accessible for admins to perform maintenance of docker hosts.

closed time in 4 months

artisticcheese

issue commentmoby/docker-ci-zap

Please add this to chocolatey

Due to the danger of the tool, I do not believe this is a good idea. The binary is available for direct download.

artisticcheese

comment created time in 4 months

issue closedmoby/docker-ci-zap

Usage?

What folder path should be supplied?

closed time in 4 months

dazinator

issue closedmoby/docker-ci-zap

The specified executable is not a valid application for this OS platform

OS: Windows Server Core (1709)

To reproduce: .\docker-ci-zap.exe -folder "D:\dockerleftoversdir"

Error:

PS D:\tools> .\docker-ci-zap.exe -folder "D:\oldDocker"
Program 'docker-ci-zap.exe' failed to run: The specified executable is not a valid application for this OS platform.At
line:1 char:1
+ .\docker-ci-zap.exe -folder "D:\oldDocker"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
At line:1 char:1
+ .\docker-ci-zap.exe -folder "D:\oldDocker"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed

Expected: it should be platform independent, I mean should work on any recent Windows version.

closed time in 4 months

firepol

pull request commentcontainerd/project

Farewell John Howard

Thank you @dmcgowan and everyone else. I've had the best time working on container related projects the past 4+ years. But time to move on and retire :)

LGTM

dmcgowan

comment created time in 4 months

delete branch microsoft/docker

delete branch : jjh/jjh-gocode

delete time in 4 months

push eventmoby/moby

Sebastiaan van Stijn

commit sha b323c6e9aeb6c18b25cd77b6ecafc761785b8c65

Jenkinsfile: update references to repositories that were moved Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

view details

Sebastiaan van Stijn

commit sha 83fd212f2cb71aae2f4a5a60c893c2bd01e59b72

Dockerfile.windows: update references to repositories that were moved Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

view details

Sebastiaan van Stijn

commit sha 5175ed54e58d2027e54571ef384eed54626f6c89

hack/ci/windows.ps1 update references to repositories that were moved Also updated the related docs. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

view details

John Howard

commit sha fd820c4d6526da4df07ae7456c8d46f20a61f26d

Merge pull request #39990 from thaJeztah/update_moved_repositories Update links/references to transferred repositories

view details

push time in 4 months

PR merged moby/moby

Reviewers
Update links/references to transferred repositories area/testing platform/windows process/cherry-pick status/2-code-review

fixes https://github.com/moby/moby/issues/39989

for reviewers: I kept commits separate, because I'll be backporting this to various branches; keeping them separate makes conflict-resolution a bit more convenient 🤗

+14 -14

1 comment

4 changed files

thaJeztah

pr closed time in 4 months

issue closedmoby/moby

Update links/references to transferred repositories

We transferred a couple of repositories to the moby org; GitHub redirects them from the old location, but we should not rely on those redirects, and update references to them to use the new location;

Old location New location
https://github.com/jhowardmsft/docker-ci-zap https://github.com/moby/docker-ci-zap
https://github.com/jhowardmsft/docker-signal https://github.com/moby/docker-signal
https://github.com/jhowardmsft/busybox https://github.com/moby/busybox
https://github.com/jhowardmsft/busybox64 not transferred should not be referenced anywhere
https://github.com/jhowardmsft/docker-tdmgcc https://github.com/moby/docker-tdmgcc

closed time in 4 months

thaJeztah

pull request commentmoby/moby

Remove refs to jhowardmsft from .go code

@thaJeztah

jhowardmsft

comment created time in 4 months

PR opened moby/moby

Reviewers
Remove refs to jhowardmsft from .go code

Signed-off-by: John Howard jhoward@microsoft.com

As many of you know, I'm retiring imminently. And will be leaving Microsoft and changing my GitHub handle. While there's still logistics in rehosting binaries used to other repos under my GitHub handle, this removes the references in .go code.

+14 -16

0 comment

12 changed files

pr created time in 4 months

create barnchmicrosoft/docker

branch : jjh/jjh-gocode

created branch time in 4 months

create barnchmicrosoft/docker

branch : retire

created branch time in 4 months

more