[openstack-dev] [all][tc] Moving away from "big tent" terminology

joehuang joehuang at huawei.com
Wed Jun 21 06:18:16 UTC 2017

hello, Flavio,

This thread is to discuss moving away from the "big tent" term, not removing some project.
Removing a project will make this flavor disappear from the ice-cream counter, but this thread,
it's to use another concept to describe projects under openstack project governance. 
If we don't want to use "big tent" for those projects staying in the counter, 
I hope all projects could be treated in flat, just like different flavor ice-creams are flat in the
same counter, kid can make choice by themselves. 

Even Nova may be only "core"  to some cloud operators, but not always for all cloud operators,
for example, those who only run object storage service, hyper.sh also not use Nova,  some day may
some cloud operators only use Zun or K8S instead for computing, it should not be an issue
to OpenStack community.

OpenStack should be "OPEN" stack for infrastructure, just like kid can choose how many
balls of ice-cream, cloud operators can make decision to choose which project to use or
not to manage his infrastructure.

Best Regards
Chaoyi Huang (joehuang)

From: Flavio Percoco [flavio at redhat.com]
Sent: 20 June 2017 17:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tc] Moving away from "big    tent"   terminology

On 20/06/17 00:33 +0000, joehuang wrote:
>I think openstack community  provides a flat project market place for infrastructure is good enough:
>all projects are just some "goods" in the market place, let the cloud operators to select projects
>from the project market place for his own infrastructure.
>We don't have to mark a project a core project or not, only need to tag attribute of a project, for
>example how mature it is, how many "like" they have, what the cloud operator said for the project. etc.
>All flat, just let people make decision by themselves, they are not idiot, they have wisdom
>on building infrastructure.
>Not all people need a package: you bought a package of ice-cream, but not all you will like it,
>If they want package, distribution provider can help them to define and customize a package, if
>you want customization, you will decide which ball of cream you want, isn't it?

The flavors you see in a ice-creem shop counter are not there by accident. Those
flavors have gone through a creation process, they have been tested and they
have also survived over the years. Some flavors are removed with time and some
others stay there forever.

Unfortunately, tagging those flavors won't cut it, which is why you don't see
tags in their labels when you go to an ice-cream shop. Some tags are implied,
other tags are inferred and other tags are subjective.

Experimenting with new flavors doesn't happen overnight in some person's
bedroom. The new flavors are tested using the *same* infrastructure as the other
flavors and once they reach a level of maturity, they are exposed in the counter
so that customers will able to consume them.

Ultimately, experimentation is part of the ice-cream shop's mission and it
requires time, effort and resources but not all experiments end well. At the
end, though, what really matters is that all these flavors serve the same
mission and that's why they are sold at the ice-cream shop, that's why they are
exposed in the counter. Customer's of the ice-cream shop know they can trust
what's in the counter. They know the exposed flavors serve their needs at a high
level and they can now focus on their specific needs.

So, do you really think it's just a set of flavors and it doesn't really matter
how those flavors got there?


Flavio Percoco

More information about the OpenStack-dev mailing list