<theh>
Inside an autocmd (BufReadPost) I'm trying to access vim.bo.filetype from within a callback. This returns an empty string, as if the filetype is not yet set. Any idea why?
plarsen has joined #fedora-coreos
mnguyen has joined #fedora-coreos
<MTRNord[m]>
Hi I may be missing something but if I were to change my config of a system deployed with coreos how would I do that? Would I redeploy it using coreos-installer, would I need to change it somewhere on the FS or do I just directly interact with the system itself? :)
<MTRNord[m]>
as in if I would like to change the butane config
<MTRNord[m]>
(directly interact meaning rpm-ostree)
<walters>
Specifically, you build and deploy a container with your configs, and when you change the configs, those changes propagate transactionally, offline and with rollback in the same way OS updates do.
* MTRNord[m]
takes a look and sees how I might nicely integrate this into my setup :)
<walters>
But, it's still very useful to be sure you can fully reprovision for many reasons.
mheon has joined #fedora-coreos
<MTRNord[m]>
yeah :) I will try to keep things within the butane file for that reason.
<MTRNord[m]>
Tbh I am not yet sure if I even need this or if I can live with just having it deployed once, use the auto updates and then update the butane as required to reflect reality. I am currently still figuring out what the best approach for my setup is :)
<dustymabe>
travier[m]: yeah, we need to consider the increase boot option, but that is probably going to be a decent amount of work
<travier[m]>
agree
<travier[m]>
but we'll need it at some point
<dustymabe>
was hoping for some shorter path to victory (considering we are manually updating our PPC64LE builders now)
<jlebon>
dustymabe: i'm not sure i follow the 'the same problem of "staged update today but not going to reboot to apply until saturday"' part. are you referring that you wouldn't find out there's an issue until saturday?
<travier[m]>
I don't see the kernel or the initrd getting smaller over time and we'll need to have a new default size at some point
<dustymabe>
travier[m]: have faith in new compression technologies :)
<travier[m]>
:D
<dustymabe>
jlebon: you brought it up: jlebon | doing it in zincati would be worse because it increases the window between the point of no return and finding out the deployment you're on is broken
<travier[m]>
that are not going to be implemented on ppc64le? :p
<dustymabe>
:)
<jlebon>
dustymabe: ahh, the window i was talking about there is different
<dustymabe>
at least not for the kernel, maybe the initrd
<travier[m]>
For ppc64le, it's a new arch, we should set a bigger default as a temporary measure while we figure out how to announce / bump the size for everybody else
<jlebon>
to your concern, zincati could do this "cleanup rollback" just before starting the reboot
<dustymabe>
jlebon: so the kernel/initrd aren't put in place in /boot until finalize-staged ?
<dustymabe>
jlebon: right, which is why I think we should make this opportunistic
<jlebon>
and i guess zincati could do a naive space check too
<jlebon>
it wouldn't be as good as what libostree could do, but still pretty close
<jlebon>
dustymabe: let me post in the issue and we can see what people think
<dustymabe>
i.e. if space is low, copy rollback kernel/initrd into RAM or something - then try the finalize - if succeed then yay - if fail then try to copy it back from RAM
<dustymabe>
but if space isn't low - we don't do the extra (risky) part
<jlebon>
yeah, unless it triggers finalization manually, which reintroduces /etc races. honestly though, i think just naively checking and pruning the rollback would be enough for now.
<jlebon>
checking the space left*
<jlebon>
i think the complexity with libostree is handling of ENOSPC at the last minute, but maybe space calculations up front would be good enough
ravanelli has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
<dustymabe>
jlebon: i'm going to merge the azure library updates PRs after I get back from lunch and update the secrets in the two pipelines - LMK if that's not good
<jlebon>
dustymabe: SGTM
aaradhak has quit [Quit: Connection closed for inactivity]
ravanelli has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
jpn has quit [Ping timeout: 255 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 255 seconds]
<travier[m]>
<dustymabe> "travier: did you make any..." <- I have not been working on that
<baude>
bgilbert, did you have a chance to review the altered approach on the ignition PR? Was it more inline with what you had in mind?
<bgilbert>
baude: skimmed it quickly just now; will reply in more detail later. it's closer, yeah
<baude>
how bout the other one ?
<bgilbert>
baude: I'd tend to think that key reassembly should go in Ignition, since it's not something that most KVP users should do, and Ignition is the one defining how keys should be broken up
<baude>
bgilbert, actually jason and i wanted the splice and dice NOT in ignition on purpose
<baude>
we have other plans there
<bgilbert>
oh?
<bgilbert>
more details would be helpful. that's the sort of thing I don't think we'd normally want to delegate to a library
<bgilbert>
re the cosa PR, it still says "Add hyperV support to cosa including". sorry for nitpicking this, but that suggests that we've comprehensively done something that we have not
<baude>
then i dont know what you are asking for
<baude>
bgilbert, on the slice and dice, i cannot speak to what Jason has plans for .... but the generic fcos utility for messing with kvps will come from that library
<bgilbert>
"generic fcos utility for messing with kvps"?
<baude>
you asked for a powershell utility for those not using podman machine
<baude>
it aint going to be powershell, it willi be a nice golang cli
<baude>
from libhvee
<baude>
all that work is done
<baude>
(more or less)
<bgilbert>
who's going to be responsible for releasing and packaging it?
<baude>
packaging it for what
<bgilbert>
well, I guess just releasing it
<baude>
you mean like cutting releases and putting the binaries on gh?
<bgilbert>
and signing them
<baude>
is it wrong to say libhvee maintainers?
<bgilbert>
who are they? :-) the containers team?
<baude>
well jason and i rn
<baude>
i am happy to also add you
<baude>
or a gh team
<baude>
but those cmds we built are kind of important for development as well, so they are handy as hell for libhvee
<bgilbert>
so that I understand the options, is it physically possible to do as a PowerShell script?
<baude>
we could stub something more specific for ignition too
<baude>
i dont know for sure
<baude>
i would not feel comfy doing it in powershell
<bgilbert>
yeah, it's awkward
<baude>
it requires some job control whichi think we can do
<baude>
again, we could make a util specific for ignition, in ignition if you prefer
<bgilbert>
let me think on this one some more and I'll follow up in the PR
<baude>
that just does load_ignition.exe <vm_name> path_to_igntiion_file ?
<baude>
sure
<bgilbert>
re the cosa one, for example the PR isn't adding the hyperv image to the release metadata
<bgilbert>
so there'll be more work to do on the cosa side
<bgilbert>
so the commit shouldn't claim to have done all the work. that's all.
<bgilbert>
"add support for building hyperv images" is the general vibe I'm going for
<baude>
oh you want the commit message to be more generic? ok
<baude>
sure i can fixer that up, happy to
<bgilbert>
less generic, more specific to the work actually done
<bgilbert>
I could also just write some text rather than complaining here, if you'd prefer :-)
<baude>
sure man
<baude>
bgilbert, also for the metadata, is that something you want me doing? or is that too close skynet to let humans in ?>
klaas has quit [Read error: Connection reset by peer]
<bgilbert>
it's a good question. contributions welcome, but that does get to the annoying plumbing part
<bgilbert>
we have a checklist in place, we should probably create an issue from it
<bgilbert>
mostly. your PR doesn't enable release metadata yet, which I don't think it can do until stream-metadata-go has been updated
<bgilbert>
in cmd-generate-release-meta
klaas has joined #fedora-coreos
<baude>
ok so how does this checklist thing work ... do i click on the stuff as it merges? as it is pr'd? or is all that in comments or ?
<baude>
also is this a Cloud Image by definition or ?
<bgilbert>
the development section says "create PRs addressing the following", so I'd say you can check boxes when the PRs go up
<bgilbert>
this is not a cloud image
<baude>
++
<baude>
yeah, ill give it a go if you dont mind the questions here and there and there and there
<baude>
also, hopefully not out of line here, but welcome to the org/dept
<bgilbert>
+1, sounds good!
<bgilbert>
heh, thanks
<baude>
i might be on the record saying if they bring more good people into the dept i am going to have to start a "jacket" on everyone so i know how to compete with them and dig up all the useful leverage information
<bgilbert>
(for others in the channel, I'm not personally moving, the team had its reporting chain shuffled a bit)
<baude>
like dustymabe and his evili basement which you just know has "things" going on it just outside of camera angles
<baude>
dustymabe, you are not responding to me are you ?
<baude>
bgilbert, is this a cosa generate-release-meta involved thing ?>
<bgilbert>
baude: the dates and versions and hashes are made up in the example schema, yes
<baude>
ok
<baude>
bgilbert, you agree for vhdx to use zip or xz ?
<bgilbert>
oh, that's interesting
<bgilbert>
I haven't looked at vhdx. if it's a single uncompressed file, we should use xz
<baude>
does windows handle xz natively ?
<bgilbert>
oh
<baude>
i didnt think so
<bgilbert>
that's a complication
<dustymabe>
baude: i haven't read the scrollback - anything in particular I need to respond to? sorry i'm trying to finish up some things before I go PTO
<baude>
dustymabe, no i just got crosswised up with ya
Turnikov has quit [Ping timeout: 255 seconds]
<bgilbert>
baude: I think it'll probably need to be zip, which will require another cosa change, and also consensus
<bgilbert>
I'll throw a comment in the tracker PR
<bgilbert>
thanks for noticing that
<bgilbert>
*tracker issue
<baude>
for cosa compression ?
<bgilbert>
yeah
<bgilbert>
cmd-compress
<baude>
ok, i'll try to hunt that down tomorrow
<baude>
yup
<bgilbert>
+1
<baude>
i tried to use the compression and ended up with xz which windows just blinked at me about
<bgilbert>
right
Turnikov has joined #fedora-coreos
<marmijo[m]>
dustymabe: looking
<bgilbert>
dustymabe: thanks for adding the meeting label, it does seem overdue
<bgilbert>
(to 1411)
<walters>
(only tangentally looking but I think anywhere nowadays xz can be used is probably better as zstd)
<walters>
maybe it will prove to be the last word^Hletter in compression
<dustymabe>
walters: yeah, we should probably pursue at some point switching to zstd for the artifacts we can
<dustymabe>
bgilbert: yeah, for some reason I thought it was already there but it obviously wasn't on the agenda today
<bgilbert>
dustymabe: right
<bgilbert>
walters: I think xz -9 is still tighter than zstd -19 in general?
<dustymabe>
marmijo[m]: i see a new force push - did you use the tool?
<bgilbert>
anyway, for now the question is consistency vs. usability
<dustymabe>
if you are in the f-c-c repo just run ./ci/overrides.py --help
<marmijo[m]>
I see, I missed that. I went straight to the PR and didnt read the follow up messages.
<dustymabe>
marmijo[m]: no worries
<dustymabe>
marmijo[m]: the next step after we get the packages pinned is to open a bugzilla against selinux so we can get the maintainers to take a look - it will be good when we do that to include the logs (AVC denials) from when selinux is in permissive mode (so we capture them all)
<dustymabe>
jlebon: can you help him with that tomorrow if he needs help opening the bug?
<jlebon>
dustymabe, marmijo[m]: definitely
<marmijo[m]>
dustymabe, jlebon will do, thank you!
nalind has quit [Quit: bye for now]
Turnikov has quit [Ping timeout: 255 seconds]
Turnikov has joined #fedora-coreos
Turnikov has quit [Ping timeout: 255 seconds]
Turnikov has joined #fedora-coreos
Turnikov has quit [Ping timeout: 255 seconds]
ravanelli has joined #fedora-coreos
jpn has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]