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

Zane Bitter 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"?

Read 'pets'.

>> 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 
> it)?

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.

- ZB

More information about the OpenStack-dev mailing list