Getting Involved

[promaethius (Jonathan Bryant)]

It’s great to see the CoreOS community evolving like this! How can I get involved?

Thanks to dustymabe, I’m playing around with building custom atomic images but I’ve run into quite a few problems. Most of it has to do with fedora philosophy: we like python. Yum, dnf, the atomic toolset, cloud-init (not fedora specific but standard server init). CoreOS is bringing a lot of low level tooling to the table and I’ve seen dustymabe start some dracut modules for ignition so it’ll replace cloud-init with the rpm-ostree toolchain. How do the CoreOS and Fedora philosophies work together? It seems like the two will be at odds concerning interpreted languages.

With such a fast paced environment, most of the documentation over at project atomic is out of date referencing tpm-ostree-toolbox while fedora atomic will perform builds using its spiritual successor pungi which is a similar wrapper around lorax, rpm-ostree, and other containerized tools. This makes it difficult to catch up to where the atomic project is presently. I would really like to contribute more since I have a vested interest in this project as a modular alternative to CoreOS. Working with the old SDK sometimes felt clunky when installing new modules.

I do have one small contribution over at https://src.fedoraproject.org/rpms/container-selinux/pull-request/1. Anything with RunC as a dependency or docker/rkt/cri-o selinux policies require this package. However, it references a policycoreutil-python as a hard depend. However, %post does not use any python utilities. This seems like it should be a weak or forward depend. After compiling this rpm in a local repo, my fedora atomic builds without any python2,3 or perl dependencies.

As a footnote, dnf repoquery does not respect repo priorities, repo excludes, or rpm versions when compiling a dependency tree. Commands such as dnf repoquery runc --tree --requires or dnf repoquery runc --requires --recursive --resolve will locate dependencies from the same repo the initial package is found at. This bug at least means that building analytical tools for coreos fedora atomic will require some custom tooling.

[dustymabe]

@promaethius

It’s great to see the CoreOS community evolving like this! How can I get involved?

Thanks for the post and the complement!

I think the best way to get involved at this early stage is to come to the weekly meetings and follow the discussions on the issue tracker.

Thanks to dustymabe, I’m playing around with building custom atomic images but I’ve run into quite a few problems. Most of it has to do with fedora philosophy: we like python. Yum, dnf, the atomic toolset, cloud-init (not fedora specific but standard server init). CoreOS is bringing a lot of low level tooling to the table and I’ve seen dustymabe start some dracut modules for ignition so it’ll replace cloud-init with the rpm-ostree toolchain. How do the CoreOS and Fedora philosophies work together? It seems like the two will be at odds concerning interpreted languages.

We are taking this opportunity to evaluate a lot of fundamental design choices when it comes to defining and delivering an OS. yum/dnf → rpm-ostree. cloud-init → ignition. The atomic toolset, not sure exactly, but see #37 for a partial discussion there. As for python, discussion ongoing in #32.

With such a fast paced environment, most of the documentation over at project atomic is out of date referencing tpm-ostree-toolbox while fedora atomic will perform builds using its spiritual successor pungi which is a similar wrapper around lorax, rpm-ostree, and other containerized tools. This makes it difficult to catch up to where the atomic project is presently. I would really like to contribute more since I have a vested interest in this project as a modular alternative to CoreOS. Working with the old SDK sometimes felt clunky when installing new modules.

Yes. With Atomic Host and related projectatomic projects some of the docs are wildly out of date at this point. With CL and all projects related to CoreOS Inc. we are very pleased with their documentation standards so we hope that, along with the hopes that we will have a much larger and involved community for Fedora CoreOS, we will have much better documentation in the future.

Specifically regarding the SDK, we are trying to make some pretty radical changes there as well. For example we have created a POC project called the coreos-assembler that should make it fairly easy for anyone to hack on Fedora CoreOS on their own hardware/infra. We will still have to integrate this with Fedora Releng at some point (see #44), but we are trying to drive some changes of these changes because we believe they will ultimately foster a healthier project.

I do have one small contribution over at PR#1: python-utils weak depend - rpms/container-selinux - src.fedoraproject.org. Anything with RunC as a dependency or docker/rkt/cri-o selinux policies require this package. However, it references a policycoreutil-python as a hard depend. However, %post does not use any python utilities. This seems like it should be a weak or forward depend. After compiling this rpm in a local repo, my fedora atomic builds without any python2,3 or perl dependencies.

Would you be interested in helping us decrease our dependencies on python? I think there will definitely be opportunities here.

As a footnote, dnf repoquery does not respect repo priorities, repo excludes, or rpm versions when compiling a dependency tree. Commands such as dnf repoquery runc --tree --requires or dnf repoquery runc --requires --recursive --resolve will locate dependencies from the same repo the initial package is found at. This bug at least means that building analytical tools for coreos fedora atomic will require some custom tooling.

I’m not sure about the exact bugs you are referring to but maybe something like coreos-assembler will help with that?

[promaethius (Jonathan Bryant)]

I think the best way to get involved at this early stage is to come to the weekly [meetings] and follow the discussions on the [issue tracker].

Ok sounds good! I should probably anchor a chatbot in there too.

We are taking this opportunity to evaluate a lot of fundamental design choices when it comes to defining and delivering an OS. yum/dnf -> rpm-ostree. cloud-init -> ignition. The atomic toolset, not sure exactly, but see [#37]for a partial discussion there. As for python, discussion ongoing in [#32].

By atomic toolset, I was referencing the early adoption of a cli at GitHub - projectatomic/atomic: Atomic Run Tool for installing/running/managing container images.. I wasn’t sure why this was needed but I understand that it represents a high level abstraction of starting containers (but the docker cli is already pretty high level). But yes, CoreOS’s philosophy on not shipping python is very important given long term support of certain tools which might break if python needs a security update. “If you need to run python scripts, just containerize them.” So using the atomic cli is counterintuitive to CoreOS.

I’m hoping toolbox, etcd-member, and kubelet-wrapper will see some use in fedora coreos. With ignition, I’d really like to see something like stateless baremetal through matchbox.

What about kickstart or anaconda? Will those see any use in coreos? They are also Python but kickstart feels like the fedora equivalent of ignition.

Specifically regarding the SDK, we are trying to make some pretty radical changes there as well. For example we have created a POC project called the [coreos-assembler ] that should make it fairly easy for anyone to hack on Fedora CoreOS on their own hardware/infra. We will still have to integrate this with Fedora Releng at some point (see [#44]), but we are trying to drive some changes of these changes because we believe they will ultimately foster a healthier project.

Oh brilliant! I’d been seeing issues and prs in mantle about the sdk but I wasn’t sure where that sdk was being generated. I’ll totally check that out! Does it only generate VM images tho?

Would you be interested in helping us decrease our dependencies on python? I think there will definitely be opportunities here.

Absolutely. So far, I’m messing with local repositories kind of like the coreos emerge overlay did. That and building some analytical dependency tools. Containers-selinux proved the stickiest dependency to remove because there were no equivalents to it.

I’m not sure about the exact bugs you are referring to but maybe something like coreos-assembler will help with that?

Possibly? It’s a hard bug to explain. So, imagine that remote repo A has packageX 0.1 and local repo B has packageX 0.2. Repo A is using priority 2, repo B is using priority 1. PackageY which exists only on Repo A requires packageX. If I make a dnf repoquery --recursive --resolve --requires PackageY it’ll return packageX 0.1 as from Repo A rather than from Repo B. Additionally, if I add the exclude=packageX to repo A, the dnf query still ignores it and returns packageX 0.1 as a depend of packageY. dnf repoquery --recursive --resolve --repo repoA --exclude packageX --repo repoB packageY. However, with this setup, rpm-ostree honors the correct depend trees and I see packageX 0.2 in the build.

This seems to be a fundamental flaw in dnf repoquery?

[miabbott (Micah Abbott)]

@promaethius

What about kickstart or anaconda? Will those see any use in coreos? They are also Python but kickstart feels like the fedora equivalent of ignition.

There’s some discussion about this on the tracker - Host Installer for Fedora CoreOS (bare metal) · Issue #50 · coreos/fedora-coreos-tracker · GitHub

@promaethius

Oh brilliant! I’d been seeing issues and prs in mantle about the sdk but I wasn’t sure where that sdk was being generated. I’ll totally check that out! Does it only generate VM images tho?

Check it out for yourself! GitHub - coreos/coreos-assembler: Tooling container to assemble CoreOS-like systems

When doing a build, it’s currently generating an ostree commit and qcow2 image.

[promaethius (Jonathan Bryant)]

There’s some discussion about this on the tracker

I’ll check that out. I know that the project-atomic documentation uses livemedia-creator which is a high level for anaconda into kickstart into lorax into a virtual machine into an iso. So I’m interested in the flow for the assembler.

Check it out for yourself! [GitHub - coreos/coreos-assembler: Tooling container to assemble CoreOS-like systems ]
When doing a build , it’s currently generating an ostree commit and qcow2 image.

I am not well read in virtual disks vs physical disks. Is it possible to use a simple qemu-img convert atomic-coreos.qcow2 -O raw coreos.img? My specific use case is pxe loading on bare metal so that’s the direction I’d like to help with.

[promaethius (Jonathan Bryant)]

@promaethius

Would you be interested in helping us decrease our dependencies on python? I think there will definitely be opportunities here.

@dustymabe would this be in the area of anaconda/kickstart? Or package dependencies for runtimes?

[dustymabe]

@promaethius

@dustymabe would this be in the area of anaconda/kickstart? Or package dependencies for runtimes?

Not Anaconda. I was referring to package dependencies on python for packages we use in Fedora CoreOS.

[promaethius (Jonathan Bryant)]

@dustymabe

Not Anaconda. I was referring to package dependencies on python for packages we use in Fedora CoreOS.

Ok, will do! You’ve already seen my PR over at fedora-coreos-config, but are there any guidelines for contribution? I’d like to help more than make mistakes haha.

I’ll start by trying to tool an easy package analyzer.