Re: [Qemu-devel] [PATCH] qapi: Reintroduce CommandDisabled error class

[Michal Privoznik]

On 8/29/19 3:12 PM, Eric Blake wrote:
> On 8/29/19 8:04 AM, Michal Privoznik wrote:
>
> > > > A bit of background: up until very recently libvirt used qemu-ga
> > > > in all or nothing way. It didn't care why a qemu-ga command
> > > > failed. But very recently a new API was introduced which
> > > > implements 'best effort' approach (in some cases) and thus
> > > > libvirt must differentiate between: {CommandNotFound,
> > > > CommandDisabled} and some generic error. While the former classes
> > > > mean the API can issue some other commands the latter raises a
> > > > red flag causing the API to fail.
> > >
> > > Why do you need to distinguish CommandNotFound from CommandDisabled?
> >
> > I don't. That's why I've put them both in curly braces. Perhaps this
> > says its better:
> >
> > switch (klass) {
> >    case CommandNotFound:
> >    case CommandDisabled:
> >          /* okay */
> >          break;
>
> So the obvious counter-question - why not use class CommandNotFound for
> a command that was disabled, rather than readding another class that has
> no distinctive purpose?

Because disabling a command is not the same as nonexistent command. 
While a command can be disabled by user/sysadmin, they are disabled at 
runtime by qemu-ga itself for a short period of time (e.g. on FS freeze 
some commands are disabled - typically those which require write disk 
access). And I guess reporting CommandNotFound for a command that does 
exist only is disabled temporarily doesn't reflect the reality, does it?

On the other hand, CommandNotFound would fix the issue for libvirt, so 
if you don't want to invent a new error class, then that's the way to go.

Michal