Re: QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management)

2020-03-05 Thread Maxim Levitsky
On Tue, 2020-03-03 at 11:18 +0200, Maxim Levitsky wrote: > On Sat, 2020-02-15 at 15:51 +0100, Markus Armbruster wrote: > > Review of this patch led to a lengthy QAPI schema design discussion. > > Let me try to condense it into a concrete proposal. > > > > This is about the QAPI schema, and therefo

Re: QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management)

2020-03-03 Thread Maxim Levitsky
On Sat, 2020-02-15 at 15:51 +0100, Markus Armbruster wrote: > Review of this patch led to a lengthy QAPI schema design discussion. > Let me try to condense it into a concrete proposal. > > This is about the QAPI schema, and therefore about QMP. The > human-friendly interface is out of scope. Not

Re: QAPI schema for desired state of LUKS keyslots

2020-02-26 Thread Maxim Levitsky
On Wed, 2020-02-26 at 08:28 +0100, Markus Armbruster wrote: > Max Reitz writes: > > > On 25.02.20 17:48, Markus Armbruster wrote: > > > Max Reitz writes: > > > > > > > On 15.02.20 15:51, Markus Armbruster wrote: > > > > > Review of this patch led to a lengthy QAPI schema design discussion. > >

Re: QAPI schema for desired state of LUKS keyslots

2020-02-25 Thread Markus Armbruster
Max Reitz writes: > On 25.02.20 17:48, Markus Armbruster wrote: >> Max Reitz writes: >> >>> On 15.02.20 15:51, Markus Armbruster wrote: Review of this patch led to a lengthy QAPI schema design discussion. Let me try to condense it into a concrete proposal. This is about the

Re: QAPI schema for desired state of LUKS keyslots

2020-02-25 Thread Daniel P . Berrangé
On Tue, Feb 25, 2020 at 05:48:02PM +0100, Markus Armbruster wrote: > Max Reitz writes: > > > On 15.02.20 15:51, Markus Armbruster wrote: > >> Review of this patch led to a lengthy QAPI schema design discussion. > >> Let me try to condense it into a concrete proposal. > >> > >> This is about the

Re: QAPI schema for desired state of LUKS keyslots

2020-02-25 Thread Max Reitz
On 25.02.20 17:48, Markus Armbruster wrote: > Max Reitz writes: > >> On 15.02.20 15:51, Markus Armbruster wrote: >>> Review of this patch led to a lengthy QAPI schema design discussion. >>> Let me try to condense it into a concrete proposal. >>> >>> This is about the QAPI schema, and therefore ab

Re: QAPI schema for desired state of LUKS keyslots

2020-02-25 Thread Markus Armbruster
Max Reitz writes: > On 15.02.20 15:51, Markus Armbruster wrote: >> Review of this patch led to a lengthy QAPI schema design discussion. >> Let me try to condense it into a concrete proposal. >> >> This is about the QAPI schema, and therefore about QMP. The >> human-friendly interface is out of

Re: QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management)

2020-02-25 Thread Max Reitz
On 15.02.20 15:51, Markus Armbruster wrote: > Review of this patch led to a lengthy QAPI schema design discussion. > Let me try to condense it into a concrete proposal. > > This is about the QAPI schema, and therefore about QMP. The > human-friendly interface is out of scope. Not because it's no

Re: QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management)

2020-02-24 Thread Maxim Levitsky
On Mon, 2020-02-24 at 14:46 +, Daniel P. Berrangé wrote: > On Mon, Feb 17, 2020 at 01:07:23PM +0200, Maxim Levitsky wrote: > > On Mon, 2020-02-17 at 11:37 +0100, Kevin Wolf wrote: > > > Am 15.02.2020 um 15:51 hat Markus Armbruster geschrieben: > > > > Review of this patch led to a lengthy QAPI

Re: QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management)

2020-02-24 Thread Daniel P . Berrangé
On Mon, Feb 17, 2020 at 01:07:23PM +0200, Maxim Levitsky wrote: > On Mon, 2020-02-17 at 11:37 +0100, Kevin Wolf wrote: > > Am 15.02.2020 um 15:51 hat Markus Armbruster geschrieben: > > > Review of this patch led to a lengthy QAPI schema design discussion. > > > Let me try to condense it into a conc

Re: QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management)

2020-02-24 Thread Daniel P . Berrangé
On Sat, Feb 15, 2020 at 03:51:46PM +0100, Markus Armbruster wrote: > Review of this patch led to a lengthy QAPI schema design discussion. > Let me try to condense it into a concrete proposal. > > This is about the QAPI schema, and therefore about QMP. The > human-friendly interface is out of scop

Re: QAPI schema for desired state of LUKS keyslots

2020-02-24 Thread Daniel P . Berrangé
On Mon, Feb 17, 2020 at 01:28:51PM +0100, Markus Armbruster wrote: > Kevin Wolf writes: > > > Am 15.02.2020 um 15:51 hat Markus Armbruster geschrieben: > >> Review of this patch led to a lengthy QAPI schema design discussion. > >> Let me try to condense it into a concrete proposal. > >> > >> Thi

Re: QAPI schema for desired state of LUKS keyslots

2020-02-17 Thread Eric Blake
On 2/17/20 6:28 AM, Markus Armbruster wrote: Proposal: { 'enum': 'LUKSKeyslotState', 'data': [ 'active', 'inactive' ] } { 'struct': 'LUKSKeyslotActive', 'data': { 'secret': 'str', '*iter-time': 'int } } { 'struct': 'LUKSKeyslotInactive', 'd

Re: QAPI schema for desired state of LUKS keyslots

2020-02-17 Thread Markus Armbruster
Kevin Wolf writes: > Am 15.02.2020 um 15:51 hat Markus Armbruster geschrieben: >> Review of this patch led to a lengthy QAPI schema design discussion. >> Let me try to condense it into a concrete proposal. >> >> This is about the QAPI schema, and therefore about QMP. The >> human-friendly inter

Re: QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management)

2020-02-17 Thread Maxim Levitsky
On Mon, 2020-02-17 at 11:37 +0100, Kevin Wolf wrote: > Am 15.02.2020 um 15:51 hat Markus Armbruster geschrieben: > > Review of this patch led to a lengthy QAPI schema design discussion. > > Let me try to condense it into a concrete proposal. > > > > This is about the QAPI schema, and therefore abo

Re: QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management)

2020-02-17 Thread Kevin Wolf
Am 15.02.2020 um 15:51 hat Markus Armbruster geschrieben: > Review of this patch led to a lengthy QAPI schema design discussion. > Let me try to condense it into a concrete proposal. > > This is about the QAPI schema, and therefore about QMP. The > human-friendly interface is out of scope. Not b

Re: QAPI schema for desired state of LUKS keyslots

2020-02-17 Thread Maxim Levitsky
On Mon, 2020-02-17 at 07:45 +0100, Markus Armbruster wrote: > Maxim Levitsky writes: > > > On Sat, 2020-02-15 at 15:51 +0100, Markus Armbruster wrote: > > > Review of this patch led to a lengthy QAPI schema design discussion. > > > Let me try to condense it into a concrete proposal. > > > > > >

Re: QAPI schema for desired state of LUKS keyslots

2020-02-16 Thread Markus Armbruster
Maxim Levitsky writes: > On Sat, 2020-02-15 at 15:51 +0100, Markus Armbruster wrote: >> Review of this patch led to a lengthy QAPI schema design discussion. >> Let me try to condense it into a concrete proposal. >> >> This is about the QAPI schema, and therefore about QMP. The >> human-friendly

Re: QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management)

2020-02-16 Thread Maxim Levitsky
On Sat, 2020-02-15 at 15:51 +0100, Markus Armbruster wrote: > Review of this patch led to a lengthy QAPI schema design discussion. > Let me try to condense it into a concrete proposal. > > This is about the QAPI schema, and therefore about QMP. The > human-friendly interface is out of scope. Not

QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management)

2020-02-15 Thread Markus Armbruster
Review of this patch led to a lengthy QAPI schema design discussion. Let me try to condense it into a concrete proposal. This is about the QAPI schema, and therefore about QMP. The human-friendly interface is out of scope. Not because it's not important (it clearly is!), only because we need to