Bug 1260743 - [RFE] Move /rhev to a more standard location
[RFE] Move /rhev to a more standard location
Status: NEW
Product: vdsm
Classification: oVirt
Component: RFEs (Show other bugs)
---
Unspecified Unspecified
low Severity high (vote)
: ---
: ---
Assigned To: Nir Soffer
Raz Tamir
: FutureFeature, Reopened
Depends On:
Blocks: 1361659
  Show dependency treegraph
 
Reported: 2015-09-07 11:16 EDT by Fabian Deutsch
Modified: 2018-05-10 17:38 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Cause: Consequence: Fix: Result:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-11-26 07:29:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑future?
fdeutsch: testing_beta_priority?
ylavi: planning_ack+
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 67248 master MERGED autoconf: make data-center location customizable 2016-11-29 13:33 EST

  None (edit)
Description Fabian Deutsch 2015-09-07 11:16:01 EDT
Description of problem:
The top-level /rhev dir should be moved to some subdir, i.e. /run/vdsmd/mounts or /var/lib/vdsm or whatever - to better suite the FHS and make the adoption to all kind if image related delivery methods easier (Node, containers, ).

Often these kind of tools are already handling well known paths in an appropriate way, and no special handling for /rhev is needed.
Comment 2 Nir Soffer 2015-10-18 08:23:08 EDT
This will break compatibility with old hypervisors - migrating a vm from
new host using /var/run/vdsm/storage to old host using /rhev/data-center
will fail, since the vm is looking for its disks in /rhev/data-center.
Comment 3 Allon Mureinik 2015-12-03 11:56:25 EST
(In reply to Nir Soffer from comment #2)
> This will break compatibility with old hypervisors - migrating a vm from
> new host using /var/run/vdsm/storage to old host using /rhev/data-center
> will fail, since the vm is looking for its disks in /rhev/data-center.

Worth considering when designing RHEV 4.0.
Comment 4 Fabian Deutsch 2016-02-23 11:11:49 EST
Please consider to raise the priority again, this is an important structural change for Node.
Comment 5 Fabian Deutsch 2016-04-05 06:50:34 EDT
Any update on this one?
Comment 6 Yaniv Bronhaim 2016-08-23 09:53:33 EDT
*** Bug 1369102 has been marked as a duplicate of this bug. ***
Comment 7 Yaniv Bronhaim 2016-08-23 09:56:06 EDT
please notice "Bug 1369102 - vdsm violates FHS with /rhev" . Can we raise priority?
Comment 8 Nir Soffer 2016-08-29 11:37:13 EDT
Why do we need to raise the priority? what is the benefit of this to users?
Comment 9 Fabian Deutsch 2016-08-29 11:43:14 EDT
Just my 2ct: Some systems like ostree assume that the OS is following the FHS, non-FHS dirs like /rhev mark an exception and can not easily be handled correctly. Thus to better integrate with this it makes sense to move the dir to an FHS compliant directory.
Comment 10 Nir Soffer 2016-08-29 11:56:58 EDT
(In reply to Fabian Deutsch from comment #9)
> Just my 2ct: Some systems like ostree assume that the OS is following the
> FHS, non-FHS dirs like /rhev mark an exception and can not easily be handled
> correctly.

/rhev/data-center is a temporary directory used for mounting storage domains
and file-like directory structure for block storage domains. The directory
will be created automatically by vdsm when a host is added to a data center
on engine.

We don't need any handling from the OS. Do you know of any real issue with this
directory affecting users?
Comment 11 Fabian Deutsch 2016-08-29 12:15:59 EDT
When I was trying vdsm in an ostree tree, / was immutable (chattr +i /) which prevented the creation of /rhev
Comment 12 Nir Soffer 2016-08-29 12:31:55 EDT
(In reply to Fabian Deutsch from comment #11)
> When I was trying vdsm in an ostree tree, / was immutable (chattr +i /)
> which prevented the creation of /rhev

Looks like an ostree bug, breaking compatibility with existing packages.

We can easily fix this by making / mutable during installation, since we own the
machine :-)
Comment 13 Fabian Deutsch 2016-08-29 12:33:20 EDT
:)

Yes - That#s an easy thing to do.
Otherwise we can try to comply with the FHS, because other systems like ostree make the same assumptions - that a package is following the FHS, this would allow us to adopt vdsm quicker to other systems - which also include containers.
Comment 14 Matthew Miller 2016-09-05 11:18:46 EDT
(In reply to Nir Soffer from comment #10)
> We don't need any handling from the OS. Do you know of any real issue with
> this
> directory affecting users?

The ostree example is a good one — having standards lets packages like ostree make assumptions that will work across various software, rather than having to do a bunch of special cases. That can be extended across a lot of other user-focused cases as well: backups, disk/partition sizing, etc.

Additionally, if one package starts doing it without going through the documented exception process, it's an invitation for all sorts of other packages to do it, and after not too long we have no standard at all.
Comment 15 Nir Soffer 2016-09-05 11:49:28 EDT
I think we can do this:

4.0 Add --enable-fhs configuration, using standard location for /rhev/data-center
    this will allow packaging vdsm in platforms that require this, or new platforms
    they have no users yet, so backward compatibility is not required.
    This will be considered experimental and unsupported.
    On upstream and RHEL builds we will continue to use /rhev/data-center.

4.1 Provide an easy way to migrate vms from old system using /rhev/data-center
    to new system using fhs compliant location.
    Migrating vms from new system (using fhs) to old system will not be possible.

5.0 Make fhs the default, do not support migration from old versions.

Dan, what do you think?
Comment 16 Dan Kenigsberg 2016-09-06 03:19:40 EDT
Sounds like a sound plan.
Comment 17 Nir Soffer 2016-09-07 04:31:30 EDT
After discussion with Dan and Allon, we will need a better solution.

Users typically upgrade one or few hypervisors at a time, and expect that vms
can migrate to any hypervisor using the same cluster version, regardless of
vdsm version.

Any vdsm version supporting cluster versions 3.6 and 4.0 must be able to migrate
vm to and from any other vdsm version supporting same cluster versions.

To migrate vms to a host with different data-center location, the vm xml must be
modified on the source host using libvirt pre migration hook. Since this feature
is not available in ovirt 4.0, we cannot support FHS compliant data-center on 
any setup running ovirt-3.6 and 4.0 hypervisors.

Since we don't support mixing hypervisors of different platforms, this is not 
an issue for new platforms like Debian, using FHS compliant configuration:
https://anonscm.debian.org/git/collab-maint/vdsm.git/tree/debian/patches/paths.patch

On Fedora it seems that we have no choice but to break backward compatibility:
https://bugzilla.redhat.com/show_bug.cgi?id=1361659#c23
So we will use same setup as in Debian (/run/vdsm). Being able to upgrade
to ovirt 4.0 with some vm downtime is better then having no upgrade.

Fedora users using that want to avoid the downtime should install the upstream
builds from http://resources.ovirt.org/pub/ovirt-4.0 - they will be backward
compatible and use /rhev.
Comment 18 Yaniv Lavi 2016-12-06 06:32:13 EST
What is the status? Should this be MODIFIED?
What is the next step here?
Comment 19 Nir Soffer 2016-12-06 06:40:59 EST
(In reply to Yaniv Dary from comment #18)
> What is the status? Should this be MODIFIED?
> What is the next step here?

No, we cannot move /rhev, this will break compatibility with existing installations.
We have now a configure option enabled in the fedora build, so on fedora built
vdsm, /rhev/data-center moved to /run/vdsm/data-center.

But on ovirt, centos and rhel builds, we still use /rhev/data-center until we find
a way to support migration of vms between hosts with different data-center 
locations.
Comment 20 Yaniv Lavi 2017-11-26 07:29:22 EST
Seems risky with limited benefit.
Closing,
Comment 21 Neal Gompa 2017-11-26 22:32:55 EST
Yaniv,

There is plenty of benefit, not the least of which is that you're no longer polluting the main filesystem tree in an unexpected fashion, so things like system backups can leverage the relationships and roles of the regular FHS to properly back up data.

Moving the directory would also make it possible for oVirt to be part of Fedora itself, as well as restore compatibility with oVirt.org oVirt, Debian oVirt, and other builds derived from that branch (where they moved it due to FHS incompatibility).

Generally speaking, the /rhev path should have never been allowed to begin with. It should *not* be difficult to move the directory.

You could even check for /rhev on upgrade and just move it and symlink it back or something. That way existing installs using /rhev work, while new installs that don't use /rhev would work too.

Note You need to log in before you can comment on or make changes to this bug.