Convert html to adoc

concepts/adoc_output/AI-intro-how-works.adoc

@@ -0,0 +1,104 @@
+%entities; ++]>++
+
+&productname; architecture
+
+&productname; is a cloud native solution that comprises multiple
+software building blocks. These blocks include the Linux operating
+system, &kube; cluster with a Web UI management layer, supportive tools
+to utilize GPU capabilities, and other containerized applications that
+care for monitoring and security. The &sappco; includes a collection of
+AI-related applications called &ailibrary;.
+
+&productname; building blocks
+
+Linux operating system
+
+The underlying operating system with the optional &nvidia; driver
+installed. We prefer &sls; (). If you require an immutable operating
+system, &slema; is the recommended alternative.
+
+&kube; cluster
+
+&kube; cluster managed by &ranchermanager; ensuring container and
+application lifecycle management. We recommend using the &rke2; ()
+distribution.
+
+&nvoperator;
+
+Utilizes the &nvidia; GPU computing power and capabilities for
+processing AI-related tasks.
+
+&ssecurity; ()
+
+For security and compliance.
+
+&sobservability; ()
+
+Provides advanced performance and data monitoring.
+
+&sstorage; ()
+
+Enterprise-grade storage solution.
+
+&svirtualization; ()
+
+For virtualized workloads.
+
+&smlm; ()
+
+For managing multiple Linux distributions.
+
+&sappco; ()
+
+As a source of &helm; charts and container images for the &ailibrary;
+applications.
+
+&ailibrary; applications
+
+Following is a list of AI applications that you can find in the
+&sappco;. For a complete and up-to-date list, refer to .
+
+&certmanager; ()
+
+An extensible X.509 certificate controller for &kube; workloads.
+
+&opensearch; ()
+
+A search and analytics suite for analyzing and visualizing search data.
+
+&milvus; ()
+
+A vector database built for generative AI applications with minimal
+performance loss.
+
+&ollama; ()
+
+A platform that simplifies the installation and management of large
+language models (LLM) on local devices.
+
+&owui; ()
+
+An extensible Web user interface for the &ollama; LLM runner.
+
+&vllm; (
+
+A high-performance inference and serving engine for large language
+models (LLMs).
+
+&mcpo; ()
+
+The &mcp;-to-OpenAPI proxy server provided by &owui;.
+
+&pytorch; ()
+
+An open source machine learning framework.
+
+&mlflow; ()
+
+An open source platform to manage the machine learning lifecycle,
+including experimentation, reproducibility, deployment and a central
+model registry.
+
+Basic schema of &productname;
+
+An image showing a basic structure of &productname;

concepts/adoc_output/packages_lifecycle_desktop_components.adoc

@@ -0,0 +1,42 @@
+%entities; ++]>++
+
+Update strategy of desktop components
+
+In general, desktop components follow the balanced lifecycle of their
+packages.
+
+The &slea; 16 desktop environment provides the following components:
+
+GNOME desktop
+
+The minimum version is 48.0. The exact version must be determined before
+the end of beta releases.
+
+GStreamer, PipeWire and Flatpak
+
+These components are updated to the latest stable branch version at the
+last beta release.
+
+Firefox
+
+The minimum version is 140.3. The update strategy follows the ESR update
+lifecycle.
+
+WebKit
+
+The minimum version is 2.46. WebKit has a periodic update cycle
+determined by critical CVEs. The component is updated but not
+backported.
+
+BRLTTY
+
+The accessibility tools are at the latest upstream stable versions in
+the 16.0. Only bug fixes will happen in this minor release.
+
+QT
+
+The Qt 6 is delivered. The initial version is Qt 6.9.
+
+KDE
+
+Not a standard &suselinux; delivery; available only in PackageHub 16.

concepts/adoc_output/packages_lifecycle_faq.adoc

@@ -0,0 +1,43 @@
+%entities; ++]>++
+
+Package maintainer's FAQ
+
+The topic covers FAQ a package mantaine may have.
+
+I want to define a lifecycle for my package. What should I do?
+
+Raise a Jira ticket so we can track and document the process. If you are
+not sure about the lifecycle category, contact your manager and a SLEA
+architect.
+
+Which type of lifecycle can or should I adopt?
+
+The further down in the stack your component is, the more packages
+depend on it, so you should take a more conservative approach. When in
+doubt, contact the SLEA architects.
+
+I want to use a balanced lifecycle for my package. Should I go for
+several versions in parallel?
+
+In general, it is better to replace the old package with a new version.
+It creates less overhead on the maintainer side and is less confusing to
+customers. A sliding window is useful for most toolchain components that
+have API or ABI changes as part of new releases. However, the particular
+approach depends on the amount and type of changes. For example, if the
+changes can be adopted easily or even automated, then it is better to
+just update the package. When changes lead to conflicts that neither we
+nor the customer can easily resolve, then maintaining parallel versions
+is a better option.
+
+SUSE tried this on a case-by-case basis for Python modules.
+
+Should I convert my package from a balanced lifecycle to an agile one,
+and release updated versions also to code streams under LTS?
+
+This is a question that we need to investigate in every case. In
+general, if the particular package is beneficial for customers on the
+older releases, then it may be worth releasing the updated packages to
+older releases. For example, if a component is mostly about operations,
+then it may be useful for customers on older releases. On the contrary,
+newer packages that provide hardware enablement are usually not needed,
+as customers' hardware has not changed since the time of installation.

concepts/adoc_output/packages_lifecycle_python.adoc

@@ -0,0 +1,56 @@
+%entities; ++]>++
+
+Python update strategy
+
+The primary Python interpreter with its stack is 3.13 in &sle;
+&productnumber;
+
+Python interpreter and stack support lifecycles
+
+The support lifecycles of the Python interpreter are the following:
+
+Short-term support interpreter
+
+It is supported for 2 years. The support lifecycle applies also to basic
+packages: setuptools, venv, pip, wheel and pipx.
+
+Primary Python
+
+The OS's main Python. It is supported for 4 years and includes the
+interpreter and its stack, /usr/bin/python3 and all packages with the
+python3- prefix.
+
+Legacy Python
+
+It is supported for 4 years and includes the interpreter and stack but
+not the python3- packages. A legacy interpreter is a former primary
+Python. Short-term interpreters, by contrast, follow a different
+lifecycle and are becoming legacy.
+
+Python release cycle
+
+The starting version of Python in &suselinux; 16 is Python 3.13. &suse;
+plans to release every odd version of Python and provide the LTS for up
+to 8 years.
+
+The latest Python interpreter is delivered with each minor release with
+only short-term support. The outdated Python version is migrated to the
+legacy mode and is supported for another 4 years.
+
+The following table shows probable versions of Python to be delivered
+with particular &suselinux; versions. The exact version will depend on
+the upstream community.
+
+Python versions delivered per &suselinux; minor release
+
+Python version &suselinux; minor release 3.13 3.14 3.15 3.16 3.17 3.18
+3.19
+
+&suselinux; 16.0 The primary Python stack &suselinux; 16.1 The primary
+Python stack As the short-term support interpreter &suselinux; 16.2 The
+primary Python stack As the short-term support interpreter &suselinux;
+16.3 The legacy Python The primary Python As the short-term support
+interpreter &suselinux; 16.4 The primary Python As the short-term
+support interpreter &suselinux; 16.5 The legacy Python The primary
+Python As the short-term support interpreter &suselinux; 16.6 The
+primary Python As the short-term support interpreter

concepts/adoc_output/packages_lifecycle_toolchain.adoc

@@ -0,0 +1,56 @@
+%entities; ++]>++
+
+Python update strategy
+
+The primary Python interpreter with its stack is 3.13 in &sle;
+&productnumber;
+
+Python interpreter and stack support lifecycles
+
+The support lifecycles of the Python interpreter are the following:
+
+Short-term support interpreter
+
+It is supported for 2 years. The support lifecycle applies also to basic
+packages: setuptools, venv, pip, wheel and pipx.
+
+Primary Python
+
+The OS's main Python. It is supported for 4 years and includes the
+interpreter and its stack, /usr/bin/python3 and all packages with the
+python3- prefix.
+
+Legacy Python
+
+It is supported for 4 years and includes the interpreter and stack but
+not the python3- packages. A legacy interpreter is a former primary
+Python. Short-term interpreters, by contrast, follow a different
+lifecycle and are becoming legacy.
+
+Python release cycle
+
+The starting version of Python in &suselinux; 16 is Python 3.13. &suse;
+plans to release every odd version of Python and provide the LTS for up
+to 8 years.
+
+The latest Python interpreter is delivered with each minor release with
+only short-term support. The outdated Python version is migrated to the
+legacy mode and is supported for another 4 years.
+
+The following table shows probable versions of Python to be delivered
+with particular &suselinux; versions. The exact version will depend on
+the upstream community.
+
+Python versions delivered per &suselinux; minor release
+
+Python version &suselinux; minor release 3.13 3.14 3.15 3.16 3.17 3.18
+3.19
+
+&suselinux; 16.0 The primary Python stack &suselinux; 16.1 The primary
+Python stack As the short-term support interpreter &suselinux; 16.2 The
+primary Python stack As the short-term support interpreter &suselinux;
+16.3 The legacy Python The primary Python As the short-term support
+interpreter &suselinux; 16.4 The primary Python As the short-term
+support interpreter &suselinux; 16.5 The legacy Python The primary
+Python As the short-term support interpreter &suselinux; 16.6 The
+primary Python As the short-term support interpreter

concepts/adoc_output/packages_lifecycle_types.adoc

@@ -0,0 +1,56 @@
+%entities; ++]>++
+
+Python update strategy
+
+The primary Python interpreter with its stack is 3.13 in &sle;
+&productnumber;
+
+Python interpreter and stack support lifecycles
+
+The support lifecycles of the Python interpreter are the following:
+
+Short-term support interpreter
+
+It is supported for 2 years. The support lifecycle applies also to basic
+packages: setuptools, venv, pip, wheel and pipx.
+
+Primary Python
+
+The OS's main Python. It is supported for 4 years and includes the
+interpreter and its stack, /usr/bin/python3 and all packages with the
+python3- prefix.
+
+Legacy Python
+
+It is supported for 4 years and includes the interpreter and stack but
+not the python3- packages. A legacy interpreter is a former primary
+Python. Short-term interpreters, by contrast, follow a different
+lifecycle and are becoming legacy.
+
+Python release cycle
+
+The starting version of Python in &suselinux; 16 is Python 3.13. &suse;
+plans to release every odd version of Python and provide the LTS for up
+to 8 years.
+
+The latest Python interpreter is delivered with each minor release with
+only short-term support. The outdated Python version is migrated to the
+legacy mode and is supported for another 4 years.
+
+The following table shows probable versions of Python to be delivered
+with particular &suselinux; versions. The exact version will depend on
+the upstream community.
+
+Python versions delivered per &suselinux; minor release
+
+Python version &suselinux; minor release 3.13 3.14 3.15 3.16 3.17 3.18
+3.19
+
+&suselinux; 16.0 The primary Python stack &suselinux; 16.1 The primary
+Python stack As the short-term support interpreter &suselinux; 16.2 The
+primary Python stack As the short-term support interpreter &suselinux;
+16.3 The legacy Python The primary Python As the short-term support
+interpreter &suselinux; 16.4 The primary Python As the short-term
+support interpreter &suselinux; 16.5 The legacy Python The primary
+Python As the short-term support interpreter &suselinux; 16.6 The
+primary Python As the short-term support interpreter