`fcosctl` - A tool for quickly developing Fedora CoreOS configuration files

[nfsmith (Nathan Smith)]

Hey folks!

Wanted to share a small tool I created for iterating quickly when developing configuration files for FCOS: GitHub - nsmith5/fcosctl: CLI for rapid Fedora CoreOS development

Helps save you a couple keystrokes while you’re testing things out. Feel free to submit issues or pull requests if you’d like to improve it

[dustymabe]

Neat. Thanks for sharing!

[jakfrost (Stephen Douglas Snow)]

Hello @nfsmith,
Welcome to the community and the discussion forum. Thank you for coming bearing gifts, 'tis the season!

[joefidler]

Very cool! Really like this idea. Just got through a bare metal install of CoreOS onto a really crap piece of hardware. My fault, but I got really sick of the iterations to get a working ignition file that would result in a bootable system on the hardware. Anyway to adapt / utilize this with a bare metal install - say from inside a live image ISO running on the target system/environment?

[nfsmith (Nathan Smith)]

I can’t think of any way to immediately adapt this to the live image ISO situation off the top of my head. If you can think of one I’m happy to accept features.

I’ve found that for myself that if I can get it working in qemu-kvm locally it will usually work fine somewhere else. The idea behind fcosctl was to turn that workflow into one command.

[walters (Colin Walters)]

Thanks for starting this! See also create fedora-coreos-tools or so · Issue #235 · coreos/fedora-coreos-tracker · GitHub

The cosa run code in coreos-assembler that I use heavily is similar to this. I’ve been thinking in the background about how to split that out.

If you’re interested, maybe take a look at that code (e.g. qemu.go and devshell.go) and think about how to split that out into a separate Go library perhaps?

[joefidler]

@nfsmith

I can’t think of any way to immediately adapt this to the live image ISO situation

For me you have taken a very appropriate approach, targeting VM creation which is well in line with what I suspect are the mainstream uses for CoreOS. Thank you for your work on that - it is very cool. Speaking as someone who has not had any long term experience with CoreOS, it seems it would not make sense to adapt it that to a very different bare-metal install scenario.

For me, I got very frustrated with installing CoreOS onto custom or finicky or non-standard (non-virtual) real hardware. It seemed that anything beyond common settings (network, users and hardware), where a config needs tweaking to see what works, can get very frustrating and time consuming. Felt like an old fashioned “batch” approach - create the fcc, compile it, boot the live iso image, copy over the config, install the OS, boot the OS, see what works and didn’t, repeat - often.

I suspect that a config tool running on the actual target hardware within the context of a booted live image would be a better approach to solve that. Or at least something that could take a snapshot of selected environment parameters to produce a coreOS image would be helpful. But I am not sure enough folks have this issue for it to be a worthwhile effort. And all this is outside the context of the issue your tool is addressing - so apologies for that

[nfsmith (Nathan Smith)]

@walters

The cosa run code in coreos-assembler that I use heavily is similar to this. I’ve been thinking in the background about how to split that out.

Ah ha! I should have known the development team had tooling for this. Very cool.

@walters

If you’re interested, maybe take a look at that code (e.g. qemu.go and devshell.go) and think about how to split that out into a separate Go library perhaps?

Oh! Excellent! Yeah I’ll take a look and see if I can factor some bits out into something. Do you think there would be interest in hosting that library in the cosa repository as a sort of source of truth or better to just copy and steal what I like?

[nfsmith (Nathan Smith)]

@joefidler

For me, I got very frustrated with installing CoreOS onto custom or finicky or non-standard (non-virtual) real hardware. It seemed that anything beyond common settings (network, users and hardware), where a config needs tweaking to see what works, can get very frustrating and time consuming. Felt like an old fashioned “batch” approach - create the fcc, compile it, boot the live iso image, copy over the config, install the OS, boot the OS, see what works and didn’t, repeat - often.

Ahhh! Yes I see. Yeah I’m definitely working on pretty generic server type installs. A local qemu VM is a great approximation of the cloud VM my configurations will eventually run on. I can see the development cycle on specific hardware being really frustrating

[bgilbert (Benjamin Gilbert)]

@joefidler

For me, I got very frustrated with installing CoreOS onto custom or finicky or non-standard (non-virtual) real hardware. It seemed that anything beyond common settings (network, users and hardware), where a config needs tweaking to see what works, can get very frustrating and time consuming. Felt like an old fashioned “batch” approach - create the fcc, compile it, boot the live iso image, copy over the config, install the OS, boot the OS, see what works and didn’t, repeat - often.

If you have the ability to set up a development PXE environment, PXE installs are much nicer to automate than ISO installs. Another option is to run coreos-installer on your development system, from the RPM or the container image, and install to a USB stick. Then move the stick over to the target system and boot from it as though it were the primary storage device.

[joefidler]

@bgilbert dont have PXE setup, but I can see the idea of installing onto a USB drive and booting that on the target machine makes sense as a way to streamline the development of the ignition file. Will give it a try - thanks for that.