Open Stack

I suggest that we continue the discussion in this freshly created specs:
https://review.openstack.org/602480

http://logs.openstack.org/80/602480/2/check/openstack-tox-docs/9da610c/html/specs/stein/podman.html

Any feedback and inputs are welcome.
Thanks,

On Thu, Sep 13, 2018 at 3:36 AM Bogdan Dobrelya <bdobreli at redhat.com> wrote:

> On 8/27/18 6:38 PM, Fox, Kevin M wrote:
> > I think in this context, kubelet without all of kubernetes still has the
> value that it provides an abstraction layer that podmon/paunch is being
> suggested to handle.
> >
> > It does not need the things you mention, network, sidecar, scaleup/down,
> etc. You can use as little as you want.
> >
> > For example, make a pod yaml per container with hostNetwork: true. it
> will run just like it was on the host then. You can do just one container.
> no sidecars necessary. Without the apiserver, it can't do scaleup/down even
> if you wanted to.
> >
> > It provides declarative yaml based management of containers, similar to
> paunch. so you can skip needing that component.
>
> That would be a step into the right direction IMO.
>
> >
> > It also already provides crio and docker support via cri.
> >
> > It does provide a little bit of orchestration, in that you drive things
> with declarative yaml. You drop in a yaml file in
> /etc/kubernetes/manifests, and it will create the container. you delete it,
> it removes the container. If you change it, it will update the container.
> and if something goes wrong with the container, it will try and get it back
> to the requested state automatically. And, it will recover the containers
> on reboot without help.
> >
> > Thanks,
> > Kevin
> >
> > ________________________________________
> > From: Sergii Golovatiuk [sgolovat at redhat.com]
> > Sent: Monday, August 27, 2018 3:46 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for
> nice       API calls
> >
> > Hi,
> >
> > On Mon, Aug 27, 2018 at 12:16 PM, Rabi Mishra <ramishra at redhat.com>
> wrote:
> >> 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).
> >
> > It's half measure. I don't see any advantages of that move. We should
> > either adopt whole kubernetes or doesn't use its components at all as
> > the maintenance cost will be expensive. Using kubelet requires to
> > resolve networking communication, scale-up/down, sidecar, or inter
> > services dependencies.
> >
> >>
> >>>>>
> >>>>> 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
> >>
> >>
> >>
> __________________________________________________________________________
> >> 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
> >
> >
> __________________________________________________________________________
> > 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
>
> __________________________________________________________________________
> 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
>


-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180913/23597777/attachment.html>