|
Post by mraineri on Nov 5, 2019 20:41:56 GMT
Talking about this more with the group, we think "UnavailableOffline" probably doesn't work for your case and "InTest" might make more sense. We're thinking of embellishing the description for "InTest" to also state "undergoing testing or capturing debug" (or something along those lines).
|
|
|
Post by mraineri on Nov 5, 2019 14:55:55 GMT
There's no restriction for HTTPS. HTTP POST is called out because HTTP verbs are simply just called out that way; they don't distinguish between HTTP or HTTPS. RFC7231 defines the formal HTTP methods, but it's agnostic to whether or not TLS is involved.
|
|
|
Post by mraineri on Nov 4, 2019 17:03:00 GMT
Yes, that looks like a schema bug to me; we did intend for folks to be able to define "Oem" parameters as part of the "MultipartHttpPushUri" operation.
|
|
|
Post by mraineri on Oct 31, 2019 16:01:27 GMT
That's a fair point; I can see something like that for that purpose being useful. We'll need to discuss this more in the group.
|
|
|
Post by mraineri on Oct 31, 2019 14:32:55 GMT
The Event Data portion of the IPMI SEL does not end up as an enum for that case; that data is just put into the "MessageId" string as raw hex data (for the three Event Data bytes). EntryCode is meant to only convey the higher order generic event types (not the sensor type specific event codes in chapter 42.2).
Specifically for your event, I would expect "EntryCode" to be either "Assert" or "Deassert" (depending on the event direction), and "MessageId" contains the three Event Data bytes that will decode as "Processor Presence Detected".
|
|
|
Post by mraineri on Oct 29, 2019 18:17:19 GMT
I agree that "UnavailableOffline" makes the most sense in terms of what's defined today. "InTest" might also make sense for this scenario. It might make sense to add a new state if we expect clients to behave differently based on seeing "CapturingDebug" vs some other state. Is that the expectation in the end? In your mind, do you think clients will need to respond differently for a "CapturingDebug" state over "UnavailableOffline"?
|
|
|
Post by mraineri on Oct 11, 2019 16:45:14 GMT
You're correct; this is definitely a gap in the spec at the moment. Actions should default to returning that "error" payload with messages (even in success cases), unless otherwise specified with a dedicated return type specified by the schema.
|
|
|
Post by mraineri on Oct 10, 2019 12:25:15 GMT
I would think that should be okay for defining OEM URIs for standard schemas. I'll raise that with the group.
|
|
|
Post by mraineri on Oct 8, 2019 14:38:26 GMT
The OpenAPI community should be solving this, which is why Redfish extended definitions into the OpenAPI space as of spec version 1.6.0. OpenAPI offers tooling to help automatically generate client-side code and documentation. The "Swagger Codegen" tool does list C++ as one of the supported output languages, but I'm not sure what the current state of the tool is with regards to C++ currently. We've had some successes with running the tool against the Redfish schemas in the OpenAPI format, but nothing that has completed error free so far. There seems to be more work to be done in the OpenAPI community with regards to how the spec is evolving, and some of that might drive back into Redfish for how we generate our schemas. Redfish is certainly a very complex example of OpenAPI, so I can imagine we're currently taking certain aspects of it further than envisioned. We have some information here with how one particular user has used Swagger Codegen to create a Go client: github.com/DMTF/Redfish-Tools/issues/179 . I'd really like to hear from others about their successes/issues and see if there's anything we can do in Redfish to better accommodate OpenAPI.
|
|
|
Post by mraineri on Oct 1, 2019 18:17:37 GMT
You are correct; null for a property should be blocked by a Redfish Service in a POST request. If the client doesn't have a value for a property in a new resource, I would expect the property to not even be part of the request body. We'll need to add this to the spec for clarity.
|
|
|
Post by mraineri on Aug 22, 2019 19:08:12 GMT
Redirection is not required for "/redfish/v1". Redirection is an option, but it also allows for a Service to "Treat it as the equivalent URI to the associated Redfish-defined URI".
200 OK is allowed for both URIs.
|
|
|
Post by mraineri on Aug 20, 2019 18:23:05 GMT
You're right about this. This will likely require some schema changes and we'll need to take this into the forum for further discussion and resolution.
|
|
|
Post by mraineri on Aug 5, 2019 12:15:29 GMT
At the moment there are not any other discovery protocols that we've agreed upon. However, if there's a desire for something other than SSDP, we can discuss it internally to see if it's something we can incorporate.
|
|
|
Post by mraineri on Jul 30, 2019 18:23:17 GMT
Would it be possible to please cite the security concerns around SSDP? Most of the issues we've reviewed before have been UPnP specific, and have nothing to do with SSDP. The only security concern we've seen specific to SSDP are using it for DDOS attacks, but those tend to be mitigated by settings on switches to not propagate responses to the victim.
|
|
|
Post by mraineri on Jul 23, 2019 17:01:24 GMT
Yes, please file an issue in that project to have special handling of OriginOfCondition add to the tool.
|
|