profile
viewpoint
Luca Bruno lucab Red Hat Berlin https://www.lucabruno.net @IBM / @RedHatOfficial / @coreos / @Debian

coreos/rpm-ostree 420

⚛📦 Hybrid image/package system with atomic upgrades and package layering

ctz/hyper-rustls 99

Integration between hyper HTTP library and rustls TLS stack

coreos/torcx 76

torcx is a boot-time addon manager for immutable systems

eurecom-s3/hdd_firmware_tools 59

Tools for viewing and extracting HDD firmware files

eurecom-s3/actaeon 38

Memory forensics of virtualization environments

lucab/caps-rs 18

A pure-Rust library to work with Linux capabilities

coreos/fedora-coreos-docs 15

Documentation for Fedora CoreOS

lucab/adns 15

Advanced, easy to use, asynchronous-capable DNS client library and utilities

coreos/fedora-coreos-streams 13

Stream metadata and overrides for Fedora CoreOS

lucab/artoolkit 11

SVN mirror for artoolkit

PullRequestReviewEvent
PullRequestReviewEvent

delete branch lucab/zincati

delete branch : ups/docs-journalctl

delete time in 9 hours

pull request commentcoreos/bootupd

filetree: Fix creation of parent directories

@cgwalters I think I've seen coreos-ci coming back on other repositories, but you may need to force-push this one to re-trigger it.

cgwalters

comment created time in 9 hours

Pull request review commentcoreos/bootupd

filetree: Fix creation of parent directories

 pub(crate) fn apply_diff(         let path = Path::new(pathstr);         if let Some(parent) = path.parent() {             // TODO: care about directory modes?  We don't for FAT.-            std::fs::create_dir_all(parent)?;+            destdir.ensure_dir_all(parent, 0o755)?;

Fine for doing both later, to be honest I thought the new 0o755 was exactly a reaction to the TODO.

cgwalters

comment created time in 10 hours

PullRequestReviewEvent

push eventlucab/zincati

Luca Bruno

commit sha 09651b294ad4e5ba4b788c1b28b23e7f78bf7140

docs/usage: misc improvements to logging page Co-authored-by: Stephen Milner <stevem@gnulinux.net>

view details

push time in 10 hours

push eventlucab/zincati

Luca Bruno

commit sha cc05ee24015f86bad89a8dc9e45d8173affc15f9

docs/usage: misc improvements to logging page Co-authored-by: Stephen Milner <stevem@gnulinux.net>

view details

push time in 10 hours

Pull request review commentcoreos/bootupd

Add a more realistic e2e upgrade test

+#!/bin/bash+# Given a coreos-assembler dir (COSA_DIR) and assuming+# the current dir is a git repository for bootupd,+# synthesize a test update and upgrade to it.  This+# assumes that the latest cosa build is using the+# code we want to test (as happens in CI).+set -euo pipefail++dn=$(cd $(dirname $0) && pwd)+. ${dn}/../kola/data/libtest.sh+. ${dn}/testrpmbuild.sh++if test -z "${COSA_DIR:-}"; then+    fatal "COSA_DIR must be set"+fi+# Validate source directory+bootupd_git=$(cd ${dn} && git rev-parse --show-toplevel)+test -f ${bootupd_git}/systemd/bootupd.service++# Start in cosa dir+cd ${COSA_DIR}+test -d builds++overrides=${COSA_DIR}/overrides+test -d "${overrides}"+mkdir -p ${overrides}/rpm+add_override() {+    override=$1+    shift+    # This relies on "gold" grub not being pruned, and different from what's+    # in the latest fcos+    (cd ${overrides}/rpm && runv koji download-build --arch=noarch --arch=$(arch) ${override})+}+if test -z "${e2e_skip_build:-}"; then+    echo "Building starting image"+    rm -f ${overrides}/rpm/*.rpm+    add_override grub2-2.04-22.fc32+    (cd ${bootupd_git} && runv make && runv make install DESTDIR=${overrides}/rootfs)+    runv cosa build+    prev_image=$(runv cosa meta --image-path qemu)+    rm -f ${overrides}/rpm/*.rpm+    echo "Building update ostree"+    add_override grub2-2.04-23.fc32+    # Only build ostree update+    runv cosa build ostree+fi+echo "Preparing test"+grubarch=+case $(arch) in+    x86_64) grubarch=x64;;+    aarch64) grubarch=aa64;;+    *) fatal "Unhandled arch $(arch)";;+esac+target_grub_name=grub2-efi-${grubarch}+target_grub_pkg=$(rpm -qp --queryformat='%{nevra}\n' ${overrides}/rpm/${target_grub_name}-2*.rpm)+target_commit=$(cosa meta --get-value ostree-commit)+echo "Target commit: ${target_commit}"+# For some reason 9p can't write to tmpfs+testtmp=$(mktemp -d -p /var/tmp bootupd-e2e.XXXXXXX)+cat >${testtmp}/test.fcct << EOF+variant: fcos+version: 1.0.0+systemd:+  units:+    - name: bootupd-test.service+      enabled: true+      contents: |+        [Unit]+        RequiresMountsFor=/run/testtmp+        [Service]+        Type=oneshot+        RemainAfterExit=yes+        Environment=TARGET_COMMIT=${target_commit}+        Environment=TARGET_GRUB_NAME=${target_grub_name}+        Environment=TARGET_GRUB_PKG=${target_grub_pkg}+        Environment=SRCDIR=/run/bootupd-source+        # Run via shell because selinux denies systemd writing to 9p apparently+        ExecStart=/bin/sh -c '/run/bootupd-source/tests/e2e/e2e-in-vm.sh &>>/run/testtmp/out.txt; test -f /run/rebooting || poweroff -ff'

Just noting here, possibly for future consideration, from an out-of-band chat: in order to avoid spiraling into a scripting trap and VM-to-kola dependencies, we could explore having an hidden bootupd exttests runner and move the testing logic into the codebase.

cgwalters

comment created time in 10 hours

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentcoreos/bootupd

filetree: Fix creation of parent directories

One small nit/confusion from my side, but otherwise big thanks for also covering this with a regression test!

cgwalters

comment created time in 12 hours

Pull request review commentcoreos/bootupd

filetree: Fix creation of parent directories

 pub(crate) fn apply_diff(         let path = Path::new(pathstr);         if let Some(parent) = path.parent() {             // TODO: care about directory modes?  We don't for FAT.-            std::fs::create_dir_all(parent)?;+            destdir.ensure_dir_all(parent, 0o755)?;

Nit: I think you also took care of the TODO above with this. If so, it can be dropped. Also, there is a very confusing #[allow(dead_code)] // Used for testing at the top of this function, which judging from this patch I think it isn't really true.

cgwalters

comment created time in 12 hours

PullRequestReviewEvent
PullRequestReviewEvent

issue closedcoreos/rpm-ostree

RFE: Atomic should meet full NIST-800 compliance

** Host system details **

Any

** Expected vs actual behavior **

Atomic has /home as a separate partition, but /var/log and /var/log/audit should also be separate, so malicious containers cannot fill the partitions with logging and create a denial of service.

Would you like to work on the issue? I'm happy to do the implementation here.

closed time in 12 hours

evol262

issue commentcoreos/rpm-ostree

RFE: Atomic should meet full NIST-800 compliance

Closing this one as it looks like a stale distro-related report (against Fedora Atomic).

evol262

comment created time in 12 hours

pull request commentcoreos/zincati

docs/usage: expand logging page

/cc @ashcrow for a quick proof-read and @bh7cw for review as she was recently going through this.

lucab

comment created time in 12 hours

PR opened coreos/zincati

docs/usage: expand logging page area/docs kind/cleanup kind/enhancement

This clarifies a few existing details related to log levels and introduces a section covering journalctl and how to inspect logs on a live system.

+25 -4

0 comment

1 changed file

pr created time in 12 hours

create barnchlucab/zincati

branch : ups/docs-journalctl

created branch time in 12 hours

create barnchlucab/zincati

branch : ups/docs-journalct

created branch time in 12 hours

delete branch lucab/zincati

delete branch : ups/docs-journalct

delete time in 12 hours

PR opened coreos/bootupd

daemon: avoid direct printing, log instead

This converts all daemon logic to stop directly printing to stdout/stderr, and instead perform logging at the appropriate level.

/cc @cgwalters

+5 -5

0 comment

1 changed file

pr created time in 13 hours

create barnchlucab/bootupd

branch : ups/daemon-log

created branch time in 13 hours

issue closedcoreos/rpm-ostree

Hook up to dependabot for automated dependency updates

Check out how it's set up in coreos-metadata.

closed time in 13 hours

jlebon

issue commentcoreos/rpm-ostree

Hook up to dependabot for automated dependency updates

Closing as this is already in place and working well, see https://github.com/coreos/rpm-ostree/pulls?q=is%3Apr+is%3Aclosed+label%3Adependencies.

jlebon

comment created time in 13 hours

issue commentcoreos/rpm-ostree

add UUID signatures, like openSUSE has for Zypper

Hey @mattdm, reading the linked material it is my understanding that this RFE has been scraped and it evolved into the count-me system instead, which we are tracking at https://github.com/coreos/rpm-ostree/issues/2142. Can you double-check there isn't anything else missing here and that this can be closed in favor of #2142?

mattdm

comment created time in 13 hours

PullRequestReviewEvent

pull request commentcoreos/fedora-coreos-docs

Make the bash script's style more consistent and appropriate for today's resource usage

LGTM too, leaving to @jlebon for the final pass/merge.

renich

comment created time in 13 hours

issue closedcoreos/rpm-ostree

Upgrade path from CentOS atomic host (7) on bare metal?

We're using CentOS atomic host to run on 2 embedded platforms - so on bare metal, I guess. Basically, we have a centos-atomic-host-<custom>.json and we use 'rpm-ostree compose' to build the image. Upgrades involve doing 'rpm-ostree rebase' to a new repo with updated packages. Our latest version is rebased on top of CentOS 7.7 - we basically use 7.7 repos to get the most up to date stuff from CentOS 7. My question is - what would our upgrade path to CentOS 8 be? Any recommendation for that?

I see the recommendation for moving from Fedora atomic to Fedora CoreOS is to re-provision (https://discussion.fedoraproject.org/t/launch-faq-how-do-i-migrate-from-fedora-atomic-host-to-fedora-coreos/51), but obviously that won't work on bare metal. Would simply updating the centos-atomic-host.json file and the repos to point to CentOS 8 work, and then 'rpm-ostree rebase' on that?

closed time in 13 hours

fencekicker

issue commentcoreos/rpm-ostree

Upgrade path from CentOS atomic host (7) on bare metal?

Closing as this question has been answered already.

For Atomic -> Fedora CoreOS migration there is a doc-page at https://docs.fedoraproject.org/en-US/fedora-coreos/migrate-ah/, which could be further enhanced with more details as needed.

fencekicker

comment created time in 13 hours

pull request commentcoreos/rpm-ostree

build(deps): bump structopt from 0.3.17 to 0.3.18 in /rust

(I've retriggered the CI as it got stuck somewhere, it then merged on green)

dependabot-preview[bot]

comment created time in 13 hours

Pull request review commentcoreos/coreos-installer

blockdev: allow only ECKD type of DASD disks

 fn stash_saved_partitions(disk: &mut File, saved: &SavedPartitions) -> Result<() fn is_dasd(config: &InstallConfig) -> Result<bool> {     let target = canonicalize(&config.device)         .chain_err(|| format!("getting absolute path to {}", config.device))?;-    Ok(target.to_string_lossy().starts_with("/dev/dasd"))+    if !target.to_string_lossy().starts_with("/dev/dasd") {

Oh indeed, sorry I missed that aspect.

nikita-dubrovskii

comment created time in 13 hours

PullRequestReviewEvent

issue closedcoreos/rpm-ostree

"No upgrade available" and "Run "systemctl reboot" to start a reboot" logs happen at the same time

** Host system details ** [root@localhost local]# rpm-ostree --version rpm-ostree: Version: 2017.4 Git: 9ebfecb859228eadeccd3486b7e908005cf875f8 Features:

  • compose

Provide the output of rpm-ostree status. State: idle Deployments: â— xxxxx:xxxxxx/2/x86_64/standard Version: OSversion-20170923_163753 (2017-09-23 08:38:40) Commit: 024369683cbdf493dcdb54cdcbcdde6c147a246a58883974aaf20826d310f52f PendingCommit: 0c1af55607027ce7a8d0d43492585c650fa8b13566bb05948554a1b2514a4dba PendingVersion: OSversion-20170925_162900 (2017-09-25 08:29:48) OSName: xxxxxx

xxxxxx:xxxxx-xxxxxx/2/x86_64/standard Version: OSversion-20170925_162900 (2017-09-25 08:29:48) Commit: 0c1af55607027ce7a8d0d43492585c650fa8b13566bb05948554a1b2514a4dba OSName: xxxxx

** Expected vs actual behavior **

[root@localhost local]# rpm-ostree upgrade No upgrade available. Run "systemctl reboot" to start a reboot

Expected:

[root@localhost local]# rpm-ostree upgrade No upgrade available.

Steps to reproduce it

  1. install OS
  2. upgrade to a newer version(no reboot)
  3. rpm-ostree rollback(no reboot)
  4. upgrade to the original installed version

Would you like to work on the issue? No.

I think it maybe caused by "PendingCommit" info? but I don't know why it works like this?

Thanks a lot!

closed time in 15 hours

isula-xufeng

issue commentcoreos/rpm-ostree

"No upgrade available" and "Run "systemctl reboot" to start a reboot" logs happen at the same time

Tentatively closing as the issue should have been fixed in the meanwhile, feel free to open a new ticket with fresh details if not.

isula-xufeng

comment created time in 15 hours

Pull request review commentcoreos/coreos-installer

blockdev: allow only ECKD type of DASD disks

 fn stash_saved_partitions(disk: &mut File, saved: &SavedPartitions) -> Result<() fn is_dasd(config: &InstallConfig) -> Result<bool> {     let target = canonicalize(&config.device)         .chain_err(|| format!("getting absolute path to {}", config.device))?;-    Ok(target.to_string_lossy().starts_with("/dev/dasd"))+    if !target.to_string_lossy().starts_with("/dev/dasd") {

Minor: you can move this .to_string_lossy() directly into target definition, that should spare you the .display() a few line below (same applies to name too).

nikita-dubrovskii

comment created time in 15 hours

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentcoreos/bootupd

cli: add flag to control logging level

Rebased and followed up on comments.

lucab

comment created time in 16 hours

Pull request review commentcoreos/bootupd

WIP: e2e test that upgrades grub

+#!/bin/bash

I think this would need to source libtest.sh in VM, no?

cgwalters

comment created time in 16 hours

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentcoreos/fedora-coreos-docs

provisioning: add instructions for IBM Cloud

I think @dustymabe wants to hold this for a bit and synchronize with the rest of the work at https://github.com/coreos/fedora-coreos-tracker/issues/277. This LGTM as is (but I haven't tried a full provisioning flow right now, I stopped midway due to lack of ACL/time), I'll let him merge when he prefers.

dustymabe

comment created time in 18 hours

PullRequestReviewEvent

issue commentcoreos/fedora-coreos-docs

Getting started docs don't reference the 'core' user

I'm confused about this report. The actual "Getting Started" page at https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/ actually mentions the core in several places already.

zmarano

comment created time in 18 hours

pull request commentcoreos/zincati

cargo: update actix to latest version

@dustymabe merged; do you need this quickly in a tagged release too?

lucab

comment created time in 18 hours

push eventcoreos/zincati

Luca BRUNO

commit sha d4381b9af710fb925dc8f41bd1d7a22dffb08f85

cargo: update actix to latest version

view details

Luca BRUNO

commit sha 5d38692ae5d7092b1b5cc40714a7824a41a1cace

lockfile: refresh after cargo changes

view details

Luca BRUNO

commit sha 231d7cba7fb42924f85f21743923bd404eef9d1a

update_agent: adapt to actix-0.10 API changes

view details

Luca Bruno

commit sha 46f8314067954c2ce0650334c4a77c3be09c3e2e

Merge pull request #359 from lucab/ups/deps-bump-actix cargo: update actix to latest version

view details

push time in 19 hours

delete branch lucab/zincati

delete branch : ups/deps-bump-actix

delete time in 19 hours

PR merged coreos/zincati

cargo: update actix to latest version area/dependencies

This updates to actix-0.10 and adapts the existing code to the new API.

+98 -280

2 comments

3 changed files

lucab

pr closed time in 19 hours

issue commentcoreos/fedora-coreos-tracker

fcos 32.20200907.3.0 no longer be install from pxe

@lfarkas thanks for both. It looks like the install flow is failing on

coreos-installer-service[759]: coreos-installer install /dev/vda --ignition-url ftp://192.168.209.1/download/vidux/tftpboot/bios/pxelinux.cfg/vidux.ign --insecure-ignition --firstboot-args rd.neednet=1 ip=dhcp  --platform qemu
coreos-installer-service[779]: Error: parsing arguments
coreos-installer-service[779]: Caused by: unknown protocol for URL 'ftp://192.168.209.1/download/vidux/tftpboot/bios/pxelinux.cfg/vidux.ign'

which indeed matched the PXE entry:

coreos.inst.ignition_url=ftp://192.168.209.1/download/vidux/tftpboot/bios/pxelinux.cfg/vidux.ign

I think this another incarnation of https://github.com/coreos/coreos-installer/issues/381, see the answer there for more details.

/cc @bgilbert on whether he wants to keep/move/close/document this one.

lfarkas

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

issue commentcoreos/fedora-coreos-tracker

fcos 32.20200907.3.0 no longer be install from pxe

and not it's not the rootfs kernel parameter since i update it to the recommended way ie: add to file to the initrd parameter.

Thanks for the report and for mentioning this, it would have been my first suggestion too.

To inspect what's going on, can you please share the whole PXE configuration? Assuming you have an input mechanism for this node console, can you please continue into the maintenance console and check the output journalctl to see if there are any hints of what is failing in the initramfs?

lfarkas

comment created time in a day

push eventlucab/bootupd

Luca BRUNO

commit sha 33974f9f87bcaa105fd6c237cf507acc975770fe

daemon: split daemon core-loop logic

view details

Luca BRUNO

commit sha bc0904eeae77e16b1f00d53fe78f6b8e295ff2ce

daemon: log and keep going on client errors This tweaks daemon core-logic to keep going on client-induced errors, logging them at "error" level. It also introduces docstring to ease casual code navigation.

view details

Luca BRUNO

commit sha c5c9be213b204e3bd4ad4c31fbf60e4002292fc5

cli: add flag to control logging level This introduces a new `-v(vv)` flag on both `bootupd` and `bootupctl` to control log verbosity. The default level only shows warnings and higher priorities. The service unit sets up the daemon to log info messages too, and can be overridden via a drop-in. This also introduces some basic unit-tests on CLI parsing.

view details

push time in a day

Pull request review commentcoreos/coreos-assembler

create_disk: Install grub config on aarch64

 x86_64)         --boot-directory $rootfs/boot \         $disk     fi-    install_grub_cfg

This has the side-effect of swapping the order of cp grub.cfg and grub-install, would that have actual implications on the bootloader bits on disk?

cgwalters

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

push eventcoreos/zincati

Luca BRUNO

commit sha e9df1fa12dcabc7f2e9f9bcce484a115dd61e1c5

cargo: add libc

view details

Luca BRUNO

commit sha 8418a040b6c0d2012df47b42b40b85f71322b3de

lockfile: refresh after manifest changes

view details

Luca BRUNO

commit sha 50d0b491362d52b99501faf935c61a03bcc50965

main: pretty-print critical error on termination This introduces a basic pretty-printer at the top-level entrypoint in order to print critical failures in a way which is simpler to understand. New output on error-exit looks like this: ``` [INFO ] starting update agent (zincati 0.0.14-alpha.0) [ERROR] critical error: failed to assemble configuration settings [ERROR] -> failed to validate agent identity configuration [ERROR] -> failed to build default identity [ERROR] -> failed to introspect OS base architecture [ERROR] -> failed to run 'rpm-ostree' binary [ERROR] -> No such file or directory (os error 2) ```

view details

Luca Bruno

commit sha ee0dc6a87cd9398182ceea4909a649eb3d8701ea

Merge pull request #361 from lucab/ups/main-print-errors main: pretty-print critical error on termination

view details

push time in 2 days

delete branch lucab/zincati

delete branch : ups/main-print-errors

delete time in 2 days

PR merged coreos/zincati

main: pretty-print critical error on termination area/usability kind/cleanup

This introduces a basic pretty-printer at the top-level entrypoint in order to print critical failures in a way which is simpler to understand. New output on error-exit looks like this:

[INFO ] starting update agent (zincati 0.0.14-alpha.0)
[ERROR] critical error: failed to assemble configuration settings
[ERROR]  -> failed to validate agent identity configuration
[ERROR]  -> failed to build default identity
[ERROR]  -> failed to introspect OS base architecture
[ERROR]  -> failed to run 'rpm-ostree' binary
[ERROR]  -> No such file or directory (os error 2)
+29 -4

1 comment

3 changed files

lucab

pr closed time in 2 days

push eventcoreos/fedora-coreos-cincinnati

Tom Lebreux

commit sha c679839733fc9f7f8e48db2c173c8e4f30f7d50d

Fix missing quote in response

view details

Tom Lebreux

commit sha 9f8a4c05422656afdcd1f3757a6ef224021b6954

Send 400 instead of 500 for unsupported basearch

view details

Luca Bruno

commit sha 2765ada2500b8daa4f055aa08c0c43f255522262

Merge pull request #36 from tomleb/master Send 400 instead of 500 for unsupported basearch

view details

push time in 2 days

issue closedcoreos/fedora-coreos-cincinnati

Unsupported basearch leads to 500 internal error

Not sure if that's the expected behavior, but sending a request to cincinnati with a non-supported basearch leads to a 500 internal error.

For example:

$ curl  --header 'Accept:application/json' 'https://updates.coreos.fedoraproject.org/v1/graph?stream=stable&basearch=mock-amd64'
HTTP status server error (500 Internal Server Error) for url (http://127.0.0.1:8080/v1/graph?basearch=mock-amd64&stream=stable)

The issue seems to be here: https://github.com/coreos/fedora-coreos-cincinnati/blob/master/fcos-graph-builder/src/main.rs#L147

    let arch_graph = policy::pick_basearch(cached_graph, basearch)?;
    let final_graph = policy::filter_deadends(arch_graph);

Instead of returning an HttpResponse, we're just erroring out.

I haven't used rust in ages, but I can attempt a fix. Should we send a 400 bad request?

closed time in 2 days

tomleb

pull request commentcoreos/fedora-coreos-cincinnati

Send 400 instead of 500 for unsupported basearch

LGTM, thanks for fixing this!

tomleb

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentcoreos/bootupd

cli: add flag to control logging level

 Documentation=https://github.com/coreos/bootupd  [Service] Type=notify-ExecStart=/usr/libexec/bootupd daemon+Environment=BOOTUPD_VERBOSITY="-v"+ExecStart=/usr/libexec/bootupd daemon $BOOTUPD_VERBOSITY

Feels like systemd really needs to grow some sort of ExecStartArgs=

We can probably cover this RFE somewhere before going to the systemd folks, but I'm not so sure and I think that the final interface would be quite similar (a map of string -> string) with the only difference being leaving envp pristine.

Wouldn't it be better to support configuration via environment directly? Can't they already do that via RUST_LOG?

Yes RUST_LOG would still work, especially for more advanced things (e.g. selectively enabling debug messages from a specific library). It isn't a very discoverable/friendly UX though, and for bootupctl specifically there are few bleeding edges as the crate name (used to control per-module logging) does not match the binary name. This is also narrower in scope, as it only bridges the top-level crate level (versus the global logging level) to a CLI flag, allowing to directly get debug/trace messages from the application without all the transitive dependencies too (i.e. RUST_LOG=bootupd=debug). To me it seems worth at least for bootupctl, and possibly on bootupd to avoid having to each every single user about the module-syntax of RUST_LOG.

lucab

comment created time in 2 days

PullRequestReviewEvent

push eventcoreos/zincati

Luca BRUNO

commit sha fe9505f931bad2457147a1fc34f5e3653205d25c

rpm-ostree: avoid duplicating error causes This fixes error context on rpm-ostree failed runs in order to avoid duplicating the underlying error cause. Failure chain already includes the root cause as the next element, thus there is no need to also embed it in the parent context.

view details

Luca Bruno

commit sha 165cbd44cf1e04fa59acb62ab79d3e98932a4466

Merge pull request #360 from lucab/ups/rpm-ostree-err-context rpm-ostree: avoid duplicating error causes

view details

push time in 2 days

delete branch lucab/zincati

delete branch : ups/rpm-ostree-err-context

delete time in 2 days

PR merged coreos/zincati

rpm-ostree: avoid duplicating error causes area/rpm-ostree area/usability kind/cleanup

This fixes error context on rpm-ostree failed runs in order to avoid duplicating the underlying error cause. Failure chain already includes the root cause as the next element, thus there is no need to also embed it in the parent context.

+5 -5

0 comment

3 changed files

lucab

pr closed time in 2 days

pull request commentcoreos/zincati

cargo: update actix to latest version

I do not know actix/futures well enough to understand the new -> pin change.

For reference, the change aligns to the new type constraints introduced with https://github.com/actix/actix/pull/355. In short, the new API requires that the future response chain can be pinned to a stable memory address, which we are upholding here.

lucab

comment created time in 2 days

pull request commentcoreos/zincati

main: pretty-print critical error on termination

As a side-effect, this avoids a few blank lines and also reverses the order in which the error-chain is traversed, pushing outer error context towards the top. That seems more intuitive to me.

Before:

[INFO ] starting update agent (zincati 0.0.14-alpha.0)
Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }

failed to run 'rpm-ostree' binary

failed to introspect OS base architecture

failed to build default identity

failed to validate agent identity configuration

failed to assemble configuration settings

After:

[INFO ] starting update agent (zincati 0.0.14-alpha.0)
[ERROR] critical error: failed to assemble configuration settings
[ERROR]  -> failed to validate agent identity configuration
[ERROR]  -> failed to build default identity
[ERROR]  -> failed to introspect OS base architecture
[ERROR]  -> failed to run 'rpm-ostree' binary
[ERROR]  -> No such file or directory (os error 2)
lucab

comment created time in 2 days

PR opened coreos/zincati

main: pretty-print critical error on termination area/usability kind/cleanup

This introduces a basic pretty-printer at the top-level entrypoint in order to print critical failures in a way which is simpler to understand. New output on error-exit looks like this:

[INFO ] starting update agent (zincati 0.0.14-alpha.0)
[ERROR] critical error: failed to assemble configuration settings
[ERROR]  -> failed to validate agent identity configuration
[ERROR]  -> failed to build default identity
[ERROR]  -> failed to introspect OS base architecture
[ERROR]  -> failed to run 'rpm-ostree' binary
[ERROR]  -> No such file or directory (os error 2)
+29 -4

0 comment

3 changed files

pr created time in 2 days

create barnchlucab/zincati

branch : ups/main-print-errors

created branch time in 2 days

PR opened coreos/zincati

rpm-ostree: avoid duplicating error causes area/rpm-ostree area/usability kind/cleanup

This fixes error context on rpm-ostree failed runs in order to avoid duplicating the underlying error cause. Failure chain already includes the root cause as the next element, thus there is no need to also embed it in the parent context.

+5 -5

0 comment

3 changed files

pr created time in 2 days

create barnchlucab/zincati

branch : ups/rpm-ostree-err-context

created branch time in 2 days

Pull request review commentcoreos/fedora-coreos-docs

provisioning: add instructions for IBM Cloud

+= Provisioning Fedora CoreOS on IBM Cloud++This guide shows how to provision new Fedora CoreOS (FCOS) instances in IBM Cloud VPC Generation 2.++== Prerequisites++Before provisioning a FCOS instance, you must have an Ignition configuration file containing your customizations. If you do not have one, see xref:producing-ign.adoc[Producing an Ignition File].++You also need to have access to an https://cloud.ibm.com/login[IBM Cloud account]. The examples below use the https://cloud.ibm.com/docs/cli?topic=cli-getting-started[`ibmcloud`] command-line tool, which must be separately installed and configured beforehand. There are also several pieces that need to be in place first, like a VPC, SSH keys, networks, permissions, etc.. Unfortunately, this guide is not a comprehensive IBM Cloud guide. If you are new to IBM Cloud please familiarize yourself using https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started[the documentation for VPC Gen2] first.

s/etc../etc./ ?

dustymabe

comment created time in 2 days

Pull request review commentcoreos/fedora-coreos-docs

provisioning: add instructions for IBM Cloud

+= Provisioning Fedora CoreOS on IBM Cloud++This guide shows how to provision new Fedora CoreOS (FCOS) instances in IBM Cloud VPC Generation 2.++== Prerequisites++Before provisioning a FCOS instance, you must have an Ignition configuration file containing your customizations. If you do not have one, see xref:producing-ign.adoc[Producing an Ignition File].++You also need to have access to an https://cloud.ibm.com/login[IBM Cloud account]. The examples below use the https://cloud.ibm.com/docs/cli?topic=cli-getting-started[`ibmcloud`] command-line tool, which must be separately installed and configured beforehand. There are also several pieces that need to be in place first, like a VPC, SSH keys, networks, permissions, etc.. Unfortunately, this guide is not a comprehensive IBM Cloud guide. If you are new to IBM Cloud please familiarize yourself using https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started[the documentation for VPC Gen2] first.++Regarding the `ibmcloud` CLI, it is worth noting that it is supported to run the CLI https://cloud.ibm.com/docs/cli?topic=cli-using-idt-from-docker[via a container]. You'll need both the `cloud-object-storage` and `infrastructure-service` plugins installed. This can be done with:++ * `ibmcloud plugin install cloud-object-storage`+ * `ibmcloud plugin install infrastructure-service`++After you've logged in using `ibmcloud login` you can set a target region:++.Target a specific region+[source, bash]+----+REGION='us-east' # run `ibmcloud regions` to view options+ibmcloud target -r $REGION+----++=== Creating an Image++The following sets of commands will show you how to download the most recent image for a stream, upload it to cloud storage, and then create the cloud image in IBM Cloud. It is worth noting that Fedora CoreOS comes in three streams, with different update schedules per stream. These steps show the `stable` stream as an example, but can be used for other streams too.+++.Fetch the latest image suitable for your target stream (or https://getfedora.org/coreos/download/[download and verify] it from the web).+[source, bash]+----+STREAM='stable'+coreos-installer download -s "${STREAM}" -p ibmcloud -f qcow2.xz --decompress+----++.Create a Service Account for uploading and an Authorization Policy to allow creating images from the uploaded objects.+[source, bash]+----+BUCKET='my-unique-bucket'+ibmcloud resource service-instance-create "${BUCKET}-service-instance" cloud-object-storage standard global++SERVICE_INSTANCE_ID='25df0db0-89a4-4cb8-900f-ed8b44259f80' # from just created service account+ibmcloud iam authorization-policy-create is --source-resource-type image cloud-object-storage Reader --target-service-instance-id $SERVICE_INSTANCE_ID +----++.Upload the fetched image file to IBM Cloud Object Storage.+[source, bash]+----+FCOS_VERSION='...'+FILE=fedora-coreos-${FCOS_VERSION}-ibmcloud.x86_64.qcow2+ibmcloud cos create-bucket --bucket $BUCKET --ibm-service-instance-id $SERVICE_INSTANCE_ID+ibmcloud cos upload --bucket=$BUCKET --key=$FILE --file=$FILE+----++.Create the image from the storage object.+[source, bash]+----+IMAGE=${FILE:0:-6}     # pull off .qcow2+IMAGE=${IMAGE//[._]/-} # replace . and _ with -+ibmcloud is image-create $IMAGE --file "cos://${REGION}/${BUCKET}/${FILE}" --os-name centos-7-amd64+----++NOTE: Specifying `--os-name centos-7-amd64` is required for now until IBM expands the list of OS types.++You'll have to wait for the image creation process to and now show up as `pending`. Before you can use the image. Monitor with the following command:

I think something went wrong with this sentence, possibly some copy-paste mixup?

dustymabe

comment created time in 2 days

Pull request review commentcoreos/fedora-coreos-docs

provisioning: add instructions for IBM Cloud

+= Provisioning Fedora CoreOS on IBM Cloud++This guide shows how to provision new Fedora CoreOS (FCOS) instances in IBM Cloud VPC Generation 2.++== Prerequisites++Before provisioning a FCOS instance, you must have an Ignition configuration file containing your customizations. If you do not have one, see xref:producing-ign.adoc[Producing an Ignition File].++You also need to have access to an https://cloud.ibm.com/login[IBM Cloud account]. The examples below use the https://cloud.ibm.com/docs/cli?topic=cli-getting-started[`ibmcloud`] command-line tool, which must be separately installed and configured beforehand. There are also several pieces that need to be in place first, like a VPC, SSH keys, networks, permissions, etc.. Unfortunately, this guide is not a comprehensive IBM Cloud guide. If you are new to IBM Cloud please familiarize yourself using https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started[the documentation for VPC Gen2] first.++Regarding the `ibmcloud` CLI, it is worth noting that it is supported to run the CLI https://cloud.ibm.com/docs/cli?topic=cli-using-idt-from-docker[via a container]. You'll need both the `cloud-object-storage` and `infrastructure-service` plugins installed. This can be done with:++ * `ibmcloud plugin install cloud-object-storage`+ * `ibmcloud plugin install infrastructure-service`++After you've logged in using `ibmcloud login` you can set a target region:++.Target a specific region+[source, bash]+----+REGION='us-east' # run `ibmcloud regions` to view options+ibmcloud target -r $REGION

Nit: I think ibmcloud login -r ${REGION} --apikey @my-key.json is equivalent here and also covers the API-login step (but please double-check that it also affects commands further below).

dustymabe

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentvmware/vmw-guestinfo

vmcheck: allow ignoring iopl errors

 import ( // Get the CPU ID low level leaf values. func cpuid_low(arg1, arg2 uint32) (eax, ebx, ecx, edx uint32) -// IsVirtualWorld returns true if running in a VM and the backdoor is available.-func IsVirtualWorld() (bool, error) {+// IsVirtualWorld returns `true` if running in a VM and the backdoor is available.+// It also tries to elevate I/O privileges for the calling thread, which in+// some cases may be forbidden by the system (e.g Linux in `kernel_lockdown` mode+// does not allow `iopl` calls); the `ignoreAccessErrors` parameter allows+// to control library behavior in order to threat such errors as non-fatal.

Good catch! I've directly amended the typo in the existing commit.

lucab

comment created time in 2 days

PullRequestReviewEvent

delete branch lucab/afterburn

delete branch : ups/ssh-openstack

delete time in 2 days

push eventlucab/vmw-guestinfo

Luca BRUNO

commit sha f4349affeb83672548213feb63341fade2b28913

vmcheck: allow ignoring iopl errors This introduces an additional flag for the VM-checking logic, in order to allow consuming applications to keep going when changing I/O access level is not alloewd (see `kernel_lockdown(7)` on Linux). In most cases the library may work without higher I/O level, and actual failures can be handled via normal error-handling on RPC methods.

view details

push time in 2 days

issue commentcoreos/ignition

Consider supporting .d directory for base config fragments

This looks like a useful generalization of the base.ign + user.ign merge :+1:. Among other things, right now base & user configs are explicitly identified by kind. @bgilbert were you planning to have separate base.d and user.d paths, or to only touch the former, or to get rid of the split, or something else?

bgilbert

comment created time in 2 days

pull request commentcoreos/fedora-coreos-cincinnati

Send 400 instead of 500 for unsupported basearch

@tomleb code looks fine, but this needs a cargo fmt pass to make CI happy.

tomleb

comment created time in 2 days

Pull request review commentcoreos/fedora-coreos-cincinnati

Send 400 instead of 500 for unsupported basearch

 pub(crate) async fn gb_serve_graph(      let cached_graph = addr.send(scraper::GetCachedGraph { stream }).await??; -    let arch_graph = policy::pick_basearch(cached_graph, basearch)?;+    let arch_graph = match policy::pick_basearch(cached_graph, basearch) {+        Err(err) => return Ok(HttpResponse::BadRequest().body(err.to_string())),

Zincati is fine with empty errors. For reference, the plaintext error would have been fine too, but it would have been discarded as not matching the expected JSON format, so it was mostly pointless.

tomleb

comment created time in 2 days

PullRequestReviewEvent

issue commentcoreos/fedora-coreos-cincinnati

Unsupported basearch leads to 500 internal error

@tomleb no problems, happy to merge that if it makes the flow less surprising, I was just missing the whole context about the ticket thus asking for more hints :)

tomleb

comment created time in 2 days

PR opened coreos/zincati

cargo: update actix to latest version area/dependencies

This updates to actix-0.10 and adapts the existing code to the new API.

+98 -280

0 comment

3 changed files

pr created time in 2 days

create barnchlucab/zincati

branch : ups/deps-bump-actix

created branch time in 2 days

pull request commentcoreos/afterburn

sshkeys: activate service on OpenStack

/cc @dustymabe

lucab

comment created time in 2 days

PR opened coreos/afterburn

Reviewers
sshkeys: activate service on OpenStack kind/enhancement platform/openstack

This adds triggering condition to SSH-keys service units on OpenStack.

+2 -1

0 comment

1 changed file

pr created time in 2 days

create barnchlucab/afterburn

branch : ups/ssh-openstack

created branch time in 2 days

push eventcoreos/fedora-coreos-docs

Timothée Ravier

commit sha 1f086ccf239bd142e65d58d706d5ee661d95467d

Add link to Afterburn and improve sidebar link text (#184) * nav: Add link to Afterburn docs * nav: Improve projects docs naming and link names

view details

push time in 2 days

pull request commentcoreos/fedora-coreos-config

`core` user: specifically enable afterburn-sshkeys@core.service

Overall this is ok to land, but it's quite likely that we make uncoordinated changes when merging/ratcheting this, thus ending up with behavioral side-effects in RHCOS. Before merging this, @bh7cw it would be great if you could:

  1. already prepare and get merged the override in RHCOS config repo
  2. add a README here pointing back to that copy to be kept in sync
bh7cw

comment created time in 2 days

PullRequestReviewEvent
more