<walters>
today ostree/rpm-ostree do not natively understand the ad-hoc `tar` format we made up in coreos-assembler. They *do* natively understand "ostree-native containers" and so machines can directly pull from those whether a registry or a local copy of the ociarchive
<dustymabe>
mgrundmann: TL:DR sudo rpm-ostree rebase --experimental ostree-unverified-image:oci-archive:/path/to/ociarchive
<walters>
we don't ship an rpm-ostree release unless this works
<mgrundmann>
nice. i will test that but it looks like it will fit
<mgrundmann>
what aboutt the rebase in there? it ist just needed for the first upgrade?
<dustymabe>
mgrundmann: good question.. walters does this work with `rpm-ostree upgrade` too?
<walters>
yep! after that simply doing `rpm-ostree upgrade` will check the container registry for updates
<dustymabe>
the command I gave above uses a local file
<dustymabe>
can you `rpm-ostree upgrade --experimental ostree-unverified-image:oci-archive:/path/to/ociarchive` ?
<dustymabe>
not really sure there would be any difference with rebase really end result is probably the same
<mgrundmann>
i will try that, thanks
<walters>
The container flow is still (as you might infer from the required `--experimental`) still classified as experimental, but it's never going to eat your machine or anything, we're more reserving the right to change interfaces and CLI arguments and possibly break compatibility with older container images
<walters>
But in order to mark it as stable, we definitely need feedback and testing
<mgrundmann>
that's fine as long as i can still just rebase to an old classic repo
<walters>
you definitely can, see `ostree container unencapsulate` which takes a container image and pulls out the bit-for-bit underlying ostree commit
<mgrundmann>
thanks i can work with that
<lucab>
mgrundmann: if you have some time, we'd be happy to have some more details about your offline-rebasing flow recorded in https://discussion.fedoraproject.org/
jpn has joined #fedora-coreos
<lucab>
mgrundmann: your current one, I mean. We know that we lack in the UX for that, but we don't know where users are drawing the "offline" line
<mgrundmann>
sure
jpn has quit [Ping timeout: 276 seconds]
<mgrundmann>
rebase worked
fifofonix has joined #fedora-coreos
<mgrundmann>
upgrade does not have the --experimental switch
plarsen has joined #fedora-coreos
<walters>
yeah you've already opted-in to this state
fifofonix has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mgrundmann>
makes sense
fifofonix has joined #fedora-coreos
<mgrundmann>
after the rebase rpm-ostree upgrade tries to upgrade from the same file path
<mgrundmann>
exactly what i need
<mgrundmann>
however if i try to "downgrade" after that using rebase i get
<walters>
if you haven't booted into it, just `rpm-ostree cleanup -p`
crobinso has joined #fedora-coreos
<mgrundmann>
i have and cleaned the old entries with cleanup -r
<mgrundmann>
yeah my bad..
jlebon has joined #fedora-coreos
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 256 seconds]
guesswhat has quit [Quit: Client closed]
fifofonix has joined #fedora-coreos
fifofonix has quit [Client Quit]
<ravanelli>
jlebon: dustymabe I have a question about the new ansible setup we have for fedora-infra. I got my name added for the coreos-ci namespace. But I guess this playbook needs to be run again, at least I still can't see the coreos-ci namespace.
<ravanelli>
This leads me to another question, the staging namespace should be also described in these playbooks? Do we already have this namespace around?/
<dustymabe>
ravanelli: I can help!
<dustymabe>
maybe after our next round of meetings
<ravanelli>
dustymabe: Thanks, sure ;)
gursewak has joined #fedora-coreos
jcajka has quit [Quit: Leaving]
<lucab>
dustymabe: https://pagure.io/fedora-infrastructure/issue/10684 we'll migrate coreos-cincinnati to the OCP4 cluster tomorrow. I don't expect downtime and if it happens it isn't really a problem, but do you want me to post this somewhere?
<dustymabe>
lucab: ehh. I think it's OK - but maybe lean on bgilbert for some other input
<dustymabe>
i.e. OK without a coreos-staus post
Betal has joined #fedora-coreos
tormath1 has quit [Quit: leaving]
<lucab>
dustymabe: I think your feedback is enough. It isn't much in advance anyway and not actionable by users (hopefully not even visible to them)
<jlebon>
fyi, i've deleted a bunch of stale webhooks on f-c-c and added a hook for fcos-buildroot
<jlebon>
this after finding out the fcos-buildroot image was over a month old
* dustymabe
still doesn't exactly know what that image is for
<dustymabe>
upstream project CI ?
<jlebon>
yup, CI that needs to actually compile code
<jlebon>
ravanelli: have you started looking at rebasing cosa to f36 yet by chance?
<dustymabe>
we probably need to make a card for that
<dustymabe>
I think it can wait til next week (or even a few weeks even).
<dustymabe>
ravanelli: I do need to get you access to the openshift namespaces - let me look at that now
<jlebon>
dustymabe, ravanelli: if you don't mind I can try doing it now; sadly we still have binding issues between cosa and fcos-buildroot which means we're stuck on the rpm-ostree CI side until they match again (or we disable some tests, but I'd prefer not to do that esp. across a major rebase)
<dustymabe>
jlebon: I don't mind.
<jlebon>
i think we might need a `fcos-buildroot:cosa` image, but easiest would be i think to just coordinate so we bump cosa and fcos at the same time
<dustymabe>
hoping there's no fallout, but that's always the case
<dustymabe>
ehh, I'd prefer not to force binding them because inevitably there's going to be problems