Ori Liel has posted comments on this change.
Change subject: restapi: Added Gluster entities in REST schema
......................................................................
Patch Set 7: (5 inline comments)
....................................................
File
backend/manager/modules/restapi/interface/definition/src/main/resources/api.xsd
Line 2394: <xs:element name="volume_type" type="GlusterVolumeType"
minOccurs="1" maxOccurs="1"/>
We don't use enums in the schema. We use strings. The reason is that we and the
API to work only with primitives, so that it can be used by any client. In our
code we have the enum objects, and when the user goes to: .../api/capabilities,
we show him all options for all enums.
You can take an example from any enum; for instance look at:
/restapi-definition/src/main/java/org/ovirt/engine/api/model/StorageDomainType.java
And the code which is responsible to show the user the possible enum values is
at: BackendCapabilitiesResource
So to summarize: can you please:
1) replace all enums which you've added to api.xsd with strings
2) For each, add an actual enum object to:
/restapi-definition/src/main/java/org/ovirt/engine/api/model/
3) Add code to BackendCapabilitiesResource that shows the enum's values (the
code does not do this generically, using reflection, to all enums in the
package, so you have to add manually).
Contact me for any questions.
Line 2399: <xs:element name="access_protocols" type="xs:string"
minOccurs="0" maxOccurs="1"/>
if there can be more than one, use collection rather than delimited string. See
for example 'usages' in Network
Line 2400: <xs:element name="access_control_list" type="xs:string"
minOccurs="0" maxOccurs="1"/>
if there can be more than one, use collection rather than delimited string. See
for example 'usages' in Network
Line 2476: <xs:element ref="gluster_brick" minOccurs="1"
maxOccurs="unbounded"/>
We prefer not to limit minOccurs="1" in a collection at the schema level. If
client GETs a gluster volume which has no bricks, the de-serialization might
fail because of this constraint. Validations such as these ("the collection of
bricks in a volume is always expected to have at least one brick") are business
validations, so we prefer to have them in the code and not in the XML schema.
Line 2509: <xs:element ref="gluster_option" minOccurs="1"
maxOccurs="unbounded"/>
same comment about minOccurs="1", except this time I tend to think that it's
not true to begin with, that there must at least be one option. Apologies in
advance if I'm wrong
--
To view, visit http://gerrit.ovirt.org/3360
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I93c4df85068c3ed1ebfa35124bdfc2ae8f4482c8
Gerrit-PatchSet: 7
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Shireesh Anjal <san...@redhat.com>
Gerrit-Reviewer: Gilad Chaplik <gchap...@redhat.com>
Gerrit-Reviewer: Livnat Peer <lp...@redhat.com>
Gerrit-Reviewer: Michael Pasternak <mpast...@redhat.com>
Gerrit-Reviewer: Omer Frenkel <ofren...@redhat.com>
Gerrit-Reviewer: Ori Liel <ol...@redhat.com>
Gerrit-Reviewer: Shireesh Anjal <san...@redhat.com>
Gerrit-Reviewer: Yair Zaslavsky <yzasl...@redhat.com>
_______________________________________________
Engine-patches mailing list
Engine-patches@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-patches
