Closed durandom closed 2 years ago
TBH I find the existince of this repo kind of confusing, can we just merge it with apps
repo, and archive this one? Half the times we have issues being created her, and the other times it's in apps repo.
But I guess apps
is a subproject repo under the purview of the cluster-ops sub-project. And I suppose this repo would be more at the sig level. Do we need such a repo? ¯_(ツ)_/¯
TBH I find the existince of this repo kind of confusing, can we just merge it with apps repo, and archive this one?
Sometimes it's nice to have a place for issues that isn't tied to a particular codebase: e.g. for things like hardware problems ("node X is down due to a failed NIC") or software bugs that aren't directly tied to our YAML manifests ("Grafana bug is causing incorrect rendering of cpu graph"), etc.
Fair enough -- rename to operations
then?
Sure. Or merge SRE
with support
and just call it issues
.
I wonder how this works with peribolos, if I just rename this will it delete the repo and create a new one called operations
? Should I do it manually then send a pr in? @harshad16 do you or anyone else know?
I haven't tried it before but I think we would have to include key previously
.
example:
SRE:
description:
This repo contains all the SRE (Site Reliability Engineering) principles
and guidelines for managing Operate First services
has_projects: false
previously:
- backend
we can try it on a dummy repo and then do it here. like first we create an empty repo test and rename it with this method.
You're right that's what we need to do: https://github.com/kubernetes/test-infra/tree/master/prow/cmd/peribolos#org-configuration
Let's just do it, don't think we need to test it out.
Does the PR require any further signoff and/or testing?
Now that we have sig-operations and one subproject called operations, we could rename this repository to
operations
and free the namesre
toThis is an area that @mmazur brought up in the sig-operations meeting
cc @quaid @jeremyeder @larsks @HumairAK