Add no power management status and alert for BMH by rawagner · Pull Request #5830 · openshift/console

rawagner · 2020-06-26T08:40:32Z

List view

Overview (message in Status)

Details - maybe in this case the message does not have to be alert ?

I've also disabled power actions if there's no power management.
Improved the BMH activities on overview page - wont be shown anymore if there's no power mgmt.

Now I wonder what should we do about the New/Edit BMH dialog - BMC address/pass/username is required right now but I guess we should remove that. But if user fills in one of these values he has to fill in all - its all or nothing - how to visualize that ? - tracking in https://issues.redhat.com/browse/MGMT-1352

rawagner · 2020-06-26T09:23:10Z

@andybraren

andybraren

That was fast, and great improvements/additions! 😄

There's some new discussion happening in MGMT-1262 about additional API changes that I still need to read through, which may affect some of this.

Nit: A period should be placed in every place after the word provided. EDIT: I see it's correct in the code, maybe the screenshots are just a bit older?

I notice that the BMH Overview's Status card status has Status as the primary text and Externally provisioned as secondary. That status should probably align with the status shown in the List page, so just Externally provisioned, right?

Details - maybe in this case the message does not have to be alert ?

Agreed, in that particular popover moving the text outside of the inline alert and putting the Add credentials button in the footer of the popover makes sense to me.

Improved the BMH activities on overview page - wont be shown anymore if there's no power mgmt.

Nice, I've filed a somewhat-related styling issue.

Now I wonder what should we do about the New/Edit BMH dialog - BMC address/pass/username is required right now but I guess we should remove that. But if user fills in one of these values he has to fill in all - its all or nothing - how to visualize that ?

I've created MGMT-1352 with some ideas.

FYI @nirfarkas

andybraren · 2020-06-26T15:40:50Z

Suggested change

from this source will not receive updates unitl this source is re-enabled.

from this source will not receive updates until this source is re-enabled.

I guess not in scope for this PR, but spelling error here.

rawagner · 2020-06-29T05:32:30Z

Nit: A period should be placed in every place after the word provided. EDIT: I see it's correct in the code, maybe the screenshots are just a bit older?

I knew you would notice it :) These are older screenshots.

I notice that the BMH Overview's Status card status has Status as the primary text and Externally provisioned as secondary. That status should probably align with the status shown in the List page, so just Externally provisioned, right?

Right, I will align those.

Details - maybe in this case the message does not have to be alert ?

Agreed, in that particular popover moving the text outside of the inline alert and putting the Add credentials button in the footer of the popover makes sense to me.

+1

Improved the BMH activities on overview page - wont be shown anymore if there's no power mgmt.

Nice, I've filed a somewhat-related styling issue.

Thanks I will take a look.

Now I wonder what should we do about the New/Edit BMH dialog - BMC address/pass/username is required right now but I guess we should remove that. But if user fills in one of these values he has to fill in all - its all or nothing - how to visualize that ?

I've created MGMT-1352 with some ideas.

FYI @nirfarkas

rawagner · 2020-07-01T09:02:54Z

@andybraren @jtomasek
Since we have Unmanaged provisioning state I'm using that one instead of Externally Provisioned. BMH becomes Externally Provisioned (or Provisioned) once BMC credentials are provided.

new pics

andybraren · 2020-07-01T12:58:03Z

Unmanaged looks good, and I agree the inline alert wasn't needed in the status popover anymore. 👍

andybraren · 2020-07-01T14:38:30Z

Reading through baremetal-operator/#569 and thinking about this more with @nirfarkas, maybe this Unmanaged state shouldn't be represented with a happy green checkmark.

@dhellmann @beekhof Are there any potentially serious/annoying limitations of Unmanaged hosts that would warrant changing the green checkmark to something else in the UI? Maybe something as severe as a yellow warning icon?

I know Machine Health Checks wouldn't work, but what about upgrades? Would we be able to upgrade a host without its BMC credentials? If not, that seems like something we'd want to bring to users' attention in a much more visible way, and nudge the user more strongly toward providing those credentials as soon as they can.

dhellmann · 2020-07-01T14:45:56Z

Upgrades happen in place and don't go through the machine API or use metal3, so they'll work fine without credentials.

We won't be able to hard-reboot the host (when/if we have soft reboot the remediation code may be able to use that).

It will be possible to end up with an unmanaged host outside of the assisted installer by creating the host resource without the BMC details. If that happens, the host will not be associated with a node, won't have hardware details, and the user won't be able to provision it until they add the credentials.

It seems like it would be worth using a different representation to indicate that we don't have full control. I'm not sure a "warning" icon is necessary, though. Maybe a question mark? Or just a solid circle without the check mark in it? Something that's a gentle reminder that they could do more to get more.

nirfarkas · 2020-07-01T20:04:38Z

Hi,
I've attached 4 possible options for icons we can add next to the "Unmanaged" status instead of the "happy green checkmark" (:

The top one is (good old) info icon
The second is the "wrench" icon
The third is the "degraded" icon
The last one is "power off" icon

Andy, I still think we need here a stronger call to action (maybe the sub-status can be more instructive, somthing like: "Enter power management credentials"
What do you think?

dhellmann · 2020-07-01T20:30:34Z

I like the info mark.

We need to be careful not to press too hard for BMC credentials. The cluster isn't broken without them. It isn't degraded. There are just some features not in use.

nirfarkas · 2020-07-05T09:07:50Z

I like the info mark.

We need to be careful not to press too hard for BMC credentials. The cluster isn't broken without them. It isn't degraded. There are just some features not in use.

@andybraren What do you think?

rawagner · 2020-07-07T08:38:16Z

I updated the code with info icon, since I like that one too. @andybraren let us know if you have any objections.
@jtomasek ready for review

andybraren · 2020-07-08T04:10:19Z

Let's proceed with an info icon for now and we'll work with the other OpenShift designers to see if we can figure out a better one (or maybe even none at all?) for this pretty unique case. I believe this is the first time we'd be using this info icon as a status icon which is why I'm a little hesitant, but I'd rather not hold up the rest of this PR's fixes longer for something that can be easily changed later.

Since it sounds like a user could leave hosts in this state for months with no impact on upgrades or anything potentially dangerous, maybe it is a "checkmark" state after all, but more like a "mostly happy grey checkmark" instead of green if we can do a color-only tweak. I realize that a checkmark doesn't quite match up to a noun like "Unmanaged" which sounds like a negative thing, however.

We'll follow up.

jtomasek · 2020-07-10T08:16:33Z

-                      icon={<RebootingIcon />}
-                    />
+                  {!hasPowerManagement(host) ? (
+                    <SecondaryStatus status={HOST_NO_POWER_MGMT} />


Shouldn't this be StatusIconAndText? SecondaryStatus is used as an additional info for Status

I wanted to show No power management as grayed out text which SecondaryStatus provides. I could change that to StatusIconAndText and add className. But I dont really see that as better solution.

jtomasek · 2020-07-10T08:27:01Z

+    }
  }
+
+  return hostStatus;


I'd prefer returning from the cases instead of setting 'hostStatus' variable and breaking. No pressure, though :)

jtomasek · 2020-07-10T08:31:12Z

 type BareMetalHostStatusProps = StatusProps & {
  host?: BareMetalHostKind;
  nodeMaintenance?: K8sResourceKind;
+  showCredentials?: boolean;


Is this prop actually used in the component? I don't see it anywhere.

leftover, removed

jtomasek · 2020-07-10T09:38:40Z

/lgtm

openshift-ci-robot · 2020-07-10T09:38:44Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jtomasek, rawagner

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~frontend/OWNERS~~ [rawagner]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

openshift-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. component/kubevirt Related to kubevirt-plugin labels Jun 26, 2020

openshift-ci-robot requested review from jtomasek and yaacov June 26, 2020 08:40

openshift-ci-robot added component/metal3 Related to metal3-plugin approved Indicates a PR has been approved by an approver from all required OWNERS files. component/olm Related to OLM component/shared Related to console-shared labels Jun 26, 2020

rawagner force-pushed the bmh_credentials branch from 2cbebc4 to 2a75dc8 Compare June 26, 2020 09:32

andybraren reviewed Jun 29, 2020

View reviewed changes

rawagner force-pushed the bmh_credentials branch 4 times, most recently from 044cc01 to ad14c50 Compare July 1, 2020 08:58

openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 2, 2020

rawagner force-pushed the bmh_credentials branch from ad14c50 to f1c308d Compare July 7, 2020 08:31

openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 7, 2020

rawagner force-pushed the bmh_credentials branch 2 times, most recently from c1aa7ef to af773dc Compare July 7, 2020 08:36

rawagner changed the title ~~[WIP] Add no power management status and alert for BMH~~ Add no power management status and alert for BMH Jul 7, 2020

openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 7, 2020

jtomasek suggested changes Jul 10, 2020

View reviewed changes

Add no power management status and alert for BMH

4fc5993

rawagner force-pushed the bmh_credentials branch from af773dc to 4fc5993 Compare July 10, 2020 09:03

jtomasek approved these changes Jul 10, 2020

View reviewed changes

openshift-ci-robot assigned jtomasek Jul 10, 2020

openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 10, 2020

openshift-merge-robot merged commit 300e2de into openshift:master Jul 10, 2020

rawagner mentioned this pull request Jul 10, 2020

Add/Edit BMH - make BMC optional #5942

Merged

spadgett added this to the v4.6 milestone Jul 14, 2020

	from this source will not receive updates unitl this source is re-enabled.
	from this source will not receive updates until this source is re-enabled.

Conversation

rawagner commented Jun 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rawagner commented Jun 26, 2020

Uh oh!

andybraren left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andybraren Jun 26, 2020

Choose a reason for hiding this comment

Uh oh!

rawagner commented Jun 29, 2020

Uh oh!

rawagner commented Jul 1, 2020

Uh oh!

andybraren commented Jul 1, 2020

Uh oh!

andybraren commented Jul 1, 2020

Uh oh!

dhellmann commented Jul 1, 2020

Uh oh!

nirfarkas commented Jul 1, 2020

Uh oh!

dhellmann commented Jul 1, 2020

Uh oh!

nirfarkas commented Jul 5, 2020

Uh oh!

rawagner commented Jul 7, 2020

Uh oh!

andybraren commented Jul 8, 2020

Uh oh!

jtomasek Jul 10, 2020

Choose a reason for hiding this comment

Uh oh!

rawagner Jul 10, 2020

Choose a reason for hiding this comment

Uh oh!

jtomasek Jul 10, 2020

Choose a reason for hiding this comment

Uh oh!

rawagner Jul 10, 2020

Choose a reason for hiding this comment

Uh oh!

jtomasek Jul 10, 2020

Choose a reason for hiding this comment

Uh oh!

rawagner Jul 10, 2020

Choose a reason for hiding this comment

Uh oh!

jtomasek commented Jul 10, 2020

Uh oh!

openshift-ci-robot commented Jul 10, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

rawagner commented Jun 26, 2020 •

edited

Loading

andybraren left a comment •

edited

Loading