<div dir="ltr">On Mon, Aug 27, 2018 at 3:25 PM, Sergii Golovatiuk <span dir="ltr"><<a href="mailto:sgolovat@redhat.com" target="_blank">sgolovat@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On Mon, Aug 27, 2018 at 5:32 AM, Rabi Mishra <<a href="mailto:ramishra@redhat.com">ramishra@redhat.com</a>> wrote:<br>
> On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker <<a href="mailto:sbaker@redhat.com">sbaker@redhat.com</a>> wrote:<br></span>Steve mentioned kubectl (kubernetes CLI which communicates with<br></blockquote><div><div class="gmail_quote"><br></div><div class="gmail_quote">Not sure what he meant. May be I miss something, but not heard of 'kubectl standalone', though he might have meant standalone k8s cluster on every node as you think.<br></div><div class="gmail_quote"> <br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
kube-api) not kubelet which is only one component of kubernetes. All<br>
kubernetes components may be compiled as one binary (hyperkube) which<br>
can be used to minimize footprint. Generated ansible for kubelet is<br>
not enough as kubelet doesn't have any orchestration logic.<br>
<span class=""></span></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">What orchestration logic do we've with TripleO atm? AFAIK we've provide roles data for service placement across nodes, right?</div><div class="gmail_extra">I see standalone kubelet as a first step for scheduling openstack services with in k8s cluster in the future (may be). <br></div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>><br>
>> This was a while ago now so this could be worth revisiting in the future.<br>
>> We'll be making gradual changes, the first of which is using podman to<br>
>> manage single containers. However podman has native support for the pod<br>
>> format, so I'm hoping we can switch to that once this transition is<br>
>> complete. Then evaluating kubectl becomes much easier.<br>
>><br>
>>> Question. Rather then writing a middle layer to abstract both container<br>
>>> engines, couldn't you just use CRI? CRI is CRI-O's native language, and<br>
>>> there is support already for Docker as well.<br>
>><br>
>><br>
>> We're not writing a middle layer, we're leveraging one which is already<br>
>> there.<br>
>><br>
>> CRI-O is a socket interface and podman is a CLI interface that both sit on<br>
>> top of the exact same Go libraries. At this point, switching to podman needs<br>
>> a much lower development effort because we're replacing docker CLI calls.<br>
>><br>
> I see good value in evaluating kubelet standalone and leveraging it's<br>
> inbuilt grpc interfaces with cri-o (rather than using podman) as a long term<br>
> strategy, unless we just want to provide an alternative to docker container<br>
> runtime with cri-o.<br>
<br>
</span>I see no value using kubelet without kubernetes IMHO.<br>
<div><div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
><br>
>>><br>
>>><br>
>>> Thanks,<br>
>>> Kevin<br>
>>> ______________________________<wbr>__________<br>
>>> From: Jay Pipes [<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>]<br>
>>> Sent: Thursday, August 23, 2018 8:36 AM<br>
>>> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
>>> Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice<br>
>>> 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>
>>>><br>
>>>> On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> On 08/15/2018 04:01 PM, Emilien Macchi wrote:<br>
>>>>>><br>
>>>>>> On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a><br>
>>>>>> <mailto:<a href="mailto:emilien@redhat.com">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<br>
>>>>>> are<br>
>>>>>> interested to continue the containerization of our services<br>
>>>>>> (which<br>
>>>>>> was initially done with Docker & Docker-Distribution).<br>
>>>>>> We're looking at how these containers could be managed by k8s<br>
>>>>>> one<br>
>>>>>> day but way before that we plan to swap out Docker and join<br>
>>>>>> CRI-O<br>
>>>>>> efforts, which seem to be using Podman + Buildah (among other<br>
>>>>>> things).<br>
>>>>>><br>
>>>>>> I guess my wording wasn't the best but Alex explained way better here:<br>
>>>>>><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.<wbr>org/irclogs/%23openstack-tc/%<wbr>23openstack-tc.2018-08-15.log.<wbr>html#t2018-08-15T17:56:52</a><br>
>>>>>><br>
>>>>>> If I may have a chance to rephrase, I guess our current intention is<br>
>>>>>> 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<br>
>>>>>> 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>
>>>>><br>
>>>>> 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<br>
>>>>> Hat<br>
>>>>> centric. Which makes sense to me, considering Triple-O is a Red Hat<br>
>>>>> product.<br>
>>>><br>
>>>> 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>
>>>>> 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<br>
>>>>> 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<br>
>>>>> 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<br>
>>>>> 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>
>>>><br>
>>>> 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>
>>>>> 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>
>>>>><br>
>>>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>>>><br>
>>>><br>
>>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>>>><br>
>>><br>
>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>>><br>
>>><br>
>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>>><br>
>>><br>
>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>><br>
>><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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Regards,<br>
> Rabi Mishra<br>
><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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
<br>
<br>
-- <br>
</div></div>Best Regards,<br>
Sergii Golovatiuk<br>
<div class="HOEnZb"><div class="h5"><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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div>Rabi Mishra<div><br></div></div></div></div></div>
</div></div>