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

coreos/rpm-ostree 364

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

ctz/hyper-rustls 84

Integration between hyper HTTP library and rustls TLS stack

coreos/torcx 74

torcx is a boot-time addon manager for immutable systems

eurecom-s3/hdd_firmware_tools 57

Tools for viewing and extracting HDD firmware files

eurecom-s3/actaeon 36

Memory forensics of virtualization environments

lucab/caps-rs 16

A pure-Rust library to work with Linux capabilities

lucab/adns 15

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

lucab/artoolkit 12

SVN mirror for artoolkit

coreos/fedora-coreos-docs 7

Documentation for Fedora CoreOS

coreos/tectonic-torcx 4

Mediate the interaction between Tectonic and Torcx

delete branch lucab/zincati

delete branch : ups/http-timeouts

delete time in 3 hours

push eventcoreos/zincati

Luca BRUNO

commit sha 41cf56119a74d19aa07aa63dfbd25123c12207c2

cincinnati: add completion timeout to HTTP requests This adds a total completion timeout of 30 minutes to all HTTP requests for the Cincinnati client.

view details

Luca BRUNO

commit sha 2eecba65c8b7496c2b064604b272a052271a4c39

fleet_lock: add completion timeout to HTTP requests This adds a total completion timeout of 30 minutes to all HTTP requests for the FleetLock client.

view details

Luca Bruno

commit sha e298d2f63cca8639555ee42e6e7983cd25add693

Merge pull request #226 from lucab/ups/http-timeouts zincati: add completion timeout to HTTP requests

view details

push time in 3 hours

PR merged coreos/zincati

zincati: add completion timeout to HTTP requests area/cincinnati area/updates kind/enhancement

This adds a total completion timeout of 30 minutes to all HTTP requests for the Cincinnati and FleetLock clients.

+16 -2

1 comment

2 changed files

lucab

pr closed time in 3 hours

pull request commentcoreos/fedora-coreos-config

manifest: add in a few utilities

For the other half of the PR: lsof is something I would expect to have for emergency debugging, and I haven't seen many creative scripting abuses of that, :+1: from my side.

dustymabe

comment created time in 3 hours

pull request commentcoreos/fedora-coreos-config

manifest: add in a few utilities

From an out-of-band chat: bash has a built-in for time.

$ help time
time: time [-p] pipeline
    Report time consumed by pipeline's execution.
    
    Execute PIPELINE and print a summary of the real time, user CPU time,
    and system CPU time spent executing PIPELINE when it terminates.
    
    Options:
      -p        print the timing summary in the portable Posix format
    
    The value of the TIMEFORMAT variable is used as the output format.
    
    Exit Status:
    The return status is the return status of PIPELINE.
dustymabe

comment created time in 4 hours

issue commentcamallo/dkregistry-rs

Support tagged digested references

Indeed. Related, it would probably be a good idea to first address this TODO item for parsing references: https://github.com/camallo/dkregistry-rs/blob/cb22b538d788f7a88bf390e34bece4a503cefecb/src/reference.rs#L156

glyn

comment created time in 9 hours

PR opened coreos/zincati

Reviewers
cincinnati: add completion timeout to HTTP requests area/cincinnati area/updates kind/enhancement

This adds a total completion timeout of 30 minutes to all HTTP requests for the Cincinnati and FleetLock clients.

+16 -2

0 comment

2 changed files

pr created time in 9 hours

pull request commentcoreos/zincati

cincinnati: add completion timeout to HTTP requests

/cc @jlebon for review

lucab

comment created time in 9 hours

create barnchlucab/zincati

branch : ups/http-timeouts

created branch time in 9 hours

PullRequestEvent

PR closed coreos/afterburn

providers: add experimental initrd network bootstrap platform/ibmcloud

This adds initial/experimental support for bootstrapping the network in the initrd. It is meant to support weird cloud providers where DHCP is not available or not enough. This feature is currently reachable as a dedicated exp rd-net-bootstrap subcommand.

+306 -74

0 comment

8 changed files

lucab

pr closed time in 9 hours

delete branch lucab/fedora-coreos-cincinnati

delete branch : ups/scraper-http-timeouts

delete time in 11 hours

push eventcoreos/fedora-coreos-cincinnati

Luca BRUNO

commit sha 130fcdb3d1e72c9099643f360ae6bc8de403beb3

scraper: add an upper bound timeout to HTTP requests This adds a very large timeout (4 hours) to all HTTP requests, as they currently default to none. It is meant to almost never trigger, except under pathological network conditions. In such cases, it should help detecting issues by explicitly erroring out instead of hanging forever.

view details

Luca Bruno

commit sha 73711c0a204514217744344a8b886c0e0e559e74

Merge pull request #10 from lucab/ups/scraper-http-timeouts scraper: add an upper bound timeout to HTTP requests

view details

push time in 11 hours

PR merged coreos/fedora-coreos-cincinnati

scraper: add an upper bound timeout to HTTP requests

This adds a very large timeout (4 hours) to all HTTP requests, as they currently default to none. It is meant to almost never trigger, except under pathological network conditions. In such cases, it should help detecting issues by explicitly erroring out instead of hanging forever.

+8 -1

0 comment

1 changed file

lucab

pr closed time in 11 hours

push eventlucab/fedora-coreos-cincinnati

Luca BRUNO

commit sha 130fcdb3d1e72c9099643f360ae6bc8de403beb3

scraper: add an upper bound timeout to HTTP requests This adds a very large timeout (4 hours) to all HTTP requests, as they currently default to none. It is meant to almost never trigger, except under pathological network conditions. In such cases, it should help detecting issues by explicitly erroring out instead of hanging forever.

view details

push time in 3 days

Pull request review commentcoreos/fedora-coreos-cincinnati

scraper: add an upper bound timeout to HTTP requests

 use reqwest::Method; use std::num::NonZeroU64; use std::time::Duration; +/// Default timeout for HTTP requests (4 hours).+const DEFAULT_HTTP_REQ_TIMEOUT: Duration = Duration::from_secs(4 * 60 * 60);

From an out-of-band discussion: we expect the responses to be short and quick to complete, as we are only grabbing JSON metadata. 4h is overly large, to the point that it impacts our release work if the backend is hanging for such a long time. Going for 30 minutes instead (@56kbps it would still fit 12 MiB).

lucab

comment created time in 3 days

pull request commentcoreos/fedora-coreos-docs

Add some troubleshooting steps for access recovery

@jlebon can we maybe remove all the password-setting references and just stick to show the SSH flow? I'm worried users could end with forgotten weak temporary passwords.

Also, I'm somehow surprised that init=sh still manages to boot into rootfs given all the missing things from systemd and rpm-ostree. Did you try this on a recent FCOS?

jlebon

comment created time in 3 days

pull request commentcoreos/fedora-coreos-docs

bare-metal: document live ISO memory requirement

It looks like we'd prefer holding this for a bit then.

lucab

comment created time in 3 days

delete branch lucab/fedora-coreos-docs

delete branch : ups/faq-refresh

delete time in 3 days

push eventcoreos/fedora-coreos-docs

Luca Bruno

commit sha 1bcef2b90005c5b0791b1ab5f915cb4e2b78c838

faq: refresh with current details (#47) This updates the FAQ page with fresh details about the current status.

view details

push time in 3 days

PR merged coreos/fedora-coreos-docs

Reviewers
faq: refresh with current details

This updates the FAQ page with fresh details about the current status.

+18 -23

0 comment

1 changed file

lucab

pr closed time in 3 days

pull request commenttokio-rs/tokio

runtime: lazily detect number of CPUs

@carllerche I was briefly thinking about that, but it seems that at least on Linux, CPU hotplugging is a thing (especially on VMs). I feel it may make more sense to leave caching duties (more importantly, refresh/invalidation) to the consumers.

To be honest, I only stepped on this coming from https://github.com/seanmonstar/reqwest/pull/807, where that is not even a concern.

lucab

comment created time in 3 days

PR opened seanmonstar/reqwest

blocking: opt-out CPUs auto-detection in debug mode

This tweaks the tokio runtime checker (only used in debug mode) in order to use a single thread. Performing the CPUs auto-detection step on each check adds significant syscall-tracing noise and runtime latency. This completely skips it.

Ref: https://github.com/tokio-rs/tokio/pull/2238

+1 -0

0 comment

1 changed file

pr created time in 3 days

create barnchlucab/reqwest

branch : ups/debug-tokio-rt

created branch time in 3 days

pull request commentcoreos/afterburn

build(deps): bump serde_json from 1.0.47 to 1.0.48

@dependabot-bot merge

dependabot-preview[bot]

comment created time in 3 days

Pull request review commentcoreos/fedora-coreos-cincinnati

scraper: add an upper bound timeout to HTTP requests

 use reqwest::Method; use std::num::NonZeroU64; use std::time::Duration; +/// Default timeout for HTTP requests (4 hours).+const DEFAULT_HTTP_REQ_TIMEOUT: Duration = Duration::from_secs(4 * 60 * 60);

It's just an arbitrary overlarge value which in my brain I can safely approximate to "insanely long".

But notably, this is a completion timeout not a first-reply one. That is, it is an hard arbitrary upper limit we are placing on how big/slow a positive response can be.

Plus, we are not going to exit but just proceed with the next scraping loop, increasing the error-counter metrics (we don't track this metrics right now).

lucab

comment created time in 4 days

PR opened coreos/fedora-coreos-docs

Reviewers
faq: refresh with current details

This updates the FAQ page with fresh details about the current status.

+18 -23

0 comment

1 changed file

pr created time in 4 days

create barnchlucab/fedora-coreos-docs

branch : ups/faq-refresh

created branch time in 4 days

issue closedcoreos/fedora-coreos-tracker

Release Notes for New Images

I just saw new Live ISO is available to download, where we can find release notes, whats fixed in it or what feature is introduced?

closed time in 4 days

imranrazakhan

issue commentcoreos/fedora-coreos-tracker

Release Notes for New Images

Please do note that we have a discussion forum for questions at https://discussion.fedoraproject.org/c/server/coreos.

Specifically on release notes, we still don't have a proper flow in place but we are discussing approaches at https://github.com/coreos/fedora-coreos-tracker/issues/194. Closing as a duplicate of that.

imranrazakhan

comment created time in 4 days

PR opened coreos/fedora-coreos-cincinnati

scraper: add an upper bound timeout to HTTP requests

This adds a very large timeout (4 hours) to all HTTP requests, as they currently default to none. It is meant to almost never trigger, except under pathological network conditions. In such cases, it should help detecting issues by explicitly erroring out instead of hanging forever.

+8 -1

0 comment

1 changed file

pr created time in 4 days

create barnchlucab/fedora-coreos-cincinnati

branch : ups/scraper-http-timeouts

created branch time in 4 days

PR opened coreos/fedora-coreos-docs

bare-metal: document live ISO memory requirement

This documents the minimum memory requirement for booting a live ISO system. The current actual usage is slightly larger than 2 GiB, so I just round up to the closest integer for a reasonable margin.

Closes: https://github.com/coreos/fedora-coreos-tracker/issues/388

+6 -6

0 comment

1 changed file

pr created time in 4 days

create barnchlucab/fedora-coreos-docs

branch : ups/live-iso-ram

created branch time in 4 days

issue commentcoreos/afterburn

ibmcloud: make auto-detection logic concurrent

Closing in favor of https://github.com/coreos/afterburn/issues/355.

lucab

comment created time in 4 days

issue closedcoreos/afterburn

ibmcloud: make auto-detection logic concurrent

This ticket is a work item for the following TODO note: https://github.com/coreos/afterburn/blob/dba86a4a59255fd68d21589503ffb9a1f64d22f6/src/providers/ibmcloud/mod.rs#L23-L24

This is only relevant for ibmcloud Classic users, resulting in a unnecessary delay of a few seconds.

closed time in 4 days

lucab

issue openedcoreos/afterburn

ibmcloud: split Classic logic to a dedicated platform

Followup to https://github.com/coreos/coreos-assembler/issues/1119#issuecomment-584539165.

We decided to go in a different direction and move Classic logic to a dedicated platform ID ibmcloud-classic.

created time in 4 days

PR opened coreos/fedora-coreos-docs

platforms: allocate ID for ibmcloud-classic

DRAFT: it is unclear whether we want to provide RHCOS/FCOS on Classic instances, due to overall limitations of Classic infrastructure. Just claiming a placeholder ID for now.


This adds ibmcloud-classic as the platform ID for IBM Cloud Classic instances.

Ref: https://github.com/coreos/coreos-assembler/issues/1119#issuecomment-584539165

+1 -0

0 comment

1 changed file

pr created time in 4 days

create barnchlucab/fedora-coreos-docs

branch : ups/platforms-ibmcloud-classic

created branch time in 4 days

issue commentcoreos/fedora-coreos-tracker

Failed to isolate default target.

Thanks for the report. It looks like the issue is that the initial VM did not have enough memory. We should better document that requirement for the live ISO. Can you maybe check if 3 GiB are enough?

ssoor

comment created time in 4 days

issue commentcoreos/fedora-coreos-tracker

couldn't find boot device for /dev/sda

Thanks for the report. Is this perhaps a duplicate of https://github.com/coreos/fedora-coreos-tracker/issues/385?

ssoor

comment created time in 4 days

PR opened coreos/coreos-installer

Reviewers
source: add an upper bound timeout to HTTP requests kind/enhancement

This adds a very large timeout (4 hours) to all HTTP requests, as they currently default to none. It is meant to almost never trigger, except under pathological network conditions. In such cases, it should help detecting issues by explicitly erroring out instead of hanging forever.

+26 -4

0 comment

1 changed file

pr created time in 4 days

create barnchlucab/coreos-installer

branch : ups/http-timeouts

created branch time in 4 days

PR opened tokio-rs/tokio

runtime: lazily detect number of CPUs

This tweaks the runtime builder default to defer and lazily auto-detect the number of CPUs. This is done in order to avoid performing useless operations which may be expensive on some platforms (e.g. Linux, where it is coupled to CPU frequency probing).

Ref: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d5905dc14a87805a59f3c5bf70173aac2bb18f8


Motivation

On Linux systems, creating a runtime::Builder and setting a fixed number of core_threads results in a number of useless syscalls to read /proc/cpuinfo. This becomes noticeable when building a large number of runtimes.

Solution

Do not perform auto-detection upfront, but lazily perform it only if a fixed number of worker threads was not specified.

+8 -7

0 comment

1 changed file

pr created time in 4 days

create barnchlucab/tokio

branch : ups/lazy-num-cpus

created branch time in 4 days

issue commentseanmonstar/num_cpus

Test/document cgroups behavior

Relevant related logic from OpenJDK 15: https://github.com/openjdk/jdk/blob/jdk-15%2B0/src/hotspot/os/linux/os_linux.cpp#L5391-L5403

olix0r

comment created time in 4 days

fork lucab/tokio

A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...

https://tokio.rs

fork in 4 days

pull request commentcoreos/zincati

build(deps): bump serde_json from 1.0.47 to 1.0.48

@dependabot merge

dependabot-preview[bot]

comment created time in 4 days

issue commentcoreos/fedora-coreos-tracker

Any plan to publish fedore-coreos on aws cn-northwest-1 region?

Indeed, sorry for omitting those details. If we intend to stick to this plan of not publishing to China/GovCloud, we should probably have a FAQ entry with the whole explanation and directions.

MartinForReal

comment created time in 5 days

issue commentcoreos/fedora-coreos-streams

stable: new release on 2020-02-11 (31.20200127.3.0)

@jlebon yes, I took a note to investigate where are the missing timeouts and add them.

dustymabe

comment created time in 5 days

issue commentcoreos/fedora-coreos-streams

stable: new release on 2020-02-11 (31.20200127.3.0)

Scraper (only the stable one) got stuck on some network request. Restarted the service, graph looks fine now.

dustymabe

comment created time in 5 days

push eventcoreos/ignition

Luca BRUNO

commit sha 3980d54f64066839e0bb98bcabb493129cef1ac0

docs: minor fixes to platforms page This fixes a few outdated names and missing links on the "Supported Platforms" doc page.

view details

Luca Bruno

commit sha 6238f4ecb8d806e0dd92be0a5e0236aa912b36ac

Merge pull request #921 from lucab/ups/docs-platforms docs: minor fixes to platforms page

view details

push time in 5 days

PR merged coreos/ignition

Reviewers
docs: minor fixes to platforms page kind/cleanup

This fixes a few outdated names and missing links on the "Supported Platforms" doc page.

+11 -6

0 comment

1 changed file

lucab

pr closed time in 5 days

issue commentcoreos/fedora-coreos-tracker

Any plan to publish fedore-coreos on aws cn-northwest-1 region?

I think the current answer here is "no", and same goes for GovCloud. Within AWS, they both are separate partitions (not just regions) which require dedicated handling.

Last status update on this was at https://github.com/coreos/fedora-coreos-tracker/issues/149#issuecomment-584244583.

MartinForReal

comment created time in 5 days

issue closedcoreos/zincati

Release 0.0.8

Release process

This project uses cargo-release in order to prepare new releases, tag and sign relevant git commit, and publish the resulting artifacts to crates.io. The release process follows the usual PR-and-review flow, allowing an external reviewer to have a final check before publishing.

Requirements

This guide requires:

  • a web browser (and network connectivity)
  • git
  • GPG setup and personal key for signing
  • cargo (suggested: latest stable toolchain from rustup)
  • cargo-release (suggested: cargo install -f cargo-release)
  • A verified account on crates.io
  • Write access to this GitHub project

Release checklist

These steps show how to release version x.y.z on the origin remote (this can be checked via git remote -av). Push access to the upstream repository is required in order to publish the new tag and the PR branch.

  • make sure the project is clean and prepare the environment:
    • [x] cargo test
    • [x] cargo clean
    • [x] git clean -fd
    • [x] export RELEASE_VER=x.y.z
    • [x] export UPSTREAM_REMOTE=origin

:warning:: UPSTREAM_REMOTE should reference the locally configured remote that points to the upstream git repository.

  • create release commits on a dedicated branch and tag it:

    • [x] git checkout -b release-${RELEASE_VER}
    • [x] cargo release (and confirm the version when prompted)
  • open a PR for this release

    • [x] git push ${UPSTREAM_REMOTE} release-${RELEASE_VER}
    • [x] open a web browser and create a PR for the branch above
    • [x] make sure the resulting PR contains exactly two commits
    • [x] in the PR body, write a short changelog with relevant changes since last release
  • [x] get the PR reviewed, approved and merged

  • publish the artifacts (tag and crate)

    • [x] git push ${UPSTREAM_REMOTE} ${RELEASE_VER}
    • [x] make sure the upstream tag matches the local tag: git fetch --tags --verbose ${UPSTREAM_REMOTE} 2>&1 | grep ${RELEASE_VER}
    • [x] git checkout ${RELEASE_VER}
    • [x] make sure the tag is what you intend to release; if so this will show an empty output: git diff release-${RELEASE_VER}~1 ${RELEASE_VER}
    • [x] cargo publish
  • publish the release:

    • [x] open a web browser and create a GitHub Release for the tag above
    • [x] write a short changelog (i.e. re-use the PR content) and publish the release
  • clean up the local environment (optional, but recommended):

    • [x] cargo clean
    • [x] git checkout master
    • [x] git pull ${UPSTREAM_REMOTE} master
    • [x] git push ${UPSTREAM_REMOTE} :release-${RELEASE_VER}
    • [x] unset RELEASE_VER
    • [x] unset UPSTREAM_REMOTE

closed time in 5 days

lucab

delete branch coreos/zincati

delete branch : release-0.0.8

delete time in 5 days

release coreos/zincati

v0.0.8

released time in 5 days

issue commentcoreos/fedora-coreos-tracker

platform: add support for Hyper-V

Self-note: values in the key-value store are limited to 2KiB, see https://github.com/torvalds/linux/blob/6f0d349d922ba44e4348a17a78ea51b7135965b1/include/uapi/linux/hyperv.h#L178.

lucab

comment created time in 5 days

created tagcoreos/zincati

tagv0.0.8

Updates agent for Fedora CoreOS

created time in 6 days

push eventcoreos/zincati

Luca BRUNO

commit sha da51b553a3e1d492ce53ce583b9672d2ff3c76f5

cargo: zincati release 0.0.8

view details

Luca BRUNO

commit sha 81fdae0dce845d793f7ba70fa04fbbff710eaf83

cargo: development version bump

view details

Luca Bruno

commit sha ddf97e7cf72e060816d0139b310f50757f56932a

Merge pull request #224 from coreos/release-0.0.8 Release 0.0.8

view details

push time in 6 days

PR merged coreos/zincati

Release 0.0.8 kind/release

Changes:

  • cargo: fix release metadata
  • config: add agent timing knobs
  • ci: add a clippy run to travis
  • zincati: use system proxy in HTTP clients
  • update_agent: make intervals state specific
  • docs: update metrics example
  • docs: minor fixes to release checklist

Tracker: https://github.com/coreos/zincati/milestone/5

+2 -2

0 comment

2 changed files

lucab

pr closed time in 6 days

PR opened coreos/zincati

Reviewers
Release 0.0.8 kind/release

Changes:

  • cargo: fix release metadata
  • config: add agent timing knobs
  • ci: add a clippy run to travis
  • zincati: use system proxy in HTTP clients
  • update_agent: make intervals state specific
  • docs: update metrics example
  • docs: minor fixes to release checklist

Tracker: https://github.com/coreos/zincati/milestone/5

+2 -2

0 comment

2 changed files

pr created time in 6 days

create barnchcoreos/zincati

branch : release-0.0.8

created branch time in 6 days

push eventcoreos/zincati

Luca BRUNO

commit sha 7627b5ec665467a3e91cbcf9cf3f44eeced1bd9c

cargo: fix release metadata This fixes manifest metadata for latest `cargo-release`.

view details

Luca Bruno

commit sha 6b85a1ddb01c5a803d04a6cc96e9da9c34dd2f4e

Merge pull request #222 from lucab/ups/cargo-release-metadata cargo: fix release metadata

view details

push time in 6 days

PR merged coreos/zincati

cargo: fix release metadata kind/cleanup

This fixes manifest metadata for latest cargo-release.

+1 -2

0 comment

1 changed file

lucab

pr closed time in 6 days

pull request commentcoreos/zincati

[security] build(deps): bump http from 0.1.20 to 0.2.0

Blocked by https://github.com/coreos/zincati/issues/223.

dependabot-preview[bot]

comment created time in 6 days

pull request commentcoreos/zincati

build(deps): bump actix from 0.8.3 to 0.9.0

Blocked by https://github.com/coreos/zincati/issues/223.

dependabot-preview[bot]

comment created time in 6 days

pull request commentcoreos/zincati

build(deps): bump reqwest from 0.9.24 to 0.10.1

Blocked by https://github.com/coreos/zincati/issues/223.

dependabot-preview[bot]

comment created time in 6 days

pull request commentcoreos/zincati

build(deps): bump tokio from 0.1.22 to 0.2.11

Blocked by https://github.com/coreos/zincati/issues/223.

dependabot-preview[bot]

comment created time in 6 days

pull request commentcoreos/zincati

build(deps): bump futures from 0.1.29 to 0.3.4

Blocked by https://github.com/coreos/zincati/issues/223.

dependabot-preview[bot]

comment created time in 6 days

issue openedcoreos/zincati

zincati: port to futures-0.3

There is an API bump for futures-0.3 pending at https://github.com/coreos/zincati/pull/216. This will in turn unblock all the other queued dependency bumps (tokio+reqwest+actix).

Unfortunately this requires some invasive changes to port the codebase to stdlib futures and to new API for all dependencies. Additionally, it will need to go in a single shot due to dependency coupling.

created time in 6 days

Pull request review commentopenshift/cincinnati

Changing the HTTP response of readiness probe to 503 when not available

 pub async fn serve_liveness(app_data: actix_web::web::Data<State>) -> Fallible<H /// /// Status: ///  * Ready (200 code): a JSON graph as the result of a successful scrape is available.-///  * Not Ready (500 code): no JSON graph available yet.+///  * Service Unavailable (503 code): no JSON graph available yet.

The docstring is meant to describe the semantics of the result ("ready" or "not ready"), not the meaning of the HTTP code.

LalatenduMohanty

comment created time in 6 days

issue commentcoreos/zincati

Release 0.0.8

I had to pause mid-way to fix https://github.com/coreos/zincati/pull/222.

lucab

comment created time in 6 days

PR opened coreos/zincati

cargo: fix release metadata kind/cleanup

This fixes manifest metadata for latest cargo-release.

+1 -2

0 comment

1 changed file

pr created time in 6 days

create barnchlucab/zincati

branch : ups/cargo-release-metadata

created branch time in 6 days

issue openedcoreos/zincati

Release 0.0.8

Release process

This project uses cargo-release in order to prepare new releases, tag and sign relevant git commit, and publish the resulting artifacts to crates.io. The release process follows the usual PR-and-review flow, allowing an external reviewer to have a final check before publishing.

Requirements

This guide requires:

  • a web browser (and network connectivity)
  • git
  • GPG setup and personal key for signing
  • cargo (suggested: latest stable toolchain from rustup)
  • cargo-release (suggested: cargo install -f cargo-release)
  • A verified account on crates.io
  • Write access to this GitHub project

Release checklist

These steps show how to release version x.y.z on the origin remote (this can be checked via git remote -av). Push access to the upstream repository is required in order to publish the new tag and the PR branch.

  • make sure the project is clean and prepare the environment:
    • [ ] cargo test
    • [ ] cargo clean
    • [ ] git clean -fd
    • [ ] export RELEASE_VER=x.y.z
    • [ ] export UPSTREAM_REMOTE=origin

:warning:: UPSTREAM_REMOTE should reference the locally configured remote that points to the upstream git repository.

  • create release commits on a dedicated branch and tag it:

    • [ ] git checkout -b release-${RELEASE_VER}
    • [ ] cargo release (and confirm the version when prompted)
  • open a PR for this release

    • [ ] git push ${UPSTREAM_REMOTE} release-${RELEASE_VER}
    • [ ] open a web browser and create a PR for the branch above
    • [ ] make sure the resulting PR contains exactly two commits
    • [ ] in the PR body, write a short changelog with relevant changes since last release
  • [ ] get the PR reviewed, approved and merged

  • publish the artifacts (tag and crate)

    • [ ] git push ${UPSTREAM_REMOTE} ${RELEASE_VER}
    • [ ] make sure the upstream tag matches the local tag: git fetch --tags --verbose ${UPSTREAM_REMOTE} 2>&1 | grep ${RELEASE_VER}
    • [ ] git checkout ${RELEASE_VER}
    • [ ] make sure the tag is what you intend to release; if so this will show an empty output: git diff release-${RELEASE_VER}~1 ${RELEASE_VER}
    • [ ] cargo publish
  • publish the release:

    • [ ] open a web browser and create a GitHub Release for the tag above
    • [ ] write a short changelog (i.e. re-use the PR content) and publish the release
  • clean up the local environment (optional, but recommended):

    • [ ] cargo clean
    • [ ] git checkout master
    • [ ] git pull ${UPSTREAM_REMOTE} master
    • [ ] git push ${UPSTREAM_REMOTE} :release-${RELEASE_VER}
    • [ ] unset RELEASE_VER
    • [ ] unset UPSTREAM_REMOTE

created time in 6 days

delete branch lucab/zincati

delete branch : ups/agent-timing

delete time in 6 days

push eventcoreos/zincati

Luca BRUNO

commit sha a08598b482c3543df5d1f3cebf25ba249e72e0b7

config: add agent timing knobs This adds support for a new config section `agent.timing` to configure timing-related settings on the agent. It currently has a single knob `steady_interval_secs` to tweak the refresh period while in steady state.

view details

Luca Bruno

commit sha fffcf070184eb636810832cb098a1109cf7db365

Merge pull request #219 from lucab/ups/agent-timing config: add agent timing knobs

view details

push time in 6 days

PR merged coreos/zincati

config: add agent timing knobs area/updates kind/new-feature

This adds support for a new config section agent.timing to configure timing-related settings on the agent. It currently has a single knob steady_interval_secs to tweak the refresh period while in steady state.

Closes: https://github.com/coreos/zincati/issues/203

+76 -5

1 comment

6 changed files

lucab

pr closed time in 6 days

issue closedcoreos/zincati

Allow customizing check frequency

Writing an update test, and I'd like Zincati to be able to check for updates much faster for the purpose of the test. I see there's a related TODO to this:

https://github.com/coreos/zincati/blob/eb55d9364ab5afbc441488c8fede9f2a9279c898/src/update_agent/mod.rs#L157-L160

Config knob works, or if we're not ready to commit to an interface yet, an env var also would be OK.

closed time in 6 days

jlebon

PR opened coreos/ignition

Reviewers
docs: minor fixes to platforms page kind/cleanup

This fixes a few outdated names and missing links on the "Supported Platforms" doc page.

+11 -6

0 comment

1 changed file

pr created time in 6 days

create barnchlucab/ignition

branch : ups/docs-platforms

created branch time in 6 days

issue commentcoreos/fedora-coreos-tracker

Include wireguard-tools package in FCOS

Moved the doc task to https://github.com/coreos/fedora-coreos-docs/issues/43.

However I was not asking how to do it, but if it currently works. Some comments in this thread seems to hint towards a negative answer, and I'd rather avoid ending up in a scenario where people start blogging their own creative workarounds as soon there is wg on the host.

jdoss

comment created time in 6 days

issue openedcoreos/fedora-coreos-docs

user-guides: document wireguard setup via Ignition

This is splitting of my comment from https://github.com/coreos/fedora-coreos-tracker/issues/362#issuecomment-583320187:

Specifically, I'm interested in reaching a final UX flow where Ignition writes NM wireguard profiles (keyfiles) and secret material, and tunnel provisioning works without further custom scripting.

We should have a doc page showing how to perform this with fcct snippets.

created time in 6 days

pull request commentcoreos/coreos-assembler

qemuvariants: add ibmcloud

There is consensus to proceed this way, summarized at https://github.com/coreos/coreos-assembler/issues/1119#issuecomment-584539165.

This is ready for review.

lucab

comment created time in 6 days

issue commentcoreos/coreos-assembler

Producing images for the IBM Cloud chimera

Ack, it looks like there is general consensus to proceed as follow:

  • keep ibmcloud as the platform identifier for IBM Cloud VPC Generation 2
  • explore IBM Cloud Classic under a specific identifier ibmcloud-classic
  • purposely ignore IBM Cloud VPC Generation 1, as it is not relevant to either RHCOS nor FCOS
lucab

comment created time in 6 days

issue commentcoreos/coreos-installer

http/https proxy support?

I think the latest release does not pick up standard env vars, but the current master branch should be fine. https://github.com/coreos/coreos-installer/pull/141 is the PR who changed that.

If you are using coreos-installer from a container, quay.io/coreos/coreos-installer:master should already work. It would be great if you could confirm it, as I don't have a proxied environment at hand to double-check.

Please do note that for NO_PROXY we'll have to wait for https://github.com/seanmonstar/reqwest/issues/705.

bcg62

comment created time in 6 days

issue commentcoreos/fcct

file Mode octal to int conversion: 0600 -> 384

Thanks for the report, however I'm not exactly sure what is the issue you are reporting here. Are you saying that the final file on disk has (octal) mode 0o0384 in octal? Or are you saying that after transpiling you see a "mode": 384 in the Ignition configuration?

The former would be a bug, while the latter is expected per Ignition spec, see https://github.com/coreos/ignition/issues/842.

trexx

comment created time in 6 days

issue commentcoreos/ignition

why decimal vs octal for file permissions

Circling back to this:

but if they ever have to look at them why not use a notation that's familiar?

This cannot be technically done, as it breaks the following invariants:

  • Ignition config must be valid JSON document
  • JSON specs (section 8 of ECMA-404) specifies that numerical values must be in decimal base and without leading zeroes
dustymabe

comment created time in 6 days

Pull request review commentcoreos/zincati

config: add agent timing knobs

+# Configure agent timing.+[agent.timing]++# Pausing interval between updates checks in steady mode, in seconds.+steady_interval_secs = 300

Yes, we can split to another ticket.

I'd say the approach so far has been more similar to https://github.com/systemd/systemd/tree/d900701eeab4a43b6626256226c68ed00a63962d/sysctl.d instead.

We leave a bit of space before (<10) for out-of-repo defaults, and most of the range (>50) for overrides.

As you noted, some in-code defaults are not the same as the config, and just fail validation if the fragment is masked.

lucab

comment created time in 7 days

delete branch lucab/zincati

delete branch : ups/clippy

delete time in 7 days

push eventcoreos/zincati

Luca BRUNO

commit sha 65cbdb57f82363d15371ae3eb18e2c423ca35109

cincinnati: fix clippy warnings

view details

Luca BRUNO

commit sha 6443908da7faa9b8d88972f82e0f1e341cd6882e

fleet_lock: fix clippy warnings

view details

Luca BRUNO

commit sha 2ad904736a0bea91e460f331d1a21ac32c49707c

ci: add a clippy run to travis

view details

Luca Bruno

commit sha 93620378f74337bf01c70df9f2dacb382854c88a

Merge pull request #220 from lucab/ups/clippy ci: add a clippy run to travis

view details

push time in 7 days

PR merged coreos/zincati

ci: add a clippy run to travis area/testing kind/cleanup kind/enhancement

This fixes all existing warnings and adds a clippy job to travis.

+16 -3

1 comment

3 changed files

lucab

pr closed time in 7 days

pull request commentcoreos/zincati

ci: add a clippy run to travis

I think Travis is missing clippy

Indeed, shame on me. CI should be green now.

lucab

comment created time in 7 days

push eventlucab/zincati

Luca BRUNO

commit sha 2ad904736a0bea91e460f331d1a21ac32c49707c

ci: add a clippy run to travis

view details

push time in 7 days

Pull request review commentcoreos/zincati

config: add agent timing knobs

 use prometheus::IntGauge; use std::time::Duration;  /// Default tick/refresh period for the state machine (in seconds).-const DEFAULT_REFRESH_PERIOD_SECS: u64 = 5 * 60;+const DEFAULT_REFRESH_PERIOD_SECS: u64 = 300; // 5 minutes.

clippy followup at https://github.com/coreos/zincati/pull/220.

lucab

comment created time in 7 days

PR opened coreos/zincati

ci: add a clippy run to travis area/testing kind/cleanup kind/enhancement

This fixes all existing warnings and adds a clippy job to travis.

+11 -3

0 comment

3 changed files

pr created time in 7 days

create barnchlucab/zincati

branch : ups/clippy

created branch time in 7 days

more