Open Stack

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


On Thu, Apr 2, 2020 at 12:33 PM Jean-Philippe Evrard <
jean-philippe at evrard.me> wrote:

> Hello,
>
> I read your nominations, and as usual I will ask what do you
> _technically_ will do during your mandate, what do you _actively_ want
> to change in OpenStack?
>
> This can be a change in governance, in the projects, in the current
> structure... it can be really anything. I am just hoping to see
> practical OpenStack-wide changes here. It doesn't need to be a fully
> refined idea, but something that can be worked upon.
>
> Thanks for your time.
>
> Regards,
> Jean-Philippe Evrard
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200407/5ffdb4a2/attachment.html>