aba...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent:
Thursday, November 29, 2012 5:22:43 PM Subject: Re: RFD: API: Identifying
vdsm objects in the next-gen API
On Thu, Nov 29, 2012 at 04:52:14PM -0500, Saggi Mizrahi wrote:
They are not future proof as the paradigm is completely
: Monday, December 3, 2012 3:30:21 PM
Subject: Re: RFD: API: Identifying vdsm objects in the next-gen API
On Thu, Nov 29, 2012 at 05:59:09PM -0500, Saggi Mizrahi wrote:
- Original Message -
From: Adam Litke a...@us.ibm.com To: Saggi Mizrahi
smizr...@redhat.com Cc: engine-de
aba...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Monday,
December 3, 2012 3:30:21 PM Subject: Re: RFD: API: Identifying vdsm objects
in the next-gen API
On Thu, Nov 29, 2012 at 05:59:09PM -0500, Saggi Mizrahi wrote:
- Original Message -
From: Adam Litke
This is all only valid for the current storage API
the new one doesn't have pools or volumes. Only domains and images.
Also, images and domains are more loosely coupled and make this method
problematic.
That being said, if we do choose to make the current storage API officially
supported I do
: API: Identifying vdsm objects in the next-gen API
On Thu, Nov 29, 2012 at 02:16:42PM -0500, Saggi Mizrahi wrote:
This is all only valid for the current storage API the new one
doesn't have
pools or volumes. Only domains and images. Also, images and
domains are more
loosely coupled
,
vdsm-devel@lists.fedorahosted.org
Sent: Thursday, November 29, 2012 4:18:40 PM
Subject: Re: RFD: API: Identifying vdsm objects in the next-gen API
On Thu, Nov 29, 2012 at 02:16:42PM -0500, Saggi Mizrahi wrote:
This is all only valid for the current storage API the new one
doesn't have
: Thursday, November 29, 2012 5:22:43 PM
Subject: Re: RFD: API: Identifying vdsm objects in the next-gen API
On Thu, Nov 29, 2012 at 04:52:14PM -0500, Saggi Mizrahi wrote:
They are not future proof as the paradigm is completely different.
Storage
domain IDs are not static any more
