On Thu, Feb 28, 2019 at 1:06 PM Marcin Sobczyk <msobczyk(a)redhat.com> wrote:
Hi,
On yesterday's vdsm weekly call, we were discussing the need of making
Python 3 vdsm RPM packages.
Some facts:
- it doesn't make a lot sense to spend much time on trying to package
everything - it's completely impossible i.e. to run vdsm without having
'sanlock' module
localfs storage works without sanlock, so we have a way to test the entire
system without sanlock. We can make sanlock configurable to be able
to build and run vdsm without it with only local storage.
But I think completing the sanlock port to python 3 will be much less work.
- our current vdsm.spec file is crap
Two non-exclusive propositions were raised:
- let's try to make a quick-and-dirty patch, that will completely
overwrite the existing 'vdsm.spec' (effectively making it Python 3-only)
for testing purposes, and maintain it for a while
- in the meantime, let's write a completely new, clean and beautiful
spec file in an package-by-package, incremental manner, (also Python
3-only) that would eventually substitute the original one
The quick-and-dirty spec file would be completely unsupported by CI. The
new one would get a proper CI sub-stage in 'build-artifacts' stage.
The steps needed to be done are:
- prepare autotools/Makefiles to differentiate Python 2/Python 3 RPM builds
- prepare the new spec file (for now including only 'vdsm-common' package)
- split 'build-artifacts' stage into 'build-py27' and
'build-py36'
sub-stages (the latter currently running on fc28 only)
The only package we can start with, when making the new spec file, is
'vdsm-common', as it doesn't depend on anything else (or at least I hope
so...).
There were also propositions about how to change the new spec file in
regard to the old one (like making 'vdsm' package a meta-package). This
is a good time for these propositions to be raised, reviewed and
documented (something like this maybe?
https://docs.google.com/document/d/13EXN1Iwq-OPoc2A5Y3PJBpOiNC10ugx6eCE72...),
so we can align the new spec file as we build it.
I can lay the groundwork by doing the autotools/Makefiles and
'build-artifacts' splitting. Gal Zaidman agreed on starting to work on
the new spec file. Milan mentioned, that he had something like the
quick-and-dirty patch, maybe he can share it with us.
Questions, comments are welcome.
Regards, Marcin
Thanks for the summary!
Nir