Open Stack

On Wed, Aug 18, 2021 at 3:08 PM Thierry Carrez <thierry at openstack.org> wrote:
>
> Rong Zhu wrote:
> > Sorry for my late response, I am a little bit busy for internal works
> > recently.
> >
> > If TC has decided to retire murano, I have no objection. But If TC think
> > someone can keep maintain it and not retire, I am glad to keeping
> > maintain Murano project. Please reconsider this.
>
> For the record, I don't think there is an urgent need to retire Murano
> as long as it is maintained, fills community goals, hits release
> requirements, and is functional.

I disagree. I think we are giving it a false sense of usability.
It likely can do "something" but there does not seem to exist enough
workforce to triage and fix bugs [1] for quite some time.
And some [2] look like users are having a hard time using it.
This was also observed by me with my Kolla hat on - folks reported to
us that they can't get Murano stuff running and we could only spread
our hands. (-:
It also does not seem to have had any new features since at least Stein. [3]

We can also take a look at stackalytics [4].
Most person-day effort was eaten up by community-wide changes.

My POV is that OpenStack is still a kind of quality badge that applies
to projects under its umbrella.
Seemingly, it's also the perspective of folks outside of the close
community (ask anyone doing consulting ;-) ).
And thus we should retire projects which did not stand the test of time.

I am thankful for Rong Zhu's efforts to keep the project alive but it
seems the world has moved on to solutions based on different
technologies, as mentioned by you (Thierry) and Mohammed.
And we, as OpenStack, should accept that and focus on better
integration with those.

[1] https://bugs.launchpad.net/murano/+bugs?orderby=-id&start=0
[2] https://bugs.launchpad.net/murano/+bug/1817538
[3] https://docs.openstack.org/releasenotes/murano/index.html
[4] https://www.stackalytics.io/?module=murano-group&metric=person-day&release=xena

-yoctozepto


> Like mnaser said, it is a bit off in the modern landscape of application
> deployment technology, so I don't think it's a priority anymore -- if
> its continued existence blocked people from focusing on more critical
> components, I would support removing it. But based on Rong Zhu's
> response I'm not sure that's the case.
>
> --
> Thierry
>