[openstack-dev] [tc] [all] TC Report 18-26

Dmitry Tantsur dtantsur at redhat.com
Thu Jul 5 18:17:49 UTC 2018


On Thu, Jul 5, 2018, 19:31 Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:

> We're pretty far into a tangent...
>
> /me shrugs. I've done it. It can work.
>
> Some things your right. deploying k8s is more work then deploying ansible.
> But what I said depends on context. If your goal is to deploy k8s/manage
> k8s then having to learn how to use k8s is not a big ask. adding a
> different tool such as ansible is an extra cognitive dependency. Deploying
> k8s doesn't need a general solution to deploying generic base OS's. Just
> enough OS to deploy K8s and then deploy everything on top in containers.
> Deploying a seed k8s with minikube is pretty trivial. I'm not suggesting a
> solution here to provide generic provisioning to every use case in the
> datacenter. But enough to get a k8s based cluster up and self hosted enough
> where you could launch other provisioning/management tools in that same
> cluster, if you need that. It provides a solid base for the datacenter on
> which you can easily add the services you need for dealing with everything.
>
> All of the microservices I mentioned can be wrapped up in a single helm
> chart and deployed with a single helm install command.
>
> I don't have permission to release anything at the moment, so I can't
> prove anything right now. So, take my advice with a grain of salt. :)
>
> Switching gears, you said why would users use lfs when they can use a
> distro, so why use openstack without a distro. I'd say, today unless you
> are paying a lot, there isn't really an equivalent distro that isn't almost
> as much effort as lfs when you consider day2 ops. To compare with Redhat
> again, we have a RHEL (redhat openstack), and Rawhide (devstack) but no
> equivalent of CentOS. Though I think TripleO has been making progress on
> this front...
>

It's RDO what you're looking for (equivalent of centos). TripleO is an
installer project, not a distribution.


> Anyway. This thread is I think 2 tangents away from the original topic
> now. If folks are interested in continuing this discussion, lets open a new
> thread.
>
> Thanks,
> Kevin
>
> ________________________________________
> From: Dmitry Tantsur [dtantsur at redhat.com]
> Sent: Wednesday, July 04, 2018 4:24 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
>
> Tried hard to avoid this thread, but this message is so much wrong..
>
> On 07/03/2018 09:48 PM, Fox, Kevin M wrote:
> > I don't dispute trivial, but a self hosting k8s on bare metal is not
> incredibly hard. In fact, it is easier then you might think. k8s is a
> platform for deploying/managing services. Guess what you need to provision
> bare metal? Just a few microservices. A dhcp service. dhcpd in a daemonset
> works well. some pxe infrastructure. pixiecore with a simple http backend
> works pretty well in practice. a service to provide installation
> instructions. nginx server handing out kickstart files for example. and a
> place to fetch rpms from in case you don't have internet access or want to
> ensure uniformity. nginx server with a mirror yum repo. Its even possible
> to seed it on minikube and sluff it off to its own cluster.
> >
> > The main hard part about it is currently no one is shipping a reference
> implementation of the above. That may change...
> >
> > It is certainly much much easier then deploying enough OpenStack to get
> a self hosting ironic working.
>
> Side note: no, it's not. What you describe is similarly hard to installing
> standalone ironic from scratch and much harder than using bifrost for
> everything. Especially when you try to do it in production. Especially with
> unusual operating requirements ("no TFTP servers on my network").
>
> Also, sorry, I cannot resist:
> "Guess what you need to orchestrate containers? Just a few things. A
> container
> runtime. Docker works well. some remove execution tooling. ansible works
> pretty
> well in practice. It is certainly much much easier then deploying enough
> k8s to
> get a self hosting containers orchestration working."
>
> Such oversimplications won't bring us anywhere. Sometimes things are hard
> because they ARE hard. Where are people complaining that installing a full
> GNU/Linux distributions from upstream tarballs is hard? How many operators
> here
> use LFS as their distro? If we are okay with using a distro for GNU/Linux,
> why
> using a distro for OpenStack causes so much contention?
>
> >
> > Thanks,
> > Kevin
> >
> > ________________________________________
> > From: Jay Pipes [jaypipes at gmail.com]
> > Sent: Tuesday, July 03, 2018 10:06 AM
> > To: openstack-dev at lists.openstack.org
> > Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
> >
> > On 07/02/2018 03:31 PM, Zane Bitter wrote:
> >> On 28/06/18 15:09, Fox, Kevin M wrote:
> >>>    * made the barrier to testing/development as low as 'curl
> >>> http://......minikube; minikube start' (this spurs adoption and
> >>> contribution)
> >>
> >> That's not so different from devstack though.
> >>
> >>>    * not having large silo's in deployment projects allowed better
> >>> communication on common tooling.
> >>>    * Operator focused architecture, not project based architecture.
> >>> This simplifies the deployment situation greatly.
> >>>    * try whenever possible to focus on just the commons and push vendor
> >>> specific needs to plugins so vendors can deal with vendor issues
> >>> directly and not corrupt the core.
> >>
> >> I agree with all of those, but to be fair to OpenStack, you're leaving
> >> out arguably the most important one:
> >>
> >>       * Installation instructions start with "assume a working
> datacenter"
> >>
> >> They have that luxury; we do not. (To be clear, they are 100% right to
> >> take full advantage of that luxury. Although if there are still folks
> >> who go around saying that it's a trivial problem and OpenStackers must
> >> all be idiots for making it look so difficult, they should really stop
> >> embarrassing themselves.)
> >
> > This.
> >
> > There is nothing trivial about the creation of a working datacenter --
> > never mind a *well-running* datacenter. Comparing Kubernetes to
> > OpenStack -- particular OpenStack's lower levels -- is missing this
> > fundamental point and ends up comparing apples to oranges.
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180705/ab3b5dbd/attachment.html>


More information about the OpenStack-dev mailing list