- Original Message -
From: Oved Ourfalli ov...@redhat.com
To: Ori Liel ol...@redhat.com
Cc: engine-devel engine-devel@ovirt.org
Sent: Wednesday, January 22, 2014 2:44:34 PM
Subject: Re: [Engine-devel] Application URI - saved anywhere?
- Original Message -
From: Ori Liel ol
Sorry guys, I wasn't here - big +1 from me
- Original Message -
From: Itamar Heim ih...@redhat.com
To: Einav Cohen eco...@redhat.com, Michael Pasternak mpast...@redhat.com
Cc: engine-devel engine-devel@ovirt.org, infra in...@ovirt.org
Sent: Thursday, December 19, 2013 12:00:26 PM
Subject:
When listing the application's capabilities we currently show 'permissions'
both for each version, and outside versions altogether:
GET .../api/capabilities
capabilities
permits/permits
version major=3 minor=1
href=/api/capabilities/332e3133-2e31-332e-3133-2e31332e3133
- Original Message -
From: Shubhendu Tripathi shtri...@redhat.com
To: ol...@redhat.com, Michael Pasternak mpast...@redhat.com, Sahina Bose
sab...@redhat.com
Cc: Dusmant Pati dp...@redhat.com, engine-devel engine-devel@ovirt.org
Sent: Monday, November 11, 2013 12:00:34 PM
Subject: Re:
to that,
addressing the technical difficulty
that you encountered.
Ori.
- Original Message -
From: Shubhendu Tripathi shtri...@redhat.com
To: Ori Liel ol...@redhat.com
Cc: Michael Pasternak mpast...@redhat.com, Sahina Bose
sab...@redhat.com, Dusmant Pati dp...@redhat.com, engine-devel
Shubhendu,
The problem you're describing stems from the fact that
BackendGlusterBricksResource already has an implementation of 'remove' which
recieves an object (GlusterBricks). This creates ambiguity that RestEasy can't
resolve: it has no way of deciding whether to deserialize the XML data
I am adding the ability to display and update engine configuration parameters
through the REST API.
Working on this has raised a lot of dilemmas. The one I want to focus on here
is:
Which configuration items do you think should be managed through the API?
Possible answers (you can add
- Original Message -
From: Livnat Peer lp...@redhat.com
To: Simon Grinberg si...@redhat.com
Cc: engine-devel engine-devel@ovirt.org
Sent: Thursday, July 5, 2012 8:58:20 AM
Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of
logical networks
On 04/07/12 19:49,
We need to enable passing 'used' luns for new storage-domain creation (used =
the lun is part of a VG).
We need a way in rest-api to explicitly approve the use of such luns.
Does anyone have a suggestion for a good name for such a flag, a name that
conveys: use the given luns
even if they are
- Original Message -
From: Ori Liel ol...@redhat.com
To: Yaniv Kaul yk...@redhat.com
Cc: engine-devel@ovirt.org, Simon Grinberg si...@redhat.com
Sent: Monday, June 18, 2012 3:31:07 PM
Subject: Re: [Engine-devel] 'deactivate' disk - what's the use case?
On 06/17/2012 12:44 PM, Simon
On 05/31/2012 09:04 AM, Livnat Peer wrote:
On 30/05/12 17:55, Michael Pasternak wrote:
On 05/30/2012 05:39 PM, Omer Frenkel wrote:
- Original Message -
From: Michael Pasternak mpast...@redhat.com
To: Livnat Peer lp...@redhat.com
Cc: engine-devel engine-devel@ovirt.org
Sent:
On 05/16/2012 01:16 PM, Gilad Chaplik wrote:
Hi All,
I am adding the ability to import a VM or a Template to a storage-domain,
when this VM or Template already exists in the destination storage domain.
Until now, Backend failed this. Now I want to enable the user to specify
that he wishes
On 05/16/2012 02:49 PM, Ori Liel wrote:
On 05/16/2012 01:16 PM, Gilad Chaplik wrote:
Hi All,
I am adding the ability to import a VM or a Template to a storage-domain,
when this VM or Template already exists in the destination storage domain.
Until now, Backend failed this. Now I want
for 'log_entry_id' (although I consider some of the other options
viable as well). Does someone disagree with 'log_entry_id'?
Thanks,
Ori.
- Original Message -
From: Itamar Heim ih...@redhat.com
To: Eoghan Glynn egl...@redhat.com
Cc: Ori Liel ol...@redhat.com, engine-devel@ovirt.org
Sent: Tuesday
On 05/08/2012 12:11 PM, Itamar Heim wrote:
On 05/07/2012 08:13 PM, Itamar Heim wrote:
On 05/07/2012 07:06 PM, Shireesh Anjal wrote:
On Monday 07 May 2012 02:06 AM, Ayal Baron wrote:
- Original Message -
i can't see any justification for the 'gluster' prefix,
as this is only
On 05/09/2012 11:35 AM, Itamar Heim wrote:
On 05/09/2012 11:40 AM, Michael Pasternak wrote:
On 05/08/2012 12:11 PM, Itamar Heim wrote:
On 05/07/2012 08:13 PM, Itamar Heim wrote:
On 05/07/2012 07:06 PM, Shireesh Anjal wrote:
On Monday 07 May 2012 02:06 AM, Ayal Baron wrote:
- Original
Still need to decide about this:
1) what's the name you'd give this parameter? job-id? batch-id?
flow-id? command-id? correlation-id???
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Correlation-ID feature allows 'tagging' a call to a Backend command
with a String ID, and this ID will be appended to all log messages
that result from this command.
http://www.ovirt.org/wiki/Features/TaskManagerDetailed
In REST-API, we would like to enable the user to pass a correlation-ID
- Original Message -
From: Itamar Heim ih...@redhat.com
To: Eoghan Glynn egl...@redhat.com
Cc: Ori Liel ol...@redhat.com, engine-devel@ovirt.org
Sent: Thursday, May 3, 2012 7:10:32 PM
Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID
On 05/03/2012 06:15 PM, Eoghan Glynn
The new design of logical network 'usages' collection came out a bit
problematic or shall i say annoying.
The idea is to send the entire collection elements every time a user
wants to update a single usage otherwise the missing elements will be
automatically removed from the collection.
Current summary:
There are four options for Floating-Disks modelling:
two that were previously discussed, and two that were
recently added by Livnat, using PUT. See full list of
options below.
Itamar, Geert, Einav Ori are currently pro option #1
(if anyone changed his mind - please say
I'd like us to move forward with this.
The option of using 'attach' action does not exist, because, as Eoghan
observed, we would be executing an action on an entity which doesn't exist in
the collection: (.../api/vms/{vm:id}/disks/???-no entity-???/attach)
There are two options left on the
- Original Message -
From: Ori Liel ol...@redhat.com
To: engine-devel@ovirt.org
Cc: meyer...@redhat.com, egl...@redhat.com, gjan...@redhat.com,
jhern...@redhat.com, Einav Cohen eco...@redhat.com, Roy Golan
rgo...@redhat.com, Michael Kublin mkub...@redhat.com
Sent: Wednesday, April 11
- Original Message -
From: Eoghan Glynn egl...@redhat.com
To: Ori Liel ol...@redhat.com
Cc: meyer...@redhat.com, jhern...@redhat.com, Geert Jansen
gjan...@redhat.com, Einav Cohen eco...@redhat.com, Michael Pasternak
mpast...@redhat.com, Michael Kublin mkub...@redhat.com,
engine-devel
- Original Message -
From: Jim Meyering meyer...@redhat.com
To: Ori Liel ol...@redhat.com
Cc: engine-devel@ovirt.org, egl...@redhat.com, gjan...@redhat.com,
jhern...@redhat.com, Einav Cohen eco...@redhat.com, Roy Golan
rgo...@redhat.com, Michael Kublin mkub...@redhat.com
Sent
On 04/09/2012 05:14 PM, Ori Liel wrote:
The Floating Disks feature makes disks into stand-alone entities: a given
disk may be attached to a VM (as all disks are today), or it may be not
attached to any VM, which makes it a floating disk
(http://www.ovirt.org/wiki/Features/FloatingDisk
26 matches
Mail list logo
