On 16.8.2018 10:38, Steven Hardy wrote:
On Wed, Aug 15, 2018 at 10:48 PM, Jay Pipes <jaypi...@gmail.com> wrote:
On 08/15/2018 04:01 PM, Emilien Macchi wrote:
On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi <emil...@redhat.com
<mailto:emil...@redhat.com>> wrote:
More seriously here: there is an ongoing effort to converge the
tools around containerization within Red Hat, and we, TripleO are
interested to continue the containerization of our services (which
was initially done with Docker & Docker-Distribution).
We're looking at how these containers could be managed by k8s one
day but way before that we plan to swap out Docker and join CRI-O
efforts, which seem to be using Podman + Buildah (among other things).
I guess my wording wasn't the best but Alex explained way better here:
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52
If I may have a chance to rephrase, I guess our current intention is to
continue our containerization and investigate how we can improve our tooling
to better orchestrate the containers.
We have a nice interface (openstack/paunch) that allows us to run multiple
container backends, and we're currently looking outside of Docker to see how
we could solve our current challenges with the new tools.
We're looking at CRI-O because it happens to be a project with a great
community, focusing on some problems that we, TripleO have been facing since
we containerized our services.
We're doing all of this in the open, so feel free to ask any question.
I appreciate your response, Emilien, thank you. Alex' responses to Jeremy on
the #openstack-tc channel were informative, thank you Alex.
For now, it *seems* to me that all of the chosen tooling is very Red Hat
centric. Which makes sense to me, considering Triple-O is a Red Hat product.
Just as a point of clarification - TripleO is an OpenStack project,
and yes there is a downstream product derived from it, but we could
e.g support multiple container backends in TripleO if there was
community interest in supporting that.
Also I think Alex already explained that fairly clearly in the IRC
link that this is initially about proving our existing abstractions
work to enable alternate container backends.
+1, and with my upgrade-centric hat on, we've had a fair share of
trouble with Docker -- update of the daemon causing otherwise needless
downtime of services and sometimes data plane too. Most recent example i
can think of is here [1][2] -- satisfactory solution still doesn't
exist. So my 2 cents: i am very interested in exploring alternative
container runtimes, and daemon-less sounds to me like a promising direction.
Jirka
[1] https://bugs.launchpad.net/tripleo/+bug/1777146
[2] https://review.openstack.org/#/c/575758/1/puppet/services/docker.yaml
Thanks,
Steve
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
