tinkerbell/rufio

Incorrect power status parsing

ibrokethecloud opened this issue · 3 comments

ibrokethecloud commented

Currently the baseboardcontroller, checks for the power status

https://github.com/tinkerbell/rufio/blob/main/controllers/baseboardmanagement_controller.go#L172

And attempts to perform conversion to PowerState type: https://github.com/tinkerbell/rufio/blob/main/controllers/baseboardmanagement_controller.go#L179

This however doesnt work with some of the supermicros and Dell servers tested against.

The actual power status response returned is Chassis Power is on. As a result the baseboardmanagement objects dont reconcile successfully.

Expected Behaviour

Expect the baseboardmanagement objects to reconcile and power status updated.

Current Behaviour

Currently the baseboardmanagement do not reconcile.

Possible Solution

Change logic in baseboardcontroller to match multiple returned power status.

Steps to Reproduce (for bugs)

Context

Your Environment

Looking to leverage tinkerbell and boots for a metal management project to mange harvester clusters.
First iteration of seeder

  • Operating System and version (e.g. Linux, Windows, MacOS):
    Running boots and rufio on a k3s cluster on Ubuntu for test environment.
    Metal nodes are old supermicros and Dell nodes.

  • How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:

  • Link to your project or a code example to reproduce issue:

chrisdoherty4 commented

@ibrokethecloud We're unsure, right now, on whether we want the BaseboardManagement type to provide write capabilities. When modeled against jobs, they collide and you have 2 entities trying to enact desired state.

We toyed with pausing BaseboardManagement but in the interim decided to make it a read only interface. Have you thoughts toward this? What's your use-case? How would you like to interact with BMC?

ibrokethecloud commented

@chrisdoherty4 i am trying to leverage Rufio for managing some metal as part of a project named seeder.

I do think the only change to power state should be managed by the bmcjob.

I would just let the baseboardmanagement controller mark the baseboard object as "Contactable".

The user could then trigger a BMCJob to run a PowerAction of type Status to query current status.

chrisdoherty4 commented

@ibrokethecloud Thanks for the feedback. That's the current train of thought we have.