|
Post by jautor on Apr 24, 2024 19:33:31 GMT
Yeah, I agree that appears to be a description issue. It wouldn't make sense to have more than one ConnectionMethod per aggregation source...
|
|
|
Post by jautor on Apr 16, 2024 15:56:27 GMT
Hi I understood. I am checkjing in the browser, which is https://<IDRAC-IP>/redfish/v1 and https://<IDRAC-IP>/redfish/v1/Systems, it asking for credentilas and it is working fine. And it shows some datas. So is that correct? Yes, that's correct. And you've also answered my next question, which is what type of system is this. I'll ask mraineri to chime in since he's very familiar with those systems!
Jeff
|
|
|
Post by jautor on Apr 15, 2024 23:54:55 GMT
Ok, I understand that use case - that makes sense especially given redundant sensors that are providing feedback to a control loop... We'll discuss this further.
What should the "Reading" be for a disabled sensor? We could specify that it returns NULL so there's no question that the value is invalid. Or we could specify that Reading is not returned for disabled sensors.
>> This should also be a Nullable property, not every sensor on a device should have the ability to be turned off.
Note that that is not what "Nullable" means in the CSDL schema language - that refers to the ability to return a value of NULL for the property. I think what you meant is that the property is "optional", and not required for every implementation. And that is true of almost all Redfish properties - if the property is not marked as "Required", then it is optional and can (and should!) be omitted from the payload if it is not applicable or supported by the service.
(and certainly the ability to enable/disable a Sensor would be an optional feature!)
|
|
|
Post by jautor on Apr 15, 2024 23:47:15 GMT
There is a "SensorGroup" that allows for redundant sensors to be accessed as if they were a single sensor, but that doesn't work for a Control (but it certainly could be applied to the sensor(s) that are providing the feedback loop for a Control). I'm not sure how that would work as you're showing different SetPoint values for the 4 controls. Is each of those tied to a specific humidity sensor? Is the user setting 4 individual values, because that would really feel like separate controls. But if this is just exposing the "gory details" behind the scenes - can this be represented by a single SetPoint with a set of associated Sensor(s)?
There are many cases in the model where multiple devices produce almost identical JSON payloads. But it's those few differences that are the critical values. In your example, though, there's no "context" for those 4 humidity controllers. How does a user, in an interoperable / vendor-independent manner, discover what controller #3 is doing vs. #4? It's those ties to the rest of the model that would be the difference between 4 Control resources. This is no different than 8 otherwise identical DIMMs in a server - the only differences in payload may be the serial number and the socket #...
Jeff
|
|
|
Post by jautor on Apr 15, 2024 23:34:24 GMT
In practice end-users do not want every single alarm offered to always be turned on. There are a large number of alarms on a CDU and something such as the room temperature being too high may not be of interest to a specific end-user. They would be able to go to where the specific alarm is and turn it off by writing to a "State" within the condition array to turn it off on the controller. This is something customers regularly use today. We have discussed the addition of "formal alarm handling" (and this topic was raised in one or more Work-in-Progress presentations for Power Distribution Units), but have yet to have enough expert opinions to weigh in on the topic for standardization. If there is more interest in this area, we'd welcome proposals or feedback on the previously release WIP concepts. Part of that support would certainly allow the enable/disable of individual alarms (alarm suppression being a concept in the formal handling) - but that would not be handled in the Conditions array, as the intent there is to show active conditions that require attention. Note also that individual users (clients) for a particular device can use the EventDestination subscription options to filter out particular event messages if the service provides that flexibility. I don't think that is what you were looking for, but that is something available in the standard today. Jeff
|
|
|
Post by jautor on Apr 15, 2024 16:22:17 GMT
Hi, I am new for redfish configuration. I have a physical servers, I need to configure my machine to manageiq with redfish configuration. I have added the redfish provider into the manageiq dashboard. But it shows the authentication invalid. but my username and password is correct. Why it shows an error? Kindly help me to add the redfish provider to manageiq dashboard. Thanks for advance.
Are you able to retrieve Redfish resources using those credentials via a web browser or by using CURL or POSTMAN? Some devices may have separate credentials for their Redfish interface compared to their command line or Web GUIs.
For example, can you perform a GET on `/redfish/v1` - which does not require a username/password (that is an un-authenticated resource)
And then if so, try to use your credentials to perform a GET on `/redfish/v1/Systems` and see what happens.
I'm not familiar with the Redfish provider for ManageIQ - you'll probably need to contact their support staff for product-specific questions.
Jeff
|
|
|
Post by jautor on Mar 28, 2024 14:18:10 GMT
I tried many possibilities and I rebuild the Scheme with the Schemecreator like this:
{ "@odata.type": "#ContosoSensor.v1_0_0.ContosoSensor", "UserLabel": "Airflow", "ReadingUnits" : "Data" }
Marian, It looks like you're trying to define an "airflow sensor", or at least, a digital input that has been configured with an airflow sensor or accessory attached. In our `ThermalMetrics` schema, there is a "AirFlowCubicMetersPerMinute" property that provides the airflow measurement (in cubic m/min) through a Chassis. But it appears that your implementation is just a boolean - which I assume is a "ok" vs "too low" that comes from your instrumentation? We ran into a very similar situation when defining the "water quality" sensor for the liquid cooling folks. In that case, we didn't have enough data from the vendors as to what reading those sensors actually produce - what units, what does it actually measure, etc. And so we couldn't provide (at least not yet) a Sensor model for that function. But we needed a standard mechanism to report when the quality was "bad". What we did to solve that was define a "CoolantQuality" property in a CoolingLoop to provide a simple Health-like reading of "OK", "Caution" or "Critical". Which allows us to provide that data now - and if, in the future, we add a Sensor to show some actual measurement of water quality in an interoperable way, we can still do that - and whether or not the equipment provides that level of detail, we will always have this basic answer. So if you're hitting a similar situation, where the instrumentation is just providing a "good" or "bad" value for airflow, and not a measurement, I would suggest that we add a property for "AirFlowQuality" or similar wording to the standard. As if you're hitting this, you're probably not alone and others will probably need the same functionality. Jeff
|
|
|
Post by jautor on Mar 25, 2024 16:38:08 GMT
Oh- good catch! I'll update that presentation!
|
|
|
Post by jautor on Mar 24, 2024 1:09:05 GMT
Yeah, that's a good point, we do need to add some realistic examples in the public mockups... But your understanding is correct. Conditions within the Status object is intended to report details about items that "require the attention of the operator", which may be due to something wrong shown in the resource itself, or may be a "health roll-up" item from a subordinate resource. Here's an example from the Redfish Release overview for 2020.4, when Conditions was added to the schema:
In that example, a StorageController resource is reporting an issue with its cache module, and also an attached Drive has an issue (the OriginOfCondition points to that Drive resource to get the details on that issue...)
Furthermore, since then we also crated the ServiceConditions resource, off of the ServiceRoot, to allow the service to provide a one-stop place to get any condition, service-wide, that requires user attention. (those Release presentations are also bundled up as the Redfish Release History: redfish.dmtf.org/schemas/Redfish_Release_History.pdf ) Hope that helps, Jeff
|
|
|
Post by jautor on Mar 21, 2024 4:16:15 GMT
Are you looking for the "alert" that the Emergency Shut Off has been used/triggered, or are you looking for the mechanism to initiate an emergency shut off?
For the "alert", you can use a combination of Status/Health to show a "Critical" Health of the resource, and placing a message in Status/Conditions to explain what has triggered that case. We have not defined a standard message for "Emergency Shut Down" - but that clearly is something that could be used across the industry, so we'd certainly take a look at any suggestion there to add to a Message Registry (probably belongs in both the Power and Environmental message registries).
If you want to actually initiate an emergency shut down, I'd probably suggest that it would be best implemented as an Action, with the results shown in the Status/Conditions. So to understand this correctly, an action can do a multi-step process following a POST command? i.e the Action "EmergencyStop" could be posted to the Pump resource, which will set PumpSpeedPercent to 0 and give a Condition that states the pump had an emergency stop. Yes, and that is a perfect example. We use "Actions" to allow for operations that don't nicely into the RESTful semantics, or when it just gets too cumbersome to implement or use. So yes, an Action defined for "EmergencyStop" could allow the service to do both of those things - set pump speed to zero, and place a message in Status/Conditions for "Pump Emergency Stop Initiated." (and change the Status/Health and Status/State as well). The difference there being that a PATCH to just set PumpSpeedPercent to 0 wouldn't cause any of those other responses. Yes, I just didn't include that in the example - you'd absolutely have the ability to place the DataSourceUri property within that object to point to the Control resource (it's not an @odata.id object, but still provides the URI) Jeff
|
|
|
Post by jautor on Mar 18, 2024 21:08:26 GMT
The below recommendations are made for the document DSP0268 Version 2023.1 or Redfish Data Model Specification: 1. The Control v1.3 resource currently does not have any Enable/Disable property. A True/False property for turning a control point on and off would be beneficial for organization. A Control point such as a dew sensor with its setpoint may need to be disabled by the user. If something along the lines of: “SetPoint”: <my-setpoint-variable>, “TurnOn”: <True-False> There is support for enable/disable of a Control - it's handled by the ControlMode property, but not a boolean, as that single property handles manual/automatic/user-override modes as well as "Disabled" with a single property. We combined those so that it was clear that the "state" of the control was known from a single property instead of several... Let us know if there's some description text we should add there to make it more obvious (I'm guessing it blended in with several other properties that start with "Control...") Are you looking for the "alert" that the Emergency Shut Off has been used/triggered, or are you looking for the mechanism to initiate an emergency shut off? For the "alert", you can use a combination of Status/Health to show a "Critical" Health of the resource, and placing a message in Status/Conditions to explain what has triggered that case. We have not defined a standard message for "Emergency Shut Down" - but that clearly is something that could be used across the industry, so we'd certainly take a look at any suggestion there to add to a Message Registry (probably belongs in both the Power and Environmental message registries). If you want to actually initiate an emergency shut down, I'd probably suggest that it would be best implemented as an Action, with the results shown in the Status/Conditions. In the Control schema there is a ControlLoop object that contains the PID variables. So any Control surfaced to a pump has that capability. But as currently defined (and we didn't expose a lot of Control instances - deferring those until folks ask for them and/or provide feedback like this!), those properties aren't copied into the Control excerpt that gets shown in the functional resource (like Pump) where the Control is actually used. I think for this case we could either add the ControlLoop to the existing excerpt, or create a new excerpt specifically to use when the PID information is expected to be surfaced to the user (and probably read-write). I would assume that would be a new PumpSpeedControl in Pump, which would show the SetPoint, OperatingMode, and then the PID components as ControlLoop. So something like this: { "PumpSpeedControl": { "SetPoint": 47, "OperatingMode": "Automatic", "ControlLoop": { "Proportional": 3, "Integral": 1, "Differential": 9 } }
And we'll need to discuss that property name - because I would normally say that the units (Percent) need to be in the name, but since we already have PumpSpeedPercent naming this control as PumpSpeedControlPercent may be unnecessary? Maybe just SpeedControlPercent as we're in the Pump resource. (and I remember now that we named it PumpSpeedPercent because SpeedPercent didn't feel like enough context)
Jeff
|
|
|
Post by jautor on Feb 21, 2024 21:19:40 GMT
My use case is to allow the redfish client to use the server's persistency storage to save critical data as files. There is no SSH available to the server(we block it for security) to upload and manage files. Yes, I too share the same concerns of letting the file system edits - but there should be rules & validations at the server to allow the operations without causing any security threats.
By "save critical files" do you mean items like crash dumps or debug logs? Although you say "client" - and those types of files would be created by the service/manager.
I'm not sure I understand what files a client would need to upload to the system via this interface. Unless this is for accessing a "virtual media store" or other storage repository that is owned by the BMC and exposed to the host OS?
As Mike indicated, I think the group will be very reluctant to open up a filesystem interface if it "owned" by a host operating system. But I'd want to understand the use cases before making any decision on that...
Jeff
|
|
|
Post by jautor on Feb 7, 2024 21:13:09 GMT
Yes, the Thermal schema has been deprecated, but it is still widely-implemented. It is being replaced by ThermalSubsystem.
In the new model, the properties that report "measurements" (aka a "metric") are represented as a Sensor. If the implementation supports the Sensor details, and not just the "excerpt" that exposes the Reading of that Sensor, then thresholds can be managed in the Sensor resource itself.
The functionality of Triggers is mostly contained within the Sensor resource model, and it allows the mix of thresholds with both vendor-defined and user-defined (as supported by the implementation).
Jeff
|
|
|
Post by jautor on Jan 30, 2024 15:29:01 GMT
Given the semantics of the PATCH operation on this property, you'd have to activate the power limit behind the scenes. Keep in mind, Redfish and IPMI aren't necessarily one-for-one; if you need to support both protocols, there will be cases where some operations in Redfish will cause multiple things to happen in IPMI, and vice versa. Thanks,for your quick response, now we need to support this feature from redfish side right? Given the direction of customer requirements for the power limit functionality, and the Redfish support expectations from OCP and other groups, that would be my recommendation... Relying on any IPMI-over-LAN functionality as a solution for the customer is not a good assumption at this point. Jeff
|
|
|
Post by jautor on Jan 10, 2024 1:50:42 GMT
See the relatively new (as of release 2023.2) `Decommission` Action defined in ComputerSystem v1.21 that is intended to cover this case. That action allows for portions of the system to be reset to factory defaults, or the entire unit (including user data).
Jeff
|
|