overlay.d/15fcos: add a migration script to move to OCI images #3355
Conversation
To simplify testing for coreos/fedora-coreos-tracker#1823 ship a script to fake the ostree origin to appear like it's on an OCI deployement. Just ship the migration script for now, without the systemd unit, to allow testing.
jbtrystram
changed the title
|
There is at least one missing bit here : I found out that when faking the origin file, |
|
|
||
| motd_path=/run/motd.d/40-fcos-oci-rebase.motd | ||
|
|
||
| cat << EOF > "${motd_path}" |
There was a problem hiding this comment.
I think we should have a separate script that writes out the MOTD and it should run on every boot unless the user has neutered it by touching a stamp file.
There was a problem hiding this comment.
basically we can roll out the MOTD script later (i.e. like a month in to F42 or something).
|
|
||
|
|
||
| # Restart Zincati | ||
| systemctl restart zincati |
There was a problem hiding this comment.
this happening here leads to temporary problems.. basically if there is an update available $now (which I guess is unlikely but could be the case when older systems are jumping through this new barrier we are going to create) then zincati will do it's thing and rpm-ostree will too, but if rpm-ostreed hasn't timed out and deactivated since we wrote the custom origin file then it will complain:
Feb 27 22:01:40 cosa-devsh rpm-ostree[3917]: Txn Deploy on /org/projectatomic/rpmostree1/fedora_coreos failed: Cannot look up version while tracking a container image reference
Maybe we should restart rpm-ostreed here too just to make sure it's picked up the new custom origin?
There was a problem hiding this comment.
Interesting scenario, I didn't thought of that.
This definitely requires more testing in these corner cases.
|
One thing I notice that isn't great is it still says is that expected? |
| booted_imgref=$(rpm-ostree status --json --booted | jq -r '.deployments[0]."container-image-reference"') | ||
|
|
||
| if [ "$booted_imgref" != "null" ]; then | ||
| echo "The booted deployement is already an OCI container." |
There was a problem hiding this comment.
| echo "The booted deployement is already an OCI container." | |
| echo "The booted deployment is already an OCI container." |
|
Also on the system I see a bunch of these messages. Not sure if we can do anything about them: |
| cincinnati_url="https://raw-updates.coreos.fedoraproject.org/v1/graph?basearch=$arch&stream=$stream&oci=true" | ||
| imgref=$(curl "$cincinnati_url" -s | jq --arg VERSION "$version" -r '.nodes[] | select(.version==$VERSION) | .payload') |
There was a problem hiding this comment.
We should make a failure here nonfatal. IIUC the reason for the curl is more cosmetic than anything else (so rpm-ostree status shows something not unexpected), but if it fails for whatever reason I think we should continue the migration.
Things that could cause this to fail could be complicated network environments like proxies, or maybe wifi where the NIC hasn't come up fully yet or something.
to simplify testing for coreos/fedora-coreos-tracker#1823
ship a script to fake the ostree origin to appear like it's on an
OCI deployement.
Just ship the migration script for now, without the systemd unit, to allow testing.