sdc-docker

They are far from abandoned. In fact they are used in production to power Triton cloud's docker emulation. In fact the latest LX-related commit was made 4 days ago (see the commit history of illumos-joyent linked below). https://github.com/joyent/sdc-docker https://github.com/joyent/triton https://github.com/joyent/illumos-joyent/commits/master

Yes -- it's open source[1], as is all of our stuff.[2] [1] https://github.com/joyent/sdc-docker [2] https://www.joyent.com/blog/sdc-and-manta-are-now-open-sourc...

> since Joyent has implemented their own docker client Not our own docker client, our own Docker engine, https://github.com/joyent/sdc-docker , which was necessary for the whole DC to be the host. For a taste of the details see https://www.joyent.com/developers/videos/bryan-cantrill-virt... . Your larger point is correct, we're still working hard every day to add increase the support particularly for the newer docker apis and extensions. Now, docker-compose 1.2 is working in the production datacenters with docker-compose 1.3 in the east-3b (beta) dc. https://www.joyent.com/developers/triton-faq https://github.com/joyent/sdc-docker/blob/master/docs/api/di...

If anyone wants to earn some huge brownie points with me (and who wouldn't), you could implement a PaaS on top of Joyent's Triton system[1]. Purely in terms of the cost structure you could offer with such a PaaS, this could be a Heroku killer. Huge bonus points if it's totally open source! 1. https://github.com/joyent/sdc-docker

As the Docker Engine for SDC is being developed to the Docker API and CLI, Triton can be used through any Docker ux. https://github.com/joyent/sdc-docker/blob/master/docs/diverg... The interesting bits are not the self-serve portal. The portal is good for introducing the stack and supplementing the experience, but few use a portal for infrastructure management -- they require more automation, specific to their business. We're working hard on getting the self-server portal code architecture and hygiene up to open sourcing it. From there we can get these portal plugins open as well. Our on-prem customers are hungry for this, as many of them have a mandate for OSS.

Thanks for the link. I've updated the "current state" notes to better reflect reality. https://github.com/joyent/sdc-docker#current-state

Didn't see the actual repo linked: https://github.com/joyent/sdc-docker "A Docker Engine for SmartDataCenter, where the whole DC is exposed as a single docker host. The Docker remote API is served from a 'docker' core SDC zone (built from this repo). ... Disclaimer: This is still very much alpha. Use at your own risk!"

We have put (and are putting) a bunch of work into LX branded zones[1], and are at the point that they are working on an incredibly broad class of apps (64-bit and with on-the-metal performance). A concrete case in point: we recently ran the (amazing!) hundred language quine relay[2] in an LX branded 64-bit Ubuntu 14.04 zone on SmartOS.[3] As for ZFS support and Docker, it will be via sdc-docker[4], our (emerging) end-point for the Docker Remote API. The progress there has been swift and everything is being done in the open; expect to see something in production from us in this first calendar quarter. [1] https://www.youtube.com/watch?v=TrfD3pC0VSs [2] https://github.com/mame/quine-relay [3] https://twitter.com/bcantrill/status/554076708173643776 [4] https://github.com/joyent/sdc-docker

Yes, but the Docker Remote API allows for a great deal of implementation freedom -- including running on a different OS substrate. We're doing this with sdc-docker[1] to run Docker on top of SmartOS and in a SmartOS container, and the Docker folks have been incredibly supportive. Despite the rhetoric, Rocket appears to be much more bound to the OS platform than Docker -- and given @philips' comment that "part of the design difference is that rocket doesn't implement an API"[2], this binding appears to be deliberate. [1] https://github.com/joyent/sdc-docker [2] https://news.ycombinator.com/item?id=8682798