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

Support updating from local mirrors #240

Open
bgilbert opened this issue Aug 1, 2019 · 10 comments
Open

Support updating from local mirrors #240

bgilbert opened this issue Aug 1, 2019 · 10 comments
Labels

Comments

@bgilbert
Copy link
Contributor

bgilbert commented Aug 1, 2019

Many Fedora CoreOS nodes will update directly from our Cincinnati server and ostree repo, but there are two other use cases we should support:

  1. Nodes updating from a local mirror on an internal network. The mirror has access to the Internet but the nodes may not.
  2. As above, but the mirror doesn't have Internet access either. Updates are shuttled to the mirror via other means.

We'll need tooling and docs for each.

EDIT(lucab): related but slightly different, #261 covers the "manual updates to air-gapped instances" scenario.

@lucab
Copy link
Contributor

lucab commented Aug 26, 2019

I'm starting to add notes here, so we can more easily collect them into docs.

To use a customized/mirrored updates backend, at least all of the following topics have to be covered:

  1. running an rpm-ostree mirror, and how to mirror/proxy ostree content for our releases
  2. running a Cincinnati backend, and how to mirror/proxy our update-graph
  3. overriding the default repository in rpm-ostree on each node
  4. overriding the default Cincinnati endpoint in Zincati on each node

@cgwalters
Copy link
Member

@3d-pro
Copy link

3d-pro commented Jul 22, 2020

Hi, any updates on this? thanks.

@dustymabe
Copy link
Member

I don't have any updates. Luca may have made some progress on the items he mentioned in #240 (comment). Will let him respond when he gets back.

@bgilbert bgilbert added the jira for syncing to jira label Sep 10, 2020
@dkliban
Copy link

dkliban commented Oct 29, 2020

Pulp (https://pulpproject.org) supports mirroring repositories locally. Pulp also supports exporting repositories to a physical media and then importing them from that media in a disconnected environment. While Pulp does not currently support OSTree repositories, we would like to add OSTree support in the near future. Please file a story at https://pulp.plan.io/issues/new/ outlining the OSTree repository mirroring use case. Having clear use cases will help us plan and execute this effort.

@cverna
Copy link
Member

cverna commented Jun 15, 2021

Linking #812 which should make it easier to support updating from a local registry

@cgwalters
Copy link
Member

As of recently, https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md is the successor to #812

One thing I'd note here is that as of rpm-ostree v2021.14 in Fedora, one can use ex-container encapsulate to mirror from the current production ostree repository into a container image, push that to an internal registry, and have a separate process which de-encapsulates for clients to use as an update source.

But eventually, the goal of coreos layering is that we just update by default from a container image - and that the container-registries config for mirroring just works for OS updates too.

@jlebon
Copy link
Member

jlebon commented Dec 15, 2021

For the subcase where the nodes have access to the Internet, but a local mirror is desired to reduce bandwidth, a simple OSTree strategy is:

  1. On the node doing the mirroring, have a systemd timer + service which does e.g. ostree pull fedora:fedora/x86_64/coreos/stable into an archive repo.
  2. On nodes that want mirrored content, modify the contenturl key of the OSTree remote to point to the archive repo on the mirror. (Or add a separate remote with that modification and rpm-ostree rebase to it.)

(I.e. this is 1 and 3 of #240 (comment))

@buckaroogeek
Copy link

Suggest adding some discussion on the effect of different --depth values

@htcosta
Copy link

htcosta commented Jan 13, 2024

Any update on this ?

Best regards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants