#69 Design and implement strategy for updating user remote configs
Closed 3 years ago by jlebon. Opened 5 years ago by jlebon.

In https://github.com/ostreedev/ostree/issues/1541, a new remote config was established for the Fedora OSTree repo. I'm filing this on the Silverblue site since it likely emotionally affects Silverblue users the most, but the fix should apply to all OSTree variants. The new config looks something like this:

[remote "fedora"]
url=https://ostree.fedoraproject.org
gpg-verify=true
gpgkeypath=/etc/pki/rpm-gpg
contenturl=mirrorlist=https://ostree.fedoraproject.org/mirrorlist

We now need to figure out a way to update user remotes. Long-term, the plan is to ship this remote config as part of an RPM (see the tracker for this in FCOS: https://github.com/coreos/fedora-coreos-tracker/issues/143).

Current idea is to simply ship a systemd unit that fires on boot to update the remote config if it wasn't modified (which we'll have to determine carefully, since it's written by Anaconda and thus always shows up as "Added" in e.g. ostree admin config-diff). We don't want to touch remote configs that don't point to Fedora's repos.


We don't want to touch remote configs that don't point to Fedora's repos.

I think the most robust way of doing this will be to have a list of sha256sums of remote configs we want to override. If e.g. they've added a comment we still assume we don't touch it.

Basically aim to replace the config only for people who have done ISO installs they haven't touched, plus the AH cloud images.

Thinking more on this, I think we might need both. I.e. ship the remote in an RPM, but also ship code to automatically change configs to use the new remote. I think this will also require kickstart modifications to only delete the Anaconda generated config, and not create a new one as well.

Thinking more on this, I think we might need both. I.e. ship the remote in an RPM, but also ship code to automatically change configs to use the new remote.

I'd rather not. This seems error prone and not something we need to spend time on since everything is already working and this is simply an optimization. New installs will come with the right config by default and upgrades can get updated when people go to rebase and look for instructions.

I think this will also require kickstart modifications to only delete the Anaconda generated config, and not create a new one as well.

yeah. We can remove the part that recreates the remote once we are shipping via rpm.

Why ask our whole user base across all the OSTree variants to type things in when we could fix it for them? At the very least, the checksum approach @walters suggested seems pretty safe and should catch the majority of cases, right?

Oh I see, you're saying it'll fix itself during the f29 -> f30 rebase because that definitely requires manual typing. Hmm, yeah I guess that does help.

yeah more or less plenty other bigger fish to fry and this problem will work itself out eventually even if we don't do anything special here other than the already stated strategy in https://github.com/coreos/fedora-coreos-tracker/issues/143

@dustymabe @jlebon is there anything that is actionable here (in SB' old pagure instance) or was everything moved to github or fixed?

we already ship remote configs via rpm. I think that's probably enough. @jlebon, do you still think we need some migration tool?

$ rpm -ql fedora-repos-ostree-31-1.noarch
/etc/ostree/remotes.d
/etc/ostree/remotes.d/fedora.conf

Yeah, I think we can close this. (I mean, technically there could still be old FSB hosts out there that are using the old remote endpoint from before we RPMized the new one, but I really hope the slow speed will eventually drive them to investigate and rebase to the new remote.)

Metadata Update from @jlebon:
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata