Hi Jean-Philippe, all,
happy to see that your questions already created a passionate discussion, but I
also would like to give my contribution.
My background and contributions have always been around deploying and operating
a large cloud infrastructure. As I mentioned in my nomination I have been
involved in the OpenStack community for a long time. I lived the crazy days of
"inflated expectations" and I still stick around in the "plateau of productivity".
To answer your questions I would like to focus in 2 points that in my opinion
are fundamental for the future success of OpenStack.
1) Operators;
2) Projects Consolidation;
1) Operators are the OpenStack users. Ultimately, they define the success of any
OpenStack project because they select what to deploy in their clouds. And what's
deployed is based of course in the requirements but also in the simplicity and
project health.
In my opinion the TC and the community in general should focus in its users
(Operators) feedback. Making sure that OpenStack is integrated and easy to deploy
and maintain over time. Also, make sure that their requirements/pain points are
the priorities during the development cycles.
Of course, many was done over the years (better docs, deployment tools, all
upgrades discussions, ...) but I still think this should be the focus of all the
development/integration direction.
And looking into the number of OpenStack projects, this bring us to my second
point, Project Consolidation.
2) As an Operator, I need to evaluate, deploy and maintain the OpenStack projects
to meet my organization requirements.
I think we all agree that the number of OpenStack projects is overwhelming! For
any new organization that selects OpenStack to deploy their Cloud, navigating
through all the projects is extremely challenging.
What's worst is that some have very little activity and actually they were never
seriously used in a production environment. This can create a lot of confusion
and wrong expectations.
Of course I know about the project navigator and in the past the project
tags/maturity. In fact I'm not advocating more of that.
Over the years we insisted to split projects. For example, as an Operator
I still don't understand the value of having "Placement" as a separate project.
Of course we can argue the architecture pros/cons, that other projects may use it,
but at the end it only adds friction to the users (Operators) to deploy and
maintain their OpenStack Cloud. This is only one example.
Also, we see more and more projects without a PTL volunteer. This doesn't
creates the required trust in those projects to anyone that is looking into
OpenStack to deploy their Cloud.
In my humble opinion the TC and the community in general needs to revaluate the
value of each OpenStack project and consolidate or "retire" what is needed.
If there's a strong dependency or the scope also matches a different project,
maybe consolidate. If the user survey shows that no one is using a project and
its health is questionable, we need to find another solution.
The goal should be to have a clear set of projects that our users (Operators)
can understand the scope and have the trust/confidence to deploy them.
cheers,
Belmiro