profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/agraul/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Alexander Graul agraul @SUSE Germany

agraul/ceph 0

Ceph is a distributed object, block, and file storage platform

agraul/contrib 0

Collection of tools that are are not (yet!) officially part of the Uyuni product

agraul/doom-emacs 0

An Emacs configuration for the stubborn martian vimmer

agraul/dotfiles 0

Mirror of dotfiles. More recent files can be found on Gitlab

agraul/emacs-osc 0

OSC wrapper inside Emacs

agraul/git-packaging-tools 0

Make it easy to track patches in git and generate a package from there.

agraul/hashie 0

Hashie is a collection of classes and mixins that make hashes more powerful.

push eventopenSUSE/salt-packaging

Pablo Suárez Hernández

commit sha fb681195dc62c66b2ccfd9f298fdf81fb2ded6cc

Enhance logging when inotify beacon is missing pyinotify (bsc#1186310) Add "python3-pyinotify" as a recommended package for Salt in SUSE/OpenSUSE distros

view details

push time in a minute

Pull request review commentuyuni-project/uyuni-rfc

[WIP] Improve the 3rd party usage of XMLRPC API

+- Feature Name: Improve the 3rd party usage of XMLRPC API+- Start Date: 2021-05-20+- RFC PR:++# Summary and motivation++The main goal of this RFC is to highlight the problems of writing client+applications or scripts compatible with multiple versions of Uynui and SUSE+Manager (SUMA) API and suggest an improvement in this area. When the consumers+use the API, there must be a way for them to make sure they call the endpoints+correctly (they need to call an existing method with correct parameters and they+also need to make some assumptions on the return value structure).+++## Note on XMLRPC structure exposition++Before describing the main problem, it is important to understand how the+information about API is exposed to clients.  Uyuni/SUMA exposes the information+about the API and its structure in 3 places:++1. Information about the versions via the `api` XMLRPC endpoint:+   - `getVersion`: the API version, e.g. `25`. This integer grows with time, but+   there are no strict rules about it.+   - `systemVersion`: the server version (e.g. `4.2.0 Beta1` for SUMA, `2021.05`+   for Uyuni)++2. Furthermore, the `api` namespace also exposes basic API <a name="intro-calls">introspection calls</a>+   describing the structure of the call:+   - `getApiNamespaces`: all API namespaces+   - `getApiNamespaceCallList`: API methods of given namespace together with+     their parameter types, faults and return types+   - `getApiCallList`: all API methods grouped by namespace++3. Faults (retrospective): When the API consumers call a method in a+   wrong way (incorrect parameters, missing method or namespace), they+   get back an XMLRPC fault with code `-1`.+   For instance:+   ```python+   # Non-existing method/wrong method signature+   <Fault -1: 'redstone.xmlrpc.XmlRpcFault: Could not find method:+   test in class: com.redhat.rhn.frontend.xmlrpc.ansible.AnsibleHandler with params: []'>++   # Non-existing handler+   <Fault -1: 'The specified handler cannot be found'>+   ```+   Note: This fault code is+   not reserved solely to report the API calling mismatch cases, but+   is used in other cases (see the`CustomInfoHandler.java` file in+   Uyuni).+++## The problem++The main problem is the difficulty of writing the API consuming applications+that:++- can be agnostic to the server product flavor (they can target both Uyuni and+  SUMA)+- can target multiple versions of the product (e.g. SUMA 4.0, 4.1 and 4.2)+- can use the features introduced in maintenance updates of SUMA (a feature was+  not present in 4.1, but was introduced in a 4.1 maintenance update)+- handle exceptional cases gracefully (e.g. display a meaningful warning to the+  user, in case the feature does not exist in the API).++### Existing approach++Some applications already try to address the problem:++In the `spacecmd` tool, this is done by API version check endpoint+(`api.getVersion` above). The logic simply checks the API version and+reacts accordingly (e.g. warns the user, that given operation is not+supported by the API version).++A similar approach is taken by the `errata-import.pl` script by Steve+Meier+[1](https://github.com/stevemeier/cefs/blob/master/errata-import.pl). The+script contains a list of supported versions and checks on runtime,+whether the API version of the Uyuni/SUMA server is contained in this+list.++This method has 2 problems:+1. targetting both Uyuni and SUSE is hard (the API version numbers are not+consistent (API version `25` in Uyuni does not need to be the identical to the+version `25` in SUMA)).+2. currently, there is no defined rule to increase the API version. Sometimes+the API is modified, but the version stays unchanged, which makes it impossible+to track a feature presence.+++## Solution++The proposed solution is+- to enhance the documentation with the guidelines of writing the API consuming+  scripts that target multiple product versions+- to improve the API introspection calls+- to exactly define the semantics of the API version number and the rules for+  its increasing++These steps are described in the further sections in greater detail.++### Enhancing the documentation++Following sections of the documentation must be enhanced.++#### API > FAQ++We should introduce 3 ways of consuming the API:+1. (relaxed) check errors post-mortem+2. (stricter) check the method existence via introspection+3. (strictest) check the method existence via introspection and check exact+   product flavor/version++This should give the users the possibility of choosing the balance between the+total correctness and ease of writing the script.++##### 1. Check errors post-mortem+Do not perform any checks before calling the API. Only handle the error code,+when calling a method fails and notify the user about the error. The error code+signaling the absence of given method/signature must be enhanced (see below).++Checking errors after call is a good practice for the client applications and+should be used in the following methods too.++##### 2. Check the method existence via introspection+Before making a call, check if the desired API method-signature combination+exists. This check can be done using the [existing methods](#intro-calls) or+with the new [single method introspection](#introduce-a-single-method-introspection-method).++The advantage of this method is that it can warn the user before making the+actual call (one possible use case would be UI apps built on top of the API).++##### 3. Check the method existence via introspection and check exact product flavor/version+This is the safest and the most complicated way. In addition to the checks made+in the previous section, also check the the flavor and the API version. All+these checks make sure that the API call is present and has the desired+semantics defined in the product flavor and version.++#### API > Script Examples+Examples showing usage of the 3 ways of consuming the API described above should+be added to this section.+++### Improving the API introspection++These areas of the introspection must be addressed:++#### Error code for non-existing method/signature+Currently, when calling a non-existing method/signature combination, the API+reports a fault with code `-1`. As of time of writing this document, this error+code is used to signal other faults too (see the the `CustomInfoHandler.java`+file).++This needs to be solved by:+- visiting the current occurences of `-1` fault code in the existing handlers+  containing "business methods" (e.g. `CustomInfoHandler.java`) and make them+  use meaningful codes (see the `exception_ranges.txt` document in the codebase)+- reserving a new code for the absence of method/signature combination and+  making the existing XMLRPC code use it++#### Introduce a single method introspection method+In addition to+[existing introspection methods](#intro-calls),+implement a call in the `api` namespace for checking, whether a method with+signature exists in a namespace:+`apiCallExists(namespace, method, parameters_varargs)`.++The same can already be achieved (although in a bit more complicated way) with+already-existing introspection methods, but this method is more convenient.++#### Introduce the API flavor endpoint+Introduce a new method under the `api` namespace returning the product flavor+(Uyuni/SUMA).+++### Bumping the API version+The version of the API is bumped when a breaking change is introduced that+cannot tracked by introspection, which involves the following:+- changing a behavior of an existing method+- removing or adding a field in a structure accepted by a method / returned by a+  method+- changing the fault thrown by a method (changing a fault code, throwing new+  faults or removing a fault)+

I would add "removing" functions (deprecated) would also increase the version.

hustodemon

comment created time in 4 minutes

Pull request review commentuyuni-project/uyuni-rfc

[WIP] Improve the 3rd party usage of XMLRPC API

+- Feature Name: Improve the 3rd party usage of XMLRPC API+- Start Date: 2021-05-20+- RFC PR:++# Summary and motivation++The main goal of this RFC is to highlight the problems of writing client+applications or scripts compatible with multiple versions of Uynui and SUSE+Manager (SUMA) API and suggest an improvement in this area. When the consumers+use the API, there must be a way for them to make sure they call the endpoints+correctly (they need to call an existing method with correct parameters and they+also need to make some assumptions on the return value structure).+++## Note on XMLRPC structure exposition++Before describing the main problem, it is important to understand how the+information about API is exposed to clients.  Uyuni/SUMA exposes the information+about the API and its structure in 3 places:++1. Information about the versions via the `api` XMLRPC endpoint:+   - `getVersion`: the API version, e.g. `25`. This integer grows with time, but+   there are no strict rules about it.+   - `systemVersion`: the server version (e.g. `4.2.0 Beta1` for SUMA, `2021.05`+   for Uyuni)++2. Furthermore, the `api` namespace also exposes basic API <a name="intro-calls">introspection calls</a>+   describing the structure of the call:+   - `getApiNamespaces`: all API namespaces+   - `getApiNamespaceCallList`: API methods of given namespace together with+     their parameter types, faults and return types+   - `getApiCallList`: all API methods grouped by namespace++3. Faults (retrospective): When the API consumers call a method in a+   wrong way (incorrect parameters, missing method or namespace), they+   get back an XMLRPC fault with code `-1`.+   For instance:+   ```python+   # Non-existing method/wrong method signature+   <Fault -1: 'redstone.xmlrpc.XmlRpcFault: Could not find method:+   test in class: com.redhat.rhn.frontend.xmlrpc.ansible.AnsibleHandler with params: []'>++   # Non-existing handler+   <Fault -1: 'The specified handler cannot be found'>+   ```+   Note: This fault code is+   not reserved solely to report the API calling mismatch cases, but+   is used in other cases (see the`CustomInfoHandler.java` file in+   Uyuni).+++## The problem++The main problem is the difficulty of writing the API consuming applications+that:++- can be agnostic to the server product flavor (they can target both Uyuni and+  SUMA)+- can target multiple versions of the product (e.g. SUMA 4.0, 4.1 and 4.2)+- can use the features introduced in maintenance updates of SUMA (a feature was+  not present in 4.1, but was introduced in a 4.1 maintenance update)+- handle exceptional cases gracefully (e.g. display a meaningful warning to the+  user, in case the feature does not exist in the API).++### Existing approach++Some applications already try to address the problem:++In the `spacecmd` tool, this is done by API version check endpoint+(`api.getVersion` above). The logic simply checks the API version and+reacts accordingly (e.g. warns the user, that given operation is not+supported by the API version).++A similar approach is taken by the `errata-import.pl` script by Steve+Meier+[1](https://github.com/stevemeier/cefs/blob/master/errata-import.pl). The+script contains a list of supported versions and checks on runtime,+whether the API version of the Uyuni/SUMA server is contained in this+list.++This method has 2 problems:+1. targetting both Uyuni and SUSE is hard (the API version numbers are not+consistent (API version `25` in Uyuni does not need to be the identical to the+version `25` in SUMA)).+2. currently, there is no defined rule to increase the API version. Sometimes+the API is modified, but the version stays unchanged, which makes it impossible+to track a feature presence.+++## Solution++The proposed solution is+- to enhance the documentation with the guidelines of writing the API consuming+  scripts that target multiple product versions+- to improve the API introspection calls+- to exactly define the semantics of the API version number and the rules for+  its increasing++These steps are described in the further sections in greater detail.++### Enhancing the documentation++Following sections of the documentation must be enhanced.++#### API > FAQ++We should introduce 3 ways of consuming the API:+1. (relaxed) check errors post-mortem+2. (stricter) check the method existence via introspection+3. (strictest) check the method existence via introspection and check exact+   product flavor/version++This should give the users the possibility of choosing the balance between the+total correctness and ease of writing the script.++##### 1. Check errors post-mortem+Do not perform any checks before calling the API. Only handle the error code,+when calling a method fails and notify the user about the error. The error code+signaling the absence of given method/signature must be enhanced (see below).++Checking errors after call is a good practice for the client applications and+should be used in the following methods too.++##### 2. Check the method existence via introspection+Before making a call, check if the desired API method-signature combination+exists. This check can be done using the [existing methods](#intro-calls) or+with the new [single method introspection](#introduce-a-single-method-introspection-method).++The advantage of this method is that it can warn the user before making the+actual call (one possible use case would be UI apps built on top of the API).++##### 3. Check the method existence via introspection and check exact product flavor/version+This is the safest and the most complicated way. In addition to the checks made+in the previous section, also check the the flavor and the API version. All+these checks make sure that the API call is present and has the desired+semantics defined in the product flavor and version.++#### API > Script Examples+Examples showing usage of the 3 ways of consuming the API described above should+be added to this section.+++### Improving the API introspection++These areas of the introspection must be addressed:++#### Error code for non-existing method/signature+Currently, when calling a non-existing method/signature combination, the API+reports a fault with code `-1`. As of time of writing this document, this error+code is used to signal other faults too (see the the `CustomInfoHandler.java`+file).++This needs to be solved by:+- visiting the current occurences of `-1` fault code in the existing handlers+  containing "business methods" (e.g. `CustomInfoHandler.java`) and make them+  use meaningful codes (see the `exception_ranges.txt` document in the codebase)+- reserving a new code for the absence of method/signature combination and+  making the existing XMLRPC code use it++#### Introduce a single method introspection method+In addition to+[existing introspection methods](#intro-calls),+implement a call in the `api` namespace for checking, whether a method with+signature exists in a namespace:+`apiCallExists(namespace, method, parameters_varargs)`.++The same can already be achieved (although in a bit more complicated way) with+already-existing introspection methods, but this method is more convenient.++#### Introduce the API flavor endpoint+Introduce a new method under the `api` namespace returning the product flavor+(Uyuni/SUMA).+++### Bumping the API version+The version of the API is bumped when a breaking change is introduced that+cannot tracked by introspection, which involves the following:+- changing a behavior of an existing method

Hmm, is not every bugfix doing this? I remember a big discussion about a fix in glibc which changed the behavior if that was breaking API change. "A Bugfix can never break the API". Not so sure if this is true.

hustodemon

comment created time in 20 minutes

Pull request review commentuyuni-project/uyuni-rfc

[WIP] Improve the 3rd party usage of XMLRPC API

+- Feature Name: Improve the 3rd party usage of XMLRPC API+- Start Date: 2021-05-20+- RFC PR:++# Summary and motivation++The main goal of this RFC is to highlight the problems of writing client+applications or scripts compatible with multiple versions of Uynui and SUSE+Manager (SUMA) API and suggest an improvement in this area. When the consumers+use the API, there must be a way for them to make sure they call the endpoints+correctly (they need to call an existing method with correct parameters and they+also need to make some assumptions on the return value structure).+++## Note on XMLRPC structure exposition++Before describing the main problem, it is important to understand how the+information about API is exposed to clients.  Uyuni/SUMA exposes the information+about the API and its structure in 3 places:++1. Information about the versions via the `api` XMLRPC endpoint:+   - `getVersion`: the API version, e.g. `25`. This integer grows with time, but+   there are no strict rules about it.+   - `systemVersion`: the server version (e.g. `4.2.0 Beta1` for SUMA, `2021.05`+   for Uyuni)++2. Furthermore, the `api` namespace also exposes basic API <a name="intro-calls">introspection calls</a>+   describing the structure of the call:+   - `getApiNamespaces`: all API namespaces+   - `getApiNamespaceCallList`: API methods of given namespace together with+     their parameter types, faults and return types+   - `getApiCallList`: all API methods grouped by namespace++3. Faults (retrospective): When the API consumers call a method in a+   wrong way (incorrect parameters, missing method or namespace), they+   get back an XMLRPC fault with code `-1`.+   For instance:+   ```python+   # Non-existing method/wrong method signature+   <Fault -1: 'redstone.xmlrpc.XmlRpcFault: Could not find method:+   test in class: com.redhat.rhn.frontend.xmlrpc.ansible.AnsibleHandler with params: []'>++   # Non-existing handler+   <Fault -1: 'The specified handler cannot be found'>+   ```+   Note: This fault code is+   not reserved solely to report the API calling mismatch cases, but+   is used in other cases (see the`CustomInfoHandler.java` file in+   Uyuni).+++## The problem++The main problem is the difficulty of writing the API consuming applications+that:++- can be agnostic to the server product flavor (they can target both Uyuni and+  SUMA)+- can target multiple versions of the product (e.g. SUMA 4.0, 4.1 and 4.2)+- can use the features introduced in maintenance updates of SUMA (a feature was+  not present in 4.1, but was introduced in a 4.1 maintenance update)+- handle exceptional cases gracefully (e.g. display a meaningful warning to the+  user, in case the feature does not exist in the API).++### Existing approach++Some applications already try to address the problem:++In the `spacecmd` tool, this is done by API version check endpoint+(`api.getVersion` above). The logic simply checks the API version and+reacts accordingly (e.g. warns the user, that given operation is not+supported by the API version).++A similar approach is taken by the `errata-import.pl` script by Steve+Meier+[1](https://github.com/stevemeier/cefs/blob/master/errata-import.pl). The+script contains a list of supported versions and checks on runtime,+whether the API version of the Uyuni/SUMA server is contained in this+list.++This method has 2 problems:+1. targetting both Uyuni and SUSE is hard (the API version numbers are not+consistent (API version `25` in Uyuni does not need to be the identical to the+version `25` in SUMA)).+2. currently, there is no defined rule to increase the API version. Sometimes+the API is modified, but the version stays unchanged, which makes it impossible+to track a feature presence.+++## Solution++The proposed solution is+- to enhance the documentation with the guidelines of writing the API consuming+  scripts that target multiple product versions+- to improve the API introspection calls+- to exactly define the semantics of the API version number and the rules for+  its increasing++These steps are described in the further sections in greater detail.++### Enhancing the documentation++Following sections of the documentation must be enhanced.++#### API > FAQ++We should introduce 3 ways of consuming the API:+1. (relaxed) check errors post-mortem+2. (stricter) check the method existence via introspection+3. (strictest) check the method existence via introspection and check exact+   product flavor/version++This should give the users the possibility of choosing the balance between the+total correctness and ease of writing the script.++##### 1. Check errors post-mortem+Do not perform any checks before calling the API. Only handle the error code,+when calling a method fails and notify the user about the error. The error code+signaling the absence of given method/signature must be enhanced (see below).++Checking errors after call is a good practice for the client applications and+should be used in the following methods too.++##### 2. Check the method existence via introspection+Before making a call, check if the desired API method-signature combination+exists. This check can be done using the [existing methods](#intro-calls) or+with the new [single method introspection](#introduce-a-single-method-introspection-method).++The advantage of this method is that it can warn the user before making the+actual call (one possible use case would be UI apps built on top of the API).++##### 3. Check the method existence via introspection and check exact product flavor/version+This is the safest and the most complicated way. In addition to the checks made+in the previous section, also check the the flavor and the API version. All+these checks make sure that the API call is present and has the desired+semantics defined in the product flavor and version.++#### API > Script Examples+Examples showing usage of the 3 ways of consuming the API described above should+be added to this section.+++### Improving the API introspection++These areas of the introspection must be addressed:++#### Error code for non-existing method/signature+Currently, when calling a non-existing method/signature combination, the API+reports a fault with code `-1`. As of time of writing this document, this error+code is used to signal other faults too (see the the `CustomInfoHandler.java`+file).++This needs to be solved by:+- visiting the current occurences of `-1` fault code in the existing handlers+  containing "business methods" (e.g. `CustomInfoHandler.java`) and make them+  use meaningful codes (see the `exception_ranges.txt` document in the codebase)+- reserving a new code for the absence of method/signature combination and+  making the existing XMLRPC code use it++#### Introduce a single method introspection method+In addition to+[existing introspection methods](#intro-calls),+implement a call in the `api` namespace for checking, whether a method with+signature exists in a namespace:+`apiCallExists(namespace, method, parameters_varargs)`.++The same can already be achieved (although in a bit more complicated way) with+already-existing introspection methods, but this method is more convenient.++#### Introduce the API flavor endpoint+Introduce a new method under the `api` namespace returning the product flavor+(Uyuni/SUMA).+++### Bumping the API version+The version of the API is bumped when a breaking change is introduced that+cannot tracked by introspection, which involves the following:+- changing a behavior of an existing method+- removing or adding a field in a structure accepted by a method / returned by a+  method

"removing" I agree, but "adding" can be made in a way that it does not break things.

hustodemon

comment created time in 19 minutes

push eventopenSUSE/salt-packaging

Pablo Suárez Hernández

commit sha a7ef9ba82bee23e9a22a7bdf3e08568ea12ba4d0

Enhance logging when inotify beacon is missing pyinotify (bsc#1186310) Add "python3-pyinotify" as a recommended package for Salt in SUSE/OpenSUSE distros

view details

push time in 3 minutes

push eventopenSUSE/salt

Pablo Suárez Hernández

commit sha ae0e25cd1a451e6079fe3f66ca4ade613e210303

Enhance logging when inotify beacon is missing pyinotify (bsc#1186310)

view details

push time in 5 minutes

push eventopenSUSE/salt-packaging

Pablo Suárez Hernández

commit sha 5f409b05de1c91307531659825b378b7139e3450

Enhance logging when inotify beacon is missing pyinotify (bsc#1186310) Add "python3-pyinotify" as a recommended package for Salt in SUSE/OpenSUSE distros

view details

Pablo Suárez Hernández

commit sha 28b1f6576590247c86f3782418242d03922b100a

[skip] Rename spec file to py27-compat-salt

view details

Pablo Suárez Hernández

commit sha c716611319469cb06cd5de8f5791b15ab59039e8

[skip] Adapt spec file to new compat package

view details

Pablo Suárez Hernández

commit sha 27416988a899997cdf0d3d8b7748807254956cee

[skip] fix typo after fixing conflicts on spec

view details

Pablo Suárez Hernández

commit sha b29451f9026aef5a9eb97a1460400be368fb9dda

[skip] Add missing Python 2 dependencies for Salt 'thin' (bsc#1185421)

view details

push time in 13 minutes

push eventuyuni-project/uyuni

Aleš Kastner

commit sha 364685b9ed9991c69612b0ad5c6560910c3a01c3

Translated using Weblate (Czech) Currently translated at 100.0% (515 of 515 strings) Translation: uyuni/java database Translate-URL: https://l10n.opensuse.org/projects/uyuni/java-database/cs/ skip-checks: true

view details

Aleš Kastner

commit sha 624740244e6fcd54373a75181983b4fbdfd05149

Translated using Weblate (Czech) Currently translated at 8.5% (146 of 1707 strings) Translation: uyuni/java Translate-URL: https://l10n.opensuse.org/projects/uyuni/java/cs/

view details

push time in 13 minutes

push eventopenSUSE/salt-packaging

Pablo Suárez Hernández

commit sha 5f409b05de1c91307531659825b378b7139e3450

Enhance logging when inotify beacon is missing pyinotify (bsc#1186310) Add "python3-pyinotify" as a recommended package for Salt in SUSE/OpenSUSE distros

view details

push time in 14 minutes

push eventopenSUSE/salt

Pablo Suárez Hernández

commit sha 3ff386db00f89c7e7ced2e13e572c5a78493e5a7

Enhance logging when inotify beacon is missing pyinotify (bsc#1186310)

view details

push time in 16 minutes

issue commentuyuni-project/uyuni

Uyuni Bugreport - Uyuni 2021.05 add amazon linux channels

I closed the other one. At this moment the doc does not have any bug at all. Amazon Linux 2 for aarch64 is not supported, as stated at the release notes.

But as I told yesterday:

Will Amazon Linux for aarch64 work fine? It should, but we don't know. And that's why we did not document it. Please give it a try and let us know :-)

As soon as users can confirm it works fine, or we can find to test it, it will be documented.

As for the problems you have, using -a is not enough by itself, you need to use it with an architecture. IIRC -a aarch64 is the thing to do here.

And for syncing with spacewalk-repo-sync, I am quite sure you didn't specify the channel name including the architecture. The channel name does not match what you add via spacewalk-common-channels. IIRC its rather channelname-architecture.

So spacewalk-repo-sync -p amazonlinux2-core-aarch64 should work. -p tells the script to sync that channel and all children (such as the client tools).

eins

comment created time in 20 minutes

issue commentuyuni-project/uyuni

Uyuni Bugreport - Uyuni 2021.05 add amazon linux channels

@juliogonzalez thanks for the reply I created a new issue in the uyuni-docs github repository https://github.com/uyuni-project/uyuni-docs/issues/999

@juliogonzalez do I need to close this issue or do you want to wait for the uyuni-docs' issues #999 to be closed first ?

eins

comment created time in 29 minutes

issue closeduyuni-project/uyuni

[GSoC] Amazon Linux 2 support

(This is a copy of https://github.com/openSUSE/mentoring/issues/132 to reach a wider audience. Uyuni has applied for Google Summer of Code as under the openSUSE umbrella: https://101.opensuse.org) Project Title: Amazon Linux 2 support

Description: Uyuni supports many Linux clients (openSUSE, CentOS, SUSE Linux Enterprise, Red Hat Enterprise Linux, etc). Let's add one more: Amazon Linux 2. It is very similar to RHEL but with a twist: metadata is in sqlite format. Supporting it as a Salt client is enough, no need to implement the traditional stack.

Deliverable: Very similar to what supporting any other client means:

  • Build openSUSE's Salt packages for Amazon Linux 2. It may very well be the case that the RHEL packages just work but at least testing is needed. - https://build.opensuse.org/package/show/systemsmanagement:saltstack:products:testing/salt
  • Onboard (register) Amazon Linux clients as Salt minions
  • Create bootstrap repository
  • Add reposync support for sqlite format. Alternatives: a) download the sqlite files and convert them to XML (which is currently works) or b) add native support for sqlite.
  • Generate and process patches and security information (CVE information from the Amazon Linux Security Advisories - https://alas.aws.amazon.com/ )

Mentor: @juliogonzalez

Skills: You will need to have a good understanding of Linux, and be comfortable with version control using git and GitHub. Some Sqlite, PostgreSQL, JSON, Python and Java (you will be mostly looking at existing code and adding new sub-cases to it). Familiarity with AWS, Amazon Linux and package management.

Skill Level: Medium

Get started:

  • Getting started hacking Uyuni: http://bosdonnat.fr/slides/openSUSEAsiaSummit19/#/about
  • Get a free tier account in AWS
  • Read about Amazon Linux 2 and create a VM to play with it: https://aws.amazon.com/amazon-linux-2/ (you can also download and run it locally)
  • Download an Uyuni Server VM and setup the Server - https://build.opensuse.org/package/binaries/home:pagarcia:Uyuni/Uyuni-2020.01-Server/Uyuni
  • Hackweek project on adding support for more Linux distributions: https://hackweek.suse.com/19/projects/testing-gnu-slash-linux-distributions-on-uyuni
  • Get familiar with the Uyuni source code and implement creation of the bootstrap repository. You can take a look at these commits as a reference: https://github.com/uyuni-project/uyuni/commit/e5d4d29f3148af40882a1c726b56556f08ed41c2 https://github.com/uyuni-project/uyuni/commit/6da14873065befad4caff4e98a5f5481212fbb36
  • Uyuni Wiki:
    • Introduction to Uyuni and systems management (presentation): https://github.com/uyuni-project/uyuni/wiki/Presentations
    • Development pages: https://github.com/uyuni-project/uyuni/wiki/

closed time in 34 minutes

paususe

delete branch uyuni-project/uyuni

delete branch : qa-debug-portus-img-build

delete time in an hour

push eventuyuni-project/uyuni

Oscar Barrios

commit sha f338f1b05714c5cfd6410573b62c7a25d50c468c

QA: Add more logs to debug portus image building in case of failure

view details

push time in an hour

PR merged uyuni-project/uyuni

Reviewers
QA: Add more logs to debug portus image building in case of failure ruby_rubocop secondary-features test-framework testing

What does this PR change?

Add more logs to debug portus image building in case of failure

GUI diff

No difference.

  • [x] DONE

Documentation

  • No documentation needed

  • [x] DONE

Test coverage

  • Cucumber tests were added

  • [x] DONE

Links

Ports:

  • Manager-4.1

  • [ ] DONE

Changelogs

If you don't need a changelog check, please mark this checkbox:

  • [x] No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)

Re-run a test

If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:

  • [ ] Re-run test "changelog_test"
  • [ ] Re-run test "backend_unittests_pgsql"
  • [ ] Re-run test "java_pgsql_tests"
  • [ ] Re-run test "schema_migration_test_oracle"
  • [ ] Re-run test "schema_migration_test_pgsql"
  • [ ] Re-run test "susemanager_unittests"
  • [ ] Re-run test "javascript_lint"
  • [ ] Re-run test "spacecmd_unittests"
+16 -0

0 comment

3 changed files

srbarrios

pr closed time in an hour

created taguyuni-project/uyuni

tagspacewalk-web-4.2.19-1

Source code for Uyuni

created time in 2 hours

push eventuyuni-project/uyuni

Julio Gonzalez Gil

commit sha e6da0c32cde44346f934349d7d479ddb8519359f

Bump Uyuni 20201.06

view details

Julio Gonzalez Gil

commit sha f517870cb8887778c6b0f810b6ccda1831e96958

Automatic commit of package [spacewalk-web] release [4.2.19-1].

view details

push time in 2 hours

created taguyuni-project/uyuni

tagsusemanager-schema-4.2.15-1

Source code for Uyuni

created time in 2 hours

push eventuyuni-project/uyuni

Julio Gonzalez Gil

commit sha e3825ca346e389f84501c7bc3bd1f4b1c2594b10

Automatic commit of package [susemanager-schema] release [4.2.15-1].

view details

push time in 2 hours

created taguyuni-project/uyuni

tagsusemanager-sync-data-4.2.7-1

Source code for Uyuni

created time in 2 hours

push eventuyuni-project/uyuni

Julio Gonzalez Gil

commit sha d6ac222d60669c8894302707e15ee7f3cd2ecccc

Automatic commit of package [susemanager-sync-data] release [4.2.7-1].

view details

push time in 2 hours

created taguyuni-project/uyuni

tagspacewalk-backend-4.2.14-1

Source code for Uyuni

created time in 2 hours

push eventuyuni-project/uyuni

Julio Gonzalez Gil

commit sha acc45521a0c958303e3fce42f8a0b3b69a49940e

Automatic commit of package [spacewalk-backend] release [4.2.14-1].

view details

push time in 2 hours

created taguyuni-project/uyuni

tagspacewalk-utils-4.2.11-1

Source code for Uyuni

created time in 2 hours

push eventuyuni-project/uyuni

Julio Gonzalez Gil

commit sha 6e47a5922c3aacef83f9a8e5eb6aaa28dd61e246

Automatic commit of package [spacewalk-utils] release [4.2.11-1].

view details

push time in 2 hours

push eventuyuni-project/uyuni

Julio Gonzalez Gil

commit sha 1af7337c61a3f25420f7a106859fa16b953f7408

Use the right repositories for the AlmaLinux 8 Uyuni client tools

view details

push time in 2 hours

PR merged uyuni-project/uyuni

Use the right repositories for the AlmaLinux 8 Uyuni client tools database merge-candidate schema_migration_test_oracle schema_migration_test_pgsql

What does this PR change?

We were supposed to use the EL8 client tools, not CentOS8, but since EL8 arrrived later to OBS, we didn't remember to change it.

This PR takes care of this, for new installations, and for existing installations.

GUI diff

No difference.

  • [ ] DONE

Documentation

  • No documentation needed: Bugfix

  • [x] DONE

Test coverage

  • No tests: We tested AlmaLinux8, thing is that the CentOS8 client tools work as well, as they use the same sources.

  • [x] DONE

Links

None

  • [x] DONE

Changelogs

If you don't need a changelog check, please mark this checkbox:

  • [ ] No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)

Re-run a test

If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:

  • [ ] Re-run test "changelog_test"
  • [ ] Re-run test "backend_unittests_pgsql"
  • [ ] Re-run test "java_pgsql_tests"
  • [ ] Re-run test "schema_migration_test_oracle"
  • [ ] Re-run test "schema_migration_test_pgsql"
  • [ ] Re-run test "susemanager_unittests"
  • [ ] Re-run test "javascript_lint"
  • [ ] Re-run test "spacecmd_unittests"
+13 -4

0 comment

4 changed files

juliogonzalez

pr closed time in 2 hours

Pull request review commentuyuni-project/uyuni

QA: Add more logs to debug portus image building in case of failure

 Feature: Build image with authenticated registry     And I check "useCredentials"     And I enter URI, username and password for portus     And I click on "create-btn"+    Then I wait until I see "portus" text

I prefer "And" here, but let's not restart this discussion :smile_cat:

srbarrios

comment created time in 2 hours

push eventuyuni-project/uyuni

Oscar Barrios

commit sha deb7d38d35d002ae6d98fc3a5f340b5849e1f4b1

QA: Add more logs to debug portus image building in case of failure

view details

push time in 2 hours