<div dir="ltr">On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker <span dir="ltr"><<a href="mailto:sbaker@redhat.com" target="_blank">sbaker@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
On 24/08/18 04:36, Fox, Kevin M wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
</blockquote>
<br></span>
I was an advocate for using kubectl standalone for our container orchestration needs well before we started containerizing TripleO. After talking to a few kubernetes folk I cooled on the idea, because they had one of two responses:<br>
- cautious encouragement, but uncertainty about kubectl standalone interface support and consideration for those use cases<br>
- googly eyed incomprehension followed by "why would you do that??"<br>
<br></blockquote><br><div>AFAIK, kubelet does not have a good set of REST API yet[1], but things like heapster do directly interface with kubelet. Last I've seen there was no general consensus for kubelet to provide a subset of api-server APIs. However, from TripleO standpoint providing a set of pod specs to kubelet generated by ansible may be sufficient? <br></div><br><div>[1] <a href="https://github.com/kubernetes/kubernetes/issues/28138">https://github.com/kubernetes/kubernetes/issues/28138</a><br></div><br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This was a while ago now so this could be worth revisiting in the future. We'll be making gradual changes, the first of which is using podman to manage single containers. However podman has native support for the pod format, so I'm hoping we can switch to that once this transition is complete. Then evaluating kubectl becomes much easier.<span class="gmail-"><br>
<br></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
</blockquote>
<br></span>
We're not writing a middle layer, we're leveraging one which is already there.<br>
<br>
CRI-O is a socket interface and podman is a CLI interface that both sit on top of the exact same Go libraries. At this point, switching to podman needs a much lower development effort because we're replacing docker CLI calls.<div class="gmail-HOEnZb"><div class="gmail-h5"><br></div></div></blockquote><div><div>I see good value in evaluating kubelet standalone and
leveraging it's inbuilt grpc interfaces with cri-o (rather than using
podman) as a long term strategy, unless we just want to provide an
alternative to docker container runtime with cri-o.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br></blockquote></span></blockquote></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Kevin<br>
______________________________<wbr>__________<br>
From: Jay Pipes [<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>]<br>
Sent: Thursday, August 23, 2018 8:36 AM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls<br>
<br>
Dan, thanks for the details and answers. Appreciated.<br>
<br>
Best,<br>
-jay<br>
<br>
On 08/23/2018 10:50 AM, Dan Prince wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 08/15/2018 04:01 PM, Emilien Macchi wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi <<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a><br>
<mailto:<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a>>> wrote:<br>
<br>
More seriously here: there is an ongoing effort to converge the<br>
tools around containerization within Red Hat, and we, TripleO are<br>
interested to continue the containerization of our services (which<br>
was initially done with Docker & Docker-Distribution).<br>
We're looking at how these containers could be managed by k8s one<br>
day but way before that we plan to swap out Docker and join CRI-O<br>
efforts, which seem to be using Podman + Buildah (among other things).<br>
<br>
I guess my wording wasn't the best but Alex explained way better here:<br>
<a href="http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org<wbr>/irclogs/%23openstack-tc/%23op<wbr>enstack-tc.2018-08-15.log.html<wbr>#t2018-08-15T17:56:52</a><br>
<br>
If I may have a chance to rephrase, I guess our current intention is to<br>
continue our containerization and investigate how we can improve our<br>
tooling to better orchestrate the containers.<br>
We have a nice interface (openstack/paunch) that allows us to run<br>
multiple container backends, and we're currently looking outside of<br>
Docker to see how we could solve our current challenges with the new tools.<br>
We're looking at CRI-O because it happens to be a project with a great<br>
community, focusing on some problems that we, TripleO have been facing<br>
since we containerized our services.<br>
<br>
We're doing all of this in the open, so feel free to ask any question.<br>
</blockquote>
I appreciate your response, Emilien, thank you. Alex' responses to<br>
Jeremy on the #openstack-tc channel were informative, thank you Alex.<br>
<br>
For now, it *seems* to me that all of the chosen tooling is very Red Hat<br>
centric. Which makes sense to me, considering Triple-O is a Red Hat product.<br>
</blockquote>
Perhaps a slight clarification here is needed. "Director" is a Red Hat<br>
product. TripleO is an upstream project that is now largely driven by<br>
Red Hat and is today marked as single vendor. We welcome others to<br>
contribute to the project upstream just like anybody else.<br>
<br>
And for those who don't know the history the TripleO project was once<br>
multi-vendor as well. So a lot of the abstractions we have in place<br>
could easily be extended to support distro specific implementation<br>
details. (Kind of what I view podman as in the scope of this thread).<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don't know how much of the current reinvention of container runtimes<br>
and various tooling around containers is the result of politics. I don't<br>
know how much is the result of certain companies wanting to "own" the<br>
container stack from top to bottom. Or how much is a result of technical<br>
disagreements that simply cannot (or will not) be resolved among<br>
contributors in the container development ecosystem.<br>
<br>
Or is it some combination of the above? I don't know.<br>
<br>
What I *do* know is that the current "NIH du jour" mentality currently<br>
playing itself out in the container ecosystem -- reminding me very much<br>
of the Javascript ecosystem -- makes it difficult for any potential<br>
*consumers* of container libraries, runtimes or applications to be<br>
confident that any choice they make towards one of the other will be the<br>
*right* choice or even a *possible* choice next year -- or next week.<br>
Perhaps this is why things like openstack/paunch exist -- to give you<br>
options if something doesn't pan out.<br>
</blockquote>
This is exactly why paunch exists.<br>
<br>
Re, the podman thing I look at it as an implementation detail. The<br>
good news is that given it is almost a parity replacement for what we<br>
already use we'll still contribute to the OpenStack community in<br>
similar ways. Ultimately whether you run 'docker run' or 'podman run'<br>
you end up with the same thing as far as the existing TripleO<br>
architecture goes.<br>
<br>
Dan<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You have a tough job. I wish you all the luck in the world in making<br>
these decisions and hope politics and internal corporate management<br>
decisions play as little a role in them as possible.<br>
<br>
Best,<br>
-jay<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div>Rabi Mishra<div><br></div></div></div></div></div>
</div></div>