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" danken@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "Sheldon" shaohef@linux.vnet.ibm.com, agl@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org, "Zheng Sheng ZS Zhou" zhshzhou@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