Open Stack

On 16.8.2018 10:38, Steven Hardy wrote:
> On Wed, Aug 15, 2018 at 10:48 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>> On 08/15/2018 04:01 PM, Emilien Macchi wrote:
>>>
>>> On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi <emilien at redhat.com
>>> <mailto:emilien at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>