Or use kubelet in standalone mode. It can be configured for either Cri-o or Docker. You can drive the static manifests from heat/ansible per host as normal and it would be a step in the greater direction of getting to Kubernetes without needing the whole thing at once, if that is the goal.
Thanks, Kevin ________________________________________ From: Fox, Kevin M [kevin....@pnnl.gov] Sent: Thursday, August 23, 2018 9:22 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls 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. Thanks, Kevin ________________________________________ From: Jay Pipes [jaypi...@gmail.com] Sent: Thursday, August 23, 2018 8:36 AM To: openstack-dev@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 <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. > > 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-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 > __________________________________________________________________________ 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 __________________________________________________________________________ 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
