create fedora-coreos-tools or so

[cgwalters]

Splitting this out from coreos/coreos-assembler#670 (comment)

I'm on board with a fedora-coreos-tools package (or maybe just many packages or subpackages?), but I don't think we should bunch them all under the same name (i.e. fcostool). I think that would just be confusing and make versioning really hard. Is there a big benefit to grouping them?

Scope of this is "things people using any distribution may want to run to target FCOS". Additionally it would be included in coreos-assembler. So far:

• fcct
• cosa run
• virt-install equivalent

If we don't have fcostool, then what would "cosa run" be called? Or I guess we could still have fcostool, and you just want fcct to be special enough to stand on its own? So it'd be:

• fcct (and fcostool ct ?)
• fcostool run
• fcostool virt-install

Anything else? Maybe something to download images?

[cgwalters]

And we wanted fcostool ign or so that would support merging Ignition and in general doing dynamic compliation. See also https://github.com/ashcrow/filetranspiler

[ajeddeloh]

I still don't see the advantage of having everything share a binary name. I find those kind of tools more confusing that just individual programs. In general I think we should be striving towards a "box of tools" rather than one integrated tool.

What would be the difference between virt-install and run? I'm not sure the utility in providing those. Users can already run qemu/virt-install/kola run individually and I don't see benefit in abstracting over those. I think it will just make it harder to tell what's going on under the hood (especially with virt-install where we would running qemu via virt-install via whatever top level wrapper we have).

[cgwalters]

Two reasons: Discoverability, and in Unix, /usr/bin is a global namespace that we don't want to pollute. While fcct is "unique enough", there are a lot of potential collisions the shorter the name gets.

In general I think we should be striving towards a "box of tools" rather than one integrated tool.

Right, the philosophical division here is also clearly visible in cosa [X] versus the mantle suite. Though for mantle it's mostly fine because those aren't tools we expect most people to install, which speaking of:

Users can already run qemu/virt-install/kola run individually and I don't see benefit in abstracting over those.

We don't want users running kola, right?

As far as running qemu directly; yes you've documented that but I find it way more convenient to cosa run.

Are you disagreeing with the premise that we want to ship a cosa run equvialent in this package?

[alanconway]

See some extra comments in #246

TL;DNR: This proposed set of install instructions is based on the fedora install page. There is an implied "coreos-common" package dependency behind each these.

---

Quick start:

dnf install coreos-quickstart

This installs coreos-virt and starts a VM cluster on your machine with default settings, ready to experiment.

Other packages:

• dnf install coreos-bare - tools to configure a bare metal cluster.
• dnf install coreos-virt - tools to configure virtual clusters.
• dnf install coreos-cloud - tools to configure CoreOS in an existing cloud.

Once installed see /usr/share/doc/coreos-/README.md.

[cgwalters]

We had a realtime chat about this issue that ranged over various topics. I forget all of it, but one bit I do remember about the "subcommands vs standalone" discussion is that the "subcommand pattern" feels most natural when the primary command is operating on an explicit "context".

git is a canonical example here because all of the git commands operate implicitly on a git repository which is assumed to be a parent of the current directory. ostree is similar. And cosa was also explicitly designed to work this way - it operates on a build directory.

In order for a hypothetical fcostool to match this, it'd need a "context directory" which...you could imagine we offer tooling to download/mirror the images which operate on that directory. But eh...probably a little too weird.

So I am leaning more towards standalone tools but...the problem is what to call them. fc as a prefix I think is simply too prone to collisions, at least here fontconfig has claimed that.

[cgwalters]

@alanconway An explicit goal of this issue was to support packaging the tools for other distributions e.g. Ubuntu as well as potentially MacOS and Windows bash shell.

So I don't think we should focus too much on the package names or dnf as a mechanism to install them. Those bits should really be driven by the name of the upstream project and CLI anyways which we should aim to be mostly host-independent.

[alanconway]

@cgwalters I think #246 isn't exactly the same issue after all, but it overlaps. I'll re-open and re-focus it on a better user experience for https://getfedora.org/en/coreos/download/

That issue could be addressed by packaging the existing download instructions, but clearly it should take account of tools and packages that emerge from this issue, so we end up with a sane set of coreos- related packages.

[nsmith5]

I built a tool in this space to help my own development workflow out. I'll leave it here for reference https://github.com/nsmith5/fcosctl. I don't know that fcosctl was an ideal name but I think it would be kind of nice to have all of the "development" toolchain bundled together. From an end user perspective, I find I need to pull upstream images (functionality of coreos-installer), compile configurations (fcct) and test out images locally (qemu-kvm or others). I glued these together in a hacky way, but I really would love it they already came together.

Everything you need to develop Go is in the go binary. Would be lovely if everything I needed to develop my Fedora CoreOS machines was in a fcos binary.