[ops] Restructuring OSOPS tools

Arnaud MORIN arnaud.morin at gmail.com
Tue Sep 1 05:59:33 UTC 2020


Hello,

I also agree with the merging of everything into one repo. When I
discovered those repos, I was surprised that it was split into several
repos.
Keeping a structure with contrib/ folder like Thierry example is the best
imo.

You said it, it will ease discovery of tools, but also maintenance.

Cheers.

Le ven. 28 août 2020 à 12:06, Thierry Carrez <thierry at openstack.org> a
écrit :

> Sean McGinnis wrote:
> > [...]
> > Since these are now owned by an official SIG, we can move this content
> > back under the openstack/ namespace. That should help increase
> > visibility somewhat, and make things look a little more official. It
> > will also allow contributors to tooling to get recognition for
> > contributing to an import part of the OpenStack ecosystem.
> >
> > I do think it's can be a little more difficult to find things spread out
> > over several repos though. For simplicity with finding tooling, as well
> > as watching for reviews and helping with overall maintenance, I would
> > like to move all of these under a common openstack/osops. Under that
> > repo, we can then have a folder structure with tools/logging,
> > tools/monitoring, etc.
>
> Also the original setup[1] called for moving things from one repo to
> another as they get more mature, which loses history. So I agree a
> single repository is better.
>
> However, one benefit of the original setup was that it made it really
> low-friction to land half-baked code in the osops-tools-contrib
> repository. The idea was to encourage tools sharing, rather than judge
> quality or curate a set. I think it's critical for the success of OSops
> that operator code can be brought in with very low friction, and
> curation can happen later.
>
> If we opt for a theme-based directory structure, we could communicate
> that a given tool is in "unmaintained/use-at-your-own-risk" status using
> metadata. But thinking more about it, I would suggest we keep a
> low-friction "contrib/" directory in the repo, which more clearly
> communicates "use at your own risk" for anything within it. Then we
> could move tools under the "tools/" directory structure if a community
> forms within the SIG to support and improve a specific tool. That would
> IMHO allow both low-friction landing *and* curation to happen.
>
> > [...]
> > Please let me know if there are any objects to this plan. Otherwise, I
> > will start cleaning things up and getting it staged in a new repo to be
> > imported as an official repo owned by the SIG.
>
> I like it!
>
> [1] https://wiki.openstack.org/wiki/Osops
>
> --
> Thierry Carrez (ttx)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/b3b5ec8f/attachment-0001.html>


More information about the openstack-discuss mailing list