[tc][ops] reviving osops- repos

Doug Hellmann doug at doughellmann.com
Fri May 31 11:50:45 UTC 2019


Mohammed Naser <mnaser at vexxhost.com> writes:

> On Thu, May 30, 2019 at 4:59 PM Jeremy Stanley <fungi at yuggoth.org> wrote:
>>
>> On 2019-05-30 15:23:43 -0400 (-0400), Mohammed Naser wrote:
>> [...]
>> > I've requested to move x/osops-* to openstack-operators/* in
>> > GitHub so that I can setup the appropriate mirroring in post
>> > pipeline (and then propose a patch to rename things inside Gerrit
>> > as well).
>> [...]
>>
>> My only real concern (voiced already with perhaps far less brevity
>> in #openstack-tc) is that we should avoid leaving the impression
>> that software written by "operators" isn't good enough for the
>> openstack/ Git namespace. I want to be sure we remain clear that
>> OpenStack was, and still is, written by its operators/users, not by
>> some separate and nebulous cloud of "developers."
>
> I would love to personally make it live under the openstack/ namespace
> however I do feel like that does make it 'pretty darn official' and the quality
> of the tools there isn't something we probably want to put our name under
> yet.  A lot of it is really old (2+ years old) and it probably needs a
> bit of time
> to get into a state where it's something that we can make official.

Oh, my. No. Just, no.

All software starts out as crap, and most of the stuff running in
production all around the world is still crap to some degree or another
(my own code very much not excluded). The parts that are less crap today
got that way through the efforts of people collaborating to improve them
from the beginning (thank you to everyone who has reviewed my code), not
by waiting until they were "good enough" to share. The tools in the
osops repo are not special in this regard, and we shouldn't treat them
as though they are.

> Personally, I think that repo should be nothing but a 'buffer' between project
> features and tools needed by deployers, a lot of the things there seem to be
> there because of bugs (i.e. orphaned resource cleanup -- which should ideally
> be cleaned up by the service itself or warned there), clean-up disks for deleted
> VMs that were not removed, etc.

That's a great vision. I love the idea of a "sandbox" (or several) for
exploring those sorts of improvements.

>> We already have plenty of repositories under openstack/ which are
>> maintained by SIGs and UC WGs/teams, so not everything there needs
>> to be a deliverable governed by the OpenStack TC anyway. If this
>> really is a collection of software written and maintained by the
>> operators of OpenStack then it should be fine alongside the rest of
>> the official OpenStack software. If it's not, then perhaps calling
>> it the "openstack-operators" organization is... misleading?

My vote is a hard "no" on an openstack-operators/ namespace because I'm
tired of perpetuating the idea that "operators" cannot (or should not)
be "contributors" to openstack/. They *must* be contributors, because
that's the only way open source works over the log term.

-- 
Doug



More information about the openstack-discuss mailing list