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 [jaypi...@gmail.com]
Sent: Tuesday, July 03, 2018 10:06 AM
To: openstack-dev@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
