ravanelli has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
ravanelli has quit [Ping timeout: 256 seconds]
ravanelli has joined #fedora-coreos
jpn has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
jpn has quit [Ping timeout: 260 seconds]
ravanelli has joined #fedora-coreos
mnguyen has quit [Ping timeout: 260 seconds]
ravanelli has quit [Remote host closed the connection]
hotbox has quit [Ping timeout: 260 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 260 seconds]
jpn has joined #fedora-coreos
gursewak has joined #fedora-coreos
jpn has quit [Ping timeout: 256 seconds]
b1000s has joined #fedora-coreos
paragan has joined #fedora-coreos
rishi` has joined #fedora-coreos
rishi has quit [Ping timeout: 260 seconds]
hotbox has joined #fedora-coreos
b1000s has quit [Remote host closed the connection]
b1000s has joined #fedora-coreos
saschagrunert has joined #fedora-coreos
Betal has quit [Quit: WeeChat 3.7.1]
jpn has joined #fedora-coreos
Gentoli[m] has quit [Quit: You have been kicked for being idle]
c4rt0 has joined #fedora-coreos
b1000s has quit [Ping timeout: 260 seconds]
bytehackr has joined #fedora-coreos
b1000s has joined #fedora-coreos
b1000s has quit [Ping timeout: 260 seconds]
fifofonix has joined #fedora-coreos
c4rt0 has quit [Remote host closed the connection]
jpn has quit [Ping timeout: 268 seconds]
saschagrunert has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
jpn has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
b1000s has joined #fedora-coreos
mnguyen has joined #fedora-coreos
b100s has joined #fedora-coreos
b1000s has quit [Ping timeout: 256 seconds]
bytehackr has quit [Quit: Leaving]
vgoyal has joined #fedora-coreos
c4rt0 has joined #fedora-coreos
c4rt0_ has joined #fedora-coreos
b100s has quit [Ping timeout: 268 seconds]
jpn has quit [Ping timeout: 260 seconds]
<fifofonix>
wanted to seek some clarification on rpm-ostree / ostree native container behaviour.
<fifofonix>
if i layer a pacakge via rpm-ostree (eg. open-vm-tools) and then an auto-os upgrade happens, it is re-layered, with potentially a newer rpm version, right?
ravanelli has quit [Remote host closed the connection]
jpn has joined #fedora-coreos
nalind has joined #fedora-coreos
plarsen has joined #fedora-coreos
<walters>
fifofonix: You're asking about where the origin is a container, but you're still doing client side layering?
<walters>
If so, then yes - basically everything that works with "native ostree" *continues to work* with the container flow, and that was done very intentionally
<fifofonix>
well, first i want to confirm my undertstanding with rpm-ostree and then i wanted to extend questioning to ostree native.
<walters>
If you have a bunch of servers for which you want to use a standard "base image", except one gateway machine needs some extra VPN software, if you want you can client-side layer on just that one machine (or, you can build a derived image from the base...both work!)
mheon has joined #fedora-coreos
<fifofonix>
so, the end question, is if i'm rebasing to ostree container image and that has a tag 1.0....and then that image changes on the registry....do i get the new 1.0 applied on the next os upgrade?
<walters>
yes
<fifofonix>
that's awesome. perhaps this is obvious but i couldn't figure this out from the documentation.
<fifofonix>
yes, it is parity with rpm-ostree layering behaviour (which is great). i think i'm going to try and create an fcos-gpu ostree native.
<fifofonix>
but i guess it would really be a fedora-gpu (not just fcos)
<walters>
Yeah...this is such a large fundamental change that I'm thinking it calls for a rebranding and entire refresh...basically what I'm thinking now is rpm-ostree → "dnf image" and ostree → bootc
<walters>
the latter is started in https://github.com/ostreedev/ostree-rs-ext/pull/412 and if you dig in there are only a few very simple commands; no rpm stuff, no policykit, no daemon actually, no local kernel args...just upgrade to and switch between bootable container images (and we probably want local rollback)
<fifofonix>
that's very interesting. i thought i was just beginning to understand this but now i think my mind has been blown again.
<walters>
😃
<fifofonix>
so, i've switched one of my hosts to ostree-unverified-registry:quay.io/fedora/fedora-coreos:next. now, for me to get another next update do you need to updated the quay image, or is that just a layer of nothing, so there is no work on your side?
<fifofonix>
i'm confused in this case whether i'm still tracking real next, or whether i'm really tracking whatever the latest quay.io image is.
<walters>
the idea is these containers are exactly in sync with the ostree repository and hence have the same behavior as systems which are fetching via ostree today
<walters>
so yes when there's a new fcos next build, that tag will be updated
<fifofonix>
ok mental model reformulated (again). so, we expect zincati to poll quay.io for updates? (i am just looking at zincati logs on rebased ostree container machine and it seems to be failing - something to do with coreos-assembler.basearch.
<fifofonix>
ok. wow. so, experimental for now with updates triggered by new rpm-ostree rebase but auto-updates coming. awesome.
<walters>
you can turn off zincati and directly `rpm-ostree upgrade` today
<fifofonix>
understood. this is just so amazing. thanks for all the hard work taking this all to the next level.
<fifofonix>
post my mental reset i realize the oci container image i would be creating really is fcos-next-gpu or similar (can't do it for fedora-gpu generically because this is not a means to actually create an rpm-like layer. it also defines the base os. correct?
<walters>
yes; what you build works the same as any other OCI container today. *However*...nothing really stops us from adding support for "dynamic linking" in the future