On 09/18/2013 12:02 PM, Daniel P. Berrange wrote:
On Wed, Sep 18, 2013 at 11:55:39AM -0400, Cole Robinson wrote:
> On 09/18/2013 11:43 AM, Daniel P. Berrange wrote:
>> On Wed, Sep 18, 2013 at 09:38:23AM -0600, Eric Blake wrote:
>>> On 09/18/2013 09:32 AM, Cole Robinson wrote:
>>>>
>>>> Seems overkill IMO. Do we really need to add an API to facilitate the
crappy
>>>> interface that is virsh detach-device? Will any other application ever
want to
>>>> use this API?
>>>
>>> Yes, I can envision other use cases. In fact, virt-manager is one of them:
>>>
>>> Oftentimes, we add features to XML, but you don't have an easy way to
>>> probe if the feature is supported. Rather than complicate the (already
>>> large) capabilities xml to call out yet more features, it is rather
>>> simple to write up XML that tries to use the feature, then run it
>>> through the normalizing API, then look at the result. If the feature is
>>> still present in the output, then libvirt understands the feature (and
>>> you can safely use it); if the feature got stripped as unrecognized,
>>> then you can issue a much nicer error message to the user stating that
>>> the libvirtd on the other end of the connection can't honor the
user's
>>> request.
>>
>> IMHO a better way to deal with that usage scenario is to add ability
>> to validate XML via the RNG schema to the API.
>>
>> eg we should add a "validate" flag that can be passed to
virDomainDefineXML
>> / virDomainCreateXML that would enable RNG validation during parsing of
>> those APis. And possibly even have a dedicated API to request validation
>> of an XML doc in general (virt-xml-validate, but part of the API instead
>> of local CLI tool)
>>
>
> Yeah that could be useful. Though so would an API to just return the libvirt
> domain rng and let apps cache it, or parse it and use that as a poor man's XML
> capabilities and make virt-install --disk cache=? list all available cache
> modes without having to hardcode them. Granted that won't be accurate across
> hypervisors but its a start.
I would not want apps to be in the business of parsing RNG docs to
extract data. We make no guarantees about the structure of the RNG
documents being stable at all. We can arbitrarily re-structure them
at any time to suit our current needs. The only thing RNG should be
used for is validating a document. This is the reason why I also
think any tools which generate APIs based on RNG schemas are a bad
idea.
I was going on the assumption that there's a standard way using libxml to say
'parse this rng' and 'give me listed values for
/domain/devices/disk/driver@cache' but maybe that's not true.
- Cole