8000 Discussion topics for Moby Summit on 2017-06-19 · Issue #998 · containerd/containerd · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Discussion topics for Moby Summit on 2017-06-19 #998

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.

Sign up for GitHub

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

Jump to bottom
Closed
samuelkarp opened this issue Jun 13, 2017 · 7 comments
Closed

Discussion topics for Moby Summit on 2017-06-19 #998

samuelkarp opened this issue Jun 13, 2017 · 7 comments

Comments

@samuelkarp
Copy link
Member

@crosbymichael:

Maybe an issue will work better. Lower barrier to add something and people can +1 things

Suggest some topics to talk about at the summit. Maybe try to keep it to one suggestion per comment so that others can vote with GitHub reactions.
@samuelkarp
Copy link
Member Author
samuelkarp commented Jun 14, 2017 •
edited
Loading

I'll start this off:

I'd like to talk about plans for a resolver-resolver and image reference namespacing.

Edit: Discussion focused on @stevvooe's experiments with different config formats that can drive a resolver-resolver. There's still a desire to drive resolvers toward git remotes and supporting user-defined aliasing.

@samuelkarp
Copy link
< 8000 /details>
Member Author
samuelkarp commented Jun 14, 2017 •
edited
Loading

I'd like to talk about how a client can reconcile between events returned by the event stream and synchronous API responses. I have a proposal in #871 but that's not the only possible answer.

Edit: Discussion showed that this may not be necessary entirely. Most of the use-case that Amazon ECS has for events are related to containers/tasks stopping, and that can be achieved with task.Wait. There was some consensus that allowing a client to specify a task ID distinct from the container ID would help in the case where multiple primary tasks were run consecutively.

@samuelkarp
Copy link
Member Author
samuelkarp commented Jun 14, 2017 •
edited
Loading

I'd like to talk about how clients can understand the capabilities of the specific containerd they're talking to. Some previous discussion is in #781.

Edit: We talked about the challenges orchestrators face with determining features that are usable across different versions and configurations of Docker today. No consensus was achieved on an approach to solving this problem yet, but some suggestions were floated for a client-library that can determine some system capabilities and probe containers that can be launched.

@Random-Liu
Copy link
Member

What is the plan for garbage collection?

8000
@tiborvass
Copy link

What will need to change in Docker wrt graphdrivers for accommodating the containerd snapshotters?

@samuelkarp
Copy link
Member Author
samuelkarp commented Jun 19, 2017 •
edited
Loading

Are there plans to migrate all the existing Docker graphdrivers over to containerd snapshotters?

Edit: Answered as part of the discussion around @tiborvass's question; the containerd maintainers are only planning to have overlay and btrfs snapshotters in the main containerd tree. Others may port other graphdrivers to snapshotters, but they would be out-of-tree.

@Random-Liu
Copy link
Member

What is the roadmap after 1.0? Are there still changes or features we plan to add?
What is the release schedule after 1.0?

@estesp estesp closed this as completed Jun 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@samuelkarp @tiborvass @estesp @Random-Liu
0