Open Stack

Hello,

My opinion (a little bit conservative, for once) is inline...

On Wed, 2020-04-01 at 19:03 +0200, Dmitry Tantsur wrote:
> The first and the main reason is the ambiguity in our positioning. We
> do see prospective operators and users confused by the perception
> that Ironic is a part of OpenStack, especially when it comes to the
> standalone use case. 
> “But what if I don’t need OpenStack” is a question that I hear in
> most of these conversations. Changing from “a part of OpenStack” to
> “a FOSS tool that can integrate with OpenStack” is critical for our
> project to keep growing into new fields.

I think the name "Ironic" associated with the term "bare metal" maps to
OpenStack. You are right.
It's in the heads of the people who were involved, in the search
engines, etc.

However, I am not 100% sure it maps with "needs Nova" or "cannot be
standalone".

If you consider OpenStack taints this "standalone" part of Ironic, do
you think that putting it as a top project of the **OpenStack
Foundation ** will help? I don't think so. People will still see it's
an OpenStack _related_ technology, with a history of being an OpenStack
project, which is now a standalone project inside the OpenStack
foundation. At best, it confuses people which are not really aware of
all these details.

If you really want to leave OpenStack for standalone purpose, I would
encourage to try a more radical approach, like gnocchi, who completely
split out. Sadly it didn't turn out fine for them, but at least the
difference was clear. It was out.

Again, I don't think that being in the "openstack" namespace prevents
standalone.
In fact that's what I would like to see more with our current openstack
projects: Be relevant as standalone. Swift and Ironic are very good
examples. They make sense in OpenStack, as standalone services, that
happen to work well together in an ecosystem for IaaS. The whole point
of the OpenStack name, for me, is the coordinated testing and
releasing. "Those independents bits are tested together!".

Can't we work on the branding, naming, and message without the move?
Why the hassle of moving things? Does that really bring value to your
team? Before forging my final (personal) opinion, I would like more
information than just gut feelings.

> To me personally it feels in line with how OpenDev itself is reaching
> into new areas beyond just the traditional IaaS. The next OpenDev
> even will apparently have a bare metal management track, so why not a
> top-level project for it? 

I like the OpenDev idea, but I cannot unshake this off the OSF. In
other words, I am not sure how far it goes "beyond the traditional
IaaS" in my mind, because the OSF (and OpenDev) have missions after
all. Would you care to explain for me? How does that map with the
ironic reflection? I am confused, Ironic _for me_ is an infrastructure
tool...

> Another reason is release cadence. We have repeatedly expressed the
> desire to release Ironic and its sub-projects more often than we do
> now. Granted, *technically* we can release often even now. We can
> even abandon the current release model and switch to “independent”,
> but it doesn’t entirely solve the issue at hand.
>  First, we don’t want to lose the notion of stable branches. 

Independant doesn't mean _not branching_. In the old times, before
cycle-trailing existed, OpenStack-Ansible was independent, we manually
branched, and used the release tooling to do official releases. It's
pretty close to what you are looking for, IMO.

> One way or another, we need to support consumers with bug fix
> releases. Second, to become truly “independent” we’ll need to remove
> any tight coupling with any projects that do integrated releases.
> Which is, essentially, what I’m proposing here.

That's for me the simplest change you can do. When you move to
independant, while still benefit from the release tooling and help of
your current reviewer sets. 

Please note that I am still writing an idea in our ideas framework,
proposing a change in the release cycles (that conversation again! but
with a little twist), which I guess you might be interested in.

Regards,
Jean-Philippe Evrard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200402/582ed877/attachment.html>