Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

K8s packages should be hosted on community infra #281

Closed
jbeda opened this issue Mar 12, 2017 · 25 comments
Closed

K8s packages should be hosted on community infra #281

jbeda opened this issue Mar 12, 2017 · 25 comments
Assignees
Labels
area/release-eng Issues or PRs related to the Release Engineering subproject lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. sig/k8s-infra Categorizes an issue or PR as relevant to SIG K8s Infra. sig/release Categorizes an issue or PR as relevant to SIG Release.
Milestone

Comments

@jbeda
Copy link
Contributor

jbeda commented Mar 12, 2017

It is clear the apt repository for the k8s packages are shared with other google repositories.

curl -iL https://apt.kubernetes.io/
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.10.3
Date: Sun, 12 Mar 2017 22:34:01 GMT
Content-Type: text/html
Content-Length: 161
Connection: keep-alive
Location: https://packages.cloud.google.com/apt/

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 302
Content-Type: text/html; charset=utf-8
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
Date: Sun, 12 Mar 2017 22:34:01 GMT


<html>
  <head>
    <title>Directory listing for /apt//</title>
    <base href="/apt//">
  </head>
  <body>
    <h2>Index of /apt//</h2>
    <p></p>
    <a href="dists">dists</a><br />
    <a href="doc">doc</a><br />
    <a href="pool">pool</a><br />
    <a href="src">src</a><br />
  </body>
</html>
@luxas
Copy link
Member

luxas commented Mar 16, 2017

I totally agree @jbeda! We just took the fast route initially with @mikedanese publishing the debs on Google infra

I guess this transition will take some time as it will be a breaking change for consumers.
But we should probably spin up a community (CNCF) hosted infra for both binaries and packages, and gradually move to it during 2017 or so.

Other thoughts @ixdy @timstclair @dankohn @bgrant0607 @thockin?

@thockin
Copy link
Member

thockin commented Mar 16, 2017 via email

@luxas
Copy link
Member

luxas commented Mar 16, 2017

Yup, I know, somebody's gotta pay :)
And it shouldn't go unsaid that I'm really happy Google is paying for it and maintaining it now, making it actually possible for us to publish binaries easily and quickly, but long-term this belongs to the independent foundation.

That's why I pinged Dan on this, I think he has insight into what CNCF can do here.
Also related is the shift from gcr.io/google_containers to something Kubernetes-wide that's maintained by the CNCF: #270

@thockin
Copy link
Member

thockin commented Mar 16, 2017 via email

@dankohn
Copy link

dankohn commented Mar 17, 2017

Just to confirm that CNCF is willing to take on the budget responsibility for this. Our preference would be to have companies that are contributing to Kubernetes continue to fulfill the sysadmin responsibilities, but once it is off Google infrastructure, non-Google sysadmins would be welcome.

Our strong preference would also be for someone from the Kubernetes community to take the lead scoping our requirements, including a budget and transition plan.

@thockin
Copy link
Member

thockin commented Mar 17, 2017 via email

@bgrant0607
Copy link
Member

Like https://github.com/kubernetes/k8s.io, prow, mungegithub, ...

@gtaylor
Copy link

gtaylor commented Apr 21, 2017

I saw some things mentioned about what needs to be done, but they aren't super concrete for me. Does anyone feel comfortable outlining the first few steps in starting this process? Links to examples of related docs that might show how things are done would be especially useful.

@thockin
Copy link
Member

thockin commented Apr 23, 2017 via email

@gtaylor
Copy link

gtaylor commented Apr 23, 2017 via email

@bgrant0607
Copy link
Member

Note that kubernetes-charts and kubernetes-helm are GCP projects to which non-Googlers have access. Maybe we should set up more such projects for relatively independent subprojects.

k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this issue Dec 18, 2017
Automatic merge from submit-queue (batch tested with PRs 54379, 56593, 56685, 54174, 57309). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

Use k8s.gcr.io vanity domain for container images

Related issue: kubernetes/release#281

```release-note
Use "k8s.gcr.io" for container images rather than "gcr.io/google_containers".  This is just a redirect, for now, so should not impact anyone materially.  

Documentation and tools should all convert to the new name. Users should take note of this in case they see this new name in the system.
```
k8s-publishing-bot added a commit to kubernetes/api that referenced this issue Dec 19, 2017
Automatic merge from submit-queue (batch tested with PRs 54379, 56593, 56685, 54174, 57309). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

Use k8s.gcr.io vanity domain for container images

Related issue: kubernetes/release#281

```release-note
Use "k8s.gcr.io" for container images rather than "gcr.io/google_containers".  This is just a redirect, for now, so should not impact anyone materially.

Documentation and tools should all convert to the new name. Users should take note of this in case they see this new name in the system.
```

Kubernetes-commit: e5abffca6f91d42fb5ae97b28fa6683e4244c12b
@dims
Copy link
Member

dims commented Sep 28, 2020

@spiffxp a prereq as being able to sign the artifacts which we don't have a good path for yet

@justaugustus
Copy link
Member

/milestone v1.22
/unassign @tpepper
/priority important-longterm

Part of kubernetes/sig-release#1372.

@k8s-ci-robot k8s-ci-robot added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Jan 20, 2021
@k8s-ci-robot k8s-ci-robot modified the milestones: v1.19, v1.22 Jan 20, 2021
@justaugustus justaugustus removed the priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now. label Jan 23, 2021
@BenTheElder
Copy link
Member

BenTheElder commented Feb 7, 2021

Super late reply but:

What about images that are actually google-specific (e.g. Stackdriver integration ones), should they also use the new domain? Right now all manifests using them are referring to k8s.gcr.io.

We host lots of stuff in the project that involve integration with specific vendor platforms, so I think that's fine.
Managed offerings like GKE should ideally consume images from their own hosting (I believe this is the case there now) though for various reasons, IMHO ...


For the record: While this issue is about the k8s packages, the conversation here veered off into the infra in general. So with that in mind: The wg-k8s-infra effort and SIG Testing, SIG release, etc. have moved many things to community controlled (though much of it google funded and GCP based), infrastructure.

This however is not one of them yet. Unlike GCR this is not a product offering we can "just" pull off migrating to a community controlled but google funded instance of. The package host is ~internal infrastructure meant for hosting official stuff like the gcloud SDK. We'll need to use something else entirely to move it to community control.

This should probably be pretty easy if someone wants to staff it, though the big question is likely that of signing packages, as currently googlers sign them via google's registry ...

Realistically we could probably just do something like docker etc., and create a key for the project and ask people to trust it / import it 🤷‍♂️

@justaugustus
Copy link
Member

(@BenTheElder -- working on a plan for this in 1.21)

@dims
Copy link
Member

dims commented Mar 17, 2021

@spiffxp
Copy link
Member

spiffxp commented Aug 4, 2021

/milestone v1.23

@justaugustus
Copy link
Member

Closing this in favor of #913.
/close

@k8s-ci-robot
Copy link
Contributor

@justaugustus: Closing this issue.

In response to this:

Closing this in favor of #913.
/close

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/release-eng Issues or PRs related to the Release Engineering subproject lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. sig/k8s-infra Categorizes an issue or PR as relevant to SIG K8s Infra. sig/release Categorizes an issue or PR as relevant to SIG Release.
Projects
None yet
Development

No branches or pull requests