[PATCH] storage: fix vstorage backend build

[Nikolay Shirokovskiy]

On 09.07.2020 19:06, Andrea Bolognani wrote:
> On Tue, 2020-07-07 at 15:00 +0300, Nikolay Shirokovskiy wrote:
>> Add headers with declarations of  geteuid/getegid
>> and virGetUserName/virGetGroupName.
> 
> Can you share the exact error message you're hitting? Our CI seems to
> be perfectly happy with the current status quo. Specifically, the
> x86-centos-7 job, the only one which is supposed to be able to build
> the OpenVZ driver, is green.

Hi! Sure.

../../src/storage/storage_backend_vstorage.c: In function 'virStorageBackendVzPoolStart':
../../src/storage/storage_backend_vstorage.c:52:9: error: implicit declaration of function 'geteuid' [-Werror=implicit-function-declaration]
         def->target.perms.uid = geteuid();
         ^
../../src/storage/storage_backend_vstorage.c:52:9: error: nested extern declaration of 'geteuid' [-Werror=nested-externs]
../../src/storage/storage_backend_vstorage.c:54:9: error: implicit declaration of function 'getegid' [-Werror=implicit-function-declaration]
         def->target.perms.gid = getegid();
         ^
../../src/storage/storage_backend_vstorage.c:54:9: error: nested extern declaration of 'getegid' [-Werror=nested-externs]
../../src/storage/storage_backend_vstorage.c:58:5: error: implicit declaration of function 'virGetGroupName' [-Werror=implicit-function-declaration]
     if (!(grp_name = virGetGroupName(def->target.perms.gid)))
     ^
../../src/storage/storage_backend_vstorage.c:58:5: error: nested extern declaration of 'virGetGroupName' [-Werror=nested-externs]
../../src/storage/storage_backend_vstorage.c:58:20: error: assignment makes pointer from integer without a cast [-Werror]
     if (!(grp_name = virGetGroupName(def->target.perms.gid)))
                    ^
../../src/storage/storage_backend_vstorage.c:61:5: error: implicit declaration of function 'virGetUserName' [-Werror=implicit-function-declaration]
     if (!(usr_name = virGetUserName(def->target.perms.uid)))
     ^
../../src/storage/storage_backend_vstorage.c:61:5: error: nested extern declaration of 'virGetUserName' [-Werror=nested-externs]
../../src/storage/storage_backend_vstorage.c:61:20: error: assignment makes pointer from integer without a cast [-Werror]
     if (!(usr_name = virGetUserName(def->target.perms.uid)))
                    ^


> 
> Looking at the raw log[1] for the latest instance of the job, you can
> see that the vz driver is enabled (vz: yes), but the vstorage driver
> is not (Virtuozzo storage: no). From the configure output, the reason
> seems clear:
> 
>   checking for vstorage... no
>   checking for vstorage-mount... no
> 
> The CentOS 7 container that we use for builds has libprlsdk-devel and
> friends installed from the official repository[2]... Although, now
> that I look at it there's apparently a newer release[3] out, so we
> should probably switch to it.

vstorage and vz driver are quite unrelated. For the former vstorage
and vstorage-mount binaries are build requirements.

> 
> 
> Another thing: the spec file calls configure with hardcoded
> 
>   --without-vz
>   --without-storage-vstorage
> 
> and there is no binary package definition for anything like
> 
>   libvirt-daemon-driver-vz
>   libvirt-daemon-driver-storage-vstorage
> 
> which would probably be nice to have enabled at least on CentOS 7?
> Funnily enough, we actually already have
> 
>   %if 0%{?rhel}
>     %define with_vz 0
>   %endif
> 
> so clearly at some point there was the intention to conditionally
> include or exclude these drivers from the build.
> 
> 
> One thing at a time, though. First, how do we get the vstorage
> commands included in the CentOS 7 container? What packages need to
> be installed, and from what repository?

The repo is http://repo.virtuozzo.com/vz/releases/7.0/x86_64/os

vstorage binary is in vstorage-ctl package and vstorage-mount binary
is in vstorage-client package.

However vstorage binary is not used at all the driver. Also the openvz
driver for example does not check for its binaries. Probably
vstorage driver should be changed accordingly as binaries are not
build requisites.


> 
> 
> As an aside, I'm still very confused by the vz/openvz dichotomy.
> AFAICT, the latter can be (and in fact is) built unconditionally,
> but the former requires the "Parallels SDK" packages to be installed:
> baffingly enough, said SDK is obtained from the repository mentioned
> above, which just so happens to include the string "openvz" twice in
> its URL...

Yeah, naming is confusing. Basically openvz manages system containers thru
vzctl binary. Vz driver manages both VMs/containers thru single connection
using prlsdk. And originally vz driver was called parallels driver but after
company split we have to change the name. Also in the past prlsdk was only
commercially available and now times changes and both vzctl and prlsdk are
available under openvz name which is an umbrella for uncommercial projects.

Nikolay

> 
> 
> [1] https://storage.googleapis.com/gitlab-gprd-artifacts/5d/af/5daf0e5fa057744f5bfc6ec3d7ebc435b6fdcd9d40afe5a23cc67756a826d8ee/2020_07_09/631037426/692468732/job.log?response-content-type=text%2Fplain%3B%20charset%3Dutf-8&response-content-disposition=inline&GoogleAccessId=gitlab-object-storage-prd@gitlab-production.iam.gserviceaccount.com&Signature=hiC9XbFsV78D1nFcOg09WWcUAR66M2nbIECVm%2BD0tLBWMviBriGhB7eFpNL3%0A7H1bZ%2Faw0M64HaCJ8PZxw4SO6KeRkd5RZ3HC%2Ff7TWngvtKGy9xp4L9QLNcf7%0AiJVYvFQqPcDurp61C%2F%2B%2B5WNMxJq1Vl1wT6Lk0XlJlnssV59FyV4UHV3UAye%2F%0AiHrjSLcbuwbNIAu19dTAJskQroJ8hfRgAcSWDdU2%2FXWsCb19oCzpLBvwtr2T%0AIOYgLDjVCzntxu1gngIB499EDl%2B38ASB27kEFRkEDp8cEqz0wGOUstN4dAWu%0A4hH3S2%2FuXWoVoJ6ibOU%2Bh8REB1luIzVDQelJfGPblA%3D%3D&Expires=1594308539
> [2] https://download.openvz.org/virtuozzo/releases/openvz-7.0.11-235/x86_64/os
> [3] https://download.openvz.org/virtuozzo/releases/openvz-7.0.14-136/x86_64/os
>