Task Service ServiceEnabled attribute | Redfish Specification Forum

AMI_Mani
Tuna

AMI

Posts: 178

Task Service ServiceEnabled attribute Apr 7, 2019 18:09:43 GMT

Quote

Post by AMI_Mani on Apr 7, 2019 18:09:43 GMT

Hi All,
I would like to understand the details of ServiceEnabled attribute in Task Service URI
Assume many tasks was created and running when ServiceEnabled attribute was true.
When user Patches ServiceEnabled as false in Task Service URI, what will happen to all task created earlier?
Do we need to delete all tasks created?
If user request for Get task Instance, what needs to be responded when ServiceEnabled as false in Task Service URI

Thanks,
Mani

jautor
Administrator

Posts: 519

Task Service ServiceEnabled attribute Apr 16, 2019 21:37:35 GMT

Quote

Post by jautor on Apr 16, 2019 21:37:35 GMT

The short answer is that you shouldn't make the ServiceEnabled property read-write. Just have it as a read-only property (which is allowed for any read-write property in Redfish - the Service implementation doesn't have to allow write access). That was probably a mistake in our definition, but we were trying to be consistent with other "Services" being modeled in Redfish - to be able to turn the service on/off using that property.

The Task service, though, is an 'internal' service for the Manager / Redfish Service to utilize, allowing a user to disable it would not make sense...

Jeff

AMI_archerwen
Guppy

Posts: 69

Task Service ServiceEnabled attribute May 10, 2022 11:17:45 GMT

Quote

Post by AMI_archerwen on May 10, 2022 11:17:45 GMT

Hi,

So can I consider that all ServiceEnabled in every Service that under redfish/v1 can follow this rule?
Ex:
The ServicedEnabled under (1)/redfish/v1/EventService (2)/redfish/v1/SessionService (3)/redfish/v1/AccountService and more...

Thanks,
Archer.

Last Edit: May 10, 2022 11:18:14 GMT by AMI_archerwen

jautor
Administrator

Posts: 519

Task Service ServiceEnabled attribute May 11, 2022 19:00:27 GMT

Quote

Post by jautor on May 11, 2022 19:00:27 GMT

The "rule" is that the service can always implement a read-write property (as defined in schema) as read-only. That is not a global recommendation about allowing a "service" to be disabled...

While allowing a user to disable the SessionService probably doesn't make sense - there are certainly good reasons (a poorly handled event storm) that an admin might want the ability to temporarily disable the EventService.

Jeff