Docker Compose is now the "Compose Specification"
Hey all, I don't know if any of y'all saw this yet, but Docker, Inc. has announced[1] this new thing called the "Compose Specification[2]". It looks like they're attempting to generalize the Docker Compose format for broader use. What do you folks think of it? [1]: https://www.docker.com/blog/announcing-the-compose-specification/ [2]: https://www.compose-spec.io/ -- 真実はいつも一つ！/ Always, there's only one truth!
Hi Neal, thanks for sharing! On Wed, Apr 8, 2020 at 1:05 AM Neal Gompa <ngompa13@gmail.com> wrote:
Hey all,
I don't know if any of y'all saw this yet, but Docker, Inc. has announced[1] this new thing called the "Compose Specification[2]". It looks like they're attempting to generalize the Docker Compose format for broader use.
What do you folks think of it?
I like that the spec is about to be opened as it gives compose a fair chance for the future. It is a rather common request for Podman to support compose and while I do not know of plans to integrate it into Podman's code base (compose is a *lot* of code), there is podman-compose [3] developed by the community. With the upcoming new rest API [4], we will likely be able to support docker-compose by pointing it to the Podman socket. Ultimately, I would love everybody to use podman-play-kube on their machines but I understand that a lot of folks depend on docker-compose and migration is not always an option. I don't feel ready to interpret the strategy behind opening the spec yet though. In my personal experience, Docker was very protective and defensive when I tried to contribute features which left me sceptical. However, lot's of things have changed at Docker and maybe there's a new genuine interest in being more open. In other words, I like it :-) but I don't fully understand the motivation yet. Thanks for reaching out! Kind regards, Valentin [3] https://github.com/containers/podman-compose [4] https://podman.io/blogs/2020/01/17/podman-new-api.html
[1]: https://www.docker.com/blog/announcing-the-compose-specification/ [2]: https://www.compose-spec.io/
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On Wed, Apr 8, 2020 at 4:41 AM Valentin Rothberg <rothberg@redhat.com> wrote:
Hi Neal,
thanks for sharing!
On Wed, Apr 8, 2020 at 1:05 AM Neal Gompa <ngompa13@gmail.com> wrote:
Hey all,
I don't know if any of y'all saw this yet, but Docker, Inc. has announced[1] this new thing called the "Compose Specification[2]". It looks like they're attempting to generalize the Docker Compose format for broader use.
What do you folks think of it?
I like that the spec is about to be opened as it gives compose a fair chance for the future. It is a rather common request for Podman to support compose and while I do not know of plans to integrate it into Podman's code base (compose is a *lot* of code), there is podman-compose [3] developed by the community. With the upcoming new rest API [4], we will likely be able to support docker-compose by pointing it to the Podman socket. Ultimately, I would love everybody to use podman-play-kube on their machines but I understand that a lot of folks depend on docker-compose and migration is not always an option.
I don't feel ready to interpret the strategy behind opening the spec yet though. In my personal experience, Docker was very protective and defensive when I tried to contribute features which left me sceptical. However, lot's of things have changed at Docker and maybe there's a new genuine interest in being more open.
In other words, I like it :-) but I don't fully understand the motivation yet.
I concur with Valentin, either way this is a good move on Docker's part. I see a couple of different positive scenarios: 1. The Podman community can better support podman-compose 2. Docker the company is more free to decide if it makes sense to continue investment in docker-compose. 3. If Docker the company decides it's not, at least it's standardized and people don't get burned 4. Potentially, even Kubernetes could implement consumption of it now that it's open, but obviously that would take a lot of work from Docker Inc. Nobody knows the future, but any of the futures above is better for users than not having the spec open. Props to Docker for doing it.
Thanks for reaching out!
Kind regards, Valentin
[3] https://github.com/containers/podman-compose [4] https://podman.io/blogs/2020/01/17/podman-new-api.html
[1]: https://www.docker.com/blog/announcing-the-compose-specification/ [2]: https://www.compose-spec.io/
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
-- -- [image: Summit Virtual Experience] <https://www.redhat.com/en/summit?sc_cid=7013a000002D2QxAAK> Scott McCarty Product Management - Containers, Red Hat Enterprise Linux & OpenShift Email: smccarty@redhat.com Phone: 312-660-3535 Cell: 330-807-1043 Web: http://crunchtools.com Using Azure Pipelines with Red Hat Universal Base Image and Quay.io: https://red.ht/2TvYo3Y
On Wed, Apr 8, 2020 at 2:24 PM Scott McCarty <smccarty@redhat.com> wrote:
On Wed, Apr 8, 2020 at 4:41 AM Valentin Rothberg <rothberg@redhat.com> wrote:
Hi Neal,
thanks for sharing!
On Wed, Apr 8, 2020 at 1:05 AM Neal Gompa <ngompa13@gmail.com> wrote:
Hey all,
I don't know if any of y'all saw this yet, but Docker, Inc. has announced[1] this new thing called the "Compose Specification[2]". It looks like they're attempting to generalize the Docker Compose format for broader use.
What do you folks think of it?
I like that the spec is about to be opened as it gives compose a fair chance for the future. It is a rather common request for Podman to support compose and while I do not know of plans to integrate it into Podman's code base (compose is a lot of code), there is podman-compose [3] developed by the community. With the upcoming new rest API [4], we will likely be able to support docker-compose by pointing it to the Podman socket. Ultimately, I would love everybody to use podman-play-kube on their machines but I understand that a lot of folks depend on docker-compose and migration is not always an option.
I don't feel ready to interpret the strategy behind opening the spec yet though. In my personal experience, Docker was very protective and defensive when I tried to contribute features which left me sceptical. However, lot's of things have changed at Docker and maybe there's a new genuine interest in being more open.
In other words, I like it :-) but I don't fully understand the motivation yet.
I concur with Valentin, either way this is a good move on Docker's part. I see a couple of different positive scenarios:
1. The Podman community can better support podman-compose
I'm hoping this means that podman-compose can be fleshed out and officially supported. It's an annoying weakness today...
2. Docker the company is more free to decide if it makes sense to continue investment in docker-compose. 3. If Docker the company decides it's not, at least it's standardized and people don't get burned 4. Potentially, even Kubernetes could implement consumption of it now that it's open, but obviously that would take a lot of work from Docker Inc.
This has already been done: https://github.com/docker/compose-on-kubernetes Now, will someone do something with this? I hope so...
Nobody knows the future, but any of the futures above is better for users than not having the spec open. Props to Docker for doing it.
Indeed. It probably helps that Docker has gotten out of the "production containers" business, so they're not interested in supporting this part of the model anymore, which makes it an opportunity for others... -- 真実はいつも一つ！/ Always, there's only one truth!
On 4/8/20 19:16, Neal Gompa wrote:
On Wed, Apr 8, 2020 at 2:24 PM Scott McCarty <smccarty@redhat.com> wrote:
On Wed, Apr 8, 2020 at 4:41 AM Valentin Rothberg <rothberg@redhat.com> wrote:
Hi Neal,
thanks for sharing!
On Wed, Apr 8, 2020 at 1:05 AM Neal Gompa <ngompa13@gmail.com> wrote:
Hey all,
I don't know if any of y'all saw this yet, but Docker, Inc. has announced[1] this new thing called the "Compose Specification[2]". It looks like they're attempting to generalize the Docker Compose format for broader use.
What do you folks think of it?
I like that the spec is about to be opened as it gives compose a fair chance for the future. It is a rather common request for Podman to support compose and while I do not know of plans to integrate it into Podman's code base (compose is a lot of code), there is podman-compose [3] developed by the community. With the upcoming new rest API [4], we will likely be able to support docker-compose by pointing it to the Podman socket. Ultimately, I would love everybody to use podman-play-kube on their machines but I understand that a lot of folks depend on docker-compose and migration is not always an option.
I don't feel ready to interpret the strategy behind opening the spec yet though. In my personal experience, Docker was very protective and defensive when I tried to contribute features which left me sceptical. However, lot's of things have changed at Docker and maybe there's a new genuine interest in being more open.
In other words, I like it :-) but I don't fully understand the motivation yet.
I concur with Valentin, either way this is a good move on Docker's part. I see a couple of different positive scenarios:
1. The Podman community can better support podman-compose I'm hoping this means that podman-compose can be fleshed out and officially supported. It's an annoying weakness today...
I don't see us every `supporting` it, podman-compose/docker-compose. We plan on supporting the podman-APIV2 which if these tools use and find bugs we will fix. The podman-compose community seems fairly healthy, I see a good amount of activity going on there.
2. Docker the company is more free to decide if it makes sense to continue investment in docker-compose. 3. If Docker the company decides it's not, at least it's standardized and people don't get burned 4. Potentially, even Kubernetes could implement consumption of it now that it's open, but obviously that would take a lot of work from Docker Inc.
This has already been done: https://github.com/docker/compose-on-kubernetes
Now, will someone do something with this? I hope so...
Nobody knows the future, but any of the futures above is better for users than not having the spec open. Props to Docker for doing it. Indeed. It probably helps that Docker has gotten out of the "production containers" business, so they're not interested in supporting this part of the model anymore, which makes it an opportunity for others...
Sure, but realize that this requires a truly large community to support.
participants (4)
-
Daniel Walsh -
Neal Gompa -
Scott McCarty -
Valentin Rothberg