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

Re-vendor swarmkit. #34061

Merged
merged 1 commit into from
Jul 12, 2017
Merged

Re-vendor swarmkit. #34061

merged 1 commit into from
Jul 12, 2017

Conversation

cyli
Copy link
Contributor

@cyli cyli commented Jul 11, 2017

This includes the following fixes:

Minor cleanups, dependency bumps, and vendoring:

Signed-off-by: Ying Li [email protected]

image

The matching PR for moby/swarmkit#2292 is #33440, although this should not affect vendoring overmuch aside from an extra nil parameter that needs to be added.

@aaronlehmann
Copy link
Contributor

There is a change needed to the executor to match a new function prototype.

If you want, you can pass nil for the new parameter, and let someone port the related feature to the Docker executor later on.

@cyli
Copy link
Contributor Author

cyli commented Jul 11, 2017

@aaronlehmann Will do

- moby/swarmkit#2266 (support for templating Node.Hostname in docker executor)
- moby/swarmkit#2281 (change restore action on objects to be update, not delete/create)
- moby/swarmkit#2285 (extend watch queue with timeout and size limit)
- moby/swarmkit#2253 (version-aware failure tracking in the scheduler)
- moby/swarmkit#2275 (update containerd and port executor to container client library)
- moby/swarmkit#2292 (rename some generic resources)
- moby/swarmkit#2300 (limit the size of the external CA response)
- moby/swarmkit#2301 (delete global tasks when the node running them is deleted)

Minor cleanups, dependency bumps, and vendoring:
- moby/swarmkit#2271
- moby/swarmkit#2279
- moby/swarmkit#2283
- moby/swarmkit#2282
- moby/swarmkit#2274
- moby/swarmkit#2296 (dependency bump of etcd, go-winio)

Signed-off-by: Ying Li <[email protected]>
@aaronlehmann
Copy link
Contributor

moby/swarmkit#2285 (extend watch queue with timeout and size limit)
moby/swarmkit#2275 (update containerd and port executor to container client library)

Note that these two shouldn't have any impact on Docker.

@aaronlehmann
Copy link
Contributor

LGTM

@@ -28,18 +28,16 @@ github.com/docker/libnetwork 37e20af882e13dd01ade3658b7aabdae3412118b
github.com/docker/libtrust 9cbd2a1374f46905c68a4eb3694a130610adc62a
github.com/opencontainers/runc b6b70e53451794e8333e9b602cc096b47a20bd0f
github.com/opencontainers/go-digest a6d0ee40d4207ea02364bd3b9e8e77b9159ba1eb
github.com/opencontainers/image-spec f03dbe35d449c54915d235f1a3cf8f585a24babe
github.com/opencontainers/image-spec 372ad780f63454fbbbbcc7cf80e5b90245c13e13
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

I believe swarmkit vendors image-spec for the containerd executor, so there isn't really a need to keep it in sync between these repos.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, doesn't seem they need to be in Sync, but might as well try doing so; we have the intent to bump to 1.0 when available, so keeping it fresh 😄

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed - just wanted to point out that we shouldn't be concerned about swarmkit being tested against a different version of this dependency, since it's not a factor for the Docker executor. If we bump it, it should be because we want to keep up-to-date, not because it's important to match swarmkit's version.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks, yes, that's useful information - it's sometimes difficult to see what packages should be kept in sync, and which ones not.

Perhaps we need to add more comments in the vendor.conf file to notify people when to bump / keep in sync

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

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

LGTM

@thaJeztah
Copy link
Member

discussing with @tiborvass - we can bump the image-spec as a follow up (#34061 (comment))

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

Successfully merging this pull request may close these issues.

4 participants