05:59 <aendruk> When I try to launch FCOS on AWS I get this error message: Volume of size 5GB is smaller than snapshot 'snap-0d6c726a0e57536b7', expect size >= 10GB

06:00 <aendruk> Do I really need 10GB for this?

10:04 <travier[m]> Andrew: You need minimum 8GB if I remember correctly for the rootfs so 10GB in total seems reasonable

10:04 <travier[m]> There should be something about that in the docs somewhere

11:07 <lucab> njha: it retries following the common state refresh timing; by default it's 300 seconds (5 mins): https://github.com/coreos/zincati/blob/820e31ec717c3c1173e17126b645f41da936b1d2/dist/config.d/10-agent.toml#L4-L5

11:13 <lucab> njha: by `trust` I think you mean `client authentication`. There are many ways of approaching that, and they depend on the surrounding AAA infra, so the protocol itself does not prescribe anything specific. The lock manager server is usually network-local, yes, but no need to strictly restrict to that. You can also run a local authenticating proxy container on `localhost`, point Zincati config to it, and perform mTLS (or whatever else) through

11:13 <lucab> the container.

11:13 <lucab> njha: some more notes here too: https://github.com/coreos/airlock/issues/7#issuecomment-1288964948

11:17 <lucab> njha: overall, it is also very common for the lock-manager address to be on a separate/overlay network belonging to the cluster orchestration (e.g. k8s cluster networking), so I do expect proxying Zincati fleetlock flow through a container to be a fully reasonable approach.

11:24 <lucab> snaipe: eh well, still feels a bit of feature creep, but if you have a real need for that then why not :)

11:25 <lucab> snaipe: do you feel what we can constrain this only to missing target directories (or existing but completely empty)?

12:27 <dustymabe> lucab: travier[m] - can I get a review on https://github.com/coreos/fedora-coreos-config/pull/2076 and https://github.com/coreos/fedora-coreos-config/pull/2075 ?

12:46 <snaipe> lucab: I'm fine with that. Does it mean skipping if the dir is non-empty, or does it mean forcing "overwrite": true (and rejecting directory entries without it)?

13:19 <lucab> dustymabe: do you want to rebase 2075 and rerun the CI in-between?

13:19 <dustymabe> lucab: yep - once config bot syncs it over I'll rebase and do a push

13:24 <lucab> snaipe: more like: no `overwrite` field at all (at least initially), and directly failing at first-boot if the target path does not meet the allowed cases (missing or empty dir).

13:27 <snaipe> sounds good. I was asking about overwrite because directory entries already have an overwrite property, so the semantics didn't seem clear

13:31 <lucab> snaipe: ah sorry you are right, I forgot about that. Then yes we can hook there. I think it is actually already implementing what I was asking for, without further touches.

13:35 <dustymabe> lucab: rebased!

13:53 <jlebon> o/

14:00 <fifofonix> getting some kind of strange auth message when i do the simplest ostree container rebase.

14:00 <fifofonix> i'm trying: `sudo rpm-ostree rebase --experimental quay.io/fedora/fedora-coreos:testing`

14:00 <fifofonix> returns: reading JSON file "/run/containers/62011/auth.json": open /run/containers/62011/auth.json: permission denied

14:01 <fifofonix> anyone seen this?

14:01 <walters> fifofonix: https://github.com/coreos/rpm-ostree/issues/4107

14:01 <walters> fixed in https://github.com/coreos/rpm-ostree/releases/tag/v2022.15

14:01 <walters> https://bodhi.fedoraproject.org/updates/FEDORA-2022-6fd2fbff80

14:01 <fifofonix> THANKS. Sorry for missing that.

14:05 <walters> Please feel free to test it out with e.g. `rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2022-6fd2fbff80 && rpm-ostree apply-live && systemctl restart rpm-ostreed` or so

14:08 <fifofonix> thanks, i'm finally starting to get my head around some of this and looking forward to playing with it.

14:08 <fifofonix> but i'm going to wait until this fix hits next first. thanks.

14:08 <walters> yep, np

14:10 <jlebon> walters: ahhh, just realized I munged the link to the release when I obsoleted the Bodhi update

14:10 <jlebon> fixing

14:12 <jlebon> ✔️

15:18 <dustymabe> jlebon: here's the 4.9 set of commits from me https://github.com/coreos/coreos-assembler/pull/3186

15:18 <dustymabe> There were a few commits I couldn't backport because mantle/kola changed a lot between 4.9 and 4.10 - i'm thinking i'll workaround needing those changes by adding a hack to the pipeline

15:18 <dustymabe> I didn't test the commits in that PR

15:19 <dustymabe> i'm thinking if you build on top of that PR and open a new PR with the container backports I'll then test them together in the new pipeline

15:23 <dustymabe> WDYT?

15:24 <lucab> dustymabe: I see you saw the s390utils locking fix landed in the latest release. Do you maybe know if the same folks also handle Fedora packaging, or if we should ping somebody else for that for a quicker bump?

15:25 <dustymabe> lucab: from https://src.fedoraproject.org/rpms/s390utils it looks like sharkcz - (he's in #fedora-devel)

15:30 <jlebon> dustymabe: SGTM

15:44 <lucab> dustymabe: ack, I guess a ping won't hurt

20:02 <dustymabe> ravanelli: can I get a review on https://github.com/coreos/coreos-assembler/pull/3187 ?