Uploaded image for project: 'Machine Config Operator'
  1. Machine Config Operator
  2. MCO-240

Set or change 'core' user password via MachineConfig

XMLWordPrintable

    • Core user password via MC
    • False
    • False
    • Yellow
    • To Do
    • OCPSTRAT-51 - Set or change 'core' user password via MachineConfig
    • OCPSTRAT-51Set or change 'core' user password via MachineConfig
    • 0% To Do, 0% In Progress, 100% Done
    • Hide

      The MCO team currently does not have capacity to complete this work in 4.12 given our other priorities. A Spike has been created for Sprint 223 to explore the viability of completing this work or handing it off to other folks.

      Show
      The MCO team currently does not have capacity to complete this work in 4.12 given our other priorities. A Spike has been created for Sprint 223 to explore the viability of completing this work or handing it off to other folks.
    • 0

      Epic Goal

      • Users who disable ssh access in favor of `oc debug` are reliant on the OpenShift API being up between the supervisors and worker nodes. In order to troubleshoot or RCA a node problem, these users would like to be able to use password auth on /dev/console, which they can access via BMC or local keyboard.

      Why is this important?

      • While setting passwords hasn't been cool in some time, it can make sense if password auth is disabled in sshd (which it is by default).
      • There is a workaround: push an /etc/shadow.

      Scenarios

      1. A new node is failing to join the cluster and ssh/api access is not possible but a local console (via cloud provider or bare metal BMC). The administrator would like to pull logs to triage the joining problem.
      2. sshd is not enabled and the API connection to the kubelet is down (so no `oc debug node`) and the administrator needs to triage the problem and/or collect logs.

      Acceptance Criteria

      • Users can set and change a password on "core" via ignition (machineconfig).
      • Changing the core user password should not cause workload disruption
      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

          1.
          		 PX Tracker Sub-task Closed Undefined Derrick Ornelas
          2.
          		 Docs Tracker Sub-task Closed Undefined Unassigned
          3.
          		 QE Tracker Sub-task Closed Undefined Unassigned
          4.
          		 TE Tracker Sub-task Closed Undefined Derrick Ornelas

            [MCO-240] Set or change 'core' user password via MachineConfig

            Sinny Kumari added a comment -

            Thanks Ju, moved to Release Pending.

            Sinny Kumari added a comment - Thanks Ju, moved to Release Pending.

            Ju Lim added a comment -

            Can the status be updated to closed or release pending since all child items are closed/release pending?

            Ju Lim added a comment - Can the status be updated to closed or release pending since all child items are closed/release pending?

            Ju Lim added a comment -

            This is confusing as the parent and child of this epic is both OCPBU-9. Aside from the parent/"child" feature (OCPBU-9), it looks like all child epics are closed. Can we get the status updated (and also the "child" epic/feature OCPBU-9) linking too?

            CC rhn-support-mrussell

            Ju Lim added a comment - This is confusing as the parent and child of this epic is both OCPBU-9 . Aside from the parent/"child" feature ( OCPBU-9 ), it looks like all child epics are closed. Can we get the status updated (and also the "child" epic/feature OCPBU-9 ) linking too? CC rhn-support-mrussell

            Yuri Almeida added a comment -

            rhn-support-mrussell Thanks for the clarification and for the tips. I was able to implement a machineconfig that sets a unit file to run chpasswd as you suggested, so this requirement is already sorted out in my case.

            Yuri Almeida added a comment - rhn-support-mrussell Thanks for the clarification and for the tips. I was able to implement a machineconfig that sets a unit file to run chpasswd as you suggested, so this requirement is already sorted out in my case.

            Mark Russell added a comment - - edited

            yalmeida@redhat.com generally we do not backport features and we're not planning to here.

            There are also viable workarounds customers can use today – like a machineconfig that pushes a new /etc/shadow or maybe a unit file that sets the password with chpasswd.

            Mark Russell added a comment - - edited yalmeida@redhat.com generally we do not backport features and we're not planning to here. There are also viable workarounds customers can use today – like a machineconfig that pushes a new /etc/shadow or maybe a unit file that sets the password with chpasswd.

            Yuri Almeida added a comment -

            Is it expected to have a backport of this feature to 4.12? This is really in demand for telco deployments that usually follow EUS (even-numbered) releases.

            Yuri Almeida added a comment - Is it expected to have a backport of this feature to 4.12? This is really in demand for telco deployments that usually follow EUS (even-numbered) releases.

            Wei Sun added a comment -

            rhn-support-rioliu Could you please check if any QE test needed? 
             

            Wei Sun added a comment - rhn-support-rioliu Could you please check if any QE test needed?   

            Bill Montgomery added a comment -

            Hi mkrejci-1, yes, this is still important to be able to troubleshoot certain failure modes. Should still be relevant in Hypershift as well, to troubleshoot Worker nodes. 

            Bill Montgomery added a comment - Hi mkrejci-1 , yes, this is still important to be able to troubleshoot certain failure modes. Should still be relevant in Hypershift as well, to troubleshoot Worker nodes. 

            Michelle Krejci added a comment -

            bmontgom.openshift the MCO team has scoped and defined this work and believe that we can target it for 4.13. Is this still a high priority for the SD team?

            Michelle Krejci added a comment - bmontgom.openshift the MCO team has scoped and defined this work and believe that we can target it for 4.13. Is this still a high priority for the SD team?

            Michelle Krejci added a comment -

            Per MCO-319, we unfortunately did not find a solution that met this requirement that could be implemented by the MCO team in 4.12. We do not have the capacity to complete this work in 4.12, as Hypershift and Layering take priority. We will revisit next release.

             cc/ rhn-support-mrussell bmontgom.openshift 

            Michelle Krejci added a comment - Per MCO-319 , we unfortunately did not find a solution that met this requirement that could be implemented by the MCO team in 4.12. We do not have the capacity to complete this work in 4.12, as Hypershift and Layering take priority. We will revisit next release.  cc/ rhn-support-mrussell bmontgom.openshift  

              dkhater@redhat.com Dalia Khater
              rhn-support-mrussell Mark Russell
              John Kyros
              Votes:
              1 Vote for this issue
              Watchers:
              17 Start watching this issue

                Created:
                Updated:
                Resolved: