[openstack-dev] [tc] [all] TC Report 18-26
zbitter at redhat.com
Sat Jul 7 01:23:08 UTC 2018
I'm not Kevin but I think I can clarify some of these.
On 03/07/18 16:04, Jay Pipes wrote:
> On 07/03/2018 02:37 PM, Fox, Kevin M wrote:
> So these days containers are out clouding vms at this use case. So, does Nova continue to be cloudy vm or does it go for the more production vm use case like oVirt and VMware?
> "production VM" use case like oVirt or VMWare? I don't know what that means. You mean "a GUI-based VM management system"?
>> While some people only ever consider running Kubernetes on top of a
>> cloud, some of us realize maintaining both a cloud an a kubernetes is
>> unnecessary and can greatly simplify things simply by running k8s on
>> bare metal. This does then make it a competitor to Nova as a platform
>> for running workload on.
> What percentage of Kubernetes users deploy on baremetal (and continue to
> deploy on baremetal in production as opposed to just toying around with
At Red Hat Summit there was a demo of deploying OpenShift alongside (not
on top of) OpenStack on bare metal using Director (downstream of TripleO
- so managed by Ironic in an OpenStack undercloud).
I don't know if people using Kubernetes directly on baremetal in
production is widespread right now, but it's clear to me that it will be
just around the corner.
>> As k8s gains more multitenancy features, this trend will continue to
>> grow I think. OpenStack needs to be ready for when that becomes a thing.
> OpenStack is already multi-tenant, being designed as such from day one.
> With the exception of Ironic, which uses Nova to enable multi-tenancy.
> What specifically are you referring to "OpenStack needs to be ready"?
> Also, what specific parts of OpenStack are you referring to there?
I believe the point was:
* OpenStack supports multitenancy.
* Kubernetes does not support multitenancy.
* Applications that require multitenancy currently require separate
per-tenant deployments of Kubernetes; deploying on top of a cloud (such
as OpenStack) makes this easier, so there is demand for OpenStack from
people who need multitenancy even if they are mainly interacting with
Kubernetes. Effectively OpenStack is the multitenancy layer for k8s in a
lot of deployments.
* One day Kubernetes will support multitenancy.
* Then what?
>> Think of OpenStack like a game console. The moment you make a component optional and make it takes extra effort to obtain, few software developers target it and rarely does anyone one buy the addons it because there isn't software for it. Right now, just about everything in OpenStack is an addon. Thats a problem.
> I don't have any game consoles nor do I develop software for them,
Me neither, but much like OpenStack it's a two-sided marketplace
(developers and users in the console case, operators and end-users in
the OpenStack case), where you succeed or fail based on how much value
you can get flowing between the two sides. There's a positive feedback
loop between supply on one side and demand on the other, so like all
positive feedback loops it's unstable and you have to find some way to
bootstrap it in the right direction, which is hard. One way to make it
much, much harder is to segment your market such a way that you give
yourself a second feedback loop that you also have to bootstrap, that
depends on the first one, and you only get to use a subset of your
existing market participants to do it.
As an example from my other reply, we're probably going to try to use
Barbican to help integrate Heat with external tools like k8s and
Ansible, but for that to have any impact we'll have to convince users
that they want to do this badly enough that they'll convince their
operators to deploy Barbican - and we'll likely have to do so before
they've even tried it. That's even after we've already convinced them to
use OpenStack and deploy Heat. If Barbican (and Heat) were available as
part of every OpenStack deployment, then it'd just be a matter of
convincing people to use the feature, which would already be available
and which they could try out at any time. That's a much lower bar.
I'm not defending "make it a monolith" as a solution, but Kevin is
identifying a real problem.
More information about the OpenStack-dev