Open Stack

On 8/23/18 6:22 PM, Fox, Kevin M wrote:
> Question. Rather then writing a middle layer to abstract both container engines, couldn't you just use CRI? CRI is CRI-O's native language, and there is support already for Docker as well.

I may be messing up abstraction levels, but IMO when it's time to 
support CRI-O as well, paunch should handle that just like docker or 
podman. So nothing changes in the moving layers of tripleo components.
It's nice that CRI-O also supports docker and other runtimes, but not 
sure we want something in tripleo moving parts to become neither docker 
not podman nor CRI-O bound.

> 
> Thanks,
> Kevin
> ________________________________________
> From: Jay Pipes [jaypipes at gmail.com]
> Sent: Thursday, August 23, 2018 8:36 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls
> 
> Dan, thanks for the details and answers. Appreciated.
> 
> Best,
> -jay
> 
> On 08/23/2018 10:50 AM, Dan Prince wrote:
>> On Wed, Aug 15, 2018 at 5:49 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.
>>
>> Perhaps a slight clarification here is needed. "Director" is a Red Hat
>> product. TripleO is an upstream project that is now largely driven by
>> Red Hat and is today marked as single vendor. We welcome others to
>> contribute to the project upstream just like anybody else.
>>
>> And for those who don't know the history the TripleO project was once
>> multi-vendor as well. So a lot of the abstractions we have in place
>> could easily be extended to support distro specific implementation
>> details. (Kind of what I view podman as in the scope of this thread).
>>
>>>
>>> I don't know how much of the current reinvention of container runtimes
>>> and various tooling around containers is the result of politics. I don't
>>> know how much is the result of certain companies wanting to "own" the
>>> container stack from top to bottom. Or how much is a result of technical
>>> disagreements that simply cannot (or will not) be resolved among
>>> contributors in the container development ecosystem.
>>>
>>> Or is it some combination of the above? I don't know.
>>>
>>> What I *do* know is that the current "NIH du jour" mentality currently
>>> playing itself out in the container ecosystem -- reminding me very much
>>> of the Javascript ecosystem -- makes it difficult for any potential
>>> *consumers* of container libraries, runtimes or applications to be
>>> confident that any choice they make towards one of the other will be the
>>> *right* choice or even a *possible* choice next year -- or next week.
>>> Perhaps this is why things like openstack/paunch exist -- to give you
>>> options if something doesn't pan out.
>>
>> This is exactly why paunch exists.
>>
>> Re, the podman thing I look at it as an implementation detail. The
>> good news is that given it is almost a parity replacement for what we
>> already use we'll still contribute to the OpenStack community in
>> similar ways. Ultimately whether you run 'docker run' or 'podman run'
>> you end up with the same thing as far as the existing TripleO
>> architecture goes.
>>
>> Dan
>>
>>>
>>> You have a tough job. I wish you all the luck in the world in making
>>> these decisions and hope politics and internal corporate management
>>> decisions play as little a role in them as possible.
>>>
>>> Best,
>>> -jay
>>>
>>> __________________________________________________________________________
>>> 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
>>
>> __________________________________________________________________________
>> 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
>>
> 
> __________________________________________________________________________
> 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
> 
> __________________________________________________________________________
> 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
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando