<JamesBelchamber[>
Of interest: I'm currently going through setting up my homelab and as part of it I note that it's quite messy to layer a package with butane. This leads to a more philosophical question, prompted by the documentation notes around this: is rpm-ostree (particularly the layering process) not something the CoreOS people want to use going forward? I ask because it's a key reason I want to use Silverblue/CoreOS 😅 but it would
<JamesBelchamber[>
explain the similar push against using it in Silverblue
<JamesBelchamber[>
(in this instance I'm installing python3 so I can use Ansible against it; I know this is also sort-of considered an anti-pattern with CoreOS)
<JamesBelchamber[>
Interesting. Is the yes in response to it being an anti-pattern then? Or the not wanting to use rpm-ostree going forward?
<walters>
client-side layering was an immense amount of work and is obviously very useful at "small scale" down to single nodes. But certainly if I had a time machine, I would definitely have gone all in on a container-native model from the start...
<JamesBelchamber[>
I'm currently at a large (unwieldingly large) corporate and I reckon layering is how I could set them on the path towards container-native
<JamesBelchamber[>
I appreciate that it might have been a lot of work, mind 😅 and I guess it's frustrating that it can never really cross the line into supporting all RPMs (technically no distro ever does, mind)
<JamesBelchamber[>
What attracts me to using CoreOS over, say, Flatcar. Is the fact that if I can't get something working in a containerised fashion I can just layer it and get 90% of the way there (then we can hack on the hard bit while the rest is happily off out in production)
<JamesBelchamber[>
I'm also kicking up a relative amount of stink around Silverblue and the stigma against layering (in my view it's just fine to layer), but I didn't have the perspective that it's discouraged in CoreOS until today
<nirik>
I just glanced over it and it seems ok, but it's a ton of changes. ;)
<dustymabe>
nirik: yeah that last commit is the bulk of it (yamllint stuff)
<dustymabe>
if you review commit by commit it should be easier
<nirik>
yeah, from a glance it seems ok... but up to you if you want to push it friday. ;)
<dustymabe>
I figure maybe I'll just merge the code and at least get it looking good in staging
<dustymabe>
maybe won't push to prod until monday
<jlebon>
dustymabe: LGTM too. i think we'll find out pretty quick if something breaks or not, so if you're going to test that everything works fine right away after merging, WFM
<dustymabe>
might need some followup PRs since it's hard to test this stuff without merging
<dustymabe>
jlebon: do you think we changed things significantly enough that we should delete and start the project fresh?
<dustymabe>
just to make sure there isn't any cruft left over
<dustymabe>
I think that's at least what I'm going to do in staging first
<jlebon>
dustymabe: hmm, did you forget to `git add` imagestream.yml?
daMaestro has joined #fedora-coreos
Whoop has quit [Quit: upgrades]
<jlebon>
dustymabe: i think the main stale thing is the old buildconfig. so doesn't seem especially necessary?
<nirik>
I have to wander away soon, but if you like I can look later (possibly monday), or you can poke at it.
plarsen has quit [Remote host closed the connection]
<dustymabe>
nirik: i.e. `EgressNetworkPolicy` isn't a thing anymore and we have to use `NetworkPolicy` ?
<nirik>
thats what it looks like, but I might be missing something.
<nirik>
We could ask darknao :)
<dustymabe>
if you look at the running prod cluster
<dustymabe>
what objects exist for this?
<dustymabe>
I haven't touched the running prod cluster, just staging
<nirik>
I'm not sure... I'm trying to finish some other things and then have to head out, so I haven't been able to look closely. This was working in 4.11 and before, but I guess 4.12 will require adjustment...
<dustymabe>
nirik: no worries
<dustymabe>
have a good rest of your day and weekend!
<dustymabe>
i'll do some digging
<nirik>
perhaps it just needs apiVersion: network.operator.openshift.io/v1 ?
<nirik>
not sure.
jpn has joined #fedora-coreos
<dustymabe>
hmm the more I look at it i'm trying to figure out if this egress policy makes sense anyway.. the last rule in the list is to allow everything to "0.0.0.0/0"
ravanelli has quit [Remote host closed the connection]