<div dir="ltr"><div>Hi,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 6, 2020 at 4:45 PM Mohammed Naser <<a href="mailto:mnaser@vexxhost.com">mnaser@vexxhost.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Dmitry,<br>
<br>
Thank you for raising this.  I think what you're looking for makes<br>
sense, I don't think splitting outside OpenStack is the right solution<br>
for this.  There are many logistical issues in doing this.<br></blockquote><div><br></div><div>I do agree with this.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
First of all, it promotes even more bureaucracy within our community<br>
which is something that we're trying to split.   "Ironic" and<br>
"OpenStack" becoming two separate pieces means that we've failed as a<br>
community to be able to deliver what OpenStack is.  If we do this, we<br>
further promote the separation of our communities and that is not<br>
sustainable.  With a dwindling contributor base, we'll find power in<br>
standing together in big groups, not by isolating ourselves to small<br>
islands.<br></blockquote><div><br></div><div>This sounds a bit like the "us vs them" mentality, which I think may be hurting OpenStack now. I think we should be more open to the things that happen outside of our control. This also goes back to my points about Oslo and the bigger Python world.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Arguably, you would say that "well, Ironic is picking up outside<br>
OpenStack and we want to capitalize on that".  I agree with you on<br>
that, I think we should absolutely do that.  However, I think simply<br>
just becoming a top-level project is not the way to go about this.  It<br>
will introduce a lot more work to our (already overwhelmed) OSF staff,<br>
it means maintaining a new identity, it means applying to be a pilot<br>
project and going through the whole process.  It means that all<br>
existing developer may need to have to revise the way they do work<br>
because they have signed the CCLA for OpenStack and not "Ironic".<br></blockquote><div><br></div><div>I fully agree, this is unfortunate.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We're adding a whole lot of bureaucray when the problem is messaging.<br>
<br>
I've gone over your points below about what you think this will do and<br>
strongly suggest those alternatives.<br>
<br>
Regards,<br>
Mohammed<br>
<br>
On Wed, Apr 1, 2020 at 1:07 PM Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>> wrote:<br>
><br>
> Hi everyone!<br>
><br>
> This topic should not come as a huge surprise for many, since it has been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion.<br>
><br>
> TL;DR I’m proposing to make Ironic a top-level project under <a href="http://opendev.org" rel="noreferrer" target="_blank">opendev.org</a> and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated.<br>
><br>
> (And no, it’s not an April 1st joke)<br>
><br>
> Background<br>
> =========<br>
><br>
> Ironic was born as a Nova plugin, but has grown way beyond this single case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it.<br>
><br>
> And before you ask: in no case do I suggest scaling down our invaluable integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team.<br>
><br>
> Okay, so why?<br>
> ===========<br>
><br>
> 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. 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?<br>
><br>
> 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. 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.<br>
><br>
> Finally, I believe that our independence (can I call it “Irexit” please?) has already happened in reality, we just shy away from recognizing it. Look:<br>
> 1. All integration points with other OpenStack projects are optional.<br>
> 2. We can work fully standalone and even provide a project for that.<br>
> 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova.<br>
> 4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service).<br>
> 5. We make releases more often than the “core” OpenStack projects (but see above).<br>
><br>
> What we will do<br>
> ============<br>
><br>
> This proposal involves in the short term:<br>
> * Creating a new git namespace: <a href="http://opendev.org/ironic" rel="noreferrer" target="_blank">opendev.org/ironic</a><br>
<br>
We could totally do this for all existing projects honestly.  I think<br>
the TC could probably be okay with this.<br></blockquote><div><br></div><div>That's an interesting thought, actually. Maybe rather than one "openstack" namespace we can have a namespace per program? Like <a href="http://opendev.org/compute/nova">opendev.org/compute/nova</a>, etc? This may also solve a part of the problem with oslo libraries adoption outside of OpenStack. <a href="http://opendev.org/libs/stevedore">opendev.org/libs/stevedore</a> doesn't suggest that it belongs to openstack the same way as <a href="http://opendev.org/openstack/stevedore">opendev.org/openstack/stevedore</a>. And it will provide an obvious link between code names and purposes! Who can we talk to to make this happen?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * Creating a new website (name TBD, bare metal puns are welcome).<br>
>    * If we can have <a href="https://docs.opendev.org/ironic/" rel="noreferrer" target="_blank">https://docs.opendev.org/ironic/</a>, it may be just fine though.<br>
<br>
Who's going to work on this website?  It's important to not only have<br>
a website but keep it maintained, add more content, update it.  </blockquote><div><br></div><div>We do realize this, and we're already doing it, to some extent, with docs.o.o/ironic. It's unfortunate that we don't have dedicated designers and technical writers, but it's already our reality.</div><div><br></div><div>Note that I don't suggest a highly dynamic web site. More of a consumer-oriented landing page like <a href="http://metal3.io/">http://metal3.io/</a> and an umbrella-neutral hosting for documentation like <a href="http://tripleo.org/">http://tripleo.org/</a>. I do agree with Thierry that it's doable without the actual split, but then it needs cooperation from the Foundation and the TC.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The<br>
website will have absolutely zero traction initially and we'll miss<br>
out on all the "traffic" that OpenStack.org gets.  I think what we<br>
should actually do is redesign OpenStack.org so that it's a focused<br>
about the OpenStack projects and move all the foundation stuff to<br>
<a href="http://osf.dev" rel="noreferrer" target="_blank">osf.dev</a> -- In there, we can nail down the messaging of "you don't need<br>
all of OpenStack".<br></blockquote><div><br></div><div>I don't think keeping ironic on <a href="http://openstack.org">openstack.org</a> will help you nail it down.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * Keeping the same governance model, only adjusted to the necessary extent.<br>
<br>
This is not easy, you'll have to come up with a whole governance, run<br>
elections, manage people.  We already have volunteers that help do<br>
this inside OpenStack, why add all that extra layer?<br>
<br>
> * Keeping the same policies (reviews, CI, stable).<br>
<br>
That seems reasonable to me<br>
<br>
> * Defining a new release cadence and stable branch support schedule.<br>
<br>
If there is anything in the current model that doesn't suit you,<br>
please bring it up, and let's revise it.  I've heard this repeated a<br>
lot as a complaint from the Ironic team and I've unfortunately not<br>
seen any proposal about an ideal alternative.  We need to hear things<br>
to change things.<br></blockquote><div><br></div><div>There is no ideal alternative, this is why most of these discussions get stuck. We may need to look at the Swift model since it seems closer to what we're aiming at. Which are:</div><div>1) More frequent releases with a possibility of bug-fix support for them (i.e. short-lived stable branches) and upgrades (time to ditch grenade?).<br></div><div>2) Stop release-to-release matching for interactions with other services (largely achieved by microversioning).</div><div>3) Support for non-coordinated releases in installation tools (okay, this one is fun, I'm not sure how to approach it).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> In the long term we will consider (not necessary do):<br>
> * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack).<br>
<br>
That seems reasonable to have more Ironic "standalone" jobs.  It is<br>
important that _the_ biggest consumers *are* the OpenStack ones, let's<br>
not alienate them so we end up in a world of nothing new.<br></blockquote><div><br></div><div>I'm not sure I get your proposal. If you suggest that we keep most of our testing on devstack/grenade/tempest with the whole OpenStack, this is something we're moving away from, no matter if split or not. The current approach to CI testing simply doesn't scale well enough to cover our feature set.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * Reducing or removing reliance on oslo libraries.<br>
<br>
Why?<br></blockquote><div><br></div><div>I've left some thoughts in my previous replies, but I don't quite like the way we're creating silos in OpenStack. Everyone is depending on oslo.utils, sometimes for one tiny helper (bool_from_string anyone?). Couldn't we move it to Python stdlib? I think the existence of our semi-private libraries discourages reaching out to the whole infrastructure. Everything depends on oslo.i18n, cannot we use the built-in gettext instead? Why is everything pulling in Babel even though nothing imports it? Sorry, this is turning into a rant, the essence of which is that we're taking a too easy approach to requirements.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * Stopping using rabbitmq for messaging (we’ve already made it optional).<br>
<br>
Please.  Please.  Whatever you replace it with, just update<br>
oslo.messaging and make all of us happy to stop using it.  It's hell.<br></blockquote><div><br></div><div>I'd be happy to, but I think the oslo.messaging API is designed around the AMQP pattern too much. I'm getting back to my rant above: do all projects really need a messaging queue? When I asked this question in Ironic, we realized that we don't. We simply introduced JSON RPC support instead.</div><div><br></div><div>Dmitry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication).<br>
<br>
I support this, and I think there's nothing stopping you from doing<br>
that today.  If there is, let's bring it up.<br>
<br>
> What we will NOT do<br>
> ================<br>
><br>
> At least this proposal does NOT involve:<br>
> * Stopping maintaining the Ironic virt driver in Nova.<br>
>    * Stopping running voting CI jobs with OpenStack services.<br>
> * Dropping optional integration with OpenStack services.<br>
> * Leaving OpenDev completely.<br>
><br>
> What do you think?<br>
> ===============<br>
><br>
> Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome.<br>
><br>
> Cheers,<br>
> Dmitry<br>
<br>
<br>
<br>
-- <br>
Mohammed Naser — vexxhost<br>
-----------------------------------------------------<br>
D. 514-316-8872<br>
D. 800-910-1726 ext. 200<br>
E. <a href="mailto:mnaser@vexxhost.com" target="_blank">mnaser@vexxhost.com</a><br>
W. <a href="https://vexxhost.com" rel="noreferrer" target="_blank">https://vexxhost.com</a><br>
<br>
</blockquote></div></div>