[continued from previous message]

How is Vessel different from other jail management systems?

There are some awesome jail management systems already. These existing systems do a great job of configuring the jail runtime environment (ZFS dataset, networking, resource control, etc). After the environment is configured though, it is just handed off to the jail program via an exec call.

In addition to jail configuration and creation, Vessel aims to take the next step and implement an event loop to manage jails based on system events. An instance of vessel runs alongside each jail to assist with management. This allows "Fat Jails" and single process jails to run in the foreground and be managed by the vessel-supervisor.

Why make Vessel?

Vessel has been a side project for a few years. I initially started it because it was a fun hobby project and I was surprised something similar did not already exist. It has now become a viable tool that I use for all of my projects. I believe it will be useful to others as well.

Is help needed?

Help is always appreciated. It’s a fun project to work on because it can touch
on so many portions of FreeBSD.

• Just using it and reporting any bugs on GitHub would be very useful.

• Whatever sounds fun. I’m happy to help get people started.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Enable the NFS server to run in a vnet prison

Links:
Source patch for main URL: https://people.freebsd.org/~rmacklem/vnet.patch Simple Setup Doc URL: https://people.freebsd.org/~rmacklem/nfsd-vnet-prison-setup.txt

Contact: Rick Macklem <rmacklem@freebsd.org>

Several users of FreeBSD identified a need to run the NFS server inside a vnet prison. This turned into a small project, where I now have a patch that does this. It is currently available at the above link for testing or on Phabricator as D37519. Without this patch, the NFS server cannot be run in a prison.

Not included in the above patch is the ability to run the rpc.tlsservd(8) and nfsuserd(8) daemons within the vnet prison. I do now have patches that allow these daemons to run in the vnet prison along with mountd(8) and nfsd(8), but I would like to get the above patch into main before adding support for rpc.tlsservd(8) or nfsuserd(8).

At this time, the code needs reviewing and testing. Hopefully this can be completed in the next few weeks, so that the patch can be committed to main and possibly also MFC’d to stable/13.

To do

• Testing the above patch.

• Reviewing the above patch.

• Doing the same for the rpc.tlsservd(8) and nfsuserd(8) patches.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Pytest support for the FreeBSD testing framework

Links:
Initial review URL: https://reviews.freebsd.org/D31084
Test examples URL: https://cgit.freebsd.org/src/tree/tests/examples/test_examples.py

Contact: Alexander Chernikov <melifaro@FreeBSD.org>

Native pytest support for atf(7) enhances the capabilities of the FreeBSD test suite.

Pytest simplifies test writing by reducing the amount of boiler-plate code. It offers several advantages over the existing atf-c and atf-shell bindings. One of the most important ones is the test parametrization, which allows improving coverage with writing nearly no code. The other is a rich assert system, offering detailed errors description. Python atf(7) support comes with a number of libraries that abstract a number of commonly-used tasks. For example, running a test within a VNET jail with epair(4) requires adding a single line of code. Such helpers are especially handy in the networking area, where tests with complex VNET setups are not uncommon.

Current status

Python support has been committed to HEAD. Currently, ~80 tests use the Python framework and the number is rising. Example tests have been committed to show the handling of the typical cases.

Next steps

• Work on increasing the adoption of the framework

• Rewrite some of the older Python/shell tests in the netinet[6] to pytest
(help is appreciated)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Userland

Changes affecting the base system and programs in it.

Base System OpenSSH Update

Links:
OpenSSH URL: https://www.openssh.com/
OpenSSH 9.1 release notes URL: https://www.openssh.com/txt/release-9.1

Contact: Ed Maste <emaste@freebsd.org>

OpenSSH, a suite of remote login and file transfer tools, was updated from version 9.0p1 to 9.1p1 in the FreeBSD base system.

It has been merged to the stable branches, is available in FreeBSD 12.4, and will be in the upcoming FreeBSD 13.2.

A number of bug fixes and minor improvements have been submitted upstream to OpenSSH, and this process will continue with subsequent updates.

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Kernel

Updates to kernel subsystems/features, driver support, filesystems, and more.

Enabling Snapshots on Filesystems Using Journaled Soft Updates

Links:
Milestone 1 Core Changes URL: https://reviews.freebsd.org/D36491

Contact: Kirk McKusick <mckusick@FreeBSD.org>

The goal of this project is to make UFS/FFS filesystem snapshots available when running with journaled soft updates.

First a bit of background. Soft updates have been available for UFS/FFS since the mid 1990s. They eliminate the need for most synchronous disk writes and keep the state of the filesystem sufficiently consistent that it can be put back online after a crash without the need to run fsck(8). However, it may incorrectly assume that some of its blocks are still in use when in fact they are free. So, eventually it is necessary to take the filesystem offline to run fsck(8) to reclaim these lost blocks. The time to run fsck(8) is a function of the number of files in the filesystem and the size of the filesystem. Large filesystems may take hours to complete an fsck(8).

Enabling journaling reduces the time spent by fsck(8) cleaning up a filesystem after a crash to a few seconds. With journaling, the time to recover after a crash is a function of the amount of activity in the filesystem in the minute before the crash. Journaled recovery time is usually only a few seconds and never exceeds a minute.

The drawback to using journaling is that the writes to its log add an extra write load to the media containing the filesystem. Thus a write-intensive workload will have reduced throughput on a filesystem running with journaling.

Like all journaling filesystems, the journal recovery will only fix issues known to the journal. Specifically if a media error occurs, the journal will not know about it and hence will not fix it. Thus when using journaling, it is still necessary to run a full fsck every few months or after a filesystem panic to check for and fix any errors brought on by media failure.

A full fsck(8) is normally done on an offline filesystem. However, it can be done by running fsck(8) on a snapshot of a live filesystem. When running fsck (8) in the background on a live filesystem, the filesystem performance will be about half of normal during the time that the background fsck(8) is running. Running a full fsck on a UFS filesystem is the equivalent of running a scrub on a ZFS filesystem.

The first milestone of this project has been completed. It is now possible to take snapshots when running with journaled soft updates and they can be used for doing background dumps on a live filesystem.

The second milestone of this project is to extend fsck(8) to be able to do a background check using a snapshot on a filesystem running with journaled soft updates. This milestone is expected by Q3 of 2023.

Sponsored by: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Wireless updates

Links:
Bjoern’s Wireless Work In Progress landing page URL: https://people.freebsd.org/~bz/wireless/

Contact: Bjoern A. Zeeb <bz@FreeBSD.org>

During the quarter not much work was publicly visible and admittedly slightly slow. Behind the scenes wireless work was happening on two fronts:

• 11n, 11ac, and wpa,

• more drivers and firmware, problems, testing, and filling gaps for these.

While the main development for newer standards and the Intel iwlwifi driver is sponsored by the FreeBSD Foundation, I find myself spending a lot of private time with Realtek rtw88 and rtw89, Atheros, and Mediatek mt76 (7921 and 7915) drivers now as well. Testing changes on bare metal and using bhyve VMs using passthru has become more time-consuming, with the amount of supported chipsets increasing, in order not to break other drivers. Even different (generations of) chipsets supported by the same driver, at times, behave differently with the same change.

A separate discussion was brought to me about the size of firmware added to the tree for the already existing drivers and the firmware for more drivers coming. The chicken-egg problem to solve is having firmware available on the release media; without firmware, a lot of modern laptops will not have any sort of outside communications available at the time of install in their default configuration. This will be a larger discussion to have to also solve firmware for other drivers, but that discussion will be for another day and place.

Slightly belatedly I have started to push LinuxKPI and 802.11 changes into the tree at the end of the year and that work will continue into early 2023 at which point more of the aforementioned remaining drivers will also hit the tree.

One of the main remaining problems to solve is the firmware crashes on interface down/up cycles currently experienced with at least two drivers.

Thankfully during the last weeks, after my call for help, multiple people have stood up wanting to help with various drivers (especially Realtek and Mediatek). I hope that after me catching up and pushing things out this can accelerate progress again.

Thanks again to everyone doing testing, providing debug output, sending in feedback, or using the drivers at this point.

For the latest state of the development, please use the freebsd-wireless mailing list, and check the landing page, which has links to all wiki pages for each driver status.

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Netlink on FreeBSD

Links:
Initial review URL: https://reviews.freebsd.org/D36002
Netlink talk URL: https://static.ipfw.ru/files/netlink.pdf

Contact: Alexander Chernikov <melifaro@FreeBSD.org>

Netlink is a communication protocol defined in RFC 3549. It is an async, TLV-based protocol, providing 1-1 and 1-many communications between kernel and userland. Netlink is currently used in the Linux kernel to modify, read and subscribe for nearly all networking states. Interface state, addresses, routes, firewall, rules, fibs, etc, are controlled via Netlink.

Why is Netlink important for FreeBSD?

POSIX defines an API for base functions/system calls. There is no such standard for the plethora of protocol/device-level/subsystem-level ioctls. Each subsystem/driver invents its own protocol, handling format and compatibility. Extendability is a notable problem in the networking control plane. For example, it is extremely hard to add properties to the routing socket messages without breaking compatibility.

Netlink offers unification by providing a standard communication layer and basic easily-extendable message formatting. It can serve as a "broker", automatically combining requested data from different sources in a single request (example: interface state dump). Netlink APIs lower the bar for application developers to support FreeBSD, while providing the desired extendability.

Current status

Netlink has been committed to HEAD. The code implements a subset of the NETLINK_ROUTE subsystem and NETLINK_GENERIC framework.

NETLINK_ROUTE supports add/delete/replace operations for routes, nexthops and link-level addresses. Partial support exists for the interface addresses and interfaces.

Linuxulator support for Netlink has been committed to HEAD. It is possible to use the unmodified ip from iproute2 with routes, nexthops, addresses and interfaces.

The simple userland library, snl(3), that provides convenient abstractions on the netlink socket, has been committed to HEAD.

The first third-party software, BIRD, added experimental FreeBSD Netlink support.

Next steps

• Add Netlink to GENERIC

• Make netstat/route/arp/ndp/ifconfig use Netlink interfaces (help is
appreciated)

• Add FreeBSD Netlink support to ports of FreeRangeRouting (FRRouting (FRR)).

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Adding basic CTF support to ddb

Links:
Differential 1 URL: https://reviews.freebsd.org/D37898
Differential 2 URL: https://reviews.freebsd.org/D37899

Contact: Bojan Novković <bojan.novkovic@kset.org>

The goal of this project was to extend the ddb kernel debugger to use the kernel’s Compact C Type Format (CTF) data and use the newly added features to implement a pretty-printing command in ddb.

Due to a restrictive execution environment (no IO or memory allocation), ddb can not use existing kernel linker methods to retrieve the kernel’s CTF data. Instead, the first patch adds the ability to load the kernel’s CTF data during
boot and adds a new kernel linker method used for accessing CTF data from ddb. The second patch adds a basic interface for using CTF data in ddb and a pretty-printing command built using the newly added interfaces.

Any feedback, comments, and reviews are welcome and would be greatly appreciated.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Architectures

Updating platform-specific features and bringing in support for the new hardware platform.

CheriBSD 22.12 release

Links:
CheriBSD URL: https://www.cheribsd.org
CheriBSD Announcements list URL: https://lists.cam.ac.uk/sympa/info/cl-cheribsd-announce

Contact: Brooks Davis <brooks@FreeBSD.org>
Contact: Edward Tomasz Napierala <trasz@FreeBSD.org>
Contact: George Neville-Neil <gnn@FreeBSD.org>
Contact: Jessica Clarke <jrtc27@FreeBSD.org>
Contact: John Baldwin <jhb@FreeBSD.org>
Contact: Robert Watson <rwatson@FreeBSD.org>
Contact: Ruslan Bukin <br@FreeBSD.org>

CheriBSD extends FreeBSD to implement memory protection and software compartmentalization features supported by the CHERI instruction-set extensions. There are two active architectural implementations of the CHERI protection model: CHERI-RISC-V and Arm’s Morello. A sketch of CHERI-x86 is also
under development. CheriBSD is a research operating system with a stable baseline implementation into which various new research features have been, or are currently being, merged.

We have published the 22.12 release of CheriBSD including:

• A general update of the baseline FreeBSD OS to August 2022.

• Memory-safe adaptation of Direct Rendering Manager (DRM) and Panfrost
device driver, which enable a Morello-based desktop system using on-board
GPU and HDMI. These drivers may be used with hybrid or pure-capability
kernels.

• An initial set of graphics and desktop CheriABI software packages such as
Wayland and portions of KDE to get you up and running with a memory-safe
desktop environment. These components remain under active development, and
we anticipate continuing package updates after the CheriBSD release.

• An early research prototype of library-based compartmentalization, which
implements an alternative run-time linker running shared objects in
libraries. This implementation is very much a work-in-progress, and is
provided to enable research at other collaborator institutions needing easy
access to the prototype. It is neither complete nor intended to be secure.

• Improved pluggability of experimental heap temporal memory-safety support,
which is not yet merged into the main development branch, but will now be
easier to use by downloading an alternative kernel and heap allocator
libraries provided by Microsoft.

• An updated version of GDB with support for Morello instructions and
inspecting memory tags.

• Alpha support for ZFS file systems including support for boot environments.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

FreeBSD/riscv64 Improvements

Links:
Wiki Homepage URL: https://wiki.freebsd.org/riscv

Contact: Mitchell Horne <mhorne@FreeBSD.org>

The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture.

This quarter I resumed work on improvements to FreeBSD’s RISC-V architecture support (riscv64). Work was focused primarily on small bug-fixes and improvements, and tooling. A handful of known panics and bug reports were fixed and closed.

On the performance tooling side, some issues with the use of DTrace on riscv64 were found and addressed. Specifically, backtraces produced by the stack() function were not being captured correctly. First, a change was made to the compiler flags to ensure that kernel modules always make use of the frame pointer, so that unwinding the kernel stack works as expected. Second, some tweaks were made to machine-dependent DTrace code in the profile and fbt providers, making the correct number of frames appear in each backtrace. Now, DTrace can be used to accurately capture profiling data on this platform, enabling the generation of flamegraphs.

I also began porting the hwpmc(4) driver to run on this platform. Unlike other ISAs, RISC-V does not standardize the set of counter events that a CPU must support, nor are the programmable event selection registers accessible to the kernel. To work around this, there is an SBI "Performance Monitoring Unit" extension which provides an abstracted interface for managing such functionality. The new hwpmc(4) class is written to use this interface. Current generation RISC-V hardware supports incrementing performance counters, but lacks the counter overflow interrupts required to enable sampling PMCs.

Work is expected to continue next quarter. Aside from the in-progress items mentioned, focus will be given to the following areas:

• Support for newer OS-level extensions such as Page-Based Memory Types
(Svpbmt)

• Profiling system performance.

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

go on FreeBSD riscv64

Links:
golang Home Page URL: https://github.com/golang/go
FreeBSD riscv64 github repo URL: https://github.com/MikaelUrankar/go/tree/freebsd_riscv64
FreeBSD riscv64 golang issue URL: https://github.com/golang/go/issues/53466

Contact: Mikaël Urankar <mikael@FreeBSD.org>
Contact: Dmitri Goutnik <dmgk@FreeBSD.org>

The proposal to add support for FreeBSD riscv64 has been accepted and the patches merged. golang on FreeBSD riscv64 will be available in golang v1.20 (to be released in February 2023).

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

FreeBSD/ARM64 on Xen

Links:
Xen Project URL: https://www.xenproject.org/
FreeBSD wiki page on Xen URL: https://wiki.freebsd.org/Xen

Contact: Elliott Mitchell <ehem+freebsd@m5p.com>

Xen is an open source hypervisor. Xen is one of the earliest hypervisors and has support for many OSes. Since FreeBSD 8.0, GENERIC FreeBSD/x86 has been able to run on Xen. Near the time FreeBSD was ported to run on Xen, work was started on running Xen on ARM. For a number of years Linux has run fine on Xen/ARM, but FreeBSD hasn’t been available.

Having FreeBSD/ARM64 on Xen means any system capable of having Xen can also have FreeBSD in operation. Of note, the Raspberry PI 4B has hardware (GICv3) which Xen works with. If you’re okay with Linux handling the hardware, you can
use all the hardware of a Raspberry PI 4B.

In 2014 a proof of concept of running FreeBSD/ARM64 on Xen was done by Julien Grall, but this was never polished for release. During the past 2 years I’ve been working towards having this in FreeBSD’s tree, so released versions of FreeBSD/ARM64 would run on Xen. At this point all changes which need to be shared with the x86 Xen source code have been reviewed (not all reviews are on Phabricator). This now awaits testing by Roger Pau Monné before being committed
to FreeBSD’s tree.

I now urgently need someone with a high level of familiarity with the interrupt subsystem of FreeBSD on ARM64 to review (and commit) the ARM-specific portions. My builds are functional far more often than they fail, and most failures are temporary problems in FreeBSD’s tree. Some significant issues will need to be addressed regarding FreeBSD’s interrupt subsytem.

There is substantial hope of having FreeBSD/ARM64 available for "DomU" (unprivileged) operation for FreeBSD 14.0. There is potential for FreeBSD/ARM and FreeBSD/RISC-V to run on Xen in short order. No plans currently exist for having FreeBSD/ARM64 operating as the controlling VM (someone could try to sponsor this).

Thanks

Thanks to Julien Grall <julien@xen.org> for the Proof of Concept.
Thanks to Roger Pau Monné <royger@FreeBSD.org> for reviewing changes involving x86.
Thanks to Mitchell Horne <mhorne@FreeBSD.org> for helping with various FreeBSD/ ARM64 issues and addressing a key problem with FreeBSD/ARM64.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Cloud

Updating cloud-specific features and bringing in support for new cloud platforms.

FreeBSD on Microsoft HyperV and Azure

Links:
Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/MicrosoftAzure
Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV

Contact: Microsoft FreeBSD Integration Services Team <bsdic@microsoft.com> Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team <releng-azure@FreeBSD.org> Contact: Wei Hu <whu@FreeBSD.org>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

In this quarter, the 12.4-RELEASE image has been published to Azure Marketplace.

Work in progress tasks:

• Automating the image building and publishing process and merge to src/
release/.

• Building and publishing ZFS-based images to Azure Marketplace

□ All the required codes are merged to main branch, and can create
ZFS-based images by specifying VMFS=zfs.

□ Need to make the build process more automatic and collaborating with
release engineering to start generating snapshots.

• Building and publishing Hyper-V gen2 VM images to Azure Marketplace

□ Blocked by https://bugs.freebsd.org/264267

The above tasks are sponsored by The FreeBSD Foundation, with resources provided by Microsoft.

Wei Hu and his colleagues in Microsoft are working on several tasks sponsored by Microsoft:

• Fixing booting issue on Hyper-V gen2 VM in Azure

□ https://bugs.freebsd.org/264267

• Porting Hyper-V guest support to aarch64

□ https://bugs.freebsd.org/266248

□ https://bugs.freebsd.org/267654

Open tasks:

• Update FreeBSD related doc at https://docs.microsoft.com

• Support FreeBSD in Azure Pipelines

• Update Azure agent port to the latest version

• Upstream local modifications of Azure agent

Sponsor: Microsoft for work by Wei Hu and others in Microsoft, and for resources for the rest
Sponsor: The FreeBSD Foundation for everything else

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

FreeBSD as a Tier 1 cloud-init Platform

Links:
cloud-init Website URL: https://cloud-init.io/
cloud-init Documentation URL: https://cloudinit.readthedocs.io/en/latest/ cloud-init ongoing refactorization URL: https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst

Contact: Mina Galić <me+FreeBSD@igalic.co>

cloud-init is the standard way of provisioning servers in the cloud. Unfortunately, cloud-init support for operating systems other than Linux is rather poor, and the lack of cloud-init support on FreeBSD is a hindrance to cloud providers who want to offer FreeBSD as a Tier 1 platform. To remedy the situation, this project aims to bring FreeBSD cloud-init support on par with Linux support. The broader plan is to lift support across all BSDs.

The first milestone has been delivered. Along with many bug fixes, we now have merged an ifconfig(8) parser, which allows us to retrieve all the information of all network devices, similarly to how on Linux this is done by parsing the contents of /sys/class/net/<dev>/. In the coming weeks, this project will align itself with the Azure developers to do some crucial refactoring. This will move our new parser further into cloud-init’s main execution paths.

People interested in helping with the project can help with testing new features and fixes through net/cloud-init-devel, which will be updated whenever we make significant commits. Further, people with access to, and experience with, OpenBSD and NetBSD are also highly welcome to help.

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

OpenStack on FreeBSD

Links:
OpenStack URL: https://www.openstack.org
OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd

Contact: Chih-Hsin Chang <starbops@hey.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

OpenStack is an open-source cloud operating system for different resource types like virtual and bare-metal machines. Users can spawn FreeBSD instances on the open cloud platform, but it is not currently possible to run the OpenStack control plane on FreeBSD hosts. This project aims to port key OpenStack components so that FreeBSD can function as an OpenStack host.

In 2022 Q4, we have almost completed the porting work regarding the crucial OpenStack components. Most of the components/services composing an essential OpenStack cluster are now able to run on FreeBSD hosts, including:

• Keystone (identity service)

□ keystone server

• Glance (image service)

□ glance-api

• Placement (resource tracking and inventory service)

□ placement-api

• Neutron (networking service)

□ neutron-server

□ neutron-metadata-agent

□ neutron-dhcp-agent

□ neutron-openvswitch-agent

• Nova (compute service)

□ nova-api

□ nova-conductor

□ nova-scheduler

□ nova-compute

□ nova-novncproxy

The step-by-step documents for constructing a POC can be found in the docs repository.

In its design, most of the OpenStack components provide an abstraction layer for the underlying implementations. For nova, we choose the combination of the libvirt driver with the bhyve virtualization type enabled. For neutron, it is the openvswitch mechanism driver. We solved several runtime dependencies and porting issues against the Libvirt, bhyve, and Open vSwitch combinations with minimal effort. We still have lots of work to undertake to make the changes back to OpenStack upstream.

TODOs include:

• Develop a proper alternative execution path in the oslo_privsep module for
FreeBSD environments

• Develop a new virtualization type, bhyve, for nova-compute’s libvirt driver

• Develop the IP library for FreeBSD under neutron/agent/freebsd

In the first few weeks of 2023, we will focus on breaking through the last mile of the instance spawn path and wrapping up the documentation regarding POC site construction. We will also try rebasing the porting work to the master branch of OpenStack (now Xena).

People interested in helping with the project can first help check the documentation by following the installation guide.

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Documentation

Noteworthy changes in the documentation tree, manual pages, or new external books/documents.

Documentation Engineering Team

Links:
FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/
FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/
Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-doceng

Contact: FreeBSD Doceng Team <doceng@FreeBSD.org>

The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter.

During the last quarter:

• crees@ and zeising@ doc bits were taken in for safekeeping.

Items pending and in the discussion:

• A new document about licensing has been added to the documentation set.

Porter’s Handbook:

Two new USES knobs have been added to the Handbook:

• New USES = luajit.

• New USES = llvm.

Also:

• Erlang facilities have been documented

• The new CABAL_REVISON knob has been documented.

FreeBSD Translations on Weblate

Link: Translate FreeBSD on Weblate
Link: FreeBSD Weblate Instance

Q4 2022 Status

• 12 languages

• 150 registered users

Languages

• Chinese (Simplified) (zh-cn) (progress: 8%)

• Chinese (Traditional) (zh-tw) (progress: 4%)

• Dutch (nl) (progress: 1%)

• French (fr) (progress: 1%)

• German (de) (progress: 1%)

• Indonesian (id) (progress: 1%)

• Italian (it) (progress: 4%)

• Norwegian (nb-no) (progress: 1%)

• Persian (fa-ir) (progress: 3%)

• Portuguese (pt-br) (progress: 16%)


[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)