Great work!

Can you please split commit to smaller, based on subject?

I see most can be submitted today upstream.

Change to vdsm/storage/12-vdsm-lvm.rules:

You should add the owner and group to and rename the file to an 
.in suffix so that substitutes can happen. This can be merged today if defaults 
are the same.

Change to and relevant also to the above...

You should add --with-user-qemu= to autoconf, with the default of qemu, same 
for group and any change between distributions, then you can go ahead and 
configure the package properly with built.

Change to tests/functional/

I do not know the code well, but it seems like you can ask for distribution 
name and perform the assignment accordingly.

Change to tests/ requires root, so I don't think it is wise... 
better just to fail test if the configfs is not mounted, asking user to make 
sure it is.

uninstall - I am not sure it is required at all.

Why did you change the order of the udev rules?

Change to vdsm/storage/ - please detect distribution at autoconf 
and handle right service.

Change to vdsm/storage/protect/ can be submitted now.

Can you please explain change to vdsm/

I leave our the change for vdsm/, as it needs much work, but we 
can leave as last task, it requires more detection using autoconf, and call 
common script.

Thank you,

----- Original Message -----
> From: "Zhou Zheng Sheng" <>
> To: "VDSM Project Development" <>
> Sent: Wednesday, March 20, 2013 12:00:57 PM
> Subject: [vdsm] Porting and to Ubuntu
> Hi guys,
> You may notice recently I work on porting VDSM to Ubuntu. I managed
> to
> run VDSM functional tests with some hacks in the code, then I
> documented
> the hacks and try to create long term solution patches for them [1].
> I'm a bit stuck on the two files, and I
> made
> a lot of small modifications to to make it work in
> Ubuntu.
> Firstly I try to do it in the GNU autotools way to add more macros to
> this file, and make it adapt to Ubuntu. Then I find this file is
> already
> somewhat complicated, adding more macros to and this
> file
> would make it worse. So I created a separate init file for Ubuntu
> based
> on, but I find the structure and most part of the new
> file
> is the same as the original one. Dan suggests me break the init file
> into small functions and put the functions in vdsm-tool. I think this
> job may take long time and delay the process of porting VDSM. You can
> have a look at my modifications to this file at [2].
> I have another idea. I can create a vdsm-contrib sub-directory under
> the
> VDSM source directory. Then put a
> vdsm-contrib/ubuntu/ file in it. When the user
> build
> VDSM in Ubuntu, he can firstly patch the In this way
> we
> avoid creating more complicated macros and re-use the existing code.
> We
> do not have to maintain There is no promise on
> this
> file to be patched cleanly in the long term. For now I can write new
> upates for vdsm-contrib/ubuntu temporarily. Once Ubuntu accept VDSM,
> we
> have them maintain the init file. How does this plan sound like?
> As regarding to, I find there are some shell scripts to
> be
> executed during/after the installation. When I'm on Ubuntu, I grab
> the
> scripts out of vdsm.spec and run them to make VDSM work. If I want to
> create .deb files, these scripts should be re-used. Otherwise the
> spec
> file for .deb contains duplicated content from spec file for .rpm. My
> idea is crab these script out of and create standalone
> scripts
> like Then we distribute these script in vdsm
> package and invoke them after installation.
> If I could successfully port these two files, it would be a big step
> closer to my final goal. Could anyone gives me some suggestions?
> Really
> thanks.
> [1]
> [2]
> --
> Thanks and best regards!
> Zhou Zheng Sheng / 周征晟
> E-mail:
> Telephone: 86-10-82454397
> _______________________________________________
> vdsm-devel mailing list
vdsm-devel mailing list

Reply via email to