Saggi,

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

http://gerrit.ovirt.org/#/c/9345/

That try to decouple the HSM configuration parameters from the vdsm.conf and store them into a new different conf file.

Saggi Mizrahi:
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, 
vdsm-devel@lists.fedorahosted.org, "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
packages.
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
site-packages.
Would you elaborate on your position? Do you mind the wrong
implications
this may give about API stability?


_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel


--
---
舒明 Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626  Tieline: 9051626 E-mail: shum...@cn.ibm.com or 
shum...@linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, 
Beijing 100193, PRC


_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to