Juan Hernandez has posted comments on this change. Change subject: REST API: Adding external status to API ......................................................................
Patch Set 6: (1 comment) https://gerrit.ovirt.org/#/c/40997/6/backend/manager/modules/restapi/interface/definition/src/main/resources/api.xsd File backend/manager/modules/restapi/interface/definition/src/main/resources/api.xsd: Line 1921: <xs:sequence> Line 1922: <xs:element name="address" type="xs:string" minOccurs="0"/> Line 1923: <xs:element ref="certificate" minOccurs="0" maxOccurs="1"/> Line 1924: <xs:element ref="status" minOccurs="0" maxOccurs="1"/> Line 1925: <xs:element name="external_status" type="xs:string" minOccurs="0" maxOccurs="1"/> > Hi Juan If you decide to use the existing complex type you can still use the "external_status" name. It wouldn't be like in your example: <event> <host ...> <status> <state>error</state> </status> </host> </event> But with "external_status": <event> <host ...> <external_status> <state>error</state> </external_status> </host> </event> Fields that can have a value but aren't used are a common thing in our RESTAPI design. Think about the "Host" type that you are using, you are only using the "id" and the "external_status", but not the "name", for example. That is as confusing as using the "Status" type and not using the "detail" field. So this isn't a reason to choose one alternative over the other. The fact that the "detail" is available is a good thing, as you may in the future want to extend the external status to contain a detail, as the description of the event and the detail of the status are two potentially different things. Using the existing complex type gives more flexibility for future enhancement. You should also take into account that most RESTAPI callers will never submit events to change the status, but they will read it (from the /hosts/{host:id} resource). These read operations are more important than the write ones. If you use the existing complex type then users don't have to learn how to manage yet another "status" type, and we can (in the future) report the details of the external status. But this is a matter of opinion, so proceed as you and Ori decide. Line 1926: <xs:element name="cluster" type="Cluster" minOccurs="0"/> Line 1927: <!-- unsigned to avoid issues with port values greater than 32767, Line 1928: e.g. the standard VDSM port 54321 --> Line 1929: <xs:element name="port" type="xs:unsignedShort" minOccurs="0"/> -- To view, visit https://gerrit.ovirt.org/40997 To unsubscribe, visit https://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I833f8e607fac7107e9352a547b3e36cbf9000f01 Gerrit-PatchSet: 6 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Eli Mesika <emes...@redhat.com> Gerrit-Reviewer: Eli Mesika <emes...@redhat.com> Gerrit-Reviewer: Jenkins CI Gerrit-Reviewer: Juan Hernandez <juan.hernan...@redhat.com> Gerrit-Reviewer: Ori Liel <ol...@redhat.com> Gerrit-Reviewer: Oved Ourfali <oourf...@redhat.com> Gerrit-Reviewer: automat...@ovirt.org Gerrit-HasComments: Yes _______________________________________________ Engine-patches mailing list Engine-patches@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-patches
