qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-block] Transactions, Jobs, and Cancellation


From: John Snow
Subject: [Qemu-block] Transactions, Jobs, and Cancellation
Date: Fri, 30 Sep 2016 12:35:21 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

Hi Eric (as a proxy for Libvirt);

I want to make a change to transactions such that they do not actually start the jobs until the entire transaction is error-checked for validity.

This would be a change from the current setup where:

- Some jobs are started
- One job cannot start
- Existing jobs are cancelled, emitting job events
- QMP transaction returns failure.

to something more like:

- Some jobs are queued to start
- One job cannot start
- Existing queued jobs are un-created
- No events are emitted, but the QMP transaction fails.

If I understand correctly, it's possible for the transaction to fail even after it has started several jobs because they begin operating during the prepare phase.

Then, because the transaction preparation has failed, QEMU will cancel the transaction instead of proceeding, which will generate some BLOCK_JOB_CANCELLED events.

This may affect libvirt and others if I change these semantics.

Does that sound appropriate to you, or would you from a libvirt perspective RATHER get events for "uncreated" jobs like you do now? I could make it do either, but I'd rather prefer to simply not emit events for jobs that didn't truly never start.

I can also begin emitting events for jobs that *actually* start if it would help to disambiguate the cases between old and new transactions.

Note: This has nothing to do with the transactional-cancel property, which only impacts what happens when jobs created by a transaction fail AFTER a successful return from qmp_transaction.

--js



reply via email to

[Prev in Thread] Current Thread [Next in Thread]