decomission k8s-staging-txtdirect

[spiffxp]

Broken out from #460

We have a staging project for txtdirect from the days we thought we might use it to implement go.k8s.io. At this point, the nginx-based deployment is continuously deployed and has served us well enough. Meanwhile txtdirect remains unused.

We should no longer host a staging project for it

Things that should be decommissioned:

• the k8s-staging-txtdirect project
• the [email protected] group
• the image promoter manifest
• any associated image pushing jobs

Open questions:

• should the promoter manifests be archived, or deleted?
• will the promoter break if the staging project is deleted?

/sig release
/area release-eng
/wg k8s-infra
/area artifacts
/area groups
/area infra

[ameukam]

cc @stp-ip

[stp-ip]

Ok with this. Still plan on working on it, but that doesn't depend on the staging project being hosted by k8s.
One requirement for k8s infra to use it was it being build or hosted by us, that's why the staging project was done in the first place.

We never formally got a decision on what should or shouldn't be hosted by k8s and txtdirect made or fell into a first attempt, but overall it or probably I failed to get this through into a final decision or written rule.

[spiffxp]

#2806 tries to clarify policy

We've allowed other things to run that aren't necessarily built or owned by us, so I would be fine with seeing a prototype happen that doesn't meet those criteria. I agree that eventually if it becomes mission-critical we want to make sure we own or have visibility into the whole supply chain.

[spiffxp]

/priority important-soon
/milestone v1.23

[spiffxp]

/close
Decomissioned

[k8s-ci-robot]

@spiffxp: Closing this issue.

In response to this:

/close
Decomissioned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.