It might be that the wiki page was a bit confusing. Let me articulate
it again and help others to understand the intention of this project.
1) Now, HSM files here refers to the files under "vdsm/storage" which
are storage service related code. And other VDSM files call into those
functions in HSM files in local way(different from RPC). So in the
production environment, HSM files are linked in the VDSM process and
there is no additional HSM process standing in the ovirt node.
2) This project goal is to move all the HSM files into self-contained
workspace and a new stand alone HSM process will be started from these
HSM files. Also a new HSM package will be built from this new
self-contained workspace. Also all of the HSM APIs are public to the
original VDSM service by RPC calls. It is possible that the HSM
standalone workspace and the original VDSM workspace may share some
functions in misc.py,task.py&etc. We can move those common files to
vdsm site packages as the other common files. After this goal is
achieved, we have one more HSM process in production environment and one
more release package for HSM files. For backward compatibility, vdsm
will run in two possible modes. VDSM service will try to discover if HSM
RPC APIs are available from the new HSM process. If the discovery is
successful, VDSM service will make RPC calls to the HSM process. If the
discovery fails, it will fall back the legacy way calling the HSM
functions by local way.
3) In order to achieve this goal, we should remove the preconditions
gradually and safely. The first step here is the patch
That try to decouple the HSM configuration parameters from the vdsm.conf
and store them into a new different conf file.
HSM is not a package it's an application. Currently it and the rest of VDSM
share the same process but they use RPC to communicate. This is done so that
one day we can actually have them run as different processes.
HSM is not something you import, it's a daemon you communicate with.
----- Original Message -----
From: "Dan Kenigsberg" <dan...@redhat.com>
To: "Saggi Mizrahi" <smizr...@redhat.com>
Cc: "Sheldon" <shao...@linux.vnet.ibm.com>, a...@linux.vnet.ibm.com,
email@example.com, "Zheng Sheng
ZS Zhou" <zhshz...@cn.ibm.com>
Sent: Monday, December 3, 2012 12:01:28 PM
Subject: Re: [vdsm] [VDSM][RFC] hsm service standalone
On Mon, Dec 03, 2012 at 11:35:44AM -0500, Saggi Mizrahi wrote:
There are a bunch of precondition to having HSM pulled out.
On simple things is that someone needs to go through
storage/misc.py and utils.py and move all the code out to logical
There also needs to be a bit of a rearrangement of the code files
so they can import the reusable code properly.
I am also still very much against putting core VDSM in to
Would you elaborate on your position? Do you mind the wrong
this may give about API stability?
vdsm-devel mailing list
舒明 Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
vdsm-devel mailing list