On 07/14/2014 10:13 PM, Liu Yuan wrote:
>>> + '*read-pattern': 'str' } }
>>
>> Raw strings that encode a finite set of values are bad for type-safety.
>> Please add an enum:
>>
>> { 'enum': 'QuorumReadPattern', 'data': [ 'quorum', 'fifo' ] }
>>
>> then use '*read-pattern': 'QuorumReadPattern'
>
> For startup command line, did it imply a change too? Sorry I'm not familiar
> with
> block-core.json.Adding an enum in the .json file will generate an enum that you can reuse in your parsing code (look at commit 82a402e99, parse_enum_option). The command line will be the same, but instead of open-coding things, you can now use the same enum as what the QMP code will use. > > With your suggestion, how we pass read-pattern via qmp? > > read-pattern: fifo > or > read-pattern: quorum The QMP wire format will be identical - the user still passes "read-pattern":"fifo" as part of building up their JSON. It's just that the string "fifo" is now validated for correctness against the enum of valid strings, instead of being open-ended anything goes. > > >> >> Should we offer multiple modes in addition to 'quorum'? For example, I >> could see a difference between 'fifo' (favor read from the first quorum >> member always, unless it fails, good when the first member is local and >> other member is remote) and 'round-robin' (evenly distribute reads; each >> read goes to the next available quorum member, good when all members are >> equally distant). > > I guess so. 'round-robin' in your context would benefit use case seeking for > better read load balance. Of course, if you do add 'round-robin', do it in a separate patch; and that's also a case where having the enum list valid modes will make it easier to add in a new mode. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
