Dartboard TUI by IValentin

Description

Our scalability and performance testing swiss-army knife tool Dartboard is a major WIP so why not add more scope creep? Dartboard is a cli tool which enables users to:

• Define a "Dart" config file as YAML which defines the various components to be created/setup when Dartboard runs its commands
• Spin up infrastructure utilizing opentofu/terraform providers
• Setup K3s or RKE2 clusters on the newly created infrastructure
• Deploy Rancher (with or without downstream cluster), rancher-monitoring (Grafana + Prometheus)
• Create resources in-bulk within the newly created Rancher cluster (ConfigMaps, Secrets, Users, Roles, etc.)
• Run various performance and scalability tests via k6
• Export/Import various tracked metrics (WIP)

Given all these features (and the features to come), it can be difficult to onboard and transfer knowledge of the tool. With a TUI, Dartboard's usage complexity can be greatly reduced!

Goals

• Create a TUI for Dartboard's "subcommands"
• Gain more familiarity with Dartboard and create a more user-friendly interface to enable others to use it
• Stretch Create a TUI workflow for generating a Dart file

Resources

https://github.com/charmbracelet/bubbletea

---

suse-rancher-supportconfig by eminguez

Description

Update: Live at https://github.com/e-minguez/suse-rancher-supportconfig I finally didn't used golang but used gum instead

SUSE's supportconfig support tool collects data from the SUSE Operating system. Rancher's rancher2_logs_collector.sh support tool does the same for RKE2/K3s.

Wouldn't be nice to have a way to run both and collect all data for SUSE based RKE2/K3s clusters? Wouldn't be even better with a fancy TUI tool like bubbletea?

Ideally the output should be an html page where you can see the logs/data directly from the browser.

Goals

• Familiarize myself with both supportconfig and rancher2_logs_collector.sh tools
• Refresh my golang knowledge
• Have something that works at the end of the hackweek ("works" may vary )
• Be better in naming things

Resources

All links provided above as well as huh

---

Implement a CLI tool for Trento - trentoctl by nkopliku

Description

Implement a trentoctl CLI for interacting with a trento installation

Goals

• learn rust
• implement an initial trentoctl tool to enhance trento automation
• have fun

Resources

trento rust. TUIs listed on this other hackweek project Hack on rich terminal user interfaces

---

file-organizer: A CLI Tool for Efficient File Management by okhatavkar

Description

Create a Go-based CLI tool that helps organize files in a specified folder by sorting them into subdirectories based on defined criteria, such as file type or creation date. Users will pass a folder path as an argument, and the tool will process and organize the files within it.

Goals

• Develop Go skills by building a practical command-line application.
• Learn to manage and manipulate files and directories in Go using standard libraries.
• Create a tool that simplifies file management, making it easier to organize and maintain directories.

Resources

• Go Standard Libraries: Utilize os, filepath, and time for file operations.
• CLI Development: Use flag for basic argument parsing or consider cobra for enhanced functionality.
• Go Learning Material: Go by Example and The Go Programming Language Documentation.

Features

• File Type Sorting: Automatically move files into subdirectories based on their extensions (e.g., documents, images, videos).
• Date-Based Organization: Add an option to organize files by creation date into year/month folders.
• User-Friendly CLI: Build intuitive commands and clear outputs for ease of use. This version maintains the core idea of organizing files efficiently while focusing on Go development and practical file management.

---

A CLI for Harvester by mohamed.belgaied

[comment]: # Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI [comment]: # Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. [comment]: # Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.

Project Description

Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as: harvester vm create my-vm --count 5 to create 5 VMs named my-vm-01 to my-vm-05.

Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.

Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli

Done in previous Hackweeks

• Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
• Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE

Goal for this Hackweek

The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.

Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it

Issue list is here: https://github.com/belgaied2/harvester-cli/issues

Resources

The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact). Welcome contributions are:

• Testing it and creating issues
• Documentation
• Go code improvement

What you might learn

Harvester CLI might be interesting to you if you want to learn more about:

• GitHub Actions
• Harvester as a SUSE Product
• Go programming language
• Kubernetes API

---

Mammuthus - The NFS-Ganesha inside Kubernetes controller by vcheng

Description

As the user-space NFS provider, the NFS-Ganesha is wieldy use with serval projects. e.g. Longhorn/Rook. We want to create the Kubernetes Controller to make configuring NFS-Ganesha easy. This controller will let users configure NFS-Ganesha through different backends like VFS/CephFS.

Goals

1. Create NFS-Ganesha Package on OBS: nfs-ganesha5, nfs-ganesha6
2. Create NFS-Ganesha Container Image on OBS: Image
3. Create a Kubernetes controller for NFS-Ganesha and support the VFS configuration on demand. Mammuthus

Resources

NFS-Ganesha

---

suse-rancher-supportconfig by eminguez

Description

Update: Live at https://github.com/e-minguez/suse-rancher-supportconfig I finally didn't used golang but used gum instead

SUSE's supportconfig support tool collects data from the SUSE Operating system. Rancher's rancher2_logs_collector.sh support tool does the same for RKE2/K3s.

Wouldn't be nice to have a way to run both and collect all data for SUSE based RKE2/K3s clusters? Wouldn't be even better with a fancy TUI tool like bubbletea?

Ideally the output should be an html page where you can see the logs/data directly from the browser.

Goals

• Familiarize myself with both supportconfig and rancher2_logs_collector.sh tools
• Refresh my golang knowledge
• Have something that works at the end of the hackweek ("works" may vary )
• Be better in naming things

Resources

All links provided above as well as huh

---

Automate PR process by idplscalabrini

Description

This project is to streamline and enhance the pr review process by adding automation for identifying some issues like missing comments, identifying sensitive information in the PRs like credentials. etc. By leveraging GitHub Actions and golang hooks we can focus more on high-level reviews

Goals

• Automate lints and code validations on Github actions
• Automate code validation on hook
• Implement a bot to pre-review the PRs

Resources

Golang hooks and Github actions

---

A CLI for Harvester by mohamed.belgaied

[comment]: # Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI [comment]: # Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. [comment]: # Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.

Project Description

Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as: harvester vm create my-vm --count 5 to create 5 VMs named my-vm-01 to my-vm-05.

Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.

Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli

Done in previous Hackweeks

• Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
• Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE

Goal for this Hackweek

The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.

Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it

Issue list is here: https://github.com/belgaied2/harvester-cli/issues

Resources

The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact). Welcome contributions are:

• Testing it and creating issues
• Documentation
• Go code improvement

What you might learn

Harvester CLI might be interesting to you if you want to learn more about:

• GitHub Actions
• Harvester as a SUSE Product
• Go programming language
• Kubernetes API

---

terraform-provider-feilong by e_bischoff

Project Description

People need to test operating systems and applications on s390 platform.

Installation from scratch solutions include:

• just deploy and provision manually (with the help of ftpboot script, if you are at SUSE)
• use s3270 terminal emulation (used by openQA people?)
• use LXC from IBM to start CP commands and analyze the results
• use zPXE to do some PXE-alike booting (used by the orthos team?)
• use tessia to install from scratch using autoyast
• use libvirt for s390 to do some nested virtualization on some already deployed z/VM system
• directly install a Linux kernel on a LPAR and use kvm + libvirt from there

Deployment from image solutions include:

• use ICIC web interface (openstack in disguise, contributed by IBM)
• use ICIC from the openstack terraform provider (used by Rancher QA)
• use zvm_ansible to control SMAPI
• connect directly to SMAPI low-level socket interface

IBM Cloud Infrastructure Center (ICIC) harnesses the Feilong API, but you can use Feilong without installing ICIC, provided you set up a "z/VM cloud connector" into one of your VMs following this schema.

What about writing a terraform Feilong provider, just like we have the terraform libvirt provider? That would allow to transparently call Feilong from your main.tf files to deploy and destroy resources on your system/z.

Other Feilong-based solutions include:

• make libvirt Feilong-aware
• simply call Feilong from shell scripts with curl
• use zvmconnector client python library from Feilong
• use zthin part of Feilong to directly command SMAPI.

Goal for Hackweek 23

My final goal is to be able to easily deploy and provision VMs automatically on a z/VM system, in a way that people might enjoy even outside of SUSE.

My technical preference is to write a terraform provider plugin, as it is the approach that involves the least software components for our deployments, while remaining clean, and compatible with our existing development infrastructure.

Goals for Hackweek 24

Feilong provider works and is used internally by SUSE Manager team. Let's push it forward!

Let's add support for fiberchannel disks and multipath.

Goals for Hackweek 25

• Finish support for fiberchannel disks and multipath
• Fix problems with registration on hashicorp providers registry

---

Jenny Static Site Generator by adam.pickering

Description

For my personal site I have been using hugo. It works, but I am not satisfied: every time I want to make a change (which is infrequently) I have to read through the documentation again to understand how hugo works. I don't find the documentation easy to use, and the structure of the repository that hugo requires is unintuitive/more complex than what I need. So, I have decided to write my own simple static site generator in Go. It is named Jenny, after my wife.

Goals

• Pages can be written in markdown (which is automatically converted to HTML), but other file types are also allowed
• Easy to understand and use
  • Intuitive, simple design
  • Clear documentation
  • Hot reloading
  • Binaries provided for download
• Future maintenance is easy
  • Automated releases

Resources

https://github.com/adamkpickering/jenny

---

ddflare: (Dynamic)DNS management via Cloudflare API in Kubernetes by fgiudici

Description

ddflare is a project started a couple of weeks ago to provide DDNS management using v4 Cloudflare APIs: Cloudflare offers management via APIs and access tokens, so it is possible to register a domain and implement a DynDNS client without any other external service but their API.

Since ddflare allows to set any IP to any domain name, one could manage multiple A and ALIAS domain records. Wouldn't be cool to allow full DNS control from the project and integrate it with your Kubernetes cluster?

Goals

Main goals are:

1. add containerized image for ddflare
2. extend ddflare to be able to add and remove DNS records (and not just update existing ones)
3. add documentation, covering also a sample pod deployment for Kubernetes
4. write a ddflare Kubernetes operator to enable domain management via Kubernetes resources (using kubebuilder)

Available tasks and improvements tracked on ddflare github.

Resources

• https://github.com/fgiudici/ddflare
• https://developers.cloudflare.com/api/
• https://book.kubebuilder.io

---

Automate PR process by idplscalabrini

Description

This project is to streamline and enhance the pr review process by adding automation for identifying some issues like missing comments, identifying sensitive information in the PRs like credentials. etc. By leveraging GitHub Actions and golang hooks we can focus more on high-level reviews

Goals

• Automate lints and code validations on Github actions
• Automate code validation on hook
• Implement a bot to pre-review the PRs

Resources

Golang hooks and Github actions

---

Contribute to terraform-provider-libvirt by pinvernizzi

Description

The SUSE Manager (SUMA) teams' main tool for infrastructure automation, Sumaform, largely relies on terraform-provider-libvirt. That provider is also widely used by other teams, both inside and outside SUSE.

It would be good to help the maintainers of this project and give back to the community around it, after all the amazing work that has been already done.

If you're interested in any of infrastructure automation, Terraform, virtualization, tooling development, Go (...) it is also a good chance to learn a bit about them all by putting your hands on an interesting, real-use-case and complex project.

Goals

• Get more familiar with Terraform provider development and libvirt bindings in Go
• Solve some issues and/or implement some features
• Get in touch with the community around the project

Resources

• CONTRIBUTING readme
• Go libvirt library in use by the project
• Terraform plugin development
• "Good first issue" list

---

A CLI for Harvester by mohamed.belgaied

[comment]: # Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI [comment]: # Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. [comment]: # Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.

Project Description

Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as: harvester vm create my-vm --count 5 to create 5 VMs named my-vm-01 to my-vm-05.

Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.

Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli

Done in previous Hackweeks

• Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
• Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE

Goal for this Hackweek

The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.

Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it

Issue list is here: https://github.com/belgaied2/harvester-cli/issues

Resources

The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact). Welcome contributions are:

• Testing it and creating issues
• Documentation
• Go code improvement

What you might learn

Harvester CLI might be interesting to you if you want to learn more about:

• GitHub Actions
• Harvester as a SUSE Product
• Go programming language
• Kubernetes API

---

Introducing "Bottles": A Proof of Concept for Multi-Version CRD Management in Kubernetes by aruiz

Description

As we delve deeper into the complexities of managing multiple CRD versions within a single Kubernetes cluster, I want to introduce "Bottles" - a proof of concept that aims to address these challenges.

Bottles propose a novel approach to isolating and deploying different CRD versions in a self-contained environment. This would allow for greater flexibility and efficiency in managing diverse workloads.

Goals

• Evaluate Feasibility: determine if this approach is technically viable, as well as identifying possible obstacles and limitations.
• Reuse existing technology: leverage existing products whenever possible, e.g. build on top of Kubewarden as admission controller.
• Focus on Rancher's use case: the ultimate goal is to be able to use this approach to solve Rancher users' needs.

Resources

Core concepts:

• ConfigMaps: Bottles could be defined and configured using ConfigMaps.
• Admission Controller: An admission controller will detect "bootled" CRDs being installed and replace the resource name used to store them.
• Aggregated API Server: By analyzing the author of a request, the aggregated API server will determine the correct bottle and route the request accordingly, making it transparent for the user.

---

Cluster API Provider for Harvester by rcase

Project Description

The Cluster API "infrastructure provider" for Harvester, also named CAPHV, makes it possible to use Harvester with Cluster API. This enables people and organisations to create Kubernetes clusters running on VMs created by Harvester using a declarative spec.

The project has been bootstrapped in HackWeek 23, and its code is available here.

Work done in HackWeek 2023

• Have a early working version of the provider available on Rancher Sandbox : *DONE *
• Demonstrated the created cluster can be imported using Rancher Turtles: DONE
• Stretch goal - demonstrate using the new provider with CAPRKE2: DONE and the templates are available on the repo

Goals for HackWeek 2024

• Add support for ClusterClass
• Add e2e testing
• Add more Unit Tests
• Improve Status Conditions to reflect current state of Infrastructure
• Improve CI (some bugs for release creation)
• Testing with newer Harvester version (v1.3.X and v1.4.X)
• Due to the length and complexity of the templates, maybe package some of them as Helm Charts.
• Other improvement suggestions are welcome!

DONE in HackWeek 24:

• Add more Unit Tests
• Improve Status Conditions for some phases
• Add cloud provider config generation
• Testing with Harvester v1.3.2
• Template improvements
• Issues creation

Thanks to @isim and Dominic Giebert for their contributions!

Resources

Looking for help from anyone interested in Cluster API (CAPI) or who wants to learn more about Harvester.

This will be an infrastructure provider for Cluster API. Some background reading for the CAPI aspect:

• Cluster infrastructure provider contract
• Machine infrastructure provider contract
• Provider implementers guide

---

Enabling Rancher as an OIDC Provider by rcabello

Description

Kubernetes supports OpenID Connect (OIDC) natively as an authentication mechanism, enabling token-based user authentication. This can be configured through flags in the Kubernetes API server or by using AuthenticationConfiguration.

The purpose of this project is to enable Rancher to function as an OIDC provider, allowing Rancher's local cluster to act as an OIDC identity provider for downstream clusters. This setup will allow users to authenticate directly with downstream clusters without relying on Rancher’s proxy and impersonation mechanisms.

Rancher will continue to support all authentication providers. When a user attempts to log in via the Rancher OIDC provider, they will be redirected to the authentication provider configured in Rancher.

This approach also facilitates integration with third-party tools (e.g StackState)

Goals

• Implement Rancher as an OIDC provider using the ORY Fosite library, focusing only on the essential functionality required for basic integration.
• Enable downstream clusters to authenticate using JWT tokens issued by Rancher.
• Configure StackState to authenticate using Rancher as an OIDC provider.

Resources

https://github.com/ory/fosite

---

Integrate Backstage with Rancher Manager by nwmacd

Description

Backstage (backstage.io) is an open-source, CNCF project that allows you to create your own developer portal. There are many plugins for Backstage.

This could be a great compliment to Rancher Manager.

Goals

Learn and experiment with Backstage and look at how this could be integrated with Rancher Manager. Goal is to have some kind of integration completed in this Hack week.

Progress

Screen shot of home page at the end of Hackweek:

Day One

• Got Backstage running locally, understanding configuration with HTTPs.
• Got Backstage embedded in an IFRAME inside of Rancher
• Added content into the software catalog (see: https://backstage.io/docs/features/techdocs/getting-started/)
• Understood more about the entity model

Day Two

• Connected Backstage to the Rancher local cluster and configured the Kubernetes plugin.
• Created Rancher theme to make the light theme more consistent with Rancher

Days Three and Day Four

• Created two backend plugins for Backstage:

  1. Catalog Entity Provider - this imports users from Rancher into Backstage
  2. Auth Provider - uses the proxied sign-in pattern to check the Rancher session cookie, to user that to authenticate the user with Rancher and then log them into Backstage by connecting this to the imported User entity from the catalog entity provider plugin.

• With this in place, you can single-sign-on between Rancher and Backstage when it is deployed within Rancher. Note this is only when running locally for development at present

Day Five

• Start to build out a production deployment for all of the above
• Made some progress, but hit issues with the authentication and proxying when running proxied within Rancher, which needs further investigation

---

Small healthcheck tool for Longhorn by mbrookhuis

Project Description

We have often problems (e.g. pods not starting) that are related to PVCs not running, cluster (nodes) not all up or deployments not running or completely running. This all prevents administration activities. Having something that can regular be run to validate the status of the cluster would be helpful, and not as of today do a lot of manual tasks.

As addition (read enough time), we could add changing reservation, adding new disks, etc. --> This didn't made it. But the scripts can easily be adopted.

This tool would decrease troubleshooting time, giving admins rights to the rancher GUI and could be used in automation.

Goal for this Hackweek

At the end we should have a small python tool that is doing a (very) basic health check on nodes, deployments and PVCs. First attempt was to make it in golang, but that was taking to much time.

Overview

This tool will run a simple healthcheck on a kubernetes cluster. It will perform the following actions:

• node check: This will check all nodes, and display the status and the k3s version. If the status of the nodes is not "Ready" (this should be only reported), the cluster will be reported as having problems

• deployment check: This check will list all deployments, and display the number of expected replicas and the used replica. If there are unused replicas this will be displayed. The cluster will be reported as having problems.

• pvc check: This check will list of all pvc's, and display the status and the robustness. If the robustness is not "Healthy", the cluster will be reported as having problems.

If there is a problem registered in the checks, there will be a warning that the cluster is not healthy and the program will exit with 1.

The script has 1 mandatory parameter and that is the kubeconf of the cluster or of a node off the cluster.

The code is writen for Python 3.11, but will also work on 3.6 (the default with SLES15.x). There is a venv present that will contain all needed packages. Also, the script can be run on the cluster itself or any other linux server.

Installation

To install this project, perform the following steps:

• Create the directory /opt/k8s-check

mkdir /opt/k8s-check

• Copy all the file to this directory and make the following changes:

chmod +x k8s-check.py

---

New migration tool for Leap by lkocman

Update

I will call a meeting with other interested people at 11:00 CET https://meet.opensuse.org/migrationtool

Description

SLES 16 plans to have no yast tool in it. Leap 16 might keep some bits, however, we need a new tool for Leap to SLES migration, as this was previously handled by a yast2-migration-sle

Goals

A tool able to migrate Leap 16 to SLES 16, I would like to cover also other scenarios within openSUSE, as in many cases users would have to edit repository files manually.

• Leap -> Leap n+1 (minor and major version updates)
• Leap -> SLES docs
• Leap -> Tumbleweed
• Leap -> Slowroll
• Leap Micro -> Leap Micro n+1 (minor and major version updates)
• Leap Micro -> MicroOS

Hackweek 24 update

Marcela and I were working on the project from Brno coworking as well as finalizing pieces after the hackweek. We've tested several migration scenarios and it works. But it needs further polishing and testing.

Projected was renamed to opensuse-migration-tool and was submitted to devel project https://build.opensuse.org/requests/1227281

Repository

https://github.com/openSUSE/opensuse-migration-tool

Out of scope is any migration to an immutable system. I know Richard already has some tool for that.

Resources

Tracker for yast stack reduction code-o-o/leap/features#173 YaST stack reduction

---