Backup Restore API integration feature page available.

Michael Pasternak mpastern at redhat.com
Tue Apr 23 07:23:52 UTC 2013


Hi Sharad,

On 04/22/2013 07:16 PM, snmishra at linux.vnet.ibm.com wrote:
> 
> Quoting Michael Pasternak <mpastern at redhat.com>:
> 
>> Hi Sharad,
>>
>> On 04/21/2013 01:42 AM, Sharad Mishra wrote:
>>> Hi Michael,
>>>
>>> Not sure if you had a chance to look at the backup/restore feature wiki page. Let me give you some high level idea on what I am trying to do.
>>
>> thanks for the "high level"
>>
>>>
>>> 1. When a user wants to backup a VM or disk, he/she issues a command to backup, which may look like 'backup(VM)' and 'backup(disk)'. Internally, this command is broken down
>>> to taking snapshot, preparing backup disk, making the disk available to backup server using qemu-nbd etc.
>>>
>>> 2. There will be a similar call to restore VM or disk . 'restore(VM)' and 'restore(disk)'.
>>>
>>> My question for you is, how do I go about implementing these rest apis? I need to create an RSDL, what else? Any good patches that show how to add a new call will help.
>>
>> here how it goes
>>
>> backup
>> ======
>>
>> in general we expose such capabilities in api via action, for instance
>> you can take a look on disk.activate() at [1],
>>
>> in your case this should be divided to actions on two resources vm/disk., i.e
>>
>> /api/vms/xxx/backup
>>
>> /api/vms/xxx/disks/yyy/backup
>>
>> /api/disks/xxx/backup
>>
>>
> 
> Thanks for the explanation Michael.
> 
>> q1: the last one is a disk resources that may be not attached to any vm, or on opposite
>> to be attached in 1:N relation, active/not-active etc., how do you plan to expose 'backup'
>> here (feature-wise)?
> 
> I don't think there is anything special to be done to expose backups of above mentioned devices. An unattached/1-N/active/not-active should all be treated the same for
> backup purposes. The backup will display the disk ID, alias, VMs attached to (if any) etc. for the backedup disk.
> 
>>
>> [1] http://gerrit.ovirt.org/#/c/3601/
>>
>> restore
>> =======
>>
>> q1: iiuc there will be > 1 backup to restore from (am i right?) if so, you should be
>> exposing sub-collection of backups to restore from, and we need to model this resource accordingly?
> 
> Is there any value in keeping multiple backups? I am leaning  towards just keeping the latest backup and once a newer backup is available for the VM/disk, replacing the
> older one.

the thing is that if we decide that we should allow multiple backups, api
modelling should be different, e.g

list
====

GET /api/vms/xxx/disks/yyy/backups
GET /api/vms/xxx/backups

fetch
====

GET /api/vms/xxx/disks/yyy/backups/zzz
GET /api/vms/xxx/backups/zzz

create
======

POST /api/vms/xxx/disks/yyy/backups
<backup/>

POST /api/vms/xxx/backups
<backup/>

restore
=======

POST /api/vms/xxx/disks/yyy/backups/zzz/restore
<action/>

POST /api/vms/xxx/backups/zzz/restore
<action/>

while if we have only single instance of the backup, modelling
should look like:

list
====

not available as only single backup exist

fetch
=====

not available as only single backup exist

create
======

POST /api/vms/xxx/disks/yyy/backup
<action/>

POST /api/disks/xxx/backup
<action/>

restore
=======

POST /api/vms/xxx/disks/yyy/restore
<action/>

POST /api/disks/xxx/restore
<action/>

as you can see the design is quite different, so no is
the time for supporting (or not) multiple restore points
decision.

> 
> Thanks
> Sharad
> 
>>
>>>
>>>
>>> Thanks
>>> Sharad Mishra
>>> Open Virtualization
>>> Linux Technology Center
>>> IBM
>>>
>>> Inactive hide details for Sharad Mishra---04/17/2013 04:41:10 AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 Sharad Mishra---04/17/2013 04:41:10
>>> AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 03:15:57 AM: > From: Michael Pasternak <
>>>
>>> From: Sharad Mishra/Beaverton/IBM
>>> To: Michael Pasternak <mpastern at redhat.com>,
>>> Cc: amureini at redhat.com
>>> Date: 04/17/2013 04:41 AM
>>> Subject: Re: Adding a new REST API call.
>>>
>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>>
>>> Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 03:15:57 AM:
>>>
>>>> From: Michael Pasternak <mpastern at redhat.com>
>>>> To: Sharad Mishra/Beaverton/IBM at IBMUS,
>>>> Cc: amureini at redhat.com
>>>> Date: 04/17/13 03:14 AM
>>>> Subject: Re: Adding a new REST API call.
>>>>
>>>> On 04/16/2013 11:14 PM, Sharad Mishra wrote:
>>>> > Hi Michael,
>>>> >
>>>> > I am adding a new feature to support backup and restore using ISV
>>>> packages in ovirt. As part of that work, I will be adding few new
>>>> APIs. I am not very familiar with REST
>>>> > API, can you point me to an example REST API patch that adds a new API ?
>>>>
>>>> can you give me some background for this feature?
>>>
>>> The feature page is http://www.ovirt.org/Features/Backup-Restore_API_Integration
>>>
>>> Thanks
>>> Sharad
>>>
>>>>
>>>> >
>>>> > Thanks
>>>> > Sharad Mishra
>>>> > Open Virtualization
>>>> > Linux Technology Center
>>>> > IBM
>>>> >
>>>>
>>>>
>>>> -- 
>>>>
>>>> Michael Pasternak
>>>> RedHat, ENG-Virtualization R&D
>>>>
>>>
>>
>>
>> -- 
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D



More information about the Arch mailing list