Open Stack

On Mon, Aug 27, 2018 at 3:25 PM, Sergii Golovatiuk <sgolovat at redhat.com>
wrote:

> Hi,
>
> On Mon, Aug 27, 2018 at 5:32 AM, Rabi Mishra <ramishra at redhat.com> wrote:
> > On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker <sbaker at redhat.com> wrote:
> Steve mentioned kubectl (kubernetes CLI which communicates with
>

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.


> kube-api) not kubelet which is only one component of kubernetes. All
> kubernetes components may be compiled as one binary (hyperkube) which
> can be used to minimize footprint. Generated ansible for kubelet is
> not enough as kubelet doesn't have any orchestration logic.
>

What orchestration logic do we've with TripleO atm? AFAIK we've provide
roles data for service placement across nodes, right?
I see standalone kubelet as a first step for scheduling openstack services
with in k8s cluster in the future (may be).

>>
> >> 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.
> >>
> >>> 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.
> >>
> >>
> >> We're not writing a middle layer, we're leveraging one which is already
> >> there.
> >>
> >> 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.
> >>
> > 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.
>
> I see no value using kubelet without kubernetes IMHO.
>
>
>
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>> ____________________________________________________________
> ______________
> >>> 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
> >
> >
> >
> >
> > --
> > Regards,
> > Rabi Mishra
> >
> >
> > ____________________________________________________________
> ______________
> > 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,
> Sergii Golovatiuk
>
> __________________________________________________________________________
> 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
>



-- 
Regards,
Rabi Mishra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180827/87694d74/attachment.html>