Re: [vdsm] Helping ovirt-3.2 run on EL6
On 01/13/2013 02:39 PM, Dan Kenigsberg wrote:
On Sun, Jan 13, 2013 at 04:40:11PM +0400, Andrey Gordeev wrote:
Hi Dan.
On Fri, Jan 11, 2013 at 12:42 AM, Dan Kenigsberg dan...@redhat.com wrote:
Hi Andrey,
I just have seen your http://www.dreyou.org/ovirt/vdsm.patch for
ovirt-3.2. I would like to thank you for your packaging and engineering
work. I'd like to incorporate as much of it into vdsm's upstream so that
it runs properly on any EL6 out-of-the-box.
Could you help me understand some of your changes?
Glad to help you.
I've posted http://gerrit.ovirt.org/#/c/10893/ which is taken from a
former patchset of yours - is it intentionally missing form the 3.2
version of your patchset?
From adf7dc96767783ab81993504267c3cfd65b4c1bb Mon Sep 17 00:00:00 2001
From: Andrey Gordeev dre...@gmail.com
Date: Fri, 7 Dec 2012 13:12:19 +0400
Subject: [PATCH 1/2] CentOS 6.2 changes
---
build-aux/pkg-version |6 +-
vds_bootstrap/setup |2 +-
vdsm.spec.in | 30 ++
vdsm/configNetwork.py |5 +
vdsm/storage/misc.py |2 +-
vdsm/vdsmd.init.in|3 ++-
6 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/build-aux/pkg-version b/build-aux/pkg-version
index 346ad23..9c410ff 100755
--- a/build-aux/pkg-version
+++ b/build-aux/pkg-version
@@ -32,7 +32,11 @@ if test x$1 = x--full; then
elif test x$1 = x--version; then
echo $PKG_VERSION | awk $AWK_VERSION | tr -cd '[:alnum:].'
elif test x$1 = x--release; then
-echo $PKG_VERSION | awk $AWK_RELEASE | tr -cd '[:alnum:].'
+if [ $LOCAL_BUILDID ]; then
+ echo $PKG_VERSION | awk $AWK_RELEASE | sed
s/git.*$/{$LOCAL_BUILDID}/ | tr -cd '[:alnum:].'
+else
+ echo $PKG_VERSION | awk $AWK_RELEASE | tr -cd '[:alnum:].'
+fi
else
echo usage: $0 [--full|--version|--release]
exit 1
diff --git a/vds_bootstrap/setup b/vds_bootstrap/setup
index 01306bd..177e089 100755
--- a/vds_bootstrap/setup
+++ b/vds_bootstrap/setup
@@ -29,7 +29,7 @@ import re
import tempfile
from time import strftime
-SUPPORTED_PLATFORMS = [ RedHatEnterpriseServer, Fedora ]
+SUPPORTED_PLATFORMS = [ RedHatEnterpriseServer, Fedora, CentOS,
Scientific, Oracle ]
I see no reason not to take this upstream
HYPERVISOR_PLATFORMS = [ RedHatEnterpriseVirtualizationHypervisor,
RedHatEnterpriseHypervisor, oVirtNodeHypervisor ]
HYPERVISOR_RELEASE_FILE = '/etc/rhev-hypervisor-release'
REDHAT_RELEASE_FILE = '/etc/redhat-release'
diff --git a/vdsm.spec.in b/vdsm.spec.in
index 465d548..a9de23d 100644
--- a/vdsm.spec.in
+++ b/vdsm.spec.in
@@ -102,8 +102,10 @@ Requires: iscsi-initiator-utils = 6.2.0.872-15
Requires: device-mapper-multipath = 0.4.9-52
Requires: e2fsprogs = 1.41.12-11
Requires: kernel = 2.6.32-279.9.1
-Requires: sanlock = 2.3-4, sanlock-python
-Requires: initscripts = 9.03.31-2.el6_3.1
+#Requires: sanlock = 2.3-4, sanlock-python
+#Requires: initscripts = 9.03.31-2.el6_3.1
These requirements are for real bugs. Better include them into your EL6
flavor
or build yourself.
Agreed with sanlock, I can build newest version from rhev rpms repo,
but initscripts packages has the different names with the same version in
different distributions i.e. 9.03.31-2.el6_3.1 - rhel
, 9.03.31-2.el6.centos.1 - centos
Too bad about the naming convention. However, it is important that
initscripts bug https://bugzilla.redhat.com/854852 is solved in that
release.
+Requires: sanlock = 2.3-1, sanlock-python
+Requires: initscripts = 9.03.31-2
Requires: mom = 0.3.0
Requires: selinux-policy-targeted = 3.7.19-80
Requires: lvm2 = 2.02.95-10.el6_3.2
@@ -431,6 +433,8 @@ install -Dm 0644 vdsm/limits.conf \
# Install the SysV init scripts
install -Dm 0755 vdsm/vdsmd.init %{buildroot}%{_initrddir}/vdsmd
install -Dm 0755 vdsm_reg/vdsm-reg.init
%{buildroot}%{_initrddir}/vdsm-reg
+install -Dm 0644 vdsm/vdsm.conf.sample \
+ %{buildroot}%{_sysconfdir}/vdsm/vdsm.conf
Federico, do you recall why don't we ship vdsm.conf on el?
# This is not commonplace, but we want /var/log/core to be a
world-writable
# dropbox for core dumps
@@ -475,6 +479,15 @@ export LC_ALL=C
/usr/sbin/usermod -a -G %{qemu_group},%{vdsm_group} %{snlk_user}
%post
+if [ -f /etc/sysconfig/modules/softdog.modules ]
+then
+cp /etc/sysconfig/modules/softdog.modules
/etc/vdsm/softdog.modules.prevdsm
+fi
+echo -e '#!/bin/sh\nmodprobe softdog\nexit 0'
/etc/sysconfig/modules/softdog.modules
+chmod +x /etc/sysconfig/modules/softdog.modules
+/sbin/chkconfig wdmd on
+/sbin/chkconfig sanlock on
+
Andrey/Federico: why is this hack required?
Really don't know, but in one of my installation on Intel Blade System, i
got error:
*VM testVm is down. Exit message: internal error Failed to open socket to
sanlock daemon: No such file or directory.*
I.e. softdog module not loaded, then I add this hack.
%{_bindir}/vdsm-tool
Re: [vdsm] RFC: New Storage API
On 12/04/2012 11:52 PM, Saggi Mizrahi wrote:
I've been throwing a lot of bits out about the new storage API and I think it's
time to talk a bit.
I will purposefully try and keep implementation details away and concentrate
about how the API looks and how you use it.
First major change is in terminology, there is no long a storage domain but a
storage repository.
This change is done because so many things are already called domain in the
system and this will make things less confusing for new-commers with a libvirt
background.
One other changes is that repositories no longer have a UUID.
The UUID was only used in the pool members manifest and is no longer needed.
connectStorageRepository(repoId, repoFormat, connectionParameters={}):
repoId - is a transient name that will be used to refer to the connected
domain, it is not persisted and doesn't have to be the same across the cluster.
repoFormat - Similar to what used to be type (eg. localfs-1.0, nfs-3.4,
clvm-1.2).
connectionParameters - This is format specific and will used to tell VDSM how
to connect to the repo.
disconnectStorageRepository(self, repoId):
In the new API there are only images, some images are mutable and some are not.
mutable images are also called VirtualDisks
immutable images are also called Snapshots
There are no explicit templates, you can create as many images as you want from
any snapshot.
There are 4 major image operations:
createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
userData={}, options={}):
targetRepoId - ID of a connected repo where the disk will be created
size - The size of the image you wish to create
baseSnapshotId - the ID of the snapshot you want the base the new virtual disk
on
userData - optional data that will be attached to the new VD, could be anything
that the user desires.
options - options to modify VDSMs default behavior
returns the id of the new VD
createSnapshot(targetRepoId, baseVirtualDiskId,
userData={}, options={}):
targetRepoId - The ID of a connected repo where the new sanpshot will be
created and the original image exists as well.
size - The size of the image you wish to create
baseVirtualDisk - the ID of a mutable image (Virtual Disk) you want to snapshot
userData - optional data that will be attached to the new Snapshot, could be
anything that the user desires.
options - options to modify VDSMs default behavior
returns the id of the new Snapshot
copyImage(targetRepoId, imageId, baseImageId=None, userData={}, options={})
targetRepoId - The ID of a connected repo where the new image will be created
imageId - The image you wish to copy
baseImageId - if specified, the new image will contain only the diff between
image and Id.
If None the new image will contain all the bits of image Id.
This can be used to copy partial parts of images for export.
userData - optional data that will be attached to the new image, could be
anything that the user desires.
options - options to modify VDSMs default behavior
return the Id of the new image. In case of copying an immutable image the ID
will be identical to the original image as they contain the same data. However
the user should not assume that and always use the value returned from the
method.
removeImage(repositoryId, imageId, options={}):
repositoryId - The ID of a connected repo where the image to delete resides
imageId - The id of the image you wish to delete.
getImageStatus(repositoryId, imageId)
repositoryId - The ID of a connected repo where the image to check resides
imageId - The id of the image you wish to check.
All operations return once the operations has been committed to disk NOT when
the operation actually completes.
This is done so that:
- operation come to a stable state as quickly as possible.
- In case where there is an SDM, only small portion of the operation actually
needs to be performed on the SDM host.
- No matter how many times the operation fails and on how many hosts, you can
always resume the operation and choose when to do it.
- You can stop an operation at any time and remove the resulting object making a distinction
between stop because the host is overloaded to I don't want that image
This means that after calling any operation that creates a new image the user
must then call getImageStatus() to check what is the status of the image.
The status of the image can be either optimized, degraded, or broken.
Optimized means that the image is available and you can run VMs of it.
Degraded means that the image is available and will run VMs but it might be a
better way VDSM can represent the underlying data.
Broken means that the image can't be used at the moment, probably because not
all the data has been set up on the volume.
Apart from that VDSM will also return the last persisted status information
which will conatin
hostID - the last host to try and optimize of fix the image
stage - X/Y (eg. 1/10) the last persisted stage
Re: [vdsm] RFC: New Storage API
On 12/07/2012 09:53 PM, Saggi Mizrahi wrote:
...
connectStorageRepository(repoId, repoFormat,
connectionParameters={}):
repoId - is a transient name that will be used to refer to the
connected domain, it is not persisted and doesn't have to be the
same across the cluster.
repoFormat - Similar to what used to be type (eg. localfs-1.0,
nfs-3.4, clvm-1.2).
connectionParameters - This is format specific and will used to
tell VDSM how to connect to the repo.
Where does repoID come from? I think repoID doesn't exist before
connectStorageRepository() return. Isn't repoID a return value of
connectStorageRepository()?
No, repoIDs are no longer part of the domain, they are just a
transient handle.
The user can put whatever it wants there as long as it isn't
already taken by another currently connected domain.
So what happens when user mistakenly gives a repoID that is in use
before.. there should be something in the return value that specifies
the error and/or reason for error so that user can try with a
new/diff
repoID ?
Asi I said, connect fails if the repoId is in use ATM.
so how do add connections to the repo without first disconnecting it
(extend storage domain flow)?
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Meeting minutes, Jan 14
Speaking attendees (no particular order): Dustin, Saggi, Adam, Douglas, Federico, Danken. Issues raised: - Saggi's amqp patches: - Saggi will resend first json_rpc patch with bug fixes - Adam will ack the series since it is sane and does not break anything useful. - Saggi's old patches: - nothing is urgently waiting for review, stay idea for future reference - FlowID is broken for storage-related bugs, and people are complaining. Douglas would take a look to please Haim and Co. - gerrit routine (Deepack asked to mention this) It is sad to loose all the acks on a patch when you rebase something below it. But if there are no changes to the patch, Danken can copy the old score. Still it would be nice if the original reviewer does it. - imperfact documentation (raised by ShaoHe Feng on list) - There is sphinx-based documentation in tree, but it is old and its build is broken. Time for someone to fix it. ShaoHe Feng, maybe? ;-) - tests/functions has examples of api usage, and it should have many more. - Debian/Ubuntu support. - Adam raises the need to have it - we are all looking forward for participation of developers/packagers of new distributions. - This may mean the end of our easy life of requiring the latest Fedora package in order to consude a new feature or avoid a bug. We may need to discover installed version of a lib/exec during runtime, like libvirt does. - ovirt-3.2 release: - no advancement in the NetworkManager front of last month - Fedora f18 branch should have code from the relatively-tested ovirt-3.2 branch, not from master. Douglas would keep it this way. - Yeela and Vered should backport their F18 blocker bugs to the ovirt-3.2 branch, and ping Federico. (iscsi_id location and udevadm settle issues). - Ongoing discussion on running vdsm for el6 - thanks for everyone who is fixing bugs there (mostly dreyou) - but please let us join forces and make this work out-of-the-box. See you again in two weeks! Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] RFC: New Storage API
- Original Message -
From: Itamar Heim ih...@redhat.com
To: Saggi Mizrahi smizr...@redhat.com
Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org,
engine-devel engine-de...@ovirt.org
Sent: Monday, January 14, 2013 6:18:13 AM
Subject: Re: [vdsm] RFC: New Storage API
On 12/04/2012 11:52 PM, Saggi Mizrahi wrote:
I've been throwing a lot of bits out about the new storage API and
I think it's time to talk a bit.
I will purposefully try and keep implementation details away and
concentrate about how the API looks and how you use it.
First major change is in terminology, there is no long a storage
domain but a storage repository.
This change is done because so many things are already called
domain in the system and this will make things less confusing for
new-commers with a libvirt background.
One other changes is that repositories no longer have a UUID.
The UUID was only used in the pool members manifest and is no
longer needed.
connectStorageRepository(repoId, repoFormat,
connectionParameters={}):
repoId - is a transient name that will be used to refer to the
connected domain, it is not persisted and doesn't have to be the
same across the cluster.
repoFormat - Similar to what used to be type (eg. localfs-1.0,
nfs-3.4, clvm-1.2).
connectionParameters - This is format specific and will used to
tell VDSM how to connect to the repo.
disconnectStorageRepository(self, repoId):
In the new API there are only images, some images are mutable and
some are not.
mutable images are also called VirtualDisks
immutable images are also called Snapshots
There are no explicit templates, you can create as many images as
you want from any snapshot.
There are 4 major image operations:
createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
userData={}, options={}):
targetRepoId - ID of a connected repo where the disk will be
created
size - The size of the image you wish to create
baseSnapshotId - the ID of the snapshot you want the base the new
virtual disk on
userData - optional data that will be attached to the new VD, could
be anything that the user desires.
options - options to modify VDSMs default behavior
returns the id of the new VD
createSnapshot(targetRepoId, baseVirtualDiskId,
userData={}, options={}):
targetRepoId - The ID of a connected repo where the new sanpshot
will be created and the original image exists as well.
size - The size of the image you wish to create
baseVirtualDisk - the ID of a mutable image (Virtual Disk) you want
to snapshot
userData - optional data that will be attached to the new Snapshot,
could be anything that the user desires.
options - options to modify VDSMs default behavior
returns the id of the new Snapshot
copyImage(targetRepoId, imageId, baseImageId=None, userData={},
options={})
targetRepoId - The ID of a connected repo where the new image will
be created
imageId - The image you wish to copy
baseImageId - if specified, the new image will contain only the
diff between image and Id.
If None the new image will contain all the bits of
image Id. This can be used to copy partial parts of
images for export.
userData - optional data that will be attached to the new image,
could be anything that the user desires.
options - options to modify VDSMs default behavior
return the Id of the new image. In case of copying an immutable
image the ID will be identical to the original image as they
contain the same data. However the user should not assume that and
always use the value returned from the method.
removeImage(repositoryId, imageId, options={}):
repositoryId - The ID of a connected repo where the image to delete
resides
imageId - The id of the image you wish to delete.
getImageStatus(repositoryId, imageId)
repositoryId - The ID of a connected repo where the image to check
resides
imageId - The id of the image you wish to check.
All operations return once the operations has been committed to
disk NOT when the operation actually completes.
This is done so that:
- operation come to a stable state as quickly as possible.
- In case where there is an SDM, only small portion of the
operation actually needs to be performed on the SDM host.
- No matter how many times the operation fails and on how many
hosts, you can always resume the operation and choose when to do
it.
- You can stop an operation at any time and remove the resulting
object making a distinction between stop because the host is
overloaded to I don't want that image
This means that after calling any operation that creates a new
image the user must then call getImageStatus() to check what is
the status of the image.
The status of the image can be either optimized, degraded, or
broken.
Optimized means
Re: [vdsm] API Documentation Since tag
- Original Message - From: Adam Litke a...@us.ibm.com To: Vinzenz Feenstra vfeen...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Friday, January 11, 2013 9:03:19 AM Subject: Re: [vdsm] API Documentation Since tag On Fri, Jan 11, 2013 at 10:19:45AM +0100, Vinzenz Feenstra wrote: Hi everyone, We are currently documenting the API in vdsmapi-schema.json I noticed that we have there documented when a certain element newly is introduced using the 'Since' tag. However I also noticed that we are not documenting when a field was newly added, nor do we update the 'since' tag. We should start documenting in what version we've introduced a field. A suggestion by saggi was to add to the comment for example: @since: 4.10.3 What is your point of view on this? I do think it's a good idea to add this information. How about supporting multiple Since lines in the comment like the following made up example: ## # @FenceNodePowerStatus: # # Indicates the power state of a remote host. # # @on:The remote host is powered on # # @off: The remote host is powered off # # @unknown: The power status is not known # # @sentient: The host is alive and powered by its own metabolism # # Since: 4.10.0 - @FenceNodePowerStatus # Since: 10.2.0 - @sentient ## I don't like the fact that both lines don't point to the same type of token. I also don't like that it's a repeat of the type names and field names. I prefer Vinzenz original suggestion (on IRC) of moving the Since token up and then have it be a state. It also makes discerning what entities you can use up to a certain version easier if you make sure to keep them sorted. We can do this because the order of the fields and availability is undetermined (unlike real structs). ## # @FenceNodePowerStatus: # # Indicates the power state of a remote host. # # Since: 4.10.0 # # @on:The remote host is powered on # # @off: The remote host is powered off # # @unknown: The power status is not known # # Since: 10.2.0 # # @sentient: The host is alive and powered by its own metabolism # ## The problem though is that it makes since a property of the fields and not of the struct. This isn't that much of a problem as we can assume the earliest version is the time when the struct was introduced. Remember that any patch to change the schema format will require changes to process-schema.py as well. -- Adam Litke a...@us.ibm.com IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] RFC: New Storage API
- Original Message -
- Original Message -
From: Itamar Heim ih...@redhat.com
To: Saggi Mizrahi smizr...@redhat.com
Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org,
engine-devel engine-de...@ovirt.org
Sent: Monday, January 14, 2013 6:18:13 AM
Subject: Re: [vdsm] RFC: New Storage API
On 12/04/2012 11:52 PM, Saggi Mizrahi wrote:
I've been throwing a lot of bits out about the new storage API
and
I think it's time to talk a bit.
I will purposefully try and keep implementation details away and
concentrate about how the API looks and how you use it.
First major change is in terminology, there is no long a storage
domain but a storage repository.
This change is done because so many things are already called
domain in the system and this will make things less confusing for
new-commers with a libvirt background.
One other changes is that repositories no longer have a UUID.
The UUID was only used in the pool members manifest and is no
longer needed.
connectStorageRepository(repoId, repoFormat,
connectionParameters={}):
repoId - is a transient name that will be used to refer to the
connected domain, it is not persisted and doesn't have to be the
same across the cluster.
repoFormat - Similar to what used to be type (eg. localfs-1.0,
nfs-3.4, clvm-1.2).
connectionParameters - This is format specific and will used to
tell VDSM how to connect to the repo.
disconnectStorageRepository(self, repoId):
In the new API there are only images, some images are mutable and
some are not.
mutable images are also called VirtualDisks
immutable images are also called Snapshots
There are no explicit templates, you can create as many images as
you want from any snapshot.
There are 4 major image operations:
createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
userData={}, options={}):
targetRepoId - ID of a connected repo where the disk will be
created
size - The size of the image you wish to create
baseSnapshotId - the ID of the snapshot you want the base the new
virtual disk on
userData - optional data that will be attached to the new VD,
could
be anything that the user desires.
options - options to modify VDSMs default behavior
returns the id of the new VD
createSnapshot(targetRepoId, baseVirtualDiskId,
userData={}, options={}):
targetRepoId - The ID of a connected repo where the new sanpshot
will be created and the original image exists as well.
size - The size of the image you wish to create
baseVirtualDisk - the ID of a mutable image (Virtual Disk) you
want
to snapshot
userData - optional data that will be attached to the new
Snapshot,
could be anything that the user desires.
options - options to modify VDSMs default behavior
returns the id of the new Snapshot
copyImage(targetRepoId, imageId, baseImageId=None, userData={},
options={})
targetRepoId - The ID of a connected repo where the new image
will
be created
imageId - The image you wish to copy
baseImageId - if specified, the new image will contain only the
diff between image and Id.
If None the new image will contain all the bits of
image Id. This can be used to copy partial parts
of
images for export.
userData - optional data that will be attached to the new image,
could be anything that the user desires.
options - options to modify VDSMs default behavior
return the Id of the new image. In case of copying an immutable
image the ID will be identical to the original image as they
contain the same data. However the user should not assume that
and
always use the value returned from the method.
removeImage(repositoryId, imageId, options={}):
repositoryId - The ID of a connected repo where the image to
delete
resides
imageId - The id of the image you wish to delete.
getImageStatus(repositoryId, imageId)
repositoryId - The ID of a connected repo where the image to
check
resides
imageId - The id of the image you wish to check.
All operations return once the operations has been committed to
disk NOT when the operation actually completes.
This is done so that:
- operation come to a stable state as quickly as possible.
- In case where there is an SDM, only small portion of the
operation actually needs to be performed on the SDM host.
- No matter how many times the operation fails and on how many
hosts, you can always resume the operation and choose when to do
it.
- You can stop an operation at any time and remove the resulting
object making a distinction between stop because the host is
overloaded to I don't want that image
This means that after calling any operation that
Re: [vdsm] RFC: New Storage API
- Original Message -
- Original Message -
From: Deepak C Shetty deepa...@linux.vnet.ibm.com
To: Saggi Mizrahi smizr...@redhat.com
Cc: Shu Ming shum...@linux.vnet.ibm.com, engine-devel
engine-de...@ovirt.org, VDSM Project Development
vdsm-devel@lists.fedorahosted.org, Deepak C Shetty
deepa...@linux.vnet.ibm.com
Sent: Sunday, December 16, 2012 11:40:01 PM
Subject: Re: [vdsm] RFC: New Storage API
On 12/08/2012 01:23 AM, Saggi Mizrahi wrote:
- Original Message -
From: Deepak C Shetty deepa...@linux.vnet.ibm.com
To: Saggi Mizrahi smizr...@redhat.com
Cc: Shu Ming shum...@linux.vnet.ibm.com, engine-devel
engine-de...@ovirt.org, VDSM Project Development
vdsm-devel@lists.fedorahosted.org, Deepak C Shetty
deepa...@linux.vnet.ibm.com
Sent: Friday, December 7, 2012 12:23:15 AM
Subject: Re: [vdsm] RFC: New Storage API
On 12/06/2012 10:22 PM, Saggi Mizrahi wrote:
- Original Message -
From: Shu Ming shum...@linux.vnet.ibm.com
To: Saggi Mizrahi smizr...@redhat.com
Cc: VDSM Project Development
vdsm-devel@lists.fedorahosted.org, engine-devel
engine-de...@ovirt.org
Sent: Thursday, December 6, 2012 11:02:02 AM
Subject: Re: [vdsm] RFC: New Storage API
Saggi,
Thanks for sharing your thought and I get some comments below.
Saggi Mizrahi:
I've been throwing a lot of bits out about the new storage
API
and
I think it's time to talk a bit.
I will purposefully try and keep implementation details away
and
concentrate about how the API looks and how you use it.
First major change is in terminology, there is no long a
storage
domain but a storage repository.
This change is done because so many things are already called
domain in the system and this will make things less confusing
for
new-commers with a libvirt background.
One other changes is that repositories no longer have a UUID.
The UUID was only used in the pool members manifest and is no
longer needed.
connectStorageRepository(repoId, repoFormat,
connectionParameters={}):
repoId - is a transient name that will be used to refer to
the
connected domain, it is not persisted and doesn't have to be
the
same across the cluster.
repoFormat - Similar to what used to be type (eg.
localfs-1.0,
nfs-3.4, clvm-1.2).
connectionParameters - This is format specific and will used
to
tell VDSM how to connect to the repo.
Where does repoID come from? I think repoID doesn't exist
before
connectStorageRepository() return. Isn't repoID a return
value
of
connectStorageRepository()?
No, repoIDs are no longer part of the domain, they are just a
transient handle.
The user can put whatever it wants there as long as it isn't
already taken by another currently connected domain.
So what happens when user mistakenly gives a repoID that is in
use
before.. there should be something in the return value that
specifies
the error and/or reason for error so that user can try with a
new/diff
repoID ?
Asi I said, connect fails if the repoId is in use ATM.
disconnectStorageRepository(self, repoId)
In the new API there are only images, some images are mutable
and
some are not.
mutable images are also called VirtualDisks
immutable images are also called Snapshots
There are no explicit templates, you can create as many
images
as
you want from any snapshot.
There are 4 major image operations:
createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
userData={}, options={}):
targetRepoId - ID of a connected repo where the disk will be
created
size - The size of the image you wish to create
baseSnapshotId - the ID of the snapshot you want the base the
new
virtual disk on
userData - optional data that will be attached to the new VD,
could
be anything that the user desires.
options - options to modify VDSMs default behavior
IIUC, i can use options to do storage offloads ? For eg. I can
create
a
LUN that represents this VD on my storage array based on the
'options'
parameter ? Is this the intended way to use 'options' ?
No, this has nothing to do with offloads.
If by offloads you mean having other VDSM hosts to the heavy
lifting then this is what the option autoFix=False and the fix
mechanism is for.
If you are talking about advanced scsi features (ie. write same)
they will be used automatically whenever possible.
In any case, how we manage LUNs (if they are even used) is an
implementation detail.
I am a bit more interested in how storage array offloads ( by that
I
mean, offload VD creation, snapshot, clone etc to the storage array
when
available/possible) can be done from VDSM ?
In the past there were talks of using libSM to do that. How does
that
strategy play in
Re: [vdsm] API Documentation Since tag
On Mon, Jan 14, 2013 at 12:37:57PM -0500, Saggi Mizrahi wrote: - Original Message - From: Adam Litke a...@us.ibm.com To: Vinzenz Feenstra vfeen...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Friday, January 11, 2013 9:03:19 AM Subject: Re: [vdsm] API Documentation Since tag On Fri, Jan 11, 2013 at 10:19:45AM +0100, Vinzenz Feenstra wrote: Hi everyone, We are currently documenting the API in vdsmapi-schema.json I noticed that we have there documented when a certain element newly is introduced using the 'Since' tag. However I also noticed that we are not documenting when a field was newly added, nor do we update the 'since' tag. We should start documenting in what version we've introduced a field. A suggestion by saggi was to add to the comment for example: @since: 4.10.3 What is your point of view on this? I do think it's a good idea to add this information. How about supporting multiple Since lines in the comment like the following made up example: ## # @FenceNodePowerStatus: # # Indicates the power state of a remote host. # # @on:The remote host is powered on # # @off: The remote host is powered off # # @unknown: The power status is not known # # @sentient: The host is alive and powered by its own metabolism # # Since: 4.10.0 - @FenceNodePowerStatus # Since: 10.2.0 - @sentient ## I don't like the fact that both lines don't point to the same type of token. I also don't like that it's a repeat of the type names and field names. I prefer Vinzenz original suggestion (on IRC) of moving the Since token up and then have it be a state. It also makes discerning what entities you can use up to a certain version easier if you make sure to keep them sorted. We can do this because the order of the fields and availability is undetermined (unlike real structs). That is not correct. These structures are parsed into an OrderedDict and the ordering is important (especially for languages like C which might use real structs). ## # @FenceNodePowerStatus: # # Indicates the power state of a remote host. # # Since: 4.10.0 # # @on:The remote host is powered on # # @off: The remote host is powered off # # @unknown: The power status is not known # # Since: 10.2.0 # # @sentient: The host is alive and powered by its own metabolism # ## The problem though is that it makes since a property of the fields and not of the struct. This isn't that much of a problem as we can assume the earliest version is the time when the struct was introduced. I don't like this any better than my suggestion. Aside from the fact that field ordering is important (in the data structure itself), this spreads the since information throughout the comment rather than concentrating it in a single place. -- Adam Litke a...@us.ibm.com IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
