[tc][ops] reviving osops- repos
Hi everyone,
So we've realized that we have a few operational tools that we keep around that live all over the place and it would probably be the best for the community to have access to them. I did a bit of research and it looks like the openstack/osops-* repos used to exist between operators to maintain things like this, however, they've gone pretty abandoned over time.
I'd like to pick up this effort and as part of doing that, I'd like to move them into a GitHub organization and rename them out of x/ to make them not seem so .. 'dead'.
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).
There was concern around the idea of using 'openstack' as it's a copyrighted term and a TC discussion was brought up as an idea which makes sense. I'd like to ask if everyone else feels like it's okay so move things into that org and host them there.
Thanks, Mohammed
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."
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?
On Thu, May 30, 2019 at 4:59 PM Jeremy Stanley fungi@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.
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.
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? -- Jeremy Stanley
Mohammed Naser mnaser@vexxhost.com writes:
On Thu, May 30, 2019 at 4:59 PM Jeremy Stanley fungi@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.
On Fri, May 31, 2019 at 07:50:45AM -0400, Doug Hellmann wrote:
: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.
what Doug said!
The most important and perhaps most difficult thing in OpenSource is the bravery to be bad in public. This is why the worst thing in OpenSource is shaming people for being bad in public.
The internet has no end of my "dumb" questions and "stupid" statements and virtually everything I know about software and operations is because of them.
So let's dare to be bad :)
-Jon
On Fri, May 31, 2019 at 8:35 AM Jonathan D. Proulx jon@csail.mit.edu wrote:
On Fri, May 31, 2019 at 07:50:45AM -0400, Doug Hellmann wrote:
: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.
what Doug said!
The most important and perhaps most difficult thing in OpenSource is the bravery to be bad in public. This is why the worst thing in OpenSource is shaming people for being bad in public.
That sounds fair. It seems there is significant thoughts from within the community that this should continue to live under the openstack/ namespace.
How do we make this happen then? I'm struggling to find the correct platform to put this under in order to make this live under openstack/
The internet has no end of my "dumb" questions and "stupid" statements and virtually everything I know about software and operations is because of them.
So let's dare to be bad :)
-Jon
Mohammed Naser mnaser@vexxhost.com writes:
On Fri, May 31, 2019 at 8:35 AM Jonathan D. Proulx jon@csail.mit.edu wrote:
On Fri, May 31, 2019 at 07:50:45AM -0400, Doug Hellmann wrote:
: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.
what Doug said!
The most important and perhaps most difficult thing in OpenSource is the bravery to be bad in public. This is why the worst thing in OpenSource is shaming people for being bad in public.
That sounds fair. It seems there is significant thoughts from within the community that this should continue to live under the openstack/ namespace.
How do we make this happen then? I'm struggling to find the correct platform to put this under in order to make this live under openstack/
What part is hard, defining an owner?
On Fri., May 31, 2019, 9:49 a.m. Doug Hellmann, doug@doughellmann.com wrote:
Mohammed Naser mnaser@vexxhost.com writes:
On Fri, May 31, 2019 at 8:35 AM Jonathan D. Proulx jon@csail.mit.edu
wrote:
On Fri, May 31, 2019 at 07:50:45AM -0400, Doug Hellmann wrote:
: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.
what Doug said!
The most important and perhaps most difficult thing in OpenSource is the bravery to be bad in public. This is why the worst thing in OpenSource is shaming people for being bad in public.
That sounds fair. It seems there is significant thoughts from within the community that this should continue to live under the openstack/ namespace.
How do we make this happen then? I'm struggling to find the correct
platform to
put this under in order to make this live under openstack/
What part is hard, defining an owner?
Yes. A SIG? A WG?
I'm not sure where to put it under to make it official under OpenStack namespace.
I'm happy to hear suggestions
On May 31, 2019, at 9:52 AM, Mohammed Naser mnaser@vexxhost.com wrote:
On Fri., May 31, 2019, 9:49 a.m. Doug Hellmann, <doug@doughellmann.com mailto:doug@doughellmann.com> wrote: Mohammed Naser <mnaser@vexxhost.com mailto:mnaser@vexxhost.com> writes:
On Fri, May 31, 2019 at 8:35 AM Jonathan D. Proulx <jon@csail.mit.edu mailto:jon@csail.mit.edu> wrote:
On Fri, May 31, 2019 at 07:50:45AM -0400, Doug Hellmann wrote:
: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.
what Doug said!
The most important and perhaps most difficult thing in OpenSource is the bravery to be bad in public. This is why the worst thing in OpenSource is shaming people for being bad in public.
That sounds fair. It seems there is significant thoughts from within the community that this should continue to live under the openstack/ namespace.
How do we make this happen then? I'm struggling to find the correct platform to put this under in order to make this live under openstack/
What part is hard, defining an owner?
Yes. A SIG? A WG?
I thought we had converted everything that wasn’t a Board working group to a SIG. A SIG seems appropriate for this, in any case.
Doug
I'm not sure where to put it under to make it official under OpenStack namespace.
I'm happy to hear suggestions
-- Doug
On Fri, May 31, 2019 at 9:54 AM Mohammed Naser mnaser@vexxhost.com wrote:
On Fri., May 31, 2019, 9:49 a.m. Doug Hellmann, doug@doughellmann.com wrote:
Mohammed Naser mnaser@vexxhost.com writes:
On Fri, May 31, 2019 at 8:35 AM Jonathan D. Proulx jon@csail.mit.edu wrote:
On Fri, May 31, 2019 at 07:50:45AM -0400, Doug Hellmann wrote:
: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.
what Doug said!
The most important and perhaps most difficult thing in OpenSource is the bravery to be bad in public. This is why the worst thing in OpenSource is shaming people for being bad in public.
That sounds fair. It seems there is significant thoughts from within the community that this should continue to live under the openstack/ namespace.
How do we make this happen then? I'm struggling to find the correct platform to put this under in order to make this live under openstack/
What part is hard, defining an owner?
Yes. A SIG? A WG?
I'm not sure where to put it under to make it official under OpenStack namespace.
I'm happy to hear suggestions
Back in the old days (*shakes cane at you kids on his lawn*) when these repos were started, there really weren't WGs or SIGs. There were projects. So there's a project [1].
So either: A) Make a SIG out of that and assign the repos to the sig, or B) Maybe add it under / rename the Ops Docs SIG [2] as it might bring more eyes to both things which serve the same folks.
I personally don't care about the location for the sake of feeling "included." A repo is a repo to me. However, from a marketing standpoint, I think having it in openstack/ would increase the visibility and garner both more contributors and users.
We currently talk about Ops Docs things during the Ops Meetup team meeting on Tuesdays at 10am EDT (15:00 UTC), so if anyone would like to discuss this as an agenda item during that meeting I can add it to the agenda. Let me know if there's interest.
[1] https://wiki.openstack.org/wiki/Osops [2] https://wiki.openstack.org/wiki/Operation_Docs_SIG
-Erik
-- Doug
On 2019-05-31 10:24:36 -0400 (-0400), Erik McCormick wrote: [...]
there's a project [1].
So either: A) Make a SIG out of that and assign the repos to the sig, or B) Maybe add it under / rename the Ops Docs SIG [2] as it might bring more eyes to both things which serve the same folks.
[...]
I'd also be perfectly fine with C) say that it's being vouched for by the UC through its Osops project, stick these repos in a list *somewhere* as a durable record of that, and let decisions about project vs. SIG decision be independent of the repository naming decision.
I came to this thread late, but I'm very glad for the clarity brought to the discussion. Yes, yes, yes, leave this in openstack. Yes, operators wrote/write/will write OpenStack (but yes, also, there are full-time devels that never run an openstack for others. I'm not sure anyone is arguing against that.) Yes, this occurred well before the emergence of SIGs and maybe that ownership question is a valid concern. Who has commit/+2 rights to this repo once it exists (again). I don't have a stake in this game but maybe there should be a poll somewhere originating in openstack.org that goes out and queries anyone registered with openstack.org to find out if a) they are still involved b) if they self identify as an operator c) if they self identify are they interested in joining a SIG focused on ops.
OpenStack operators are already having some trouble reaching/contacting/keeping involved other operators. Anything we can do to unite in force will be a good thing. -dave "med" medberry
Jeremy Stanley wrote:
On 2019-05-31 10:24:36 -0400 (-0400), Erik McCormick wrote: [...]
there's a project [1].
So either: A) Make a SIG out of that and assign the repos to the sig, or B) Maybe add it under / rename the Ops Docs SIG [2] as it might bring more eyes to both things which serve the same folks.
[...]
I'd also be perfectly fine with C) say that it's being vouched for by the UC through its Osops project, stick these repos in a list *somewhere* as a durable record of that, and let decisions about project vs. SIG decision be independent of the repository naming decision.
+2 to keep it under the openstack/ namespace one way or another.
As to what construct should "own" it, the closest thing we have that would match history would be a UC "team"[1] or "working group"[2], both of which have repositories defined in [3].
Alternatively, I feel like a SIG (be it the Ops Docs SIG or a new "Operational tooling" SIG) would totally be a good idea to revive this. In that case we'd define the repository in [4].
My personal preference would be for a new SIG, but whoever is signing up to work on this should definitely have the final say.
[1] https://opendev.org/openstack/governance-uc/src/branch/master/reference/team... [2] https://opendev.org/openstack/governance-uc/src/branch/master/reference/work... [3] https://opendev.org/openstack/governance/src/branch/master/reference/user-co... [4] https://opendev.org/openstack/governance/src/branch/master/reference/sigs-re...
Alternatively, I feel like a SIG (be it the Ops Docs SIG or a new "Operational tooling" SIG) would totally be a good idea to revive this. In that case we'd define the repository in [4].
My personal preference would be for a new SIG, but whoever is signing up to work on this should definitely have the final say.
Agreed on having it inside OpenStack namespace, and code handled by a team/SIG/WG (with my preference being a SIG -- existing or not). When this team/SIG/WG retires, the repo would with it. It provides clean ownership, and clear cleanup when disbanding.
Regards, Jean-Philippe Evrard (evrardjp)
On 11/06/2019 13.55, Jean-Philippe Evrard wrote:
Alternatively, I feel like a SIG (be it the Ops Docs SIG or a new "Operational tooling" SIG) would totally be a good idea to revive this. In that case we'd define the repository in [4].
My personal preference would be for a new SIG, but whoever is signing up to work on this should definitely have the final say.
Agreed on having it inside OpenStack namespace, and code handled by a team/SIG/WG (with my preference being a SIG -- existing or not). When this team/SIG/WG retires, the repo would with it. It provides clean ownership, and clear cleanup when disbanding.
Mohammed, is that consensus and actionable?
Could you then update https://review.opendev.org/#/c/662300/ to reflect this, please?
Andreas
On 2019-05-31 07:50:45 -0400 (-0400), Doug Hellmann wrote: [...]
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.
As I said in my previous post, OpenStack was built by its operators and continues to be maintained by them. That there are some in our midst who feel separate from and disenfranchised by the process through which OpenStack is developed is disappointing, but I don't believe they are representative of OpenStack operators as a whole. I would further argue that operators of OpenStack are and have always been its primary contributors. Following the true spirit of open source, operators got together and built automation they needed to make their jobs easier (or even possible).
To me a key signal of this heritage was the early choice to standardize on Python, a runtime-interpreted scripting language enforcing readability, historically used by operators for automating systems administration tasks. This was almost certainly not a coincidence. Find a bug? You can read the source code right there on the server's filesystem, modify it in place, test that it's fixed without having to manually recompile anything, and then share the solution with the community. (Tweaking software in production is of course usually not the *best* way to fix bugs, but when you're in a tight spot because it's 3am and customers are blowing up the support line and your pager won't shut up, it's attractive and expedient.)
We should celebrate this heritage, and always remind ourselves that OpenStack emerged out of a shared desire for operational automation. To assume that operators are not the people making OpenStack day in and day out is to discredit the work we all do. "Operators" aren't some separate set of people from "developers." Operators are us.
participants (9)
-
Andreas Jaeger
-
David Medberry
-
Doug Hellmann
-
Erik McCormick
-
Jean-Philippe Evrard
-
Jeremy Stanley
-
Jonathan D. Proulx
-
Mohammed Naser
-
Thierry Carrez