Scarf Proposal #6667
Scarf Proposal #6667
Conversation
|
Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it. 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. |
jetstack-bot
added
dco-signoff: no
davidnoyes
force-pushed
the
proposal/scarf
branch
from
1d30657
to
57d2d91
Compare
jetstack-bot
added
dco-signoff: yes
design/20240122.scarf.md
Outdated
|
|
||
| ## Summary | ||
|
|
||
| With our focus on CNCF graduation, CNCF aims for its projects to become vendor-neutral wherever possible. The cert-manager project should uphold this aim. In doing so, it will need to take a further step to move on from its proud Jetstack legacy with a change to remove Jetstack from the container image repository name. Recently partnered with the Linux Foundation, Scarf is a service designed for open-source projects that will allow us to perform this migration seamlessly. In addition, Scarf will provide the benefit of not being tied to a single container image/binary repository vendor, giving us the freedom to change vendors and continue to provide container images seamlessly while still maintaining observability of how the project is downloaded. |
There was a problem hiding this comment.
Extra improvement: Additional to removing the jetstack name, we will also remove the quay.io name and switch to a more neutral domain (eg. cert-manager.io).
|
👍 LGTM |
|
After reading the document, my takeways are:
I have a few questions:
|
Signed-off-by: David Noyes <david.noyes@venafi.com>
Signed-off-by: David Noyes <david.noyes@venafi.com>
|
|
Hi, just wanted to leave a quick note here as well are just pointing out a couple of other CNCF projects that are utilizing Scarf:
Also, that Scarf is building a formal partnership with the Linux Foundation (and all of its subsidiary organizations, like the CNCF), and is now listed on this list of partners here: https://www.linuxfoundation.org/projects/partnerships |
|
We discussed this proposal during the bi-weekly development meeting: https://docs.google.com/document/d/1Tc5t6ylY9dhXAan1OjOoldeaoys1Yh4Ir710ATfBa5U/edit#bookmark=id.cn5lnyf8y3oh I think that the PR can be merged based on that conversation. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: inteon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
jetstack-bot
added
the
approved
|
|
||
| With our focus on CNCF graduation, CNCF aims for its projects to become [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) wherever possible. The cert-manager project should uphold this aim. In doing so, it will need to take a further step to move on from its proud Jetstack legacy with a change to remove Jetstack from the container image repository name. | ||
|
|
||
| In addition, Quay.io, the current container image registry for cert-manager, has limitations on the amount of analytic data it can provide due to the high volume of downloads that cert-manager receives. The cert-manager maintainers have also found that Quay has had several outages during 2023, and they want to manage that situation quickly in the future if required. |
There was a problem hiding this comment.
scarf.sh also seems to have had several outages during 2023
But there's no record of these on their uptime history page AFAICS:
There was a problem hiding this comment.
Hi @wallrj , just chiming in here, the Scarf team is working to backfill those incidents and they should be up shortly. We will comment again to update when finished.
There was a problem hiding this comment.
Thanks Melanie. I should also have linked to this issue:
There was a problem hiding this comment.
@wallrj scarf-sh/gateway#26 has been updated. We've officially switched over our status page provider and backfilled the incident reports for the Gateway.
|
|
||
| With our focus on CNCF graduation, CNCF aims for its projects to become [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) wherever possible. The cert-manager project should uphold this aim. In doing so, it will need to take a further step to move on from its proud Jetstack legacy with a change to remove Jetstack from the container image repository name. | ||
|
|
||
| In addition, Quay.io, the current container image registry for cert-manager, has limitations on the amount of analytic data it can provide due to the high volume of downloads that cert-manager receives. The cert-manager maintainers have also found that Quay has had several outages during 2023, and they want to manage that situation quickly in the future if required. |
There was a problem hiding this comment.
Are there any limitations to the analytic data provided by Scarf?
For example, their documentation says that data export is only available if you are on a paid plan:
There was a problem hiding this comment.
Currently, the ability to export data is only available in Scarf's paid subscriptions. Otherwise, you will have access to software downloads by location, operating system, version, cloud provider, container runtimes, and referral source. As well as, documentation views by company, location, and pages that are most visited using our super lightweight pixel that has no cookies or javascript.
| Any users downloading from secure environments with limited internet connections through firewall restrictions will need to add "allowed" rules for the Scarf gateway domain in addition to any existing rules for the image repository, such as quay.io. These should be clearly documented. | ||
|
|
||
| ### Known issues/limitations | ||
| - Currently, the Scarf service only allows for custom domains and doesn't include custom paths. When speaking with members of the Scarf organisation, this is due to a technical limitation as the path is used in the image identification/verification process. Scarf is investigating a workaround; however, we may need to consider an additional hosting location/service to allow us to remove "jetstack" from the download path. An additional hosting location will increase existing maintenance and deployment process overheads. |
There was a problem hiding this comment.
Risks
Some risks which we should consider.
-
Outages of the gateway service:
-
Ad Blocking software blocking the scarf proxy (and vanity domains that use the scarf CNAME)
|
|
||
| ## Summary | ||
|
|
||
| With our focus on CNCF graduation, CNCF aims for its projects to become [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) wherever possible. The cert-manager project should uphold this aim. In doing so, it will need to take a further step to move on from its proud Jetstack legacy with a change to remove Jetstack from the container image repository name. |
There was a problem hiding this comment.
Scarf.sh does not solve this problem, as explained in the "known issues/limitations" section below.
Currently, the Scarf service only allows for custom domains and doesn't include custom paths.
The word Jetstack is in the path, not the domain: quay.io/jetstack/cert-manager-controller.
The simplest solution to this problem is to publish the images to quay.io/cert-manager/cert-manager-controller,
which we now have the ability to do.
There was a problem hiding this comment.
I agree. The design reads like the number one benefit is to "become vendor neutral", but we have established that Scarf isn't required for that. I suggest that we don't mention this benefit in the design document at all.
The number one benefit that would justify Scarf's adoption, to me, being able for maintainers to know each version's adoption... and also being able to show a daily number of downloads at events like KubeCon.
A proposal to use Scarf as a gateway for binary and container image downloads.