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

Remote Execution: content journey

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • None
    • REX docs improvements
    • 5
    • False
    • sat-endeavour
    • None
    • None
    • None

      Mini Content Journey

      Who is your target persona?

      Satellite user running remote jobs (admin-type role)

      What stage of the user journey are you targeting?

      Learn, Try, Expand

      Why is this content important?

      This area was highlighted by Satellite CS as a good one to focus on.

      What is the main user goal aka job to be done?

      As a Satellite admin-type user, I want to perform various tasks on multiple Satellite hosts simultaneously.

      What high level steps does the user need to take to accomplish the goal?

      1. Learn about REX and the push/pull modes, 2. Decide which mode to use, 3. Run basic jobs, 4. Tweak the settings and run more advanced jobs.

      (Optional) What is the general sentiment of users towards this goal?

       

      (Optional) What pain points are the user likely to encounter when accomplishing this goal?

      Users are likely to appreciate examples and tutorial-like example REX jobs.

      (Optional) What other feedback do users have around this goal?

       

      (Optional) Are there any additional opportunities you can also implement for the user when documenting this goal?

      Existing docs for REX don't comply with Red Hat's documentation standards.

      • Inconsistent terminology:
        • Remote execution/remote jobs/remote execution of commands on hosts
        • Pull client/mqtt pull client/pull mode/mqtt mode + ssh mode/push mode
      • Lack of examples and hands-on procedures, tutorials
      • Conceptual/procedural/referential information is not clearly separated
      • Too many modules, several very small procedures about configuring a single option
      • Procedures don't follow DITA requirements.

      Proposed solution:

      • Rearrange information based on the information type: strictly separate concept, procedures, and reference.
      • Investigate ways to turn some procedures (based on setting a single option) into a reference module (with an overview of options).
      • Reduce the amount of content (lines) that we maintain.
      • Define and use consistent terminology.
      • Make all new content follow modular docs/DITA requirements (to the best of our current knowledge)
      • Add examples.

      Right now, we effectively have two documents that describe REX: See "Links to existing content". If we manage to merge them, we could then create a new guide specifically for "Managing Satellite hosts remotely".

      Links to existing content 

      Configuring and setting up remote jobs

      Configuring hosts by using Ansible also covers remote execution and we should consider whether we really need two resources for REX as a feature.

      People:

      • SME: [SME name]
      • QE: [QE name]

      Release Note: No

      Documentation Outline

      • Concept:
        • Overview (what REX is and why it's useful)
        • Architecture (the technical solution underlying REX)
        • Comparison of the two REX modes and the features they support (Ansible vs Script providers)
      • Procedure:
        • Configuring hosts for REX
        • Permissions (defining which roles can trigger which jobs)
        • Establishing a connection for SSH-mode REX jobs (SSH keys, Kerberos TGTs)
        • Defining jobs templates
        • Running the actual jobs

              apetrova@redhat.com Aneta Šteflová Petrová
              apinnick@redhat.com Avital Pinnick
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: