Uploaded image for project: 'Satellite'
  1. Satellite
  2. SAT-27476

Update pull-provider to work with yggdrasil-0.4.z landing in RHEL 9.6 and RHEL 10

XMLWordPrintable

    • Update pull-provider to work with yggdrasil-0.4.z landing in RHEL 9.6 and RHEL 10
    • SAT-27793 - Upgrade to yggdrasil-0.4.z landing in RHEL 9
    • Endeavour
    • 4
    • False
    • Feature
    • Hide
      .Remote execution in pull mode is now compatible with clients running `yggdrasil` versions 0.2.z and 0.4.z

      The remote execution pull provider has been updated to be compatible with all versions of the `yggdrasil` package that can be installed on a host. As a result, remote execution jobs in pull mode work on Satellite hosts that run any of the currently supported versions of RHEL. This applies also to hosts with the Extra Packages for Enterprise Linux (EPEL) repository enabled.

      The pull-based transport mode relies on the Yggdrasil service and requires different Yggdrasil configuration based on the version of the `yggdrasil` package that is installed on the host. If weak dependencies are enabled on your hosts, the Yggdrasil client configuration is automatically updated and no further steps are required. If weak dependencies are disabled on your hosts, you must install the `foreman_ygg_migration` package manually to ensure that the Yggdrasil client configuration is updated. For detailed instructions, see link:https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/html-single/managing_hosts/index#troubleshooting-remote-jobs-timing-out-after-yggdrails-update[Remote jobs timing out after yggdrasil update] in _{ManagingHostsDocTitle}_.
      Show
      .Remote execution in pull mode is now compatible with clients running `yggdrasil` versions 0.2.z and 0.4.z The remote execution pull provider has been updated to be compatible with all versions of the `yggdrasil` package that can be installed on a host. As a result, remote execution jobs in pull mode work on Satellite hosts that run any of the currently supported versions of RHEL. This applies also to hosts with the Extra Packages for Enterprise Linux (EPEL) repository enabled. The pull-based transport mode relies on the Yggdrasil service and requires different Yggdrasil configuration based on the version of the `yggdrasil` package that is installed on the host. If weak dependencies are enabled on your hosts, the Yggdrasil client configuration is automatically updated and no further steps are required. If weak dependencies are disabled on your hosts, you must install the `foreman_ygg_migration` package manually to ensure that the Yggdrasil client configuration is updated. For detailed instructions, see link: https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/html-single/managing_hosts/index#troubleshooting-remote-jobs-timing-out-after-yggdrails-update [Remote jobs timing out after yggdrasil update] in _{ManagingHostsDocTitle}_.
    • Done

      Since we introduced the pull provider, we carried both yggdrasil and our own worker (foreman_ygg_worker) in satellite client repos. Starting with RHEL 9.6 and RHEL 10, yggdrasil is going to be included in RHEL repos. The version there (0.4.1, we need >=0.4.2 due to dbus policies) is much newer than the one we ship, and therefore "wins" when yggdrasil is being installed. This causes a problem, because our own worker is not compatible with this newer version of yggdrasil.

      Goal:

      • Ensure remote execution pull provider is usable on client machines running any of the currently supported versions of RHEL

      Acceptance Criteria:

      • Make sure the version of foreman_ygg_worker works on all versions of RHEL, no matter what version of yggdrasil is available there
        • it should work on RHEL7, RHEL8, RHEL9 and RHEL 10 out of the box
        • it should work on RHEL 9.6 after upgrade from RHEL 9.5
        • it should work on RHEL 9.6 after LEAPP upgrade from RHEL 8.y
        • it should work on RHEL 10 after LEAPP upgrade from RHEL 9.y
      • Make sure all the supplementary tools (katello-pull-transport-migrate, pull-provider deployment templates in Satellite) still work
        • backport the in-satellite changes to currently supported Satellites - 6.14, 6.15, 6.16
      • Documentation is adjusted to the changes which might be introduced with newer version of yggdrasil (for example different service names)
        • the working dir procedure will need to be adjusted

      Open questions:

      • Instead of having the worker plugin be compatible with different versions of yggdrasil, could we update the version of yggdrasil the we have in the client repo?
      • Q: Is it possible that newer yggdrasil will be introduced to RHEL 8.y?
        A: Quote from 2024-09-24's CSI client tooling sync "RHEL 8 might not get this update [yggdrasil-0.4.z] at all (at this point)"
      • Q: Possibility of yggdrasil from pull mode conflicting with RHC?
        A: As of today, current RHEL 10 composes still have grpc-based builds of rhc, there's no risk of conflict until it switches to dbus. If it switched to dbus, the clash could happen on Satellite machine itself. Having both yggdrasil and rhc there is currently technically possible, but undocumented. In this situation, nothing would change, it would still be technically possible, but it would still remain undocumented. On managed hosts reporting to cloud through Satellite, having yggdrasil and rhc coexist doesn't sound useful.

              aruzicka@redhat.com Adam Ruzicka
              aruzicka@redhat.com Adam Ruzicka
              Peter Ondrejka Peter Ondrejka
              Aneta Šteflová Petrová Aneta Šteflová Petrová
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: