Ancor Gonzalez Sosa ancorgs

This is the definition of a thin pool:

{
  "logicalVolumes": [
    {
      "size": "40 GiB"
      "name": "hanalv",
      "pool": true
 }

Proposal of interface to select the APQNs on YaST based on the configured master keys.

This adapts the interface to support both EP11 and CCA and, in the latter case, to select between AES DATA and AES CIPHER.

One important change (compared to the current YaST UI), is that APQNs without a valid current AES or P11 master key are not even considered.

Adding master key selection, EP11 cards and key types results in many, many possible combinations. Let's try to describe how the new UI works in all those cases. The screens are displayed as 80x24 text mode.

Scenario 1. There is only one APQN from a EP11 card with a valid key (1 key, 1 EP11 APQN)

I was involved in several Hack Week projects and, as a result, I only invested some hours on https://hackweek.opensuse.org/24/projects/editor-mode-at-agama-web-interface

Fortunatelly, Imo and David helped me to get started, so I was able to get something working. See below.

Storage Section of the Agama Profile

Supporting a Legacy AutoYaST Specification

The Agama profile should contain a storage section. If it's omitted, an alternative section called legacy_autoyast_storage can be specified instead.

That legacy_autoyast_storage is a 1:1 representation of the XML specification of AutoYaST. No json validation will be performed for it.

Basic Structure of the Storage Section

<Checkbox
  label={_("Use the TPM to decrypt automatically on each boot")}
  description={
    _(The password will not be needed to boot or to access de data in the <abbr title=\"Trusted Platform Module\">TPM</abbr>..."
  }
/&gt;

The file zone.tab allow us to map timezones to a representative country. Basically, the country in which the city mentioned in the name of the timezone is located.

Good news - that mapping actually works for 434 of the timezones Agama offers.

Not so good, there are 39 missmatches. So there are timezones for which we cannot inferre the country.

Let's group them

A. No country, indeed

Tumbleweed and Leap roles

kde
gnome
xfce
generic_desktop
server
serverro

Some fun ideas for using Agama from the installation media

Agama can be controlled with two interfaces:

A CLI (command-line interface) written in Rust
A web interface offering a more graphical and user-frienly way of doing things

Of course, to connect to the latter a browser is needed. Currently Agama-Live (the demo image for Agama) uses a full screen Firefox. We are not sure if that will be the solution in the definitive installation-media for future (open)SUSE distributions. It obviously has its drawbacks.

This is a draft for a possible OOP solution for https://trello.com/c/drW2FI0q/165-agama-storage-proposal-settings, but certainly not the only one. The chosen solution must be discussed before progressing with the implementation.

Representing the desired Agama behavior on Agama's storage backend

This shows how the classes at the storage backend of Agama could be organized. These classes may be exposed in the D-Bus interface as some kind of direct translation (having interfaces like Settings, EncryptionSettings, Volume, VolumeTemplate and so on) or with a more conservative interface similar to the current one that is based only on the interface Storage1.Proposal, which contains only a few properties and an array of volumes described as plain hashes.

This classes represent how the configuration of the Agama proposal could be represented in the Agama backend, to be consistent with the behavior described at the Trello card.

class Settings

	# Class to calculate a storage proposal for autoinstallation
	#
	# @example Creating a proposal from the current AutoYaST profile
	# partitioning = Yast::Profile.current["partitioning"]
	# proposal = Y2Storage::AutoinstProposal.new(partitioning: partitioning)
	# proposal.proposed? # => false
	# proposal.devices # => nil
	# proposal.planned_devices # => nil
	#
	# proposal.propose # Performs the calculation